A
A
Aidar Khayatov2018-11-29 09:41:42
Software design
Aidar Khayatov, 2018-11-29 09:41:42

How to configure server architecture?

Good afternoon!
It is planned to develop a loaded project - and now we are planning the architecture. we will use nginx + php fpm
The application can be divided into 3 main parts (mysql database, backend api, frontend js).
Please advise how to properly organize the installation of these three parts, given that the load on the project will grow over time and you will need to think about scaling (for example, replication). Are all three parts put on one server? Or is it better to separate it somehow?

Answer the question

In order to leave comments, you need to log in

1 answer(s)
S
stratosmi, 2018-11-29
@Haiatov

The architecture is not configurable.
The architecture is created, developed.
Join Devman
Replication is not for actual scaling, but for reliability. In a responsible project, replication should be done immediately. Even when there is no load.
There are 2 ways:
Horizontal scaling, and vertical scaling.
Vertical scaling uses iron much more efficiently as long as there is enough iron in the face of a single server. Yes, put all parts on one server.
Horizontal scaling implies the organization of interaction between different servers. But on which you do not have a DBMS on one at all, but a backend on the second.
And when you have a lot of DBMS, a lot of backends hosted on different servers.
And you will not get by with simple replication here. You will need to somehow organize the interaction between these parts. Typically - through MQ.
Thus, if you immediately plan the wildest scale that you cannot handle on a single server, then you immediately need to do this so that you can freely increase the number of backends and DBMS and at the same time they do not interfere with each other.
Typical:
Which backend will the next request be sent to? You need either a sticky session or a complete lack of state on the backend (and the second is bad for performance).
Typical:
Replications? Ha. Replication the master master - that still hemorrhagic. And master-slave replication implies that you have exactly one DBMS loaded for writing.
Further:
Managed to cope with all this, horizontally scaling perfectly. And now you have dozens of servers. The more iron - the more falls, the more service discovery. And how will you resolve it? Pens? So it's time to think about orchestration.
Etc. etc.
IMHO, since you have no idea what you are getting into at all, just use vertical scaling on one server. And replication as a backup.
It is wise to separate the DBMS and the backend. Because it immediately increases the overhead for each call. A network is added between the DBMS and the backend. If you still do not understand why to share - then do not share.

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question