lumo

Module 15 · Lesson 3 of 9Free

AI system design interviews: a framework

Level
Intermediate
Topic
AI engineering interviews
Reading time
18 min

When you finish this page you can

  1. Run an AI system design answer through eight steps, from clarifying requirements to closing on trade-offs, inside 45 minutes.
  2. Estimate volume, tokens, cost per task and rate limits for a model-backed feature, and turn each number into a design choice.
  3. Explain what an AI design adds to a classic one: cost per task, measured quality, non-deterministic output and safety.
  4. Score your own answer against a checklist of what strong answers cover and weak ones miss.
  1. Estimating the cost and latency of a feature15 min
  2. RAG: grounding answers in your own documents14 min

Video lesson · coming soon

Minute 24 of 45. The prompt was: “Design an assistant that answers customer questions from a company’s help center.” You have drawn a load balancer, three app servers, PostgreSQL and a Redis cache.

The interviewer asks: “A customer asks if they can return opened headphones. How do you know the answer is right, and what did that answer cost?” You have no number for either.

The boxes were the design of any web app. This lesson answers one question: what does an AI system design interview test that a classic one doesn’t, and how do you spend 45 minutes showing it?

What the interviewer is trying to learn

Companies describe design rounds in general terms. Atlassian’s handbook, for example, says its 60-minute session wants to see how you explore a problem and which questions you ask.1 It also says interviewers may add new constraints, such as reliability or cost, and watch how you adjust.1

An AI design round keeps all of that. It adds four things a classic round rarely reaches. This list is this lesson’s view of the gap, not any company’s scoring sheet.

Classic system design AI system design
Unit of cost Servers and storage; one request costs almost nothing Every task pays per token; one conversation can cost cents
Correctness A test passes or fails Quality is a rate, measured on a set of real examples
Repeatability Same input, same output Same input can give a different output
Failure Errors and downtime Confident wrong answers, injected instructions, promises the business can’t keep

A token is the unit a model reads and bills, roughly three quarters of an English word. Because output is non-deterministic, “it worked when I tried it” proves little. So the interviewer listens for three things: a price per task, a way to measure quality, and a list of what the system must never do.

Check yourselfAnswer in your head first, then reveal
In the help-center prompt, which number should you estimate first: storage for the articles, or the cost of one customer conversation?Show answerHide answer
The cost of one conversation. 500 articles of 800 tokens are about 400,000 tokens, a few megabytes, which changes no decision. The model calls are where the money and the latency are, and that number decides between designs. Not storage: classic habits point there, but here it is the smallest number on the board.

The four differences tell you what to cover. The next question is in what order, and for how long.

Eight steps on one clock

Use the same skeleton for every AI design prompt. The timings are this lesson’s practice default for a 45-minute round, not any employer’s rule. The System Design course’s 45-minute interview framework explains how to work with checkpoints instead of a rigid timer; this lesson adds the AI steps.

Diagram not drawn yet: ai-sd-interview-timeline.svg

A horizontal 45-minute bar split into eight segments: clarify requirements 0 to 5 minutes, estimate 5 to 10, high-level design 10 to 18, model and retrieval choices 18 to 24, evals 24 to 31, safety and failure 31 to 37, cost and scaling 37 to 42, trade-offs 42 to 45. Under each segment, the evidence it leaves on the board: agreed scope, a numbers box, one traced question, a decision with numbers, an eval plan, a never-do list, the first limit to break, three decisions and what would change them.

Each step leaves something on the board. If a step leaves nothing, you skipped it.
Minutes Step What you leave on the board
0–5 Clarify requirements Who asks, what the assistant may do, what success means
5–10 Estimate Volume, tokens per call, cost per task, latency target
10–18 High-level design One diagram and one question traced through it
18–24 Model and retrieval choices A decision backed by numbers
24–31 Evals What you measure, on what data, and the release gate
31–37 Safety and failure What the assistant must never do, and what happens when parts fail
37–42 Cost and scaling The first limit that breaks at 10×
42–45 Trade-offs Your main decisions and what would change each

Evals and safety get 13 minutes, because a classic answer leaves them out. Now walk the opening prompt through the steps.

Clarify: five questions that change the design

Ask only questions whose answers change a box or a number. If the interviewer leaves one to you, state your assumption and write it down.

Question Assumed answer What it changes
Who asks: customers on the website, or support staff? Customers, in a chat widget Answers reach customers with no one checking them first, so safety rules get stricter
What may it do besides answer? Answer from the help center only; anything else goes to a person No tools that act, so no refunds or account changes
How big is the help center? 500 articles, about 800 tokens each Whether the whole help center fits in a prompt
How many conversations a day? 20,000, about 3 questions each Cost and rate limits
How fast must it reply? First words within 2 seconds at p95 Streaming, a small model, little thinking

The last row is a , stated as a . These are the interviewer’s numbers for this example, not facts about any real company.

Then cut scope aloud: “Out of scope for now: order lookups, account data and other languages.” That buys time for evals later.

Estimate per task, not per server

The unit of cost is one completed conversation, not one API call. This estimate counts the answer calls only. It leaves out the query and any safety classifier, which are small; say so on the board. The formula and its habits come from estimating the cost and latency of a feature.

Prices are for Claude Haiku 5.5 as of October 2026: $0.10 per million input tokens and $0.50 per million output tokens, for prompts up to 100,000 tokens.2 Haiku 5.5 thinks before it answers. Thinking tokens are billed as output, so each case assumes a number of them.

Volume

20,000 conversations × 3 questions = 60,000 calls a day; 60,000 ÷ 86,400 s ≈ 0.7 a second; busiest hour at 3× ≈ 2 a second ≈ 125 a minute

The 3× peak is an assumption. Say it out loud.

Tokens per call, typical

600 system prompt + 2,000 retrieved (5 chunks × 400) + 600 history + 100 question = 3,300 input; 300 thinking (assumed) + 150 answer = 450 output

An early question in a short conversation.

Tokens per call, long

600 + 2,000 + 4,000 history + 100 = 6,700 input; 800 thinking (assumed) + 300 answer = 1,100 output

A later question. History includes earlier answers and the thinking Haiku 5.5 keeps from earlier turns.

Cost per call

typical: 3,300 × $0.10 ÷ 1M + 450 × $0.50 ÷ 1M = $0.00033 + $0.000225 ≈ $0.00056; long: 6,700 × $0.10 ÷ 1M + 1,100 × $0.50 ÷ 1M = $0.00067 + $0.00055 ≈ $0.0012

The real thinking count comes back in usage.output_tokens_details.thinking_tokens.

Cost per conversation

typical: 3 × $0.00056 ≈ $0.0017; long: 3 × $0.0012 ≈ $0.0037

Assume one conversation in four is long.

Cost per day

15,000 × $0.0017 + 5,000 × $0.0037 = $25.50 + $18.50 ≈ $44 a day, about $1,300 a month

Compare it with what a person costs to answer the same questions. Ask the interviewer for that number rather than inventing it.

Limits

average input = (45,000 × 3,300 + 15,000 × 6,700) ÷ 60,000 ≈ 4,150 tokens; 125 calls a minute × 4,150 ≈ 520,000 input tokens a minute

The Start tier allows 1,000 requests and 2,000,000 input tokens a minute on Claude Haiku 5.5, so traffic fits.3 But $1,300 a month is above the Start ($500) and Build ($1,000) monthly spend caps.3 On either tier, the assistant would start getting 429 errors partway through the month.

That is a number that changed a plan: the account tier, not the server count. The latency target gets one more line: retrieval should take about 200 ms (an estimate), which leaves the rest of the 2 seconds for the model’s first words, so stream the reply.

Draw one picture and trace one question

Draw the request path on the right, the ingestion path on the left, and keep the numbers box in a corner. Skip load balancers and replicas unless asked; at 2 calls a second they decide nothing.

Diagram not drawn yet: help-center-assistant-hld.svg

Left to right: chat widget, chat API, retriever over a hybrid index, model API (Claude Haiku 5.5), output check. Solid arrows numbered 1 to 5 carry a customer question from the widget through the chat API to the retriever, then the question with 5 chunks to the model, then the draft answer to the output check. A dashed arrow 6 streams the checked answer back to the widget. A branch from the output check goes to a support queue, labelled hand-off. Below, a dashed path: help-center articles to an ingestion job that chunks and embeds them into the hybrid index.

One question, traced: retrieve 5 chunks, answer from them, check the answer, or hand off to a person.
Component Responsibility State it keeps When it fails
Chat API Holds the conversation, builds the prompt, streams the reply Conversation history The widget shows the contact form
Retriever Finds the 5 most relevant chunks for the question Chunk text, embeddings, keyword index Answer “I can’t find that” and hand off
Model API Writes the answer from the chunks None; each call sends everything Retry 429s and 5xx with backoff, then show links to the top articles
Output check Blocks answers that break a rule Rule list Fails closed: no answer is shown, the customer is handed off
Ingestion job Turns article edits into fresh chunks within minutes Article versions Old chunks stay; a nightly check finds lost updates

The traced question: the customer asks about opened headphones (1). The chat API sends the question to the retriever (2). It searches with hybrid search, keywords plus embeddings, and returns 5 chunks from the returns article (3). The model gets the rules, the chunks and the history, and answers from them (4). The output check confirms the answer makes no promise of a refund (5). The reply streams back (6).

This design is retrieval-augmented generation (RAG). The next step is to defend that choice with numbers.

Decision: where the articles enter the prompt

How should the help center reach the model?

Put the whole help center in every prompt.

Each call is about 401,300 input tokens, over Haiku 5.5’s 100,000-token price step, so the whole request pays $0.50 and $2.50 per million: about $0.20 a call, about $12,000 a day. Even if every call read the help center from the cache at $0.05 per million, it is about $1,300 a day. Uncached, 125 calls a minute is about 50 million input tokens a minute, five times the Scale tier limit.

Fine-tune a model on the help center.

Training a model on the articles teaches style more reliably than facts. A policy changed on Monday is wrong until the next training run, and the answer can’t point to its source.

Why this choice

The arithmetic decides it: about $1,300 a day at best against about $44. Claude Haiku 5.5 has a 1M-token context window, so the help center fits, but more context isn’t free: the provider’s docs note that accuracy and recall fall as the token count grows.4 Above 100,000 tokens, Haiku 5.5 also charges higher prices for the whole request, cached tokens included.2

The choice changes with the corpus. With 60 articles (about 48,000 tokens), the whole prompt stays under the price step, and a cached help center costs about as much as retrieval with no index to run. Say that condition aloud. Long context or RAG works through this trade-off in full, and prompting, RAG or fine-tuning covers when fine-tuning wins.

The model choice gets one sentence: “Claude Haiku 5.5, because the task is short answers from given text and the latency target is tight; I’d test a larger model on the eval set before ruling it out.” That sentence leads straight to evals.

Evals: say how you would know it works

An eval is a repeatable test of output quality on fixed examples. Put five lines on the board:

  1. Data: 300 real past customer questions, each labelled with the article that answers it and whether the right behaviour is to answer or hand off. Add attacks and refund demands.
  2. Retrieval, in code: is the right article among the 5 chunks? Score it separately, so a bad answer can be traced to search or to the model.
  3. Answers: is the answer a grounded answer, every claim supported by a chunk? An LLM judge grades this, checked against people’s grades on a sample.
  4. Repeats: run each case 3–5 times and report rates, because one run proves little. Example gate: 95% grounded and zero refund promises.
  5. Online: hand-off rate, thumbs down, and customers who contact support about the same issue within a day.

Diagram not drawn yet: ai-sd-eval-loop.svg

A loop of four boxes. Labelled set of 300 questions goes to a run of the assistant, 3 to 5 times per case. The run's output goes to two graders side by side: code checks for retrieval and rules, and an LLM judge for groundedness. Their scores go to a release gate: 95 percent grounded, zero refund promises. A dashed arrow from production signals (hand-offs, thumbs down, repeat contacts) returns to the labelled set as new cases.

Offline scores gate each release; production failures become new test cases.

Evaluating RAG teaches these metrics. For the follow-up questions about them, see discussing evals and trade-offs under pressure.

Safety: what the assistant must never do

Start with a list, then give each item a mechanism. A rule that lives only in the prompt is a hope, not a control.

Must never Mechanism
Follow instructions hidden in a customer message Customer text is treated as data; the model has no tools that act; the output check runs on every answer
Promise a refund, replacement or discount The output check blocks it; the customer gets a hand-off instead
State a policy it didn’t retrieve Answer only from chunks; no chunk, no answer
Leak personal data No account access in this version; emails and card numbers are masked before logging

The first row is prompt injection: input text that tries to act as instructions. The fallback for everything is a hand-off: the conversation becomes a ticket for a person. Design: a safe customer-facing assistant builds a full version of this table. It also weighs the cost of a check against the 2-second target: streaming shows words sooner, but a reply checked only after it is shown can’t be taken back.

Which part should get the long deep dive?

Retrieval tuning.

You show search depth (chunking, reranking), but evals and safety get two minutes at the end.

Scaling the infrastructure.

At 2 calls a second, there is little to scale. You spend the round on a problem the numbers already ruled out.

Why this choice

Pick the deep dive from the riskiest requirement you wrote down. Here, answers reach customers unchecked, so quality and safety carry the risk. If the interviewer says retrieval quality is the known pain, or volume is 50 million questions a day, follow them; offer the other areas in one sentence each.

Cost and scaling: which limit breaks first

Multiply the numbers box by 10×. At 200,000 conversations a day, the busiest minute has about 1,250 calls and 5.2 million input tokens. That passes the Start tier’s 1,000 requests and the Build tier’s 5 million input tokens a minute; the Scale tier allows 10,000 and 10 million.3 The database is still not the problem.

Name each lever in one clause. Prompt caching on the system prompt and repeated context helps twice, because cache reads don’t count toward the input-token limit on most current models.3 Caching answers to common questions is the other lever, covered in caching for LLM apps.

Close on trade-offs: RAG over long context for the 30× cost gap, Haiku 5.5 until the eval set says otherwise, hand-off over guessing. Then say what you would build next.

What strong answers cover

Score your practice answers with this list.

Strong answer Weak answer
Asks who reads the output before it reaches a customer Assumes a person checks every answer
Prices one conversation, with typical and long cases and thinking tokens Gives no cost, or a cost per API call only
Checks rate limits and spend caps against peak traffic Sizes servers and stops there
Defends RAG or long context with a number, and names when it would flip Picks a vector database first, without knowing the corpus size
Measures retrieval and answers separately, over repeated runs Says “we’d test it” with no data or metric
Lists what the system must never do, each with a mechanism Puts every rule in the system prompt
Ends on decisions and what would change them Runs out of time mid-diagram

“Why not put the whole help center in the prompt? It fits.”

A strong answer covers these points, in this order:

  1. It fits: about 400,000 tokens in a 1M-token window.
  2. Price per call: over Haiku 5.5’s 100,000-token step, about $0.20 uncached and $0.02 cached, against about $0.0006 with retrieval.
  3. Quality: long prompts lose accuracy, and retrieved chunks give citations.
  4. When it flips: a help center under the price step, or one that changes rarely and is cached warm.

Common trap: Answering “context windows are too small”. It fits in 1M tokens; the objection is cost, latency and accuracy, with numbers.

If you have built something similar, describe what you measured, not only what you built. This course builds one for Deskora, a made-up help desk app: Design: a support assistant over company docs.

Common mistakes

  • Quoting prices and limits as permanent. Say “as of my last check, about $0.10 per million input tokens; I’d confirm it.” The method matters more than the digit.
  • Promising repeatable output with sampling settings. On Claude API version 2026-10-21, temperature returns a 400 error. Consistency comes from clear prompts, structured output and evals over repeated runs.
  • Designing an agent when a fixed path works. Retrieve, answer, check is a workflow. Add tools that act only when a requirement needs them.

A full mock interview on a similar prompt, an HR policy assistant, with dialogue and deep dives, is the mock interview for a RAG assistant. The next lesson moves from the whiteboard to the keyboard: live coding against a model API.

Check your understanding

Check yourselfAnswer in your head first, then reveal
The interviewer shrinks the help center to 60 articles, about 48,000 tokens. Does your design change?Show answerHide answer
It can. The prompt now stays under Haiku 5.5’s 100,000-token price step, so a cached help center in every call costs about as much as retrieval and removes the index. Not “RAG always”: the cost gap came from the corpus size, so measure both.
Check yourselfAnswer in your head first, then reveal
Traffic grows 10×. What breaks first?Show answerHide answer
Provider limits: about 1,250 calls a minute passes the Start tier’s 1,000 requests, and 5.2 million input tokens passes the Build tier’s 5 million. Not the database: it serves a few lookups a second. Spend caps were already a problem at 1×.
Check yourselfAnswer in your head first, then reveal
Your new prompt scores 97% grounded on one run of the eval set. Ship it?Show answerHide answer
Not yet. Run it 3–5 times and compare rates with the old prompt, and check the separate zero-refund-promise rule. One run of a non-deterministic system can be lucky.
Check yourselfAnswer in your head first, then reveal
Minute 30, and you are still discussing chunk sizes. Evals and safety haven’t come up. What do you do?Show answerHide answer
Close retrieval in one sentence, with the choice and how you would tune it, and move to evals and safety. They carry this product’s biggest risk, and a strong answer that never reaches them looks like a classic design.

Summary

  1. An AI design round adds four things to a classic one: cost per task, quality measured as a rate, non-deterministic output and safety. Spend about 13 of 45 minutes on evals and safety.
  2. Eight steps, each leaving evidence on the board: clarify, estimate, high-level design, model and retrieval choices, evals, safety, cost and scaling, trade-offs.
  3. Price one conversation with the formula, typical and long cases and assumed thinking tokens. For the help-center example on Claude Haiku 5.5, as of October 2026: about $44 a day, above the Start and Build spend caps.
  4. Defend RAG against long context with numbers (about $44 against $1,300 a day at best) and say when the choice flips.
  5. Evals: labelled real questions, retrieval and answers scored separately, repeated runs, a release gate. Safety: a never-do list where every item has a mechanism, and a hand-off to a person.

Report a mistake

Tell us what’s wrong in this lesson and we’ll fix it.