Traffic distribution

Your promise is quite understandable, but it is no good at all (if I don’t forget, I’ll write down a little bit below why) You have a performance problem, the basic Wishlist "It is necessary that there are no lags," which degenerated into additional Wishlist "server under A, server under B, server under C". But all of this remains a Wishlist (business goals, if you will), but not suggestions for implementing and fixing the problem.

Formally, you have two approaches to solving a performance problem. The first, cheap, is to cast the project with iron (scaling), the second, expensive, is to directly eliminate the problem. As the developer’s competence grows, he learns to solve the problem in the second way, but somehow there are limits that the application cannot physically force the application to work (or make senseless in terms of resources to spend) and it is cheaper to leave the project with additional iron. Judging by the description of the problem, I’m sure that it’s actually easier and better to solve it not through scaling, but through direct editing of the code, especially since you are already going to share files, an application and a mobile application, but you just need to work in a couple of places.

Scaling itself is of three kinds. Usually they talk about vertical scaling (increasing the capacity of servers with the application) and horizontal scaling (increasing the number of servers and the separation of the load between them). The third way, which does not quite relate to scaling, is expensive and not always possible - it is to divide the application into subapplications and spread to different servers (this is what you are going to do now). If yours is burning, the easiest way is to scale vertically and take time out to solve architecture problems. Regarding the proposed scheme - this is why it does not take off:

• You are about to make changes to the application right now. It threatens with notable technical debt, high costs and zero exhaust, with the exception of sad experience.
• I do not really understand the "bias in the rapid distribution of files." Physically, what is it like? Buy ssd? If so, why is there a separate server for this?
• Suppose, after moving to a server with a mobile application, 5% of the load was transferred, which the main server did not notice. Puff, so much work and all for nothing.
• And, finally, why divide the mobile and regular versions at all if they give the same content, and therefore will have the same challenges and brakes?

In any case, to deal with the brakes, you need to find out what exactly slows down. Without it, you can (and are going to) waste a lot of resources. You need to start with an audit, identify the real cause of the loss of productivity, and not the problem itself, and then think about how to solve it. You are now going to do the following things:

• "Scale" static by moving to a separate server. Suppose that the problem is in statics - in this case, the brakes will not go anywhere, but you are already spending three times more. And adding a server for statics just won't work out - you need to either evenly share the statics between the servers, or store a full copy of all the statics on each server. And in the first case, the application does not know from which server it should pick up a specific file, in the second you will plunge headlong into the problem of finding unreplicated files in a 500 GB array.
• "Scale" application. Is it ready for it? Are you ready for the fact that on the mobile application and the usual there will be different user sessions? What if the script creates a file during request A, then request B to work with this file will come to a completely different server?

Summarizing all the above, I would recommend:

• Conduct an audit, draw an application diagram, identify critical places (what does not scale? What slows down under load? What falls off under load?), Find brakes
• Solve the problem of brakes from the code. Believe me, it is there, modern processors process just incredible amounts of data per second, if you give them the correct code.
• Prepare an application for horizontal scaling, so that next time not to make a garden.
• Transfer all work with statics to the cloud (Amazon S3, Swift and analogues). This will save your servers from file requests (you can take a smaller disk and network) and from the problems described above with static scaling (let S3 do it)
• Put a cheap server with Nginx / HAProxy as a layer that will serve the pool of application servers. In the case of an alarm, you can add one more equivalent server to this pool to scale horizontally.

"In general," such problems are solved precisely by a pool of equivalent servers with identical copies of the application. But the applications themselves before this, of course, are written with the thought of such use.