63. Drawing System Designs: Whiteboard, Paper, and Virtual Canvas

§62 covers what goes on the board: requirements, estimates, and the diagram regions. This chapter covers how to draw: a small visual vocabulary, layout rules, how a diagram should grow during the interview, which diagram type fits which question, and how to work on a physical whiteboard, on paper, on a virtual canvas, and when presenting a working prototype.

63.1 Why drawing is part of the score

• The diagram is the shared memory of the conversation. After minute 15, both you and the interviewer reason from the board, not from what you said. A messy board makes a good design look confused.
• Interviewers write feedback from it. Many take a photo or screenshot and use it to write up the session. A clear diagram is evidence of the "communication" and "solution design" signals (§1.2).
• At Staff level and above, the diagram is how you lead. You set the structure, the interviewer points at boxes, and the discussion follows your layout.

63.2 A small, consistent visual vocabulary

Use five shapes, three arrow types, and numbered steps, and nothing more. Draw the legend in a corner if the interview is long or the notation is unusual.

 SHAPES                                        ARROWS
 ┌─────────┐                                   ───────▶   synchronous request/response
 │ Service │   rectangle: stateless service     - - - - ▶   asynchronous message / event
 └─────────┘   (draw 2 offset boxes + "×N"       ═══════▶   bulk data: replication, streaming,
                for a replicated fleet)                      batch copy
   ╭─────╮
   │ DB  │     cylinder: anything that STORES    LABELS ON ARROWS (always)
   ╰─────╯     (DB, cache, object store)          what + how much + how:
 ┌┬┬┬┬┬┬┐                                         "POST /orders · 3k/s · HTTPS"
 │││││││ │    queue / log (box with bars)        "order_events · Kafka · key=order_id"
 └┴┴┴┴┴┴┘
  /‾‾‾‾‾\                                        STEPS
 ( Ext.  )    cloud: third party / internet      ① ② ③ … numbered circles on arrows
  \_____/                                         = the order of a flow you narrate
 <  LB   >    diamond/trapezoid: load balancer,
              gateway, router                    BOUNDARIES
 ┌ ─ ─ ─ ─ ┐                                     dotted outline = region / AZ / cell /
   region     dotted outline: boundary             trust boundary (label it)
 └ ─ ─ ─ ─ ┘

Naming rules:

• Name boxes by responsibility: "Feed service", "Order DB (Postgres)". Never "backend" or "server".
• Write the key on every datastore: "Orders · PK order_id · shard by customer_id". This one line answers half the follow-up questions.
• Put numbers where they decide something: QPS on the hot arrow, size on the big store, p99 next to the latency-critical path.

63.3 Layout rules that keep a board readable

  ONE DIRECTION OF FLOW, IN BANDS (left → right)

  CLIENTS │  EDGE         │  SERVICES            │  DATA            │  ASYNC / OFFLINE
  ────────┼───────────────┼──────────────────────┼──────────────────┼──────────────────
  Mobile  │  CDN          │  API gateway         │  Cache           │  Queue → Workers
  Web     │  LB           │  Service A, B, C     │  DB (+replicas)  │  Stream → Analytics
          │               │                      │  Object store    │

1. Pick one flow direction (left → right is easiest to read; top → bottom also works), and don't mix them.
2. Use bands: clients | edge | services | data | async. A reader instantly knows what kind of thing a box is from its column.
3. Start small and centered-left, and leave 30–40% empty space. The design will grow (§63.4). Running out of space forces erasing, which wastes time and loses context.
4. Avoid crossing arrows. If two arrows cross, move a box. Crossing lines are the number-one cause of "spaghetti boards".
5. One abstraction level per diagram. The main diagram shows containers (services, stores, queues). Internals of one service go in a separate zoom-in area with a callout ("zoom: Feed service →"). This mirrors the C4 model's levels (context → containers → components), which is a useful vocabulary for design docs too.
6. Draw boundaries last (regions, cells, trust zones), as dotted outlines around boxes that already exist.
7. Keep the requirements and estimates panel visible all the time (§62's layout). Point back to it when you justify a decision.

63.4 Grow the diagram in stages; don't draw it all at once

Interviewers want to watch the design evolve because of the requirements. Draw in four passes, narrating each:

 STAGE 1 (≈ min 15): skeleton — every functional requirement works end to end
   Client ──▶ API ──▶ Order svc ──▶ (Orders DB)

 STAGE 2 (≈ min 18): scale — what the estimates forced
   Client ──▶ <LB> ──▶ API ×N ──▶ Order svc ×N ──▶ (Cache) ──▶ (Orders DB) ══▶ (Replicas)

 STAGE 3 (≈ min 22): async — take slow work off the request path
   Order svc - - ▶ [|||| order_events ||||] - - ▶ Email workers
                                             - - ▶ Search indexer ──▶ (Search index)

 STAGE 4 (min 25+): deep dives & failures — annotate, don't redraw
   ✗ next to a box = "what if this dies?" (write the answer beside it)
   ⚠ next to an arrow = hot spot / bottleneck (write the mitigation)
   zoom-in area: the Order svc's idempotency table & state machine

Each stage is a small diff on the previous drawing. If you need to change a decision, cross it out with a single line and write the replacement next to it. Interviewers like seeing the reasoning that changed it, and you avoid erasing context.

63.5 Choose the right diagram for the question

A hand-drawn sequence diagram (an idempotent payment, as in §5.4):

 Client          API                 Idem store         PSP
   │ ① POST K1    │                      │               │
   │─────────────▶│ ② insert K1 pending  │               │
   │              │─────────────────────▶│ ★             │
   │              │ ③ charge(ref=K1) ─────────────────────▶│
   │   ✗ timeout  │                      │               │ (succeeds)
   │              │ ④ mark K1 done + resp│               │
   │              │─────────────────────▶│ ★             │
   │ ⑤ retry K1   │                      │               │
   │─────────────▶│ ⑥ lookup K1 → done   │               │
   │◀─────────────│ same response (no second charge)     │

With practice it takes under two minutes, and it settles questions about retries, ordering, and consistency far faster than words.

63.6 Techniques for each medium

Physical whiteboard (onsite)

• Three colors with fixed meanings: black for structure, blue for data flow and numbered steps, red for failures, risks, and bottlenecks. Say the legend once. Pick up the markers before you start, and test them.
• Write large: letters about 3–5 cm, legible from 3 meters. Tiny writing is the most common whiteboard mistake.
• Stand to the side when you talk, so the interviewer can see the board. Face them when you make a decision, and face the board when you trace a flow.
• Erase locally, not globally. Never wipe the whole board. Requirements and estimates must survive until the end.
• Start top-left with the requirements panel. Diagram in the center-right.

Pen & paper (phone or video screens with a camera, or note-taking during a design review)

• Landscape orientation, one sheet per diagram. Grid or dot paper keeps boxes aligned. Use a pen that photographs well (a fine marker, not a light pencil).
• Hold it up to the camera after each stage, or use a document camera or phone-as-webcam setup tested before the interview.
• Pre-printed templates aren't appropriate in interviews unless allowed. A blank sheet with the §62 regions sketched in ten seconds works fine.

Virtual canvas (Excalidraw, Miro, Microsoft Whiteboard, tldraw, the company's own interview tool)

• Ask which tool will be used, and practice in it beforehand. Fumbling with a tool for 5 minutes in a 45-minute interview is expensive.
• Learn the shortcuts for rectangle, ellipse, arrow, and text (in Excalidraw the single-letter shortcuts include R, O, A, and T; hover over the toolbar to confirm) and duplicate (copy-paste a box instead of drawing new ones).
• Use arrows that attach to shapes, so moving a box keeps the connections.
• Don't polish. Alignment and colors cost time; a rough, readable diagram wins. Use one accent color for failures and risks.
• Text boxes for the requirements and estimates panel at the left edge, and zoom out periodically so the interviewer sees the whole picture.

Shared document / text only (some phone screens): ASCII boxes and arrows, like the diagrams in this guide, or a numbered flow list: Client → LB → API → Order svc → Orders DB; Order svc ⇢ Kafka ⇢ Email worker.

63.7 Presenting ideas, a design review, or a working prototype

Outside the interview (design reviews, architecture forums, demo days, and the past-project round in §64), you have time to prepare. Use it:

Prepared diagrams as code. Version-controlled, diffable, and easy to update: Mermaid (renders natively in GitHub and many wikis), PlantUML, Structurizr (the C4 model as code), D2, or the Python diagrams library (cloud-provider icons). A minimal Mermaid flow and sequence:

```mermaid
flowchart LR
  C[Client] --> LB[Load balancer] --> API[Order API]
  API --> DB[(Orders DB)]
  API -. order_events .-> K[[Kafka]] -.-> W[Email worker]
```

```mermaid
sequenceDiagram
  participant C as Client
  participant A as API
  participant S as Idempotency store
  C->>A: POST /payments (Idempotency-Key K1)
  A->>S: insert K1 pending
  A-->>C: 201 Created
  C->>A: retry with K1
  A->>S: lookup K1 (done)
  A-->>C: same 201 response
```

The prototype / demo narrative (10–15 minutes):

 1. PROBLEM (1 min)        who hurts, what metric, why now
 2. ARCHITECTURE (2 min)   ONE container diagram, numbered steps ①-⑥ on the main flow
 3. LIVE FLOW (4 min)      trigger one real request; show its trace / logs at each numbered step
                           ("this is step ③ — the event in Kafka, key = order 9001")
 4. FAILURE (3 min)        kill a dependency / inject latency; show the system degrading as designed
 5. NUMBERS (2 min)        load test results vs targets (p99, throughput, cost per request)
 6. ASK (1 min)            the decision or support you need, and the open risks

Pair every diagram step with evidence: the same request ID in logs, a trace span, a row in the database. Diagrams make the claim; the demo proves it. Keep a static screenshot fallback for every live step, because live demos fail at the worst moment.

Slides vs whiteboard: use slides for the final architecture and the results. Use a whiteboard (or a live canvas) when you want the audience to shape the design, because people engage more with a diagram they watch being built.

63.8 Narrating while you draw

• Say it, draw it, confirm it: "I'll put a cache in front of the product DB, because reads are 50:1." (draw) "Does that match what you'd expect for this workload?"
• Never draw in silence for more than about 20 seconds. Silence reads as being stuck.
• Trace with your finger or cursor when you walk a flow: "① the request hits the gateway, ② ...". Numbered steps let you say "at step ④" instead of re-explaining.
• Summarize the board every ~10 minutes: "So far: write path is ①–④, read path ⑤–⑦, async fan-out on the right. The open risk is the hot partition I marked in red."
• Invite the interviewer to point: "Which box would you like to go deeper on?" It turns the diagram into a shared tool.

63.9 Common drawing mistakes

63.10 Drills (10 minutes a day for two weeks)

Before you say "done", check: every requirement has a path on the board · arrows labeled · sync vs async distinguishable · keys on datastores · numbers on the hot path · failure annotations present · boundaries drawn · requirements panel still visible.