Design Evolution

Designs Are Movies, Not Photos

Every serious system is a sequence of architectures, each entered by a measured trigger and exited by a saturation event. Presenting only the final frame hides the judgment interviewers actually grade. The deliverable of a good design session includes the path.

The RideShare Evolution Sequence

 STAGE 1 — BASELINE (launch → ~50k DAU)
 Client → LB → App(stateless) → Postgres(single)
 exit trigger: DB reads saturate during evening peak

 STAGE 2 — READ PATH (→ ~1M DAU)
 + read replicas, + Redis cache for hot reads, + CDN for static
 exit trigger: primary write ceiling; location pings crushing it

 STAGE 3 — SPLIT BY DATA TYPE (→ ~5M DAU)
 locations evicted to dedicated memory store (TTL, sharded)
 heavy async work (receipts, notifications) moves to queue+workers
 exit trigger: trips table write rate nears single-node limit

 STAGE 4 — WRITE SCALE (→ 50M DAU)
 trips sharded by city/region hash; matching reads geo-sharded store
 cell deployment per region; global services (auth, payments) stay central
 
 each stage entered by EVIDENCE (metrics), exited by DESIGN (headroom)

Four diagrams tell one story; the final diagram alone tells none.

Trigger → Action Discipline

Evolution steps are legitimate only when triggered:

Evidence in metrics	Legitimate next step
Read latency p99 drifting up, cache hit ratio already high	More replicas / better indexes
Primary CPU sustained high on writes	Functional split or shard design begins
Queue depth growing unbounded	Consumer scaling or admission control
One shard’s load visibly diverging	Re-partition strategy (hot key work)

Absent evidence, adding stages is premature complexity wearing an evolution costume.

What Must Be True at Every Stage

Evolution only works if early stages preserve later options:

 INVARIANTS ACROSS ALL STAGES
 - app tier stays stateless            → rescaling stays boring
 - one writer per data type            → sharding has an owner to split
 - contracts between services          → internals swap freely
 - capacity headroom policy per tier   → next trigger detected early

 VIOLATIONS THAT BLOCK EVOLUTION
 - stored procedures with business logic   → can't move with the data
 - cross-service table joins               → can't split databases
 - sticky sessions everywhere              → can't drain nodes cleanly

This is why “start simple” doesn’t mean “start careless”: the simple version carries seeds of every future stage.

Cost of Each Stage (honesty check)

Stage	Adds	New operational burden
Replicas/cache	Failover mechanics, invalidation bugs	Moderate
Data-type split	Another store to operate; consistency questions	Significant
Sharding	Resharding tooling, cross-shard queries forbidden-ish	Major
Cells/regions	Deployment topology, regional ops playbooks	Largest

The ladder’s cost curve justifies staying low as long as triggers allow.

Interview Framing

The strongest closing move in any system design interview: present the current-stage diagram, then walk the next two triggers (“at 10x cities, trips shards by region; matching becomes geo-routed”). This demonstrates you know the design’s expiration date — which is precisely what staff-level engineers are paid to know.