Many user-facing applications are read-heavy. A small number of users create posts, listings, videos, or articles, while a much larger group reads or views them. In these systems, the read-to-write ratio is commonly 100:1 and can run far higher for popular content.

This creates a familiar scaling problem. The primary database is the source of truth, but it is usually the most expensive place to serve repeated reads from. A single database instance might handle thousands or tens of thousands of simple queries per second depending on hardware, schema, indexes, and query shape.

Viral content, product pages, feeds, and search endpoints can exceed that quickly.

The goal is not to make the database serve every read. The goal is to serve repeatable reads from cheaper, faster layers first, and reserve the database for cache misses, writes, and requests that need fresh source-of-truth data.

Handling high read traffic is one of the most common patterns in system design interviews. A strong answer shows how to reduce database load, control latency, manage staleness, and choose the right combination of cache, CDN, replicas, indexes, and pre-computation.