Diagramming Skills for System Design Interviews

TL;DR: Your diagram is the shared artifact the interviewer uses to evaluate whether you hold a coherent architecture in your head. A clean diagram does not guarantee a hire, but an unreadable one frequently guarantees a no-hire because the interviewer cannot tell if the reasoning behind it is sound¹. Use a disciplined subset of C4’s Container level², borrow sync/async arrow semantics from UML sequence diagrams, and practice in Excalidraw (123K GitHub stars, embedded in CoderPad³) until you can produce a labeled architecture in under 5 minutes.

Learning Objectives

After this module, you will be able to:

• Draw a consistent architecture diagram with clear boundaries between clients, services, data stores, and queues
• Use directional arrows and protocol labels so data flow is unambiguous
• Switch fluently between whiteboard and Excalidraw without losing speed
• Recognize and reuse five recurring diagram patterns across any interview problem
• Avoid the “eight boxes” and “monolith blob” anti-patterns that signal shallow thinking

Intuition

Think about how a subway map works. The London Tube map is not geographically accurate. It distorts distances, straightens curves, and uses color to group lines. But any tourist can plan a route in seconds because the notation is consistent: circles are stations, colored lines are routes, interchanges are white circles with multiple colors. Nobody needs a legend because the vocabulary is tiny and every element follows the same rules.

Your interview diagram is a subway map for an architecture. The interviewer is the tourist. They have 45 minutes to understand your system, probe its weak points, and decide whether you can build it. If your diagram uses inconsistent shapes, unlabeled arrows, and random layout, the interviewer spends cognitive budget parsing your picture instead of evaluating your reasoning. That is time they cannot spend giving you credit.

The good news: you only need about six shapes, two arrow styles, and one layout convention to produce diagrams that scan instantly. The rest is practice. This chapter gives you the vocabulary, shows you the tools, and drills the muscle memory so that diagramming becomes automatic and your brain stays free for the hard engineering decisions.

Theory

Notation that scans

A scannable diagram uses a constrained vocabulary of shapes so the reader never wonders “what does that rounded rectangle mean?”

The minimal set:

• Rectangles for services or processes (label with name + technology: “API | Go”)
• Cylinders for databases and persistent stores
• Parallelograms or double-bracketed boxes for queues and message brokers
• Rounded rectangles or stick figures for external actors and clients
• Circles for external systems you do not own

Every line is directional (one arrowhead), every line has a label describing the protocol or operation (“POST /tweet”, “gRPC”, “CDC”), and every line runs left-to-right for request flow or top-to-bottom for layered dependencies²⁴. This mirrors how English-speaking readers scan a page: left-to-right, top-to-bottom.

Color is optional. If you use it, group by function (blue for compute, green for storage, orange for async) and ensure the grouping is colorblind-safe. Never rely on color as the only signal.

Formal notations you should know (but not memorize)

Five formal approaches exist for describing software architecture. You do not need to use any of them in full during an interview, but knowing their vocabulary gives you defensible rigor when an interviewer asks “what notation is this?”

flowchart TD
    subgraph C4["C4 Model (Simon Brown, 2006-2011)"]
        direction TB
        L1[System Context] --> L2[Container]
        L2 --> L3[Component]
        L3 --> L4[Code]
    end
    subgraph UML["UML (14 diagram types)"]
        direction TB
        U1[Sequence Diagram]
        U2[Component Diagram]
        U3[Deployment Diagram]
    end
    subgraph Others["Other Frameworks"]
        direction TB
        A1["Arc42 (12 sections)"]
        A2["4+1 (Kruchten, 1995)"]
        A3["ArchiMate 3.2 (Open Group)"]
    end

C4 model is a hierarchical zoom: System Context (your system and its users), Container (applications, data stores, runtimes), Component (logical modules inside a container), and Code (class diagrams, optional)². C4 is notation-independent: it only prescribes that every element carries a type, a short description, and a technology label, and every line is unidirectional and labeled⁴. The Container level is essentially the HLD interview artifact with labels.

UML has 14 diagram types, but only three matter for interviews: the sequence diagram (lifelines, sync/async messages), the component diagram (logical modules and interfaces), and the deployment diagram (nodes and execution environments)⁵.

Arc42 is a 12-section documentation template. Sections 5 to 7 (Building Block View, Runtime View, Deployment View) map directly to interview artifacts⁶.

4+1 view model (Philippe Kruchten, 1995) uses five concurrent views: Logical, Development, Process, Physical, plus Scenarios that tie the others together⁷.

ArchiMate 3.2 organizes enterprise architecture into three core layers (Business, Application, Technology) plus four extensions. Its vocabulary is 50+ elements and is overkill for any 45-minute interview⁸.

Flow direction and arrow semantics

The single most impactful habit: make every arrow unambiguous.

sequenceDiagram
    participant Client
    participant LB as Load Balancer
    participant API as API Service
    participant Queue as Kafka
    participant Worker
    Client->>LB: POST /tweet (HTTPS)
    LB->>API: forward (gRPC)
    API-->>Client: 202 Accepted
    API->>Queue: publish tweet event
    Queue->>Worker: consume
    Worker-->>Queue: ack

Three rules:

1. Request flow runs left-to-right. Client on the left, downstream services on the right.
2. Layer hierarchy runs top-to-bottom. Load balancer at the top, data stores at the bottom.
3. Every arrow gets a label. Protocol + operation: “POST /login | HTTPS”, “gRPC | GetUser”, “Kafka | order.created”. An unlabeled arrow is an ambiguous arrow.

The sync/async distinction tells the interviewer whether you have thought about backpressure, retries, and failure modes. A solid arrow to a database means the caller blocks until the write completes. A dashed arrow to a queue means the caller continues without waiting for downstream processing. This is not decoration; it is architecture.

Tools: picking and practicing

Excalidraw (123K GitHub stars, MIT license) is the de facto remote-interview whiteboard³. Its deliberately hand-drawn aesthetic via Rough.js reduces perceived stakes: hand-drawn shapes signal “this is a sketch, we can revise” rather than “this is final.”¹⁰ Google Cloud, Meta, Notion, and Replit use it internally¹¹. CoderPad embeds Excalidraw as its Drawing Mode, making it the canvas for a large fraction of US tech interviews¹².

Mermaid is a text-based diagram DSL that renders natively on GitHub (since Feb 2022) and in most markdown pipelines. It is the right pick for written design docs because it versions cleanly alongside code. It is not suitable for live drawing in front of an interviewer because you cannot sketch iteratively.

Miro (100M+ users) and Lucidchart are heavier collaborative whiteboards. They load slowly and have deep menus; novices lose 2 to 3 minutes hunting for shapes in a live interview. Use them for multi-session design reviews inside a company, not for interviews.

tldraw and diagrams.net (draw.io) are free alternatives. Diagrams.net is the common drag-and-drop pick for architecture diagrams. tldraw is lighter but has a smaller user base.

Physical whiteboard technique: practice large handwriting (letters at least 3 cm tall), keep a “scratch” zone in the upper-right for estimation math, and always move the marker in the direction of the call so the arrowhead lands naturally at the end.

AWS / GCP / Azure icon sets: AWS publishes an official architecture icon set (SVG, PowerPoint, Visio) released three times per year (end of January, April, and July; no Q4 release)¹³. These icons are optional for interviews. A plain rectangle labeled “S3” scores identically to the canonical bucket icon.

Five recurring diagram patterns

Five diagram types cover nearly every interview question. Practice them as drills:

1. High-level architecture (flowchart) shows clients, edge, services, stores, and external dependencies as a single picture. This is the anchor diagram you draw first.

2. Sequence diagram shows one critical path (e.g., “post a tweet”) across lifelines with ordered sync/async messages. Exposes ordering, retry, and failure semantics.

3. Data flow diagram shows write and read paths through async pipelines (Kafka to Flink to Postgres), separate from the request diagram.

4. Deployment diagram shows physical topology: regions, availability zones, shards, replicas. Use subgraphs in Mermaid or color-coded zones in Excalidraw.

5. State machine shows resource lifecycle (order: pending to shipped to delivered to refunded) or connection state (WebSocket open/closed/reconnecting).

stateDiagram-v2
    [*] --> Draft
    Draft --> Published: submit
    Published --> Flagged: report
    Flagged --> Published: cleared
    Flagged --> Removed: upheld
    Published --> Deleted: author_delete
    Removed --> [*]
    Deleted --> [*]

Most candidates over-rotate on diagram type 1 and never switch modes. When the interviewer asks “what happens if the queue backs up?”, switch to a sequence diagram. When they ask “how does this deploy across regions?”, switch to a deployment diagram. The ability to switch diagram types mid-interview signals senior-level communication.

Real-World Example

Gergely Orosz documented how Uber’s engineering organization (hundreds of engineers, tens of dependent systems) handled architecture diagrams during the payments rewrite⁹. The findings are instructive for interview preparation:

No formal notation. No UML, no C4, no Arc42, no ADR templates. Engineers used “plain old boxes and arrows” captured in Google Docs RFC-style templates. Two diagrams within the same design document often had different layouts because different engineers added them at different times.

Simplicity as the top quality. The guiding principle was: “The simpler the system, the simpler it is to understand, the simpler it is to find issues with it.” Diagrams were kept jargon-free so the least experienced engineer could read the doc.

Iterative whiteboard sessions. Designs went through whiteboard sessions first, then a written RFC, then wide circulation to approximately 2,000 engineers for async review. The whiteboard sketch was the seed; the RFC diagram was the polished version.

flowchart LR
    U((User)) -->|HTTPS| CDN
    CDN -->|miss| LB[Load Balancer]
    LB --> Web[Web - React]
    Web --> API[API - Go]
    API --> Redis[(Redis - timeline cache)]
    API --> PG[(Postgres - users, tweets)]
    API -->|publish| MQ[[Kafka - tweet events]]
    MQ --> Fanout[Fanout Worker - Go]
    Fanout --> Redis
    API --> S3[(S3 - media)]

The lesson: even at Uber’s scale, the winning diagram style is disciplined boxes-and-arrows with labels, not formal notation. The discipline is what separates a hired candidate’s diagram from a no-hire’s.

Design decisions

Drawing strategy: up-front or iterative.

Canvas choice.

Common Pitfalls

Exercise

Pick one of Alex Xu’s case studies (URL shortener, rate limiter, or news feed). Open Excalidraw. Set a 5-minute timer. Draw the full architecture with labeled arrows, technology annotations, and at least one async boundary clearly marked. Save the image. Wait a day, redo the exercise without looking at your previous diagram. Compare the two. Iterate until your second pass matches the first in structure and is cleaner in layout.

Key Takeaways

• The diagram is the interview artifact. Treat it with the same care you would a pull request.
• Use six shapes, two arrow styles, and left-to-right layout. That is the entire notation.
• Label every arrow with protocol and operation. An unlabeled arrow is an ambiguous arrow.
• Excalidraw is the default remote-interview tool. Practice until you can produce a labeled architecture in under 5 minutes.
• Five diagram patterns (architecture, sequence, data flow, deployment, state machine) cover 90% of interview problems. Practice them as drills.
• Do not draw before you talk. Spend the first 5 minutes on requirements; each box earns its place from a requirement.
• Formal notations (C4, UML, Arc42) are useful vocabulary but not required ceremony. Disciplined boxes-and-arrows with labels is what actually ships at Uber, Meta, and Google.

Further Reading

• The C4 model for visualising software architecture - Simon Brown’s free guide; read the Notation and Review Checklist pages for the labeling discipline that transfers directly to interviews.
• Gergely Orosz: Software Architecture - Clear and Simple Design is Underrated - The “formal notations are not used at Uber/FAANG in practice” argument with concrete examples from Uber’s payments rewrite.
• Excalidraw and Excalidraw Libraries - The tool itself plus community-contributed system-design stencils for practice sessions.
• Mermaid.js documentation - Syntax for flowchart, sequenceDiagram, stateDiagram, erDiagram; read the flowchart and sequenceDiagram pages first.
• CoderPad Drawing Mode - The Excalidraw-based canvas you may encounter in a live interview; familiarize yourself with its toolbar before interview day.
• Hello Interview: System Design in a Hurry - The rubric categories (Problem Navigation, Solution Design, Technical Excellence, Communication) that your diagrams feed into.
• AWS Architecture Icons - The official cloud-icon deck released three times per year (Q1, Q2, Q3; no Q4 release); optional for interviews, useful for written design docs.
• Arc42 Documentation - The canonical reference for the 12-section template; useful for understanding where interview diagrams live in a production design doc.

Flashcards

References