Drawing Architecture Diagrams

In a system design interview, your diagram IS your design. The interviewer can’t see inside your head, so they’re evaluating your thinking through what’s on the whiteboard or screen. A messy, disorganized diagram signals confused thinking. A clean, well-organized diagram shows you understand how components relate, what data flows between them, and why they’re positioned that way.

Here’s the hard truth: many candidates skip the diagram or draw a vague box labeled “backend.” This is a missed opportunity. Your diagram should evolve throughout the interview as you add detail, respond to challenges, and realize new requirements. It becomes a shared artifact that guides the entire conversation.

What Should You Actually Draw?

A system design diagram typically contains these layers and components:

Client Layer: Web browsers, mobile apps, desktop clients. Draw these on the left or top.

Edge/API Layer: Load balancers, API gateways, CDNs. This is where traffic enters your system.

Service Layer: The business logic. Your microservices, application servers, or monolith. These process requests and orchestrate work.

Data Layer: Databases, caches, data warehouses. This is where state lives.

Infrastructure Components: Message queues, job schedulers, monitoring systems, logging systems.

External Services: Third-party APIs, payment processors, analytics providers.

The key principle: every box needs a name and a purpose, every arrow needs a label. An unlabeled arrow confuses everyone. Is it HTTP? gRPC? Async events through a queue? The specificity matters because it affects your design.

Organization: The Flow Approach

We recommend organizing diagrams left-to-right to show request flow, or top-to-bottom for client-to-storage progression. Consistency matters. Pick one direction and stick with it.

Here’s a diagram evolution for a social media feed system:

STEP 1: Basic Architecture (5 minutes in)
┌──────────┐      ┌────────────┐      ┌──────────┐
│  Client  │─────▶│ API Server │─────▶│ Database │
└──────────┘      └────────────┘      └──────────┘

STEP 2: Add Infrastructure (15 minutes in)
┌──────────┐      ┌──────────┐      ┌────────────┐      ┌─────────┐      ┌──────────┐
│  Client  │─────▶│   Load   │─────▶│ API Servers│─────▶│  Cache  │      │ Database │
└──────────┘      │ Balancer │      └────────────┘      └─────────┘      └──────────┘
                  └──────────┘             │
                                           ├──────────────────▶ ┌──────────────┐
                                           │                    │ Message Queue│
                                           ▼                    └──────────────┘
                                    ┌────────────────┐
                                    │ Feed Generation│
                                    │   Service      │
                                    └────────────────┘

STEP 3: Add Read/Write Paths (25 minutes in)
Shows separate read and write data flows, replicas, sharding strategy

Notice how we progressively add detail. You’re not expected to draw the final diagram from scratch. You’re building it collaboratively with your interviewer.

Key Diagram Principles

Layering by Concern: Separate read path from write path using different colors or grouping. Draw hot paths (frequent, critical) differently from cold paths (infrequent, non-critical).

Communication Patterns:

Synchronous (solid arrows): HTTP, gRPC, direct RPC calls
Asynchronous (dashed arrows): Kafka, message queues, event buses
Broadcast (fanned arrows): publish-subscribe patterns

Representing Scale:

Show multiple instances behind a load balancer (draw 3 boxes stacked)
Draw replicas with “replica” label
Indicate sharding with “sharded by user_id” notation near the database

Data Format Notation: Label arrows with protocol and content type: “HTTP/JSON”, “gRPC/Protobuf”, “Thrift”, etc.

Common Mistakes to Avoid

Too Many Boxes: 50+ components overwhelm the diagram. You can’t discuss every microservice in 45 minutes. Combine related services into logical groups.

No Labels: Unlabeled boxes and arrows force the interviewer to ask clarifying questions. You lose time and credibility.

No Direction: Always put arrowheads on arrows. Direction matters. If bidirectional, show both directions or explicitly mention it.

Mixing Abstraction Levels: Don’t draw the queue implementation and the message format in the same box. Pick an abstraction level and stay consistent.

Forgetting the Database: Surprisingly common. Every system stores data somewhere. Name your database technology.

No Indication of Protocol: A box labeled “Database” tells me nothing about consistency guarantees or whether you’re thinking about network protocols.

Trying to Be Too Pretty: Your diagram is a thinking tool, not a presentation slide. It’s okay if it’s messy. Clarity matters more than aesthetics.

Here’s how we recommend approaching the diagram:

Minute 5: Draw the “happy path” — the main user request flow. For a social media feed: client → API → database. Three boxes, two arrows. Simple.

Minute 15: Add infrastructure as you identify needs. “We need to cache feed results” — add a cache box. “Notifications need to be async” — add a message queue.

Minute 25: Zoom into specific components. Split the API layer into multiple services. Show database replication. Indicate sharding strategy.

Minute 35: Add supporting systems. Logging, monitoring, analytics. Only if there’s time and relevance.

Minute 45: Accept the diagram as “complete” for this conversation, but acknowledge what you’d do differently at scale.

Pro Tips for Diagram Drawing

Use consistent notation throughout: If you draw services as boxes, keep drawing them as boxes. Don’t switch to circles mid-interview.

Label everything the first time: Don’t draw a box and say “we’ll call it X later.” Name it immediately.

Draw with your interviewer: Pause before adding something major and ask, “Should I add caching here?” This keeps them engaged.

Redraw messily rather than erase: If you want to reorganize, just draw it again next to the old version. Erasures often hide your thinking process.

Use digital tools if available: Figma, Excalidraw, or even Google Drawings are better than whiteboards for system design because they’re cleaner and you can undo.

Leave space: Draw in the middle of your canvas. You’ll want room to add components on all sides.

Practice Exercise

Draw architecture diagrams for these three systems, progressively adding detail:

E-commerce Platform: Start with client → API → DB. Then add cart caching, order processing queue, payment service integration. Then add read replicas, CDN for images, analytics.
Real-time Chat: Start with client → API → DB. Then add WebSocket handling, message queue for offline delivery, user presence tracking. Then add message search service, read receipts handling.
URL Shortener: Start with client → API → DB. Then add cache for hot URLs, analytics queue, redirect path optimization. Then add geo-distribution, custom domain support.

For each system, time yourself: can you draw the full evolved diagram in 5 minutes? That’s a good baseline.

Key Takeaways

Your diagram is your communication tool. It’s how the interviewer understands your design. Make it clear.
Progress from simple to complex. Start with 5-6 boxes, then add detail based on requirements and interviewer questions.
Every box needs a name and purpose. Every arrow needs a label showing protocol and direction.
Separate concerns with layering or color: read vs write paths, hot vs cold paths, sync vs async.
Avoid common mistakes: too many boxes, no labels, unlabeled arrows, inconsistent notation, missing databases.
Draw for clarity, not beauty. Your thinking process matters more than aesthetic perfection.
Practice drawing different systems. You’ll develop muscle memory for component placement and notation.

Next Up: Now that you can clearly communicate what you’re building, let’s talk about defending why you built it that way. The next section covers articulating trade-offs—the hallmark of senior engineering thinking.

System Design Fundamentals