Scaling your Backend: Database (Master - Slave Replication)

Scaling your Backend: Database (Master - Slave Replication)

When you notice that your server is taking more time to respond to the client, your first step should be to find out any wrongly written slow performing code on the API server. If all checks out well, next you look at any slow performing database queries. Generally, queries can be optimized by reducing unnecessary joins or by adding indexes where required (too many indexes can slow down write operations).

After performing these checks and fixing these if you still want to improve speed then the next step would be to upgrade your database server because in a typical web app, databases become the bottleneck, so databases should be the first which should be scaled vertically.

After you hit the vertical limit of the server, your next step would be to scale horizontally. Databases are usually read heavy, having a read to write ratio of approximately 90:10. The easiest and best way to scale such a database would be to adopt master slave replication architecture. In this setting, all writes are applied to the master database and all reads go to slave databases. We can have any number of slave replicas as we need. Writes happening at master are synchronized to slave databases in a few milliseconds. In a case when the Master database goes down, one of the slave database is promoted to master using the leader election algorithm.

There are 3 types of Replication Strategies, you can choose one of them depending on your use case:

Synchronous Replication:

In Synchronous Replication, once the Master node updates its copy of the data, it initiates the write operation on its replicas. Once the Replicas receive the update, they apply the change to their copy of data and then send the confirmation to the Master. Once the Master receives the confirmation from all the Replicas, it responds to the client and completes the operation.

Asynchronous Replication:

In Asynchronous Replication, once the Master node updates its copy of the data, it immediately completes the operation by responding to the Client. It does not wait for the changes to be propagated to the Replicas, thus minimizing the block for the Client and maximizing the throughput.

Semi-synchronous Replication:

In Semi-synchronous Replication, which sits right between the Synchronous and Asynchronous Replication strategies, once the Master node updates its copy of the data, it synchronously replicates the data to a subset of Replicas and asynchronously to others.