System Design Basics
A starter framework for the open-ended design round: requirements, API, data model, scale, and the handful of building blocks you'll always reach for.
On this page
Past the junior level, most interview loops include a system design round: "design a URL shortener," "design a news feed," "design a chat app." It's open-ended and can feel unbounded, but it has structure. This lesson gives you a framework to drive the conversation and the handful of building blocks you'll reach for every time. (This is an on-ramp, not a full course - system design is a career-long study.)
A framework to drive the conversation
The failure mode is jumping straight to databases. Instead, drive the discussion through these steps:
- Clarify requirements. Functional ("users shorten a URL and get a short link") and non-functional ("read-heavy, low latency, highly available"). Ask about scale: how many users, reads/writes per second, data size?
- Estimate scale. Rough back-of-envelope numbers - requests per second, storage per year - so your design targets the right order of magnitude.
- Define the API. The handful of endpoints (
POST /shorten,GET /{code}). This pins down the contract before the internals. - Sketch the data model. What entities and how they're stored - and whether that suggests SQL or NoSQL.
- Draw the high-level design. Client → load balancer → service → database/cache, and walk a request through it.
- Address scale and bottlenecks. Now add caching, replication, sharding, queues - justified by the numbers from step 2.
The building blocks you'll always use
A small vocabulary covers most designs:
- Load balancer - spread traffic across service instances.
- Cache (Redis) - keep hot data in memory to cut latency and database load.
- Database - SQL for structured, relational, transactional data; NoSQL for scale, flexible schema, or simple key-value/document access.
- Replication - copies of the database for read scaling and failover.
- Sharding / partitioning - split data across machines when it won't fit or a single DB can't keep up.
- Message queue (Kafka) - decouple producers from consumers, absorb spikes, enable async work.
- CDN - serve static content from the network edge, close to users.
The trade-offs are the point
There are no perfect designs, only trade-offs, and voicing them is what interviewers want. SQL vs. NoSQL, strong vs. eventual consistency, more caching (faster, but stale data risk), normalization vs. denormalization. The famous CAP theorem - under a network partition you must choose consistency or availability - is the classic articulation. Naming the trade-off and justifying your choice beats pretending one exists.
Read-heavy vs. write-heavy shapes everything
One clarifying question does a lot of work: is the system read-heavy or write-heavy? A read-heavy system (a URL shortener, a news feed) leans on caching and read replicas. A write-heavy system (analytics ingestion, logging) leans on queues, batching, and write-optimized stores. Establishing this early focuses the whole design.
A coding question is cooking one dish well. System design is designing the whole restaurant: how many seats (scale), how the kitchen is laid out (services), where you keep ingredients for speed (caching), how orders flow from tables to kitchen to delivery (the request path), and what happens on a packed Friday night (handling load spikes with queues and extra staff). You don't obsess over one recipe; you make sure the whole operation stays fast and standing when a rush hits - and you explain why you'd add a second kitchen before a fancier oven.
Sketch how you'd open a 'design a URL shortener like bit.ly' round. Give the clarifying questions, the core API, and the single most important characteristic that shapes the design.
What should you do FIRST in a system design interview?
Key takeaways
- System design rounds are open-ended but structured: clarify requirements, estimate scale, define the API, sketch the data model, draw the design, then address bottlenecks.
- Don't jump to databases first - establish what the system does and how big it is.
- Core building blocks: load balancer, cache, SQL/NoSQL database, replication, sharding, message queue, CDN.
- Interviewers want trade-offs voiced: SQL vs NoSQL, consistency vs availability (CAP), caching vs staleness.
- Asking 'read-heavy or write-heavy?' early focuses the entire design. This is an on-ramp; system design is a deep, ongoing study.