1What is the standard shape for representing a database in a system design diagram?
Vetora✏️Interview Toolkit
Drawing System Design Diagrams
How to draw clear, effective architecture diagrams during a system design interview. Learn standard shapes, arrow conventions, progressive layering, and how to communicate your design visually on a whiteboard or digital canvas.
Overview
A system design interview is fundamentally a visual exercise. The diagram you draw on the whiteboard or digital canvas is the primary artifact the interviewer evaluates -- it communicates your architecture, data flow, and technical decisions more effectively than verbal explanation alone. Candidates who draw clear, well-organized diagrams consistently score higher because the interviewer can see the entire system at a glance, follow the request path from client to database and back, and verify that no critical component is missing. Conversely, a messy diagram with crossing arrows, unlabeled boxes, and no clear flow creates confusion that the interviewer may interpret as confused thinking.
Standard shapes are the vocabulary of architecture diagrams. Use rectangles for services and application components (API Gateway, User Service, Payment Service), cylinders for databases and persistent storage (PostgreSQL, Redis, S3), cloud shapes for CDNs and external services, rounded rectangles or parallelograms for message queues and event buses, and stick figures or device icons for clients. Consistency matters -- if you draw databases as cylinders, draw all databases as cylinders. If you label one service, label every service. The shapes should be immediately recognizable so the interviewer does not need to ask what a component represents.
Arrows represent data flow and should always be labeled. The direction of the arrow indicates the direction of data flow or the request/response path. Label arrows with the protocol or API call: 'HTTP GET /users', 'gRPC', 'WebSocket', 'pub/sub', 'async via Kafka'. This level of specificity demonstrates that you understand how components communicate, not just that they are connected. Double-headed arrows can represent bidirectional communication (WebSocket connections), while dashed arrows can indicate asynchronous or eventual operations.
Progressive refinement is the drawing strategy that pairs with the four-step framework. During the High-Level Design phase, draw 3-5 boxes representing the major layers: client, CDN/load balancer, API layer, service layer, data layer. Connect them with labeled arrows showing the primary request path. During the Deep Dive, zoom into specific components -- expand a single 'Database' box into a primary with read replicas, add a cache layer between the service and database, or decompose a monolithic service box into microservices. This approach lets you build complexity incrementally without cluttering the board early on.
Key Points
- 1Use standard shapes consistently: rectangles for services, cylinders for databases, clouds for CDNs and external services, rounded rectangles for queues. Consistency makes the diagram scannable at a glance.
- 2Label every arrow with the protocol or operation: HTTP, gRPC, WebSocket, Kafka publish, SQL query. Unlabeled arrows force the interviewer to guess how components communicate, which can be misinterpreted as vagueness in your design.
- 3Layer your diagram from left to right or top to bottom: Client to CDN to Load Balancer to API Gateway to Services to Cache/Database. This standard layering matches how the industry draws architecture diagrams and is immediately familiar to interviewers.
- 4Start with 3-5 boxes during high-level design. Resist the urge to draw every component at once. Add detail progressively during the deep dive by expanding boxes into sub-components or adding new layers (caching, message queues, monitoring).
- 5Reserve whiteboard real estate strategically. Put requirements in one corner, the main architecture in the center, and deep-dive details in the remaining space. Running out of space mid-interview forces you to erase or cram, neither of which looks polished.
- 6Practice drawing digitally if your interview is remote. Tools like Excalidraw, draw.io, and Miro have different interaction models than a physical whiteboard. Slow, clumsy drawing in a remote interview wastes time and makes you appear less prepared.
Simple Example
The Blueprint Analogy
Drawing a system design diagram is like showing a building blueprint. An architect does not describe a building only with words -- they draw it, using standardized symbols: thick lines for walls, dotted lines for electrical, blue lines for plumbing. Anyone trained in reading blueprints immediately understands the layout. Similarly, using standard shapes (rectangles for services, cylinders for databases) and labeled connections lets any engineer instantly understand your system's architecture. A blueprint that uses random shapes and unlabeled lines would be sent back for revision -- and a system design diagram with the same issues receives the same response from an interviewer.
Real-World Examples
Netflix
Netflix's publicly shared architecture diagrams follow a standard layering pattern: mobile/web clients at the top, an API Gateway (Zuul) receiving all requests, backend microservices handling specific domains (personalization, streaming, account), with data stores (Cassandra, EVCache, S3) at the bottom. Arrows are labeled with protocols (REST, gRPC) and even show the data flow for specific scenarios (how a play request travels from the client through the CDN to the Open Connect servers). This layered, labeled style is the gold standard for interview diagrams.
Uber
Uber's architecture diagrams emphasize geo-based decomposition. The standard layering applies (client, gateway, services, data), but with an additional dimension: services are grouped by geographic region (city-level dispatch, regional pricing, global trip history). This teaches an important diagramming lesson -- when your system has a meaningful partitioning dimension beyond the standard layers, make it visually explicit. In an interview, drawing geographic boundaries on your diagram demonstrates awareness of data locality and latency constraints.
Stripe
Stripe's published API architecture uses a contract-first diagram style. The diagram starts with the API surface (endpoints and their contracts), then shows the internal services that implement each endpoint. Arrows flow from API endpoints to internal services, clearly showing which service owns which capability. This approach is especially effective in interviews for API-heavy systems because it directly connects user-facing functionality to internal architecture, making the design easy to evaluate against the requirements.
Trade-Offs
| Aspect | Description |
|---|---|
| Detail vs Clarity | More detail makes the design more complete but can make the diagram harder to read. A diagram with 20 components and 40 arrows becomes unreadable. Show the right level of detail for each phase: 5 boxes in high-level design, 10-15 in the deep dive. If a section gets complex, draw a zoomed-in sub-diagram rather than cramming everything into one view. |
| Speed vs Neatness | Interview time is limited, so speed matters. But a messy diagram with crossed arrows and illegible labels hurts more than it helps. Find the middle ground: draw boxes roughly aligned, use straight-ish arrows, and write labels legibly. You are not producing art -- you are producing a communication tool. |
| Standard Notation vs Custom Notation | Standard shapes (rectangles, cylinders) are immediately understood by any engineer. Custom notations (color coding, unique shapes) can convey more information but require explanation. Stick to standard shapes during the interview and use color or shading sparingly for emphasis if the tool supports it. |
| Physical Whiteboard vs Digital Canvas | Physical whiteboards are natural and quick but cannot be rearranged, copied, or zoomed. Digital canvases (Excalidraw, Miro) allow restructuring and infinite space but have a learning curve and can feel less natural. Practice with whichever medium your interview will use. |
Case Study
How Diagram Quality Changed an Interview Outcome
Scenario
Two candidates designed the same e-commerce system in separate interviews. Candidate A verbally described a solid architecture with microservices, caching, and message queues, but their diagram was a tangle of unlabeled boxes connected by crossing arrows with no clear flow direction. Candidate B had a slightly simpler design but drew it with clear layering, labeled arrows, and standard shapes. Both candidates had equivalent technical depth in their verbal explanations.
Solution
Candidate B's approach was structured: they started with a clean left-to-right layout (Browser -> CDN -> Load Balancer -> API Gateway -> Services -> Database), added labeled arrows (HTTPS, gRPC, SQL, Kafka), and progressively refined during the deep dive by expanding the 'Services' box into Order Service, Inventory Service, and Payment Service. They used a cylinder for PostgreSQL, a separate cylinder for Redis cache, and a rounded rectangle for the Kafka message queue. The diagram was self-documenting -- the interviewer could understand the design without verbal explanation.
Outcome
Candidate B received a 'Hire' recommendation while Candidate A received 'No Hire.' The interviewer feedback for Candidate A noted 'difficulty following the design' and 'unclear data flow,' despite acknowledging the technical ideas were sound. Candidate B's feedback highlighted 'clear communication' and 'well-organized architecture.' The difference was not in what they designed, but in how effectively they communicated it visually.
Common Mistakes
- ⚠Drawing boxes without labels. Every box on your diagram should have a name. An unlabeled box forces the interviewer to interrupt and ask 'What is this?' which breaks your flow and suggests you are not being thorough.
- ⚠Using arrows without direction or labels. An undirected line between two boxes communicates nothing about the relationship. Does data flow from A to B, B to A, or both? What protocol? What API call? Label every arrow.
- ⚠Cramming the entire design into one diagram. If your system has 15 components, do not try to show all of them at once. Use a high-level view with 5-7 components and create focused sub-diagrams for deep-dive areas.
- ⚠Not aligning with standard reading order. Most people read left-to-right and top-to-bottom. Place clients on the left (or top) and databases on the right (or bottom). Fighting against reading order makes your diagram harder to follow.
Related Concepts
See Drawing System Design Diagrams in action
Explore system design templates that use drawing system design diagrams and run traffic simulations to see how these concepts perform under real load.
Browse TemplatesPractice drawing system diagrams with the e-commerce template
Metrics to watch
component_countedge_count
Test Your Understanding
2Why should arrows in system design diagrams be labeled?