What is a system design diagram?
A system design diagram is a visual representation of a software system's runtime components and how they interact. It shows the services, databases, caches, message queues, load balancers, CDNs, and clients that make the system function — and the data flows between them. System design diagrams are used in software architecture reviews, technical design documents, distributed systems interviews, and onboarding documentation.
Unlike UML or C4 diagrams, system design diagrams do not follow a rigid notation. The convention is pragmatic: boxes represent components, labeled arrows represent data flows, and the diagram is organized top-to-bottom from client to backend data stores. What matters is that every component has a clear role, every connection has a clear direction, and the diagram correctly represents how the system behaves under real load.
Standard components in a system design diagram
| Component | Symbol convention | Role |
|---|---|---|
| Client | Browser, mobile, or device icon | The external user or system that initiates requests. Labeled by client type (web, iOS, Android, third-party API). |
| CDN | Cloud box at edge | Distributes static assets (JS, CSS, images) from edge locations close to the user. Reduces latency and origin server load. |
| DNS / Global load balancer | Box above application tier | Resolves domain names and routes traffic to regional data centres. Enables geographic failover. |
| Load balancer | Box between client and servers | Distributes incoming requests across multiple application server instances for horizontal scaling and fault tolerance. |
| API Gateway | Box between client and microservices | Routes, authenticates, and rate-limits client requests before they reach individual microservices. |
| Application server / Service | Rectangles in application tier | Executes business logic. Labeled by domain (User Service, Order Service, Payment Service). |
| Cache | Cylinder or cloud labeled Redis/Memcached | Stores frequently accessed data in memory to reduce database load and latency. Sits between application tier and database. |
| Database | Cylinder labeled with type and role | Persists data. Show topology: primary, read replicas, or shards. Label SQL vs. NoSQL and specific technology (PostgreSQL, Cassandra). |
| Message queue / Event stream | Box labeled Kafka/RabbitMQ/SQS | Decouples services via asynchronous communication. Producers write events; consumers read them independently. |
| Object storage | Box labeled S3/GCS/Blob | Stores unstructured data (images, videos, logs) at scale. Accessed via HTTP API rather than database queries. |
Example: URL shortener system design
Use this prompt in flow-chart.io to generate a URL shortener system design diagram:
System design diagram for a URL shortener. Clients (browser, mobile) → CDN → Load Balancer → Write Service (generates short code, stores mapping) and Read Service (resolves short code to long URL). Write Service → PostgreSQL primary (stores URL mappings). Read Service → Redis cache (check first) → PostgreSQL read replica (fallback on cache miss). Write Service → Kafka (publish new URL event) → Analytics Consumer (writes to ClickHouse for analytics). Show separate read and write paths. Label all connections with HTTP/S or internal protocol.
System design diagram for interviews
System design interviews expect a clear diagram of the key components and their relationships. Follow this structure:
- Start with clients at the top and work downward through DNS, load balancers, services, and data stores.
- Label every box with its role and the technology name (e.g., "Auth Service — Node.js", "Cache — Redis").
- Draw arrows to show data flow direction. Annotate with protocol where it matters: REST, gRPC, WebSocket, AMQP.
- Separate the read path from the write path when they differ — CQRS patterns should show distinct flows.
- Show where data is stored and what reads from it. Examiners look for correct data placement, not just component names.
- Include a message queue if the system has asynchronous workloads (notification delivery, event processing, background jobs).
- Note horizontal scaling points (multiple service instances behind a load balancer) and replication (primary + read replicas).
Microservices vs. monolith architecture diagrams
| Dimension | Monolith | Microservices |
|---|---|---|
| Service count | One application box (may show internal modules) | Many service boxes, each labeled by business domain |
| Database | One shared database | Per-service databases (database-per-service pattern) |
| Communication | In-process function calls (not shown on diagram) | REST, gRPC, or message broker between services |
| Deployment unit | One box (scaled horizontally as a unit) | Independent boxes (each service scaled independently) |
| Diagram complexity | Simpler — fewer components | More complex — requires API gateway, service mesh, message broker |
| Failure isolation | Not shown (a single service failure affects everything) | Circuit breakers and retries annotated on inter-service connections |
Frequently asked questions
- What should a system design diagram include?
- A complete system design diagram includes: clients, CDN and DNS layer, load balancers, application servers or microservices, databases (primary and replicas), caches, message queues, and external services. Each component should be labeled with its role and technology. Connections should show data flow direction and protocol (HTTP/S, gRPC, AMQP).
- What is the difference between a system design diagram and an architecture diagram?
- A system design diagram focuses on runtime components — services, databases, caches, queues, and networks — and is used to reason about scalability, availability, and data flow. An architecture diagram is broader: it may represent code structure, deployment pipelines, or organisational concerns. System design diagrams are always about live infrastructure; architecture diagrams may be conceptual.
- How do I represent system design diagrams for interviews?
- Start with clients at the top, work downward through DNS, load balancers, services, and data stores. Label every box with role and technology. Draw arrows for data flow direction with protocol annotations. Separate read and write paths if they differ. Show where data is stored and what reads from it. Include message queues for asynchronous workloads.
- What components should I show in a microservices architecture diagram?
- Include an API gateway or BFF, individual microservices labeled by business domain, service-to-service communication (REST/gRPC or message broker), a message broker for event-driven communication, per-service databases, a distributed cache, a centralised logging and monitoring stack, and an identity/auth service.
- How do I show load balancers and databases in a system design diagram?
- Draw load balancers as a layer between clients and the application tier, with arrows pointing to multiple server instances. For databases, show topology: primary node with read replicas for SQL, or multiple shards for partitioned data. Draw a cache between the application tier and database, with arrows indicating reads check cache first.
- What is the difference between a system design diagram and a data flow diagram?
- A system design diagram shows components and runtime relationships — services, databases, caches, queues. A data flow diagram (DFD) focuses on how data moves and transforms through a system using formal notation: external entities, processes, data stores, and labeled data flows. System design diagrams are infrastructure-focused; DFDs are data-movement-focused.
- What export formats are available for system design diagrams?
- flow-chart.io exports system design diagrams as SVG (for technical documentation in Confluence, Notion, or GitHub wikis), PNG at 2× and 4× resolution (for slides and design docs), PDF (for architecture review documents), and JSON (re-importable scene graph for future editing). All exports are derived from the editable scene graph — not screen captures.