Visual Guide
Learn the standard shapes, patterns, and conventions for drawing system design diagrams in interviews.
Standard Component Shapes
Each system component has a conventional shape that interviewers expect to see:
Client/Server
Rectangle
Services, apps, workers
Load Balancer
Diamond
Decision/routing points
Database
Cylinder
Any persistent storage
Cache
Hexagon
Redis, Memcached
Queue
Parallelogram
Kafka, RabbitMQ, SQS
CDN
Stadium/Rounded
Edge caching layer
Object Storage
Cylinder
S3, GCS, Blob
API Gateway
Rectangle
Entry point, routing
Common Patterns
Request-Response
The most basic pattern — client sends request, server responds synchronously.
Publish-Subscribe
Decoupled communication — publishers emit events, subscribers react independently.
Fan-Out
Distribute work across multiple workers for parallel processing.
Pipeline
Sequential stages where output of one becomes input to the next.
Arrow Types & Data Flow
Solid Arrow → Synchronous Call
Caller waits for response. Use for HTTP requests, RPC calls.
Dashed Arrow -.-> Asynchronous Message
Fire and forget. Use for message queues, event streams.
Thick Arrow ==> Data Stream
High-throughput data flow. Use for streaming pipelines.
Layout Patterns
Left-to-Right (graph LR)
Best for showing request flow from client to backend.
Top-to-Bottom (graph TD)
Best for showing layers: presentation → service → data.
Interview Drawing Tips
Start Simple
Begin with a high-level overview (3-5 boxes), then add detail as you discuss trade-offs.
Label Everything
Every arrow should have a label (HTTP, gRPC, async, pub/sub). Every box needs a clear name.
Show Data Flow
Indicate the direction of data. Use solid lines for sync, dashed for async communication.
Group Related Services
Use boxes/borders to group microservices that work together. This shows you think in domains.
Include Data Stores
Always show databases, caches, and queues. Mention the technology choice (PostgreSQL, Redis, Kafka).
Think About Scale
Show where horizontal scaling happens: multiple servers behind LBs, sharded databases, cache clusters.
Highlight Critical Path
Make the primary request path clear. Secondary/background flows can be added later.
Note Non-Functional Requirements
Annotate your diagram with throughput, latency targets, and consistency requirements.