System Design Interview Part 2 - A Step by Step Guide

In part one I covered the mindset that gets you through a system design interview. This is the method: the sequence the strongest candidates follow so they never freeze, and never leave an obvious gap. Run these seven steps in order and the sprawling problem turns into a walk you control.

Step 1: Clarify the requirements

Before any architecture, nail down what you are actually being asked to build. Pull apart the problem statement, clear the ambiguities, and separate functional requirements from non-functional ones early. Ask about the core features, who the users are, how they interact, and what it depends on. The quality of your questions tells the interviewer as much as your answers do.

Step 2: Size it

With the requirements clear, estimate the scale. Daily active users, data volume, read and write rates, bandwidth. A rough capacity model up front forces scalability into the design from the start, instead of bolting it on later, and it shapes nearly every choice that follows.

Step 3: Sketch a high-level design

Turn that understanding into a simple block diagram. Front end, back end, databases, caches, external services, and the flow of data between them. Keep it rough. This picture is the map you and the interviewer work from for the rest of the session, so get it on the board early.

Step 4: Design the data layer

A system is only as good as its data model. Choose your storage deliberately, relational or NoSQL, based on the shape of your data, the consistency you need, and how it has to scale. Then lay out the main entities, their relationships, and the access patterns they have to support. This is where a lot of interviews are quietly won or lost.

Step 5: Define the APIs

Your APIs decide how cleanly the parts talk to each other and to the outside world. REST, GraphQL, or RPC, pick with intent and say why. Think about data formats and protocols, and weigh performance, security, and how easy the thing is to actually build against.

Step 6: Go deep on the components that matter

Expect the interviewer to zoom in. Database sharding and replication, scaling the web tier, removing single points of failure. Be ready to discuss the pieces in detail, including their trade-offs and the reasoning behind your choices. This is the part that reads as real experience rather than memorised diagrams.

Step 7: Get ahead of the bottlenecks

Finally, the hard parts: scalability, performance, reliability, security. Name the likely pressure points before you are asked, and bring the standard answers to bear, caching, replication, monitoring. Showing you saw the bottleneck coming is the difference between a candidate who has read about systems and one who has run them.

The point of all this

This sequence is not really about technical knowledge, though you need that. It is about showing you can take a complex, open problem and work through it methodically, layer by layer, communicating a clear and coherent design the whole way. Clarify, size, sketch, then build each layer with intent. Do that, and you come across as someone who not only knows the technicalities but understands what the choices cost.