Read-Heavy vs Write-Heavy: A Design Checklist
Questions I ask before choosing caching, replication, or sharding — a reusable checklist from five system designs.
Every system design doc should answer these before picking infrastructure.
Read-Heavy Signals
- Read:write ratio above 10:1
- Same keys queried repeatedly (catalog, config, user profiles)
- Stale reads acceptable for minutes, not hours
Typical moves: CDN, Redis cache, read replicas, materialized views.
Write-Heavy Signals
- Append-only event streams
- Strong consistency on every write
- Contention on hot rows (inventory, balances)
Typical moves: Partitioning, queue-based ingestion, CQRS with async projections.
The Questions
- What is the acceptable staleness window for reads?
- Can we lose in-flight writes on node failure?
- Where is the single writer bottleneck today?
- Does query pattern change by an order of magnitude seasonally?
If you cannot answer #1, you are not ready to pick a cache TTL.
trade-offs , checklist , design · PostgreSQL , Redis