Most applications are **read-heavy**. Think about it: in the [Yelp](/learn/system-design/questions/yelp) question, a restaurant page might get hundreds of views for every single review someone writes. In a [Leaderboard](/learn/system-design/questions/leaderboard), thousands of users check rankings every second, but scores only update when a game ends. These read-to-write ratios of 100:1 or higher are the norm, not the exception. So what happens when your app gets popular? Your database starts struggling — not because your code is bad, but because a single machine has physical limits: finite CPU, memory, and disk speed. No amount of code optimization will let one server handle 100,000 queries per second when the hardware tops out at 10,000. The good news: scaling reads is a well-understood problem with a clear progression. You apply solutions in order, each one building on the last. Don't jump to distributed caching on day one — start simple and add complexity only when needed. ## Tier 1 — Get More From Your Existing Database Before adding any new infrastructure, make sure you're not leaving performance on the table. These optimizations are essentially free. ### Indexing If you've written SQL before, you know about indexes — but it's easy to underestimate their impact. A single missing index on a high-traffic query can be the entire reason your database is slow. **What to index:** columns used in WHERE, JOIN, and ORDER BY clauses. Run EXPLAIN ANALYZE on your slow queries — if you see "Seq Scan" (sequential scan) on a large table, that's your database reading every single row to find a match. An index turns that into a near-instant lookup. **What to watch out for:** indexes aren't free. Each one consumes memory and slows down writes (because the index must be updated on every insert/update). Don't blindly index everything — focus on columns that appear in your most frequent queries. **Composite indexes** (indexes on multiple columns) can be especially powerful. If your query filters on city and sorts by rating, a composite index on (city, rating) can answer the query entirely from the index without touching the actual table rows. This is called an **index-only scan**. **See it in practice:** In [Yelp](/learn/system-design/questions/yelp), composite indexes on location and rating power the restaurant search. In [Google Calendar](/learn/system-design/questions/google-calendar), indexes on user ID and time range make event lookups fast. The [Search and Full-Text Indexing](/learn/system-design/design-patterns/search-full-text-indexing) pattern goes deeper into inverted indexes and Elasticsearch for when B-Tree indexes aren't enough. ### Denormalization In a normalized database, data is split across many tables to avoid duplication. That's clean and correct, but it means your read queries often need JOIN operations — and joins get expensive as tables grow. **Denormalization** means pre-computing and storing the result so reads don't need to join at all. In the [Yelp](/learn/system-design/questions/yelp) question, instead of computing a restaurant's average rating by scanning all its reviews on every page load, you store the average directly on the restaurant row and update it whenever a new review comes in. The trade-off: your writes become slightly more complex (you need to keep the pre-computed value in sync), but when reads outnumber writes 100:1, this is almost always worth it. **See it in practice:** In [Yelp](/learn/system-design/questions/yelp), `avg_rating` and `review_count` are denormalized onto the restaurant row to avoid scanning the reviews table on every page load. In [Leaderboard](/learn/system-design/questions/leaderboard), player ranks are pre-computed in Redis sorted sets rather than recalculated from raw game results. In [Slack](/learn/system-design/questions/slack), unread counts and last-message previews are denormalized for instant channel list rendering. ### Connection Pooling Every time your app opens a database connection, there's overhead: TCP handshake, authentication, memory allocation on the database server. If each web request opens and closes its own connection, you're wasting time and resources on connection setup. A **connection pool** (like PgBouncer for PostgreSQL) maintains a set of open connections and hands them out to requests as needed. This is a one-line infrastructure change that can dramatically increase throughput, especially during traffic spikes that would otherwise exhaust the database's connection limit. **See it in practice:** In [Webhook](/learn/system-design/questions/webhook), connection pooling is critical when delivering thousands of webhook events per second — without it, each delivery attempt would open a new database connection to log the result. In [Google Maps](/learn/system-design/questions/google-map), pooling prevents connection exhaustion during peak navigation hours when millions of tile and route queries hit the database layer. ## Tier 2 — Add More Database Nodes When one well-tuned database isn't enough, spread the read load across multiple copies of your data. ### Read Replicas This is the most common next step. Your primary database handles all writes, and one or more **replicas** receive a continuous copy of the data via streaming replication (supported by PostgreSQL, MySQL, and most relational databases). You route read queries to the replicas, which takes load off the primary. The important thing to understand is **replication lag** — replicas are not instant copies. They're typically milliseconds behind the primary, but under load, the lag can grow to seconds. This means: - **Most reads are fine on replicas.** Viewing a [Yelp](/learn/system-design/questions/yelp) restaurant page that's a few seconds stale? No one notices. - **Reads immediately after a write need the primary.** If a user submits a review and then immediately reloads the page, they expect to see their review. Reading from a lagging replica would show the old page. The fix: route the user's own reads to the primary for a short window (a few seconds) after they write. ### Sharding (When Replicas Aren't Enough) If your dataset is so large that even replicas can't keep up, you can **shard** — split data across multiple independent database clusters. Each shard holds a different subset of data (e.g., users A–M on shard 1, N–Z on shard 2). But sharding for reads alone is rare. It introduces serious complexity: cross-shard queries, choosing the right shard key, rebalancing when shards get uneven. In most cases, replicas + caching (Tier 3) will get you much further with much less pain. **See it in practice:** In [Uber](/learn/system-design/questions/uber), read replicas serve location lookups for riders and nearby-driver queries while the primary handles ride-state writes. In [Google Maps](/learn/system-design/questions/google-map), replicas handle the massive volume of map tile and route reads across regions. The [Scaling Writes](/learn/system-design/design-patterns/scaling-writes) pattern covers sharding in depth — when you actually need it and how to choose the right partition key. ## Tier 3 — Cache So Reads Never Hit the Database Caching is where the biggest performance gains live. The idea is simple: store frequently-read data in something faster than your database (usually in-memory), so most requests never touch the database at all. ### Application-Level Caching (Redis / Memcached) A cache like Redis sits between your application and your database. When your app needs data, it checks the cache first. If the data is there (**cache hit**), it returns immediately — response times drop from tens of milliseconds to under a millisecond. If not (**cache miss**), it reads from the database and stores the result in the cache for next time. There are three main strategies for keeping the cache and database in sync: **Cache-aside is the default choice** for most applications. It's simple, resilient (cache failure = slower, not broken), and naturally adapts to access patterns — only frequently-read data stays in the cache. **See it in practice:** In [Distributed Cache](/learn/system-design/questions/cache), you design a full Redis-like caching system from scratch — including eviction policies, consistent hashing, and replication. The [Distributed Caching](/learn/system-design/design-patterns/distributed-caching) pattern dives deeper into cache topologies, eviction strategies (LRU, LFU), and how to handle cache node failures without losing availability. ### CDN for Static and Semi-Static Content A **Content Delivery Network** caches content at **edge servers** around the world, close to your users. When a user in Tokyo requests an image, the CDN serves it from a nearby edge node instead of your origin server in Virginia. The request never reaches your servers at all. CDNs work best for static assets (images, CSS, JavaScript) but can also cache API responses using Cache-Control headers. In the [Yelp](/learn/system-design/questions/yelp) question, restaurant photos are served from CDN edges. In [Uber](/learn/system-design/questions/uber), map tiles are cached at the CDN layer so they don't need to be rendered on every request. **See it in practice:** In [Yelp](/learn/system-design/questions/yelp), restaurant photos and thumbnails are served entirely from CDN edges — origin servers never handle image traffic. In [Uber](/learn/system-design/questions/uber), pre-rendered map tiles are cached at CDN nodes worldwide so drivers and riders see instant map loads. The [Handling Large Blobs](/learn/system-design/design-patterns/handling-large-blobs) pattern covers how to combine CDNs with pre-signed URLs for efficient large file delivery. ### How These Layers Work Together In a high-traffic system, you typically stack multiple caching layers. Each layer filters out more requests, so only a small fraction of traffic reaches the database: 1. **CDN edge** — serves static assets and cached API responses. Handles the majority of requests. 2. **Application cache (Redis)** — serves dynamic but cacheable data. Handles most of what passes through the CDN. 3. **Database (with replicas)** — handles only cache misses and writes. Sees a fraction of total traffic. If you get a million requests per second and the CDN handles 70%, Redis handles 25%, and only 5% reaches the database — that's 50,000 queries per second instead of a million. That's the power of layered caching. ## Common Problems and How to Solve Them ### Hot Key Problem Sometimes one piece of data gets wildly more traffic than everything else — a trending post in [Meta Post Privacy](/learn/system-design/questions/facebook-post-privacy), or a live [Leaderboard](/learn/system-design/questions/leaderboard) during a competition. Even in Redis, a single key can become a bottleneck if millions of requests hit it simultaneously (Redis is single-threaded per key). Three solutions: - **Local in-process cache (L1)**: Each app server caches the hottest keys in its own memory (not Redis). This eliminates the network round-trip to Redis entirely. Use a very short TTL (a few seconds) so data stays reasonably fresh. - **Key replication**: Store the same value under key:0, key:1, ..., key:N. Each read randomly picks one. This spreads load across N Redis nodes instead of hitting one. - **Request coalescing (singleflight)**: If 100 requests arrive for the same key at the same moment, only one actually fetches it. The other 99 wait and share the result. This is built into some frameworks (Go's singleflight package, for example). **See it in practice:** In [Meta Post Privacy](/learn/system-design/questions/facebook-post-privacy), a viral post can generate millions of reads on a single key — local L1 caching and key replication prevent Redis from becoming the bottleneck. In [Leaderboard](/learn/system-design/questions/leaderboard), live competition rankings create extreme hot-key pressure on the top-N sorted set. In [Distributed Counters](/learn/system-design/questions/distributed-counters), the entire problem revolves around handling hot-key write and read contention at scale. ### Cache Stampede (Thundering Herd) Imagine a popular cached item expires. Suddenly, thousands of requests see a cache miss at the same time and all hit the database simultaneously. The database, which was happily handling a trickle of cache misses, is now flooded. This is a **cache stampede**. Three solutions: - **Probabilistic early refresh**: Instead of all readers waiting until the TTL expires, each reader has a small random chance of refreshing the key *before* it expires. This spreads recomputation over time so there's no sudden cliff. - **Lock on recomputation**: When a cache miss happens, the first request acquires a lock and recomputes the value. All other requests either wait for the result or serve slightly stale data. This guarantees only one request hits the database. - **Background refresh**: A background job proactively refreshes popular entries before they expire. No user request ever triggers a recomputation — the cache is always warm. **See it in practice:** In [Distributed Cache](/learn/system-design/questions/cache), you design stampede prevention directly into the cache layer using locking and background refresh. In [Ads Click Aggregator](/learn/system-design/questions/adds-click-aggregator), cached click counts for popular ads expire simultaneously during peak traffic — probabilistic early refresh prevents the thundering herd. The [Distributed Caching](/learn/system-design/design-patterns/distributed-caching) pattern covers these solutions in depth alongside eviction policies and replication strategies.