System Design Diagram Patterns

Architecture diagrams are the shared language of system design. Whether you are presenting to stakeholders, writing a tech spec, or preparing for a system design interview, the patterns you choose communicate both the structure and the intent of your system. This guide walks through the most common patterns, when to use them, and what to watch for.

Three-Tier Architecture

The three-tier pattern separates a system into presentation, application logic, and data layers. It remains the most widely deployed pattern for web applications because of its simplicity: a load balancer distributes traffic to stateless app servers, which read and write to a shared database.

In a diagram, draw three horizontal bands. The top holds your load balancer and CDN. The middle holds your application servers, typically grouped inside a dashed boundary to show horizontal scaling. The bottom holds your primary database with an optional read replica. Arrows flow downward for requests and upward for responses.

Three-tier works well for CRUD-heavy applications, internal tools, and small-to-medium SaaS products. It starts to show strain when different parts of the application scale at different rates, or when you need event-driven processing.

Event-Driven Architecture

In an event-driven system, components communicate by producing and consuming events through a message broker such as Kafka, RabbitMQ, or AWS SNS/SQS. The diagram typically shows producers on the left, the broker in the center, and consumers on the right, with arrows indicating message flow direction.

The key advantage visible in the diagram is decoupling: producers don't know about consumers and vice versa. This makes it easy to add new consumers without modifying existing code. Use dashed arrows for asynchronous messages and solid arrows for synchronous HTTP calls to make the communication style immediately clear.

Watch for fan-out patterns where a single event triggers multiple consumers. Draw these explicitly rather than using a single arrow with a note. Reviewers should see the blast radius of each event type at a glance. Also consider adding a dead-letter queue node to show how failed messages are handled.

Microservices with API Gateway

A microservices diagram starts with an API gateway that routes requests to individual services. Each service owns its database, enforcing the data ownership boundary that defines microservices. Draw each service as a box with its own database beneath it, connected by a vertical arrow.

Inter-service communication adds complexity. Use solid arrows for synchronous REST or gRPC calls and dashed arrows for async messages. Color-code or label each arrow with the protocol: this prevents the common interview mistake of drawing a clean diagram that hides a web of synchronous dependencies.

Group related services into bounded contexts using dashed rectangles. This shows the domain boundaries clearly and hints at team ownership. A well-drawn microservices diagram should make team boundaries as visible as technical ones.

CQRS and Event Sourcing

Command Query Responsibility Segregation splits reads and writes into separate paths. In a diagram, draw the write path on the left (command handler, event store, projectors) and the read path on the right (read model, query API). A message bus connects the two via domain events.

This pattern is worth diagramming explicitly when your read and write workloads differ significantly in shape or scale. For instance, a system that ingests thousands of writes per second but serves millions of cached reads benefits from the visual clarity of separated paths.

Data Pipeline Architecture

Data pipelines follow a left-to-right flow: sources, ingestion, processing, storage, and serving. Each stage is a distinct column in the diagram. Draw data sources on the far left (databases, APIs, event streams), processing tools in the center (Spark, Flink, dbt), and destination stores on the right (data warehouse, feature store, search index).

Label each arrow with the data format and rough volume. This turns a generic ETL diagram into a useful architecture document. For example, "JSON events, ~10K/sec" on an arrow from Kafka to a processor tells the reader more than an unlabeled line.

Diagram Best Practices

Good architecture diagrams follow a few universal rules regardless of the pattern. First, establish a consistent flow direction: top-to-bottom for request flow, left-to-right for data pipelines. Second, use color or line style to distinguish sync from async communication. Third, include a legend if you use more than two visual encodings.

Avoid the temptation to put everything on one diagram. A context-level view shows the system and its external dependencies. A container-level view shows the major deployable units. A component-level view shows the internals of a single container. Mixing levels creates noise rather than clarity.

Try building these patterns yourself with the Architecture Diagram Builder. The template gallery includes several of the patterns described here as starting points. For code-driven diagrams, the Mermaid Renderer is a complementary tool that generates diagrams from text syntax.