Start with the decision#
Scale reads only after naming the access path, freshness requirement, and skew. Replicas, caches, CDNs, and partitions remove different work from the primary; each also creates a place where data can be stale or missing.
Mechanism and state flow#
- Measure read rate, key popularity, payload size, latency target, and tolerated staleness by access path.
- Serve immutable public bytes at the edge and reusable query results from a bounded application cache.
- Route eligible queries to replicas while writes and read-after-write paths remain on the authoritative store.
- Partition when one database cannot own the total dataset or read throughput, and preserve a route to the owning partition.
- Observe hit ratio, replica lag, origin load, hot keys, and correctness - not just aggregate latency.
Concrete example#
Product pages with inventory
Cache product description and images at the edge, cache a bounded product projection near the API, and read catalog searches from replicas. Fetch inventory and checkout eligibility from an authoritative path because stale availability changes the purchase decision.
Architecture consequence: Split the response by freshness semantics instead of assigning one cache policy to the whole page.
Trade-offs#
| Option | Choose when | Cost or limit |
|---|---|---|
| Cache | Requests repeat and bounded staleness is acceptable. | Invalidation, stampedes, and hot keys become correctness and capacity work. |
| Read replicas | Queries can tolerate replication lag and the write primary has read pressure. | Read-after-write and failover routing need an explicit policy. |
| Partitioned reads | A stable key can route work across independently scalable owners. | Cross-partition queries and rebalancing become application concerns. |
Failure diagnosis#
- Failure
- A newly changed product is immediately read from a lagging replica and the cache stores the old version.
- Impact
- Staleness outlives the replica lag and may drive an incorrect user action.
- Detection
- Version-aware logs show the cache fill used an older commit or entity version than the write response.
- Mitigation
- Use primary reads or version tokens for read-after-write paths, and reject cache fills older than the known version.
- Trade-off
- Stronger freshness sends more traffic to the authoritative store.
Design checkpoint#
Work the scenario before revealing the checklist
- Classify each field in a product response by freshness tolerance.
- Choose an owner, key, TTL, and invalidation signal for every cacheable projection.
- Define the read-after-write path and a replica-lag threshold that removes replicas from eligible traffic.
- Estimate the origin load if every cache layer misses at once.
Use these prompts to extend the design. The useful answer is a reasoned change, not a memorized sentence.
- Which reads require the latest committed value?
- What happens during a cache flush or replica failover?
- How do you prevent one popular key from overloading a node?
- Which metric proves the primary was actually relieved?
Related practice problems
Use the manifest-backed prompts below to apply this lesson in a complete design.
- PostgreSQL warm standby and replicationPostgreSQL Documentation
- Caching challenges and strategiesAmazon Builders' Library
Sources reviewed 2026-09-04. Service limits and product-specific guarantees still require current verification.