Baseline Design

Always Draw This First

Whatever the prompt, the baseline is the same four boxes. It exists to be attacked, not admired:

 ┌────────┐     ┌─────────────┐     ┌──────────┐     ┌───────────────┐
 │ Client │────►│ Load        │────►│ App      │────►│ Database      │
 │ web/   │     │ Balancer    │     │ Servers  │     │ (Postgres)    │
 │ mobile │◄────│             │◄────│ stateless│◄────│ primary       │
 └────────┘     └─────────────┘     └──────────┘     └───────────────┘
                terminates TLS,      business logic,   source of truth
                spreads load,        no session state  single writer
                health-checks        horizontally      vertical for now
                                     scalable

Every element is deliberate:

Choice	Why present at baseline
LB in front	Multiple app nodes become possible; TLS + health checks centralized
Stateless app tier	Horizontal scaling stays trivial forever; no sticky sessions
One relational DB	ACID transactions day one; schema flexibility via migrations
Sync request/response only	No queues/caches until triggers demand them

What the Baseline Honestly Supports

Rough ceilings with commodity parts (illustrative):

• Tens of thousands of DAU: comfortably; likely hundreds of thousands.
• ~1–2k rps on a modest app fleet before CPU or DB becomes interesting.
• Storage: single Postgres handles TBs before partitioning conversations start.

Most real products never leave this shape. The ones that do evolve along named trigger→action steps — next lessons.

The Discipline of Baseline-First

Starting complex hides reasoning; starting simple exposes it:

 WEAK OPENING                       STRONG OPENING
 "I'll use Kafka, Cassandra,        baseline drawn in 3 minutes,
 Redis, and microservices..."       capacity stated per box:
                                    "this serves ~50k DAU; here's
 (unjustified end-state;            what breaks first at 10x —
 nothing can be questioned          the DB write path — so when we
 because nothing was justified      hit that, replicas+cache go here"

The second candidate has given the interviewer handles everywhere: every box can be probed, defended, or evolved.

Attacking the Baseline (the point of drawing it)

Run the standard weakness scan immediately:

Attack	Finding	Evolution seeded
Reads grow 10x?	Primary saturates on SELECTs	Replicas, cache, CDN
Writes grow 10x?	Single writer ceiling	Sharding path named now
One AZ dies?	Everything dies	Multi-AZ posture noted
Slow work appears? (emails, media)	Requests block user	Queue seam mentioned

Four questions, thirty seconds, and the design conversation now has an agenda.

Interview Framing

“Start simple and evolve” is graded right here. Score pattern: draw the four boxes fast, attach one capacity number and one responsibility line each, run the attack table aloud, then let the interviewer pick which evolution to walk. Candidates who open with end-state diagrams remove every handle the interviewer needs — and get interviewed harder for it.