Speak the scaling vocabulary — load balancing, caching, sharding

At a glance

Learning objectives

• Use load balancer, cache, and shard vocabulary precisely in design arguments
• Translate between the Primer's scaling terms and DDIA's partitioning/replication
• Pick the first scaling lever for a bottleneck instead of reaching for all of them

What you need

• Lesson 2's estimates (scaling needs numbers to bite on)
• One real bottleneck to reason about

Steps

1. Learn the three levers in one place — the Primer's scaling vocabulary is load balancers, caching, and sharding, taught together so their interactions are visible from day one. (from ref-system-design-primer )
2. Use the standard on-ramp — the Primer is the standard on-ramp for the estimation and tradeoff vocabulary this stage's interview path needs, so its terms are the ones interviewers and reviewers will expect you to use. (from ref-system-design-primer )
3. Translate to the canonical mechanisms — DDIA teaches the same ideas as replication and partitioning, so sharding is partitioning, and load balancing plus caching sit on top of replicated copies. (from ref-ddia )
4. Anchor the translation in production terms — the description maps partitioning to lakehouse, so your sharding argument is really a partition-layout argument about the tables you already curate. (from ref-ddia )
5. Check scaling choices against deployed guidance — AWS's best-practice guidance (Well-Architected pillars) shows which levers ship together in real architectures, and at what cost to cost and operability. (from ref-aws-arch-center )

Check yourself

• You can name which lever you would pull FIRST for a read-bound serving path, and why cache precedes shard in that order.
• Asked to shard a lakehouse table, you answer with a partition key and skew story, not with the word sharding alone.

Worked example

Bottleneck            -> first lever          -> canonical mechanism
read-heavy serving    -> cache, then LB       -> replication
write throughput      -> partition the writes -> partitioning
dataset > one node    -> shard by access key  -> partitioning
spiky traffic         -> LB + autoscale       -> replication
Rule: one lever at a time; measure before adding the second.

Sourced from

• The System Design Primer
• Designing Data-Intensive Applications (O'Reilly)
• AWS Architecture Center

Security scan

Last sweep 2026-10-24: 0 finding(s), 0 marked as examples.

Common gotchas

• Adding replicas scales reads, not writes — replication and partitioning answer different overload shapes.
• A cache without an invalidation story is a correctness bug with a latency bonus.
• Hash partitioning kills range scans; range partitioning creates hot keys — pick per access pattern.

Production considerations

• Record the chosen scaling lever and its expected headroom in the design doc.
• Watch partition skew after every key change — hot keys masquerade as capacity problems.

Diagram

scaling vocabulary
   |
   |- too slow reads   --> 1) cache  2) load-balance replicas
   |- too much data    --> shard / partition (by hash or range)
   |- too many writers --> partition first; replicas do not help writes
   |
   |- primer words:  load balancer | cache | shard
   |- ddia words:    replication   |       | partitioning
   |
    --> name the lever, its cost, and its skew story

Registry stats