Caching and Performance Engineering · Performance and Scalability
Scaling Patterns
Stateless services, read replicas, sharding, queues and CDNs.
Scale the stateless tier horizontally behind load balancers (sessions in Redis, files in object storage). Scale reads with caches and read replicas (handle replication lag), scale writes with batching, queues and sharding/partitioning by a well-chosen key, and offload slow work to async workers. Push static and cacheable content to CDNs. Each step adds complexity — scale the bottleneck you've measured.
Evolution of a growing app
1. Single server (app + DB) → simplest
2. Separate DB; vertical scaling → more headroom
3. N stateless app servers + LB; Redis sessions → horizontal web tier
4. Cache + read replicas → read scaling
5. Queues + workers for slow tasks → lower latency, isolation
6. CDN for assets/public pages → global latency
7. Partition/shard hot tables or split services → write scaling (only when needed)
Common pitfalls
- Sharding before exhausting simpler options.
- Read-your-writes bugs from replica lag.
- Sticky sessions hiding statefulness.
Key points
- Stateless app tier scales out
- Caches/replicas for reads; queues/shards for writes
- Scale the measured bottleneck
Further reading: System Design Primer
Practice questions
How do you handle read-your-writes with read replicas?
Answer
Route a user's reads to the primary for a short time after their writes (or for specific flows), or check replica lag/LSN before reading.
What makes a good shard key?
Answer
High cardinality, even distribution of load, and alignment with the most common access patterns so most queries hit a single shard.
Open in the app to mark lessons complete, take notes and track your progress.