AI System Design Interview 2026: Top 15 Questions + Diagrams

Q: What framework should I use to answer any AI system design interview question?

Use a six-step framework that interviewers consistently reward. Step one: clarify the problem — extract functional requirements (what the system does), non-functional requirements (latency, throughput, cost, compliance), and the SLOs that bound the design. Step two: capacity estimation — back-of-the-envelope numbers in tokens per second, GPU-hours per day, storage in TB, and dollars per query. Step three: high-level architecture — boxes and arrows showing the dataflow, request path, and major components. Step four: deep dive on the two or three most interesting components — the model, the index, the feature store, the orchestration layer. Step five: failure modes and trade-offs — what breaks at scale, what the alternatives are, and why you chose what you chose. Step six: evaluation and observability — how you know the system works, how you detect regressions, and what your tracing and dataset strategy is. Spend the first five minutes on clarification, not architecture; the single most common reason strong engineers fail AI system design interviews is jumping to a Kafka-and-microservices diagram before establishing what the system actually has to do.

Q: How is an AI system design interview different from a traditional system design interview?

AI system design interviews layer three additional dimensions on top of traditional distributed systems thinking. First, GPU economics — capacity estimation must account for VRAM, tensor parallelism, throughput per GPU, and the cost per token, not just CPU and memory. Second, model selection and serving patterns — continuous batching, PagedAttention, prefix caching, speculative decoding, multi-LoRA serving, and the latency components TTFT and TPOT are first-class architectural concerns. Third, evaluation and quality — the interview expects you to discuss faithfulness, hallucination, drift, evaluation pipelines, dataset curation, and the human-in-the-loop strategies that production AI requires. The traditional fundamentals (sharding, caching, replication, consistency, fault tolerance) still apply, but a strong AI system design answer integrates them with the AI-specific layer rather than treating them as separate concerns. Interviewers at OpenAI, Anthropic, Google DeepMind, Meta AI, NVIDIA, and AI-platform teams at large enterprises are listening for this integration.

Q: How do you estimate capacity for an LLM-based system?

Capacity estimation for LLM systems works in three layers. Layer one: tokens — input tokens per request, output tokens per request, requests per second, peak vs sustained. Multiply for total tokens per second, then per day. Layer two: GPU economics — for self-hosted, what model size in what precision (FP16, INT8, INT4) on what GPU class (A100, H100, MI300), what throughput in tokens per second per GPU under continuous batching, and how many GPUs you need for the target throughput with 30–50 percent headroom. For API-based, the dollar cost per million input and output tokens at the chosen model price, multiplied to get daily cost. Layer three: storage and bandwidth — vector index size at the chosen dimension and quantisation, KV cache memory for prefix caching, document corpus size, trace storage growth, network egress for streamed responses. Translate every number into dollars at the end so the trade-offs are explicit. Numbers signal seniority in these interviews — a candidate who says "we need a few GPUs" loses to one who says "Llama 70B in FP16 needs roughly 140 GB VRAM, fits on 2× H100 80GB, sustains 4,000 output tokens per second per node, so 100,000 concurrent users at 20 tokens per second each requires 500 such nodes".

Q: What is the right architecture for a production RAG system in 2026?

A production RAG system in 2026 has six layers and is not optional in any of them. Layer one: an API gateway with auth, multi-tenant isolation, and rate limiting. Layer two: a semantic cache at the question-embedding level that intercepts repeat queries and can reduce LLM calls 30–50 percent for FAQ-shaped traffic. Layer three: hybrid retrieval — BM25 keyword search plus dense vector search via HNSW or IVF-PQ — because pure dense retrieval underperforms on enterprise corpora with many keyword-y queries. Layer four: a cross-encoder reranker that takes the top 50 from retrieval down to the top 8 most relevant. Layer five: LLM generation against a frontier model (GPT-4o or Claude class) with citation-required prompting. Layer six: an async evaluation pipeline that scores faithfulness (does the cited source actually support the claim) and routes a sample to human review for dataset curation. The vector store is sharded by tenant or by hash; the embedding model is consistent between indexing and retrieval; and the entire pipeline is instrumented for tracing. See the production RAG pipeline tutorial linked in the article for implementation detail.

Q: How do you design a multi-tenant LLM gateway?

A multi-tenant LLM gateway is the unified entry point for all LLM traffic in an organisation. The architecture has six required components. First, a stateless load-balanced front end (Envoy, NGINX, or a custom service in Go or Rust) so you can scale horizontally; all tenant state lives in Redis and a data lake. Second, authentication and tenant resolution from API keys or OAuth tokens. Third, per-tenant quota and rate limiting using token-bucket algorithms in a sharded Redis cluster — most production gateways need this in Redis rather than in-memory because of horizontal scaling. Fourth, PII redaction using regex plus NER before the prompt leaves the gateway. Fifth, intelligent routing across providers (OpenAI, Anthropic, self-hosted) with cost-aware (cheap model for short prompts), quality-aware (frontier model for complex tasks), and latency-aware (failover when an upstream degrades) policies. Sixth, async logging of prompt, response, model, latency, cost, and tenant into S3 plus ClickHouse for chargeback, debugging, and analytics. Streaming responses (SSE or chunked transfer) must work end-to-end — many naive gateways break this. Gateway latency overhead under 50 ms is the typical SLO; upstream provider latency dominates beyond that.

Q: What is continuous batching and why is it the LLM serving baseline in 2026?

Continuous batching, also called iteration-level scheduling or in-flight batching, is the technique of dynamically merging requests at the token level rather than at the request level. Naive batching waits for a fixed-size batch of requests, runs them together, and waits for all of them to finish before starting the next batch — this collapses GPU utilisation below 30 percent because long-running requests block short ones. Continuous batching, popularised by Orca and now standard in vLLM, TensorRT-LLM, TGI, and SGLang, allows requests to enter and leave the batch at every decoding step. As soon as one request finishes generation, its slot is freed and a new request joins the batch on the next forward pass. Combined with PagedAttention, which manages KV cache memory in fixed-size pages similar to virtual memory, continuous batching pushes GPU utilisation to 70–90 percent and 5–20× throughput compared with naive serving. In 2026 it is the baseline; an LLM inference design that does not include it will be marked down in interview. Add prefix caching for repeated system prompts (major win for chat workloads), speculative decoding with a small draft model (2–3× throughput on top), and multi-LoRA serving (one base model serves many fine-tunes) to round out a strong answer.

Q: When should you put an LLM in the hot path of a low-latency system?

Almost never if the latency budget is sub-100 ms. Frontier LLM TTFT alone is typically 200–500 ms even with prefix caching, and TPOT adds 20–50 ms per output token. For sub-100 ms decisions — credit-card fraud, ad ranking, network routing — the LLM belongs out of the hot path. Use LLMs for offline feature generation (semantic embeddings of merchants, summaries of customer history) that feed lower-latency models in production; for periodic policy generation that gradient-boosted trees or neural networks then execute; or for explanation and analyst review after a non-LLM model has decided. For latency budgets in the 200–800 ms range (recommendations, voice assistants), a small LLM (7B–13B) on dedicated GPU with continuous batching, prefix caching, and aggressive prompt minimisation can be in the hot path. For latency budgets above 1 second (chat, search, code review), frontier LLMs in the hot path are routine. The interview test is whether you state the latency budget first and choose the model class second; candidates who reach for GPT-4o regardless of latency lose points.

Q: How do you handle evaluation and observability for LLM systems?

Production LLM evaluation and observability has two complementary tracks. The online track instruments every LLM call with structured spans (prompt, response, model, latency, cost, user, tenant) using an OpenTelemetry-style schema, ingests them into a trace store (ClickHouse, Honeycomb, or a dedicated platform like LangSmith, Langfuse, Arize, or Helicone), samples 1–5 percent of traces for online evaluation (LLM-as-judge for faithfulness, heuristics for refusal rate, custom evaluators for domain-specific quality), and alerts on quality drops, cost spikes, and latency regressions. The offline track curates a regression dataset from production traces (not synthetic data — real user prompts cover edge cases that synthetic generation misses), runs the full eval suite on every model change in CI, and gates promotion on results. Trace clustering using embeddings surfaces failure patterns that random sampling misses. Human review on stratified samples — particularly the long-tail and edge cases — is non-negotiable for systems that practitioners rely on. The single biggest mistake teams make is treating evaluation as an afterthought; in interviews, mention it in your initial architecture diagram, not as an addendum.

Q: How do you design a multi-agent system that survives production?

Production multi-agent systems differ from demos in five ways. First, durable state — every step of every workflow must be checkpointed to a durable store (Postgres, DynamoDB, or a workflow engine like Temporal, Inngest, or LangGraph) so a worker crash mid-workflow can be resumed without rerunning completed steps. Second, step limits and budget caps — every workflow has hard limits on agent calls, tokens consumed, and dollars spent; the orchestrator enforces these before each step and fails the workflow gracefully when exceeded. Third, agent-level circuit breakers — an agent that has failed repeatedly or is producing low-quality output is short-circuited so it does not consume budget on bad work. Fourth, human-in-the-loop gates at consequential actions — sending email, executing code, modifying production data, spending money — with explicit approval flows and clear audit trails. Fifth, observability at the agent level — every agent decision, tool call, and inter-agent message is traced so debugging and quality analysis are possible. The shared blackboard pattern (agents read and write to a common state) is simpler than message-passing for most production workflows; the orchestrator-worker pattern with a planner agent decomposing the goal into tasks is the dominant 2026 architecture. Cost and latency explode quickly with agent count; design for the 10× scenario, not the demo scenario.

Q: How should I practise for an AI system design interview?

Three practices give the largest improvement. First, run timed mock interviews with the framework — pick a question, set a 45-minute timer, and force yourself through clarify-estimate-architect-deep-dive-fail-evaluate. Record yourself and watch back; the single biggest improvement most candidates make is moving from qualitative answers ("we would use a vector DB") to quantitative ones ("at 2.2 billion chunks and 1,536-dimension vectors with int8 quantisation, we need roughly 3 TB of vector storage, sharded across 10 nodes for sub-50 ms p99 retrieval"). Numbers signal seniority. Second, build at least one of these systems end-to-end at small scale — deploy vLLM with continuous batching on a rented H100, build a hybrid retrieval pipeline with reranking against a real corpus, ship a multi-agent workflow with durable state in LangGraph or Temporal. The candidate who has actually deployed these answers questions differently from the candidate who has only read about them — the depth shows in the trade-off discussions and in the failure-mode questions. Third, read the architecture write-ups from the AI labs and platform teams — OpenAI engineering posts, Anthropic research papers, the vLLM and SGLang papers, LinkedIn and Pinterest recommendation engineering posts, Uber and DoorDash ML platform posts, the Hugging Face inference blog. The patterns interviewers test are the patterns described in those sources; reading them closely is the highest-leverage preparation you can do.