Architecture Whiteboarding

Introduction

Architecture Whiteboarding is the skill of communicating system design in real time — boxes, arrows, and narrative that a mixed audience (engineers, PMs, bar-raisers) can follow. At Uber, whiteboarding appears in interviews, RFC reviews, and incident postmortems. Staff candidates are judged on diagram discipline: left-to-right data flow, labeled arrows, explicit async boundaries, and verbal trade-off narration synchronized with what they draw.

Real production story

An Uber staff candidate interviewed for marketplace platform. They drew 40 boxes in 15 minutes — services, caches, queues, databases — with crossing arrows and no legend. When the EM asked "walk me through a ride request," the candidate couldn't trace a path without erasing. The panel scored "strong technical knowledge, weak communication — no hire for staff."

The next candidate used a three-panel whiteboard: (1) actors and SLOs, (2) sync request path left-to-right, (3) async/event path below with dotted lines. Each box labeled with service name + one-line responsibility. Verbal narration matched drawing pace. Trade-offs written in corner: "sync matching for p99; async for surge pricing updates." Unanimous hire. Same domain — different whiteboarding discipline.

Business problem

Business pressure: Uber architecture decisions happen in real-time meetings — engineers who cannot whiteboard clearly slow RFC approval, misalign execs in QBRs, and fail staff panels regardless of deep expertise.

• Revenue at risk: Miscommunicated architecture in ride matching redesign causes wrong implementation — measured in failed matches and driver churn.
• Engineering velocity: RFCs with clear diagrams approve 2× faster than wall-of-text proposals in Uber eng data.
• Compliance / trust: Regulators and partners review architecture diagrams — unreadable internals fail audit presentations.

Architecture overview

Architecture whiteboarding in production: (1) layout — left-to-right sync flow, async below with dotted arrows, (2) labels — every box has name + one-line responsibility, every arrow has protocol/payload hint, (3) scope — 5–9 boxes per panel; split panels before adding box 10, (4) narrative — draw while telling customer story, (5) trade-off corner — explicit sacrifices written, not only verbal.

• Definition: Real-time visual communication of architecture with diagram discipline and synchronized narrative.
• When to adopt: Interviews, RFC reviews, incident timelines, exec architecture briefings.
• When to defer: Mature system with existing C4 diagrams — update docs, don't re-whiteboard from scratch each meeting.
• Operability: photo/Excalidraw export to ADR appendix within 24 hours — whiteboard is draft, ADR is record.

Architecture motivation

Why architects care: Whiteboarding is thinking made visible — diagram discipline forces clarity on boundaries, data flow, and failure domains before code is written.

• Force: Real-time collaboration requires shared visual model — Slack threads don't replace whiteboard in design reviews.
• Constraint: 45-minute interview or 30-minute RFC slot — diagram must communicate in minutes, not hours.
• Outcome: Readable diagram + synchronized narrative + explicit trade-off corner.

Internal architecture

Uber ride request whiteboard layout:

Panel 1 — Context                    Panel 2 — Sync path (left → right)
┌─────────────────────┐              Rider App → API GW → Dispatch Svc → Driver App
│ Actors: Rider,      │                    ↓              ↓
│ Driver, Dispatcher  │              Location Svc    Matching Engine
│ SLO: match < 30s    │                    ↓              ↓
│ Constraints: peak   │              Redis geo-index   PostgreSQL trips
└─────────────────────┘

Panel 3 — Async (dotted arrows below)
Dispatch Svc - - -> Kafka - - -> Surge Pricing Svc - - -> Redis fare cache
              - - -> Analytics pipeline

Corner: TRADE-OFFS
• Sync matching: p99 latency; sacrifice: coupling on hot path
• Async surge: availability; sacrifice: eventual fare consistency (≤2s)

Data flow

Whiteboarding narration script synchronized with drawing for Uber ride matching:

• Minute 0–3: Panel 1 only — actors, SLO, constraints. No boxes yet on sync path.
• Minute 3–15: Panel 2 left-to-right — "rider taps request" draw each box as you speak.
• Minute 15–25: Panel 3 async below — dotted lines, different color if virtual whiteboard.
• Minute 25–30: Trade-off corner + deep dive on one box interviewer selects.

// Virtual whiteboard tool structure (Excalidraw/Miro) — export to ADR
const WHITEBOARD_LAYERS = {
  context: { actors: ["Rider", "Driver"], slo: "match p99 < 30s" },
  syncPath: [
    { id: "app", label: "Rider App", next: "gw" },
    { id: "gw", label: "API Gateway", next: "dispatch" },
    { id: "dispatch", label: "Dispatch Svc", next: ["location", "matching"] },
    { id: "matching", label: "Matching Engine", store: "postgres" },
  ],
  asyncPath: [
    { from: "dispatch", to: "kafka", style: "dotted" },
    { from: "kafka", to: "surge", style: "dotted" },
  ],
  tradeoffs: [
    "Sync matching for p99; async surge for scale",
  ],
};

System design diagram

Two diagrams show the Architecture Whiteboarding topology and the primary request/event path used in production at scale.

Production code example

Excalidraw RFC template — Uber three-panel standard exportable to ADR:

<!--
RFC Diagram Template (Excalidraw embed in internal RFC)
Panel 1: Context box — actors, SLO, constraints (top-left)
Panel 2: Sync flow — left-to-right, solid arrows (center)
Panel 3: Async flow — bottom, dotted arrows
Corner: Trade-offs list — explicit sacrifices
Legend: solid=sync, dotted=async, lock=PII store
-->
<!-- After RFC approval: export PNG to ADR attachments within 24h -->

Enterprise case study

Uber RFC program — diagram standards: After multiple failed staff panels due to communication, eng education added mandatory whiteboarding workshop: three-panel layout, trade-off corner, trace walkthrough — staff pass rate on communication rubric improved 35%.

• Before: strong architects failing staff on "panel couldn't follow diagram."
• Decision: three-panel standard + synchronized narration training + Excalidraw RFC template.
• After: RFC approval time −40%; staff interview communication scores normalized across sites.

Trade-offs

• Detail vs readability: Staff interviews reward clarity over completeness — 7 labeled boxes beat 40 unnamed ones.
• Physical vs virtual: Virtual whiteboard exports to ADR; physical needs photo — both need layout discipline.
• Diagram vs narrative: Diagram supports story — if narration and drawing desync, panel gets lost.

Security considerations

Security is architectural: Whiteboards in interviews and RFCs should show trust boundaries — where auth happens, what's public vs internal.

• Identity: draw auth at gateway — not scattered implicit auth on every box.
• Data: mark PII stores with lock icon convention; show encryption boundary.
• Interview: don't write secret internal service names in virtual boards that leak — use generic labels.

Scalability analysis

Scale dimensions: Uber whiteboards must communicate scale decisions — write QPS, partition strategy, hot spot callout on diagram.

• Annotation: write "10K QPS peak" on hot path arrow — shows estimation without separate sheet.
• Sharding callout: box corner note "shard by geohash" on matching engine.
• Multi-region: duplicate panel or dashed box for DR region — don't cram into one diagram.

Failure scenarios

What breaks: spider diagram; unlabeled arrows; erasing during trace walk; no trade-off corner; diagram contradicts verbal description.

• Spider diagram: stop at 9 boxes; start new panel.
• Unlabeled arrows: every arrow: protocol + payload name (gRPC/MatchRequest).
• Trace failure: practice "walk request through" before interview — panel always asks.

Staff engineer insights

• Draw slower than you think — panel follows your pen; rushing creates spider diagrams.
• Trade-off corner is your staff signal — write sacrifices visibly, not only say them.
• When interviewer says "go deeper," erase one panel, not the whole board — depth on one seam beats redrawing everything.

Interview questions

Architecture review questions

• Are quality attributes (latency, availability, consistency) explicit with SLOs for Architecture Whiteboarding?
• Is the failure/degraded mode documented — including what happens when dependencies are down?
• Are boundaries and ownership clear on an architecture diagram a new engineer understands in 10 minutes?
• Is there an ADR capturing alternatives considered and why they were rejected?
• Can this design scale 10× on traffic and 3× on engineering headcount without a rewrite?
• Security: authn/authz, encryption, and blast radius reviewed at every external interface?

Summary

Architecture Whiteboarding at Uber is communication discipline — three panels, labeled flows, trade-off corner, and synchronized customer-story narration. Diagram clarity predicts RFC success and staff interview outcomes as much as technical depth.