Delivery Framework

Overview

A lot of candidates don't know how to start a system design interview. It is often their first one, so they are not sure what the interviewer expects or where to begin. System design questions are also very open-ended, so a single question can go in countless directions.

The delivery framework is a sequence of steps that has worked well for me, and I recommend it for your interviews too. If you don't know where to start, start here. It will keep you moving in the right direction.

The interviewer may pull you off the path, and that is expected. They might ask a question and want to go deeper on one part. Your job is to answer it, then come back to the framework and carry on. It is easy to get lost when you are not building things step by step, and the framework is what keeps you on track.

Here's the framework!

A default path, not a script

There is no fixed script for this interview. Every interviewer cares about different things: some dig into state management, some into API design, some into performance or testing. The interview goes wherever your interviewer takes it, and that is normal.

What you control is your default path. When nobody is steering you, you should know what to cover next and roughly how long to spend on it. This framework is that path: thirteen steps that start with scope, spend most of their time in the middle where the design happens, and close with the concerns that show you think beyond the first version.

1. Requirements and scoping
2. Tooling
3. Styling
4. API design
5. Component architecture
6. State management
7. External library
8. Data fetching
9. Data sending
10. Performance
11. Accessibility
12. Testing
13. Deployments

Treat the order and the time you give each step as a starting allocation, not a schedule to obey. If the interviewer spends ten minutes digging into one step, that time comes out of the others, and that is fine.

Requirements and scoping

The goal of this step is to get a clear understanding of the system you are being asked to design. Let's say you are asked to build an X system. An X system can have many features, and you cannot build all of them in 50 minutes, so you need to scope down to the important ones before you start designing. Scoping down helps in two ways:

1. It shows the interviewer that you are good at understanding requirements, scoping them down, and bringing clarity to a vague problem.
2. It makes the rest of the interview much easier, because the problem is no longer vague. You might miss a few things, which you can come back to later, but you will still have a clear idea of which direction to go and what you need to cover.

In practice, scoping sounds like this: restate the product in one or two sentences, ask the clarifying questions whose answers change the design (who uses it, on which devices, how much data, does it need to update live), then say which features you are taking on and which you are cutting. Get the interviewer to agree before you move on. That agreed list is your contract for the rest of the interview; whenever you are unsure what to do next, come back to it.

Tooling

Name the foundation you would build on: the framework, the language, and the build setup. Give one reason per choice and move on; this step should take a minute or two, not five. The interviewer is not looking for a debate between frameworks. They want to see that you can make a reasonable choice and commit to it.

If the question involves many teams or many apps, this is also where you say how the codebase is organized. The articles on monoliths, monorepos, microfrontends, and choosing a repo cover those decisions.

Styling

State how you would style the app and one reason it fits this product: team size, theming needs, or performance constraints. Like tooling, this is a fast step. The styling approaches article compares the options and the trade offs behind them.

API design

Turn the vague product into concrete data. Name the entities on the screen, the endpoints that serve them, and the shape of what they return. When the product has ordering, sharing, or live collaboration, the contract you define here is what makes those features possible, so spend real time on it. The API design article walks through the whole step: entities, endpoints, pagination, errors, and the details that make writes safe.

Component architecture

Break the screen into a component tree and walk through it out loud: what owns what, where the boundaries are, and which component handles the hardest interaction. Interviewers use this step to see whether you can hold a whole client in your head, so draw the tree rather than describe it.

State management

Decide where data lives on the client and what shape it has. Separate the data that came from the server from the state that only the UI cares about, and reach for a global store only when the problem demands one. The state management tools article covers how to choose.

External library

For the genuinely hard pieces (drag and drop, rich text editing, charts), say whether you would build or install, and defend it. Interviewers care about the judgment, not the package name: what it costs to own the code versus what it costs to depend on someone else's.

Data fetching

Describe how data gets into the app: the initial load, what loads later, and how updates arrive if the product is live. If you need a live channel, compare the transports before picking one. The articles on real-time transports and server-sent events cover the options, and broadcast channels covers keeping multiple tabs in sync.

Data sending

Describe how changes leave the app: what the user sees while a save is in flight, what happens when it fails, and how the interface stays honest through both. Interviews about collaborative products get hard in this step, so expect follow up questions here. The optimistic updates article walks through the core pattern on a like button.

Performance

Say where this product gets slow at real scale and what you would do about it: too many items on screen, too much JavaScript, or too many re-renders. The performance at scale article covers the levers, and virtualization covers the most common fix for long lists.

Accessibility

Every mouse interaction needs a keyboard path, and changes that happen on screen need to be announced to screen readers. Point at the risky interactions in your design and say how you would cover them.

Testing

Say what you would test and at which layer, matched to where the product is most likely to break. The testing strategy article covers how to divide the work across layers, and specialized testing patterns covers the cases beyond ordinary feature tests.

Deployments

Close with how the frontend ships: where it is hosted, how a release rolls out, and how you would catch a bad one. One or two sentences here end the interview on a complete system rather than a screen.

That is the whole framework. To see it applied to a real question end to end, read the Jira Board breakdown.