System Design Fundamentals

6 min read

What System Design Actually Is

System design is the discipline of breaking a problem into components, deciding how they communicate, and choosing where state lives. It's not about memorizing architectures — it's about reasoning through trade-offs well enough to arrive at a defensible design for a specific set of requirements.

The process works in two passes. First, you zoom out to see the entire system as boxes and arrows — the High Level Design (HLD). Then, you zoom into the hardest or most interesting component and work through its internals — the Low Level Design (LLD). Both are essential: HLD without LLD is hand-waving; LLD without HLD is premature optimization of a piece you might not even need.

Between HLD and LLD, you'll reach for different diagram types to communicate your thinking. Each diagram is a projection of the same system from a different angle. An architecture diagram shows infrastructure. A sequence diagram shows time-ordered interactions. An ER diagram shows data relationships. You don't need all of them — you need the two or three that actually clarify the design you're proposing.

When This Comes Up

System design interviews: The entire interview is this — you're expected to produce an HLD, talk through data flow, and then deep-dive into one component's LLD when prompted. Knowing which diagram to reach for at which moment is a signal of experience.
Design documents: Real-world tech specs follow the same HLD → LLD structure. The architecture diagram goes at the top for the skip-level reader; the sequence diagrams and class diagrams go deeper for the reviewing engineer.
Cross-team communication: When explaining your system to another team, an architecture diagram or data flow diagram is worth a thousand words of prose. Diagrams are the shared language of system design.

How the Sub-Topics Connect

This topic splits naturally into two halves: the design levels (HLD and LLD — how you think about the system) and the diagram types (architecture, data flow, sequence, component, state, class, use case, ER — how you communicate the design). The diagram types aren't academic exercises; each one answers a different question:

1. High Level Design (HLD)

The bird's-eye view. HLD shows the end-to-end request path: clients, load balancers, API gateways, services, caches, databases, queues. It answers "what are the moving parts and how does data flow between them?" In an interview, this is what you draw in the first 10–15 minutes after gathering requirements. The goal is to show that every requirement has a home in the architecture — that a read request has a path, a write request has a path, and the non-functional requirements (caching, replication, async processing) are visible in the diagram.

HLD is where you make the big decisions: monolith or microservices? SQL or NoSQL? Synchronous or event-driven? These choices are hard to reverse later, which is why they deserve the most time.

2. Low Level Design (LLD)

The zoom-in. LLD takes one component from your HLD and works through its internals: the classes, interfaces, schemas, algorithms, and edge cases. If HLD is about which boxes to draw, LLD is about what's inside the hardest box. In an interview, the interviewer often picks the component they want you to go deep on — the fan-out service, the URL generator, the payment processor — and this is where you demonstrate SOLID principles, design patterns, and attention to corner cases.

LLD is where you catch the bugs that HLD can't see: race conditions, hot partitions, edge cases in state transitions, and schema design mistakes that would force a painful migration.

3–10. Diagram Types

The remaining eight sub-topics cover the diagram types you'll use to express both HLD and LLD. Each answers a specific question:

Diagram	Question It Answers	When to Use
Architecture Diagram	What are the components and infrastructure?	Always — the backbone of every HLD
Data Flow Diagram	How does data move and transform across boundaries?	When data transformation is the interesting part
Sequence Diagram	What messages pass between actors, in what order?	Handshakes, retries, consistency windows, multi-step flows
Component Diagram	What are the module dependencies?	When service/module boundaries matter
State Diagram	What lifecycle does an entity go through?	Orders, payments, tickets — anything with defined transitions
Class Diagram	What are the entities, attributes, and relationships?	LLD round — demonstrating OOP and SOLID design
Use Case Diagram	What can each actor accomplish?	Confirming scope with stakeholders
ER Diagram	How is the persistent data modeled?	Designing tables, keys, and cardinality

The key insight is that you should not produce all of these in an interview. Pick the two or three that actually clarify the design you're proposing. An architecture diagram is almost always one of them. A sequence diagram is usually the second. The third depends on whether the interesting part is data (ER diagram), state (state diagram), or object design (class diagram).

Sub-Topics

#	Sub-Topic	What You'll Learn
1	High Level Design (HLD)	The bird's-eye view — components, data flow, and big decisions
2	Low Level Design (LLD)	Zooming into one component — classes, schemas, algorithms, edge cases
3	Architecture Diagram	Showing components and infrastructure — the backbone of HLD
4	Data Flow Diagram	Tracing how data moves and transforms across process boundaries
5	Sequence Diagram	Ordered messages between actors over time
6	Component Diagram	Module dependencies and service boundaries
7	State Diagram	Entity lifecycles with defined transitions
8	Class Diagram	Entities, attributes, and relationships for LLD
9	Use Case Diagram	Mapping actors to goals for scope confirmation
10	ER Diagram	Persistent data modeling — tables, keys, and cardinality