Master-Slave Replication

Every time you browse Twitter, watch Netflix, or scroll Instagram, you're reading from a replica. The data you see wasn't fetched from the primary database, it was served by one of dozens (or hundreds) of read replicas sitting behind the primary.

This is master-slave replication, more commonly called primary-replica replication in modern terminology. One server handles all writes. Multiple servers handle reads. It's the backbone of nearly every web application that outgrows a single database server.

The reason it's so widespread: it matches real-world traffic patterns perfectly. Most applications are 90-99% reads and 1-10% writes. If your primary can handle 5,000 writes per second and you need to serve 100,000 reads per second, you don't need a faster primary, you need 20 read replicas.

This is the first replication topology most engineers encounter, and it's the one you'll use most often in your career. Let's understand it deeply.

The flow is straightforward:

Writes (always go to the primary):

1. Client sends INSERT/UPDATE/DELETE to the primary
2. Primary executes the write, stores it locally
3. Primary records the change in a replication log (called binlog in MySQL, WAL in PostgreSQL)
4. The replication log is streamed to all replicas
5. Each replica reads the log and applies the same changes to its own copy of the data

Reads (go to any replica or the primary):

1. Client sends SELECT to a replica (or the primary)
2. The server executes the query against its local data
3. Returns the result

The replication log is the key mechanism. It's an ordered sequence of every change that happened on the primary. Replicas don't need to re-parse SQL or re-execute transactions, they just replay the log entries in order. This is called log-based replication and it's how PostgreSQL, MySQL, MongoDB, and most SQL databases implement it.