Problem
Read-heavy workloads overwhelm primary. Write throughput must not be impacted by read load.
scalingestablished · medium operational burden
Read Replica
Also known as: replica, read-scaling, follower
Intent
Scale read throughput by replicating data to follower nodes that serve read queries, while primary handles writes.
Forces
- •Read:write ratio often 10:1 to 1000:1
- •Reads can tolerate eventual consistency (seconds)
- •Primary must remain available for writes
- •Replica lag must be monitored and bounded
Solution
✓ When to Use
- •Read-heavy workloads (analytics, reporting, user-facing reads)
- •Can tolerate eventual consistency for reads
- •Need to offload long-running queries from primary
✗ When Not to Use
- •Write-heavy workloads
- •Strong consistency required for all reads
- •Single-node sufficient
Pros
- +Linear read scale: add replicas
- +Primary protected from read load
- +Replicas can have different indexes, hardware
- +Geo-replicas for low-latency reads in region
Cons
- −Replication lag: stale reads possible
- −Replica promotion on primary failure: RTO/RPO
- −More nodes = more failure domains, backup complexity
- −Write throughput still limited by primary
Cost Profile
Infrastructure
Medium — additional replica nodes
Operational
Medium — lag monitoring, promotion drills
Cognitive
Low — well-understood
Failure Modes
Replica lag spikes → stale reads, alert fatigue
Replica OOM on long query → cascade to primary if sync
Promotion failure: data loss, split-brain
Network partition: replica diverges, needs rebuild
Real-World Examples
Alternatives
- partitioning
- caching
- materialized-view
- read-model-cqrs
Related Patterns
- partitioning
- cqrs
- materialized-view
- leader-election
Competency Domains
data statescalingreliability opseconomics evolution