Summary
Read-heavy API workloads that need full SQL query flexibility on every read, not just a fixed set of pre-computed or cached lookups, benefit from read replicas: every replica is a complete copy of the primary, so any query the primary can answer, a replica can answer too, at the cost of a bounded replication-lag staleness window instead of a cache TTL or refresh-interval staleness window.
Evidence
- ·read_heavy_api recommends read_replica directly, listed first among recommended_patterns (workloads/read_heavy_api.yaml)
- ·read_heavy_api's session consistency_requirement tolerates read_replica's applicable_when condition of eventual consistency via replication lag (workloads/read_heavy_api.yaml, patterns/read_replica.yaml)
- ·read_heavy_api's range_scan access pattern needs full query-engine flexibility that a replica provides and a fixed cache key or pre-computed view does not (workloads/read_heavy_api.yaml, patterns/read_replica.yaml)
Operational Context
- ·Preferred over cache_aside or materialized_view when reads are ad hoc or highly varied — a replica answers any query the primary can, while a cache or materialized view only accelerates the specific access pattern it was built for
- ·Preferred over materialized_view when exact, non-aggregated rows are needed — a replica serves the same row-level data as the primary, not a pre-computed summary
Tradeoffs
- ·Provides no read-latency improvement by itself: a replica still executes the full query, unlike a cache hit or a pre-computed materialized-view read
- ·Introduces replication-lag risk (replica_divergence, replication_lag_cascade) as its distinct failure mode, separate from cache_aside's TTL-staleness or materialized_view's refresh-staleness
Evidence grounding
Grounded, 3 supporting itemsread_heavy_api already lists read_replica as its first recommended pattern (workloads/read_heavy_api.yaml); this relationship makes the underlying condition explicit rather than leaving the recommendation unexplained.