SYSTEM DESIGN:Lesson 2: Scaling the Data Layer

What this lesson answers

After you add app servers, the database often becomes the slow part. Four tools help: read replicas, sharding, caching (often Redis), and a CDN for static files.

If you have not done Lesson 1 yet, start there: When One Server Is Not Enough.

Read replicas

Many apps do far more reads (SELECT) than writes. A read replica is a copy of the primary database that only serves reads. Writes still go to the primary. The primary copies data to the replicas.

Read replicas distributing SELECT queries

Write:  App → Primary (INSERT / UPDATE / DELETE)
Read:   App → Replica(s) (SELECT)
Sync:   Primary → replicas (usually async)

Replication lag means a write might not show on a replica for a short time (often tens to hundreds of milliseconds). Product pages and feeds can usually accept that. Payments and balances should read from the primary.

Useful rule of thumb: one primary + several replicas increases read capacity. It does not fix “too many writes” or “database too big for one disk.”

Sharding

Sharding splits data across several databases. Each shard holds part of the rows (same schema, fewer rows). Use it when one machine cannot hold or write all the data.

Example: shard by user_id % 4
  Shard 0: some users
  Shard 1: other users
  ...

Cross-shard joins are painful. Design so most requests hit one shard. Prefer indexes and read replicas before sharding. Sharding is a late move, not a first one.

Cache (Redis cache-aside)

For the same data requested over and over, read from a fast store (often Redis) instead of the database every time.

Cache-aside (common pattern):

Cache-aside pattern with Redis

READ:
  1. Look up key in Redis
  2. Hit  → return cached value
  3. Miss → query DB → store in Redis (with TTL) → return

WRITE:
  1. Write to DB (source of truth)
  2. Delete or update the cache key

Cache: profiles, catalogs, leaderboards, config, sessions.

Usually do not cache as the only source: money balances, stock that must be exact.

Always set a TTL so a bug in invalidation does not leave stale data forever.

CDN

A CDN stores static files near users: images, JS, CSS. The browser loads them from a nearby edge server, not your API box every time.

Without CDN: user → your origin for every image
With CDN:     user → nearby edge (cache hit) most of the time

CDN only helps if you set cache headers correctly.

Five stages (how systems usually grow)

Five-stage system evolution diagram

Do not jump to Stage 5 because a blog about a huge company did. Match the stage to your real load.

Small example

Read-heavy product, busy evenings:

CDN     → images and static assets
Redis   → hot lists, sessions, short-lived scores
Replicas→ most SELECTs
Primary → writes and money-sensitive reads

Match each piece of data to how fresh it must be. A score that can be 10 seconds old can live in Redis. A wallet balance should not.

Mistakes to avoid

• Caching everything (low hit rate + more complexity)
• No plan to invalidate or expire cache
• Sharding a small database that only needs indexes or a replica
• Ignoring replica lag under peak load
• CDN with no Cache-Control headers

Say this in an interview

1. Say if the system is read-heavy or write-heavy.
2. Reads: replicas and/or cache for hot keys.
3. Static files: CDN.
4. Writes / size too big for one DB: then talk sharding and the shard key.
5. Name what must be strongly consistent vs what can lag.

Practice

• Sharding Lab
• Consistency Lab

Next

Next you learn how to estimate QPS and storage on paper: Do the Math on a Napkin.