Guides / system-design
System design
How to design large, scalable systems, and how to run a system design interview: requirements, estimates, building blocks and trade-offs.
31 Jan 2025· 3 min· 7 sections
In this guide · 7 sections
What is being evaluated
How do you build large, scalable systems? In a system design interview there is no right answer: what is evaluated is how much you know about architecture, your maturity and your repertoire. That is why it pays to have a few real cases up your sleeve and, above all, to ask a lot about the requirements before drawing.
The script
A typical interview lasts 40 to 50 minutes. Keep track of time and take notes of what needs to be discussed.
- Scope and requirements: purpose, audience, main features and non-functional requirements (latency, availability, volume).
- High-level solution:
- Top-down, focused on the features you defined.
- Define how the parts communicate (REST, gRPC, WebSockets).
- Draw the schema according to the chosen solution.
- Don’t go into details before the overall design is standing.
- Deep dive: for each problem, bring two solutions, discuss the trade-offs and pick one.
- Wrap-up: summarize, point out bottlenecks and what you would do with more time.
Capacity estimates
Before picking technology, estimate: daily and hourly traffic, peaks, bandwidth, disk for 1 to 5 years and redundancy. Back-of-the-envelope math is enough.
Example: a link shortener with 100 million new links per month.
| Calculation | Result |
|---|---|
| Writes per second | 100M ÷ (30 × 24 × 3,600) ≈ 40/s |
| Reads (100:1 ratio) | ≈ 4,000/s |
| Disk over 5 years (500 bytes per link) | 100M × 12 × 5 × 500 B ≈ 3 TB |
Conclusion: it is a read-heavy system, so caching and read replicas matter more than the write database.
Building blocks
Databases
| Type | Good for | Examples |
|---|---|---|
| Relational | Structured data, transactions, flexible queries | PostgreSQL, MySQL |
| Document | Varying structures, reading the whole object | MongoDB |
| Key-value | Very fast access by key, cache, session | Redis, DynamoDB |
| Wide-column | High write volumes, time series | Cassandra |
| Graph | Complex relationships (social networks, recommendations) | Neo4j |
| Search | Free text, filters and relevance | Elasticsearch |
Relational databases offer ACID transactions: atomicity (all or nothing, with commit and rollback), consistency, isolation (concurrent transactions don’t interfere) and durability (what was committed survives crashes). Many NoSQL databases give up part of this in exchange for scale, accepting eventual consistency.
Communication and entry points
- APIs: REST (simple and universal), gRPC (efficient between services), GraphQL (the client picks the fields).
- Load balancer (Nginx, Traefik): spreads traffic and can split reads from writes.
- Cache: in front of the database for repeated reads.
- WebSockets: for real time; scaling them means dealing with long-lived connections and which instance holds each user.
Messaging
Decouples producers from consumers and absorbs peaks. Queues (SQS, RabbitMQ) for distributed work; topics and streaming (Kafka, Pub/Sub) for events with several consumers; stream processing with Flink.
Observability and data
Observability from the start, and a data lake when the business needs to analyze history.
Databases × microservices
| One database per service | One shared database | |
|---|---|---|
| Coupling | Low: each service evolves on its own | High: changing a table affects several services |
| Scale | Independent | A heavy service affects everyone |
| Data | Slightly duplicated, eventual consistency, risk of drift | Consistent, but without a clear owner |
The general rule is one database per service, with events to sync what is needed (see CQRS).
Tips
- Research technologies that solve the problem, but don’t propose what you don’t master.
- Balance design patterns, clean code and high performance: the three don’t always fit together.
- Say the trade-offs out loud: the interviewer wants to see the reasoning.
References
- System Design Primer: open material with the building blocks and exercises.
- Designing Data-Intensive Applications (Martin Kleppmann, O’Reilly): the reference for databases, replication and consistency.