Diagonal Scaling

The Pattern

 DIAGONAL = alternate vertical and horizontal moves,
 choosing the cheapest capacity increase at each stage:

 stage 1: one medium node              (vertical start)
 stage 2: bigger node                  (vertical — still simple)
 stage 3: two nodes behind LB          (horizontal begins)
 stage 4: bigger nodes again           (vertical per-node)
 stage 5: four+ nodes, replicas added  (horizontal + topology)

 each step buys time; complexity is added only when
 the cheap steps are exhausted

Why the Ladder Order Matters

 complexity price list (roughly ascending):
   bigger instance        ≈ zero code change
   second app node + LB   small (statelessness work)
   read replica           small-medium (routing reads)
   cache layer            medium (invalidation discipline)
   shard database         LARGE (query routing, rebalancing, cross-shard)
 
 diagonal scaling = always take the cheapest rung that
 provides enough headroom. premature sharding is the
 classic over-engineering wound in real systems AND interviews

A Concrete Walkthrough

 RideShare trip service growth:

 0–10k rps:    single 16-core box. fine.
 10–50k:       64-core box. still one deploy, one dashboard.
 50k+:         state extracted to Redis/S3 → N app nodes behind LB.
               DB vertical to top tier + read replica.
 millions:     DB write load forces sharding NOW — but three
               years of architecture were spent on product,
               not distribution plumbing.

The point isn’t stinginess — it’s sequencing complexity against demonstrated need.

Where Diagonal Thinking Shows Up

Component	Typical diagonal path
Primary DB	bigger → standby → replicas → shard
Cache	big single Redis → cluster mode
App tier	big box → LB pool immediately (cheap anyway)
Search	beefier node → dedicated cluster

App tiers usually skip straight to horizontal (stateless makes it nearly free); stateful stores are where diagonal sequencing earns its keep.

Anti-Pattern: Skipping Rungs

 symptom designs:
 - microservices on day one for a 3-engineer team
 - sharded Mongo before first customer
 - Kubernetes for a monolith with 100 rps

 each skips rungs whose cost was LOW and buys complexity
 whose cost is HIGH. scaling problems are good problems —
 they arrive with revenue. solve them then, with data.

Interview Framing

Interviewers reward explicit laddering: “we’d scale vertically first since it’s operationally free; at X rps we go horizontal for the stateless tier; DB gets replicas at Y, shards only when writes demand.” Naming thresholds with rough numbers converts the answer from vibes into engineering. The anti-signal is sharding in v1 without a write-load justification.