Replication, sharding, and CAP intuition

Leader–follower replication and read scalability

When your app gets popular, reads usually grow much faster than writes, and leader–follower replication is a classic way to handle that.

What leader–follower replication is

• You pick one node as the leader (or primary).
  • All writes go to the leader.
  • The leader is the source of truth.
• You have one or more followers (replicas).
  • They replicate the leader’s data (usually via a write-ahead log or change stream).
  • They usually serve read-only traffic.

So the flow is:

• Writes: client → leader → replicated to followers.
• Reads: client → any follower (read replica) or the leader.

How read replicas improve scalability

The bottleneck in many systems is read queries:

• Timeline / feed views
• Product catalog browsing
• Profile pages
• Search results

If you have only one node:

• That node must handle all writes + all reads.
• CPU, disk I/O, and network on that one machine limit you.

When you add, say, 4 read replicas:

• You still have 1 leader doing all writes.
• But now you can spread reads across 5 total nodes (1 leader + 4 followers, if you let the leader serve some reads too).
• Each node does only a fraction of the read work.
• You can often scale reads roughly linearly with the number of replicas (until other bottlenecks appear).

Requests that benefit most:

• Read-heavy operations:
  • GET /user/123/profile
  • GET /feed?user=123
  • GET /products?category=shoes
• Expensive analytical reads that don’t need the absolute latest data:
  • Trending posts
  • “People you may know”
  • Recommendations

These reads can go to replicas without stressing the leader.

When this pattern breaks or hurts

• Write-heavy workloads:
  • If almost every operation mutates data, the leader is still your main bottleneck, and replicas don’t help much.
• Strictly read-your-own-write flows:
  • User updates their profile picture and expects to see it immediately when the page reloads.
  • If you route that read to a lagging replica, they’ll see the old picture.
• Cross-replica transactions:
  • If you need strongly consistent reads after complex writes, reading from replicas can violate your assumptions.

Common mitigations:

• For “read your own writes”, route that user’s immediate follow-up reads to the leader for a short time.
• Mark certain endpoints as “must be strongly consistent” and always hit the leader for them.