How to competently increase the fault tolerance of a WEB application?

Question

linux

Hello, I have a WEB application, it is located on the same Ubuntu 18.04 server. The application is written in Node Js and works with PostgeSql, Redis databases. All requests to the server go through Cloudflare.
The essence of the question is how to increase the fault tolerance and availability of the application by hosting it on several servers. But then it is not clear to me:
1) How to distribute requests between servers;
2) How to work with PostgreSql. Work with one database or somehow synchronize several databases, each server has a copy. If with one database, then as far as I've heard, networking slows down responses from the database enough and this is not safe;
Who had a similar experience, tell me how to implement it more correctly?

Answer 1

Read about load balancing , sharding, and replication .
There is no concept of correctness, implementation depends on specific requirements. Somewhere it will be right to use horizontal sharding, somewhere vertical , and somewhere not to use at all.
Regarding balancing requests between servers, you can read this for example .

Answer 2

Two DBMS can be run in master+master mode with automatic synchronization. Two Web applications - then each should access its own DBMS and not store any data except in the DBMS. Something like this.

Answer 3

increase the reliability of the application by hosting it on multiple servers

And you solve the problem that you originally stated. For hot spare, no balancing is needed, from the base there is a simple hot standby replica.
If you need to bring the main server up, you raise the replica of the database to the new master and work as on the old server.
For a budget web, the painful question is "how to quickly transfer user requests to the desired IP." Through DNS, even with a small TTL, it's still long. Check with your host and Cloudflare once you use it to see if they have a suitable solution.
At the time of network latency, there is no escape from this. Within one rack can be neglected.
Security - of course, you will need to think about this when setting up.

Answer 4

The essence of the question is how to increase the reliability of the application by hosting it on several servers.

I would start by analyzing the reasons for a down site - to see if using multiple servers will improve reliability. In many cases this is not the case. For example - problems at a hoster. Then you have to move on to something else. For example - the database service is down. Then you need to properly configure it, optimize queries, etc.
Several servers help to protect against a hardware problem on a particular server (which happens very rarely), plus in certain cases to solve the scale problem.
It will cost money - both for servers and for the implementation of the solution. And if implemented incorrectly, this can degrade reliability.
So I advise you to return to the question - why is the site unreliable now?

Answer 5

In short :
Every server is a database client for everyone else. When the data changes, it accesses all databases asynchronously at once, and as soon as it receives the same responses from all, it returns control to the script.
Statics and scripts - work on the same server.

Answer 6

In most cases, moving a single-node application to multi-node will only degrade the performance of your application. Or you will actually re-engineer your application while adapting it to multi-node.
The world has changed a long time ago. Single node applications are very rare. Either your application uses the services of other applications (nodes), or sooner or later it will provide its services to other applications (nodes). Hence the requirement to develop your application immediately multi-node. A multi-node application can in a particular case be operated in a single-node variant.
To create a productive application, you need to purposefully save at once and on everything at the application development stage along the entire call chain: client -> network -> software layers of your application -> network -> database or other node -> network -> software layers of your application - > network -> client (not the most "complicated" chain)! The unjustified loss of several milliseconds in each link of this chain can bring you "at the exit" to the loss of several or tens of seconds.
In order to navigate where the performance failure occurred in the application, you need to have some kind of meters for different elements of the call chain. I think it's a good idea to return at least some of the most critical "measurements" in the request response. This greatly simplifies diagnosing the problem, especially in distributed (multi-node) applications, just look at the result of the query.