The Twelve-Part Design Framework

Covering every part of a design proves structure, but covering them evenly spends time on boxes that do not matter.

A design round is not a drawing exercise; it is a sequence of questions the interviewer asks silently. Learn the twelve questions in order, then answer the first four before drawing anything, because they decide every later choice.

Objectives:

• name the twelve parts of a design answer and the silent question behind each;
• turn a vague prompt into a problem statement, a short functional list and quantified quality targets;
• estimate users, traffic, storage and bandwidth well enough to justify the architecture.

An interviewer watching a design answer is checking a fixed list. Each of the twelve parts below is one item on that list. Skip one and the interviewer marks it as missing, even if the rest is strong. A part left unanswered cannot score.

The running example throughout this module is an AI travel assistant that searches flights, books hotels and chats with the user. It exercises both a traditional transactional core and every AI-specific component. Parts 5 to 8 are taught in Architecture, Data, and Request Flow; parts 9 to 12 in Scale, Reliability, and Security.

Five minutes of questions prevents twenty minutes spent designing the wrong system. Ask four things. First, what are we building? Restate it and get confirmation. A wrong assumption about the product costs far more than a wrong database.

Second, who are the users? Consumers, internal staff and partners have very different scale, latency and trust profiles. A million casual readers is a caching problem. A thousand power users writing constantly is a locking problem.

Third, what business problem does it solve: revenue, retention, cost or compliance? That answer later justifies eventual consistency, or rules it out. Fourth, what is out of scope? Park payments, fraud and admin tooling explicitly. "I'll assume payments are handled by an existing service" is a senior move, not a dodge.

Functional requirements are capabilities a user would recognise. Keep the list short, order it by importance and confirm it. For each one, know why it matters to the architecture, because that is what turns a feature list into design input.

Non-functional requirements say how well the system performs. Every one needs a number. "Highly available" means nothing; "99.99% with a 5-minute RTO" is a design constraint. A target without a number cannot be designed against.

For the travel assistant, example targets are 99.99% availability, under 2 seconds response, 10M users and GDPR compliance.

Warning: an unquantified target is not a requirement. "Fast", "scalable" and "secure" let any design pass, so they let no design be judged. Attach a number or an acceptance test to each one before moving on.

The numbers justify the architecture, so estimate before naming tools. Round aggressively. The reasoning matters, not the arithmetic.

The prompt is "design an AI travel assistant that helps customers search flights, hotels, and book trips". Start by restating it and asking who the users are. Consumers mean high read volume, which makes caching central.

Next, park payments: "I'll assume payments are an existing service." Rank the functional list with search and booking first, chat third. Then quantify: 99.99% availability, under 2 seconds, 10M users, GDPR. Finally size it: 5M MAU, 500K DAU, a 2–5× peak factor, and a read-heavy split.

Those four parts take under ten minutes. Yet they already justify a cache in front of search, a transactional store for bookings and a queue for notifications. Everything drawn afterwards points back to a number said here.

Compress the twelve parts into ten moves that fit in memory mid-conversation. Define the problem, gather requirements, estimate scale and draw the high-level architecture. Design storage and services, trace one request end to end, then address scalability. Address reliability, then security and governance, and close on trade-offs and next steps.

Walked mechanically, this is a checklist. Walked well, it guarantees no silent question goes unanswered, and the AI additions are the ones most often left silent. The habit that makes it sound like design rather than recitation is simple: name the cost of every component the moment it appears.

• The twelve parts are the interviewer's silent questions; an unanswered part cannot score.
• Problem definition fixes the product, the users, the business goal and what is out of scope.
• Functional requirements are a short, ranked list, each tied to why it shapes the architecture.
• Every quality target needs a number; percentiles beat averages.
• Capacity estimates come before technology choices and justify them.
• The framework sounds like design when every named component comes with its cost.

1. Why is "highly available" not a usable requirement? It has no number, so no design can be judged against it. "99.99% with a 5-minute RTO" is a constraint that rules designs in or out.

2. How do you derive peak requests per second from daily active users? Multiply DAU by actions per user per day, divide by 86,400, then multiply by a 2–5× peak factor. Then split reads from writes.

3. Why does the business problem matter in part 1? It is what later justifies consistency choices. Revenue at stake on bookings argues for strong consistency; a recommendation feed can tolerate eventual consistency.