Leader-Follower Replication
One writable leader, several read-only followers kept in sync.
StarterDataPlatform
All writes go to a single leader node, which streams its write-ahead log to one or more followers. Followers serve reads and stand ready to be promoted if the leader fails.
When to use it
- You need read scaling and a straightforward path to failover, without full multi-master complexity
- Writes fit comfortably on a single node's throughput
Trade-offs
- Followers lag the leader, so reads from them can be stale
- Promoting a follower after a leader failure needs an agreed, tested procedure
Components used
Managed App ServiceRelational Database
How it works
- One node accepts all writes and streams its change log to followers, which apply the same changes in the same order.
- Followers serve reads and stand ready to be promoted if the leader fails.
- Synchronous replication to at least one follower bounds data loss; fully asynchronous replication is faster but can lose recent writes on failover.
Used in the wild
- The default high-availability configuration for most relational databases.
- Read scaling combined with automatic failover.
- Maintaining a synchronous local replica plus asynchronous remote ones.
Good to know
- Split-brain — two nodes both believing they lead — is the catastrophic failure mode. Quorum-based election or an external fencing mechanism is what prevents it.
- The terminology shifted from master/slave to leader/follower or primary/replica across most major projects during 2018–2020.
Related patterns
Retrieval-Augmented Generation (RAG)
Ground an LLM's answers in retrieved, up-to-date, private documents.
Vector Search + Rerank
Cheaply retrieve a broad candidate set, then precisely re-rank the top results.
Model Serving with A/B Testing
Route inference traffic across model versions to compare live performance.
Feature Store
Compute features once, serve them consistently to training and inference.