Data Persistence
Distributed Database
Master-slave Architecture

Master-slave Architecture

Many systems experience heavy read workloads, where read operations significantly outnumber write operations. To meet this demand, we can design a database architecture with a single writer (Primary) and multiple readers (Replicas).

  • The writer propagates changes to the replicas.
  • The replicas can serve read requests independently, reducing the load on the primary and improving read scalability.
Client (Write)Database clusterClient (Read)PrimaryReplica 1Replica 2ReplicateReplicateWriteReadRead

This setup is commonly known as the Master-slave architecture (good name 🧐).

Multi-master

Now, what happens if we allow multiple writers?

Database clusterMaster 1Master 2Replica 1Replica 2

The Master-slave model is most widely adopted in SQL databases, as a single writer makes it easier to maintain strong consistency for ACID transactions.

Because of this, multi-master setups are rarely used in this context:

  • They cannot replicate asynchronously without risking violations of ACID principles.
  • On the other hand, if the masters continuously coordinate to maintain ACID , they must compromise availability, and operations spanning multiple nodes become extremely complex.

Centralized Cluster

The Master-slave model is often deployed with a centralized registry, that stores and facilitates the exchange of cluster membership information.

Database clusterMasterReplica 1Replica 2Registry

The master can be selected in several ways:

  • Through manual assignment by administrators.
  • Through a voting process: members can communicate through the store to reach agreement.

Selecting the node with the most up-to-date data is a common strategy. For example:

  • The master node becomes unresponsive.
  • The replicas put themselves forward through the registry to become the new master.
  • Replica 2 then becomes the new master because it holds newer data than Replica 1.
Database clusterDatabase clusterMasterReplica 1Replica 2RegistryNew master (from Replica 2)Replica 1RegistryDownLast record at 00:10Last record at 00:20

Reverse Proxy

Having clients connect directly to all servers does not make sense. Instead, we should place a reverse proxy in front of them. Since each server has a predefined role (master or replica), the proxy can:

  • Route write requests to the master.
  • Distribute read requests across replicas to balance the load.
Database clusterClientMasterReplica 1Replica 2ProxyWriteReadRead

Problems

The Master-slave model is simple and intuitive. Each component has a well-defined role, and the direct communication between nodes results in low latency.

However, this simplicity conceals several issues, most of which stem from the centralized control of the master server:

  • The master becomes the Single Point of Failure . Its failure halts all write operations; therefore, the Master-slave model does not guarantee High Availability .

  • The master quickly becomes a performance bottleneck, especially in write-heavy applications.

In the next section, we’ll examine this challenge in more detail and explore a decentralized approach to building robust database clusters.

Last updated on
Distributed DatabasePeer-to-peer Architecture