Most real-world applications are read-heavy. For every user who posts a tweet, thousands read it. For every product listing created, millions view it. For every article published, countless readers access it. The read-to-write ratio in production systems often exceeds 100:1.

This creates a problem. Databases are designed for durability and consistency, not for serving millions of read requests per second. A typical PostgreSQL instance might handle 10,000 queries per second on a good day. But when a tweet goes viral, it needs to be served millions of times within minutes. No single database can keep up.

The gap between what databases can deliver and what users expect is where system design gets interesting. Bridging this gap requires a layered approach, one that intercepts requests before they ever reach your database and serves them from progressively faster sources.

Handling high read traffic is one of the most common patterns in system design interviews. Whether you're designing Twitter, Netflix, Amazon, or a URL shortener, the interviewer expects you to demonstrate strategies for scaling reads. More importantly, they want to see that you understand the trade-offs involved.

1. Understanding the Read Problem