AI System Design: The Complete Course
Architecting a whole AI system rather than building its parts: what to put where, what to leave out, and which tradeoffs you are choosing deliberately. This is the layer above every other course in the series, and it doubles as preparation for AI system design interviews, which reward the same thinking that produces good architecture.
You design one system: the next version of the platform behind Northdesk, a company that sells an AI helpdesk to 240 other companies. Its employees ask questions answered from their own company's permissioned documents (Ask), hand routine requests to a bounded agent that calls their company's systems (Cases), and upload documents that are processed in the background (Intake). The product team's target is 100,000 daily users asking 10 questions each, with a 3-second response. Module 3 shows, with five minutes of arithmetic, that the target cannot be met as written, and the rest of the course designs what can. Every decision is proved with a number or a small component that runs in Colab, and written down as a design document, an architecture decision record, a numbers sheet and a failure-mode table. Northdesk is fictional and its data is simulated; every lesson also opens with a real, cited case.
Why this order
Classical system design assumes a deterministic core, a fixed cost per request and failures that announce themselves. An AI system has none of those, and every later decision follows from that (Module 1). The course then follows the order the roadmap recommends for any design, on a whiteboard or in a document: clarify the problem, set the quality bar, run the numbers, pick the simplest architecture the numbers permit, draw the data path, draw the request path, mark the trust boundaries, say how you would know it works, name the failure modes, state the tradeoffs. The arithmetic comes before the architecture on purpose: the numbers decide the design far more often than the design decides the numbers.
Who this course is for
You can write Python, you have called a language model from code, and you know what an API, a database and a queue are.
| You are... | Start at |
|---|---|
| Preparing for an AI system design interview | Module 1, then Modules 2, 3, 4 and 15 closely; the rest as reference |
| An engineer who has built AI features and now designs whole systems | Module 1, and go in order |
| A lead or architect who reviews designs | Modules 3, 4, 11, 12 and 15 |
| New to calling language models | The AI Engineering course first |
| Deep on one layer (retrieval, agents, serving) and missing the rest | The module README for your layer says what you can skip |
Every module's README lists what you need to know before starting it and which step of the design order it covers.
What you need
- A Google account, to run code in Google Colab. Nothing to install; no GPU needed.
- For about half the lessons, one free API key from Groq or Google Gemini, or no key at all if you run a model on your own computer with Ollama.
- For the parts Colab cannot run (Docker Compose, PostgreSQL with pgvector, Qdrant and Redis as servers, Langfuse, Temporal), your own computer with Docker. These parts are optional; every lesson's point is proved in Colab first.
Setup takes about ten minutes: course-guide/02-setup-colab-and-llm-providers.md.
The modules
| # | Module | What you add to Northdesk | Needs first |
|---|---|---|---|
| 1 | How AI Systems Differ | The repository, the shared data, a call log and the first failure-mode table | Python, one model call |
| 2 | Requirements | Requirements with an explicit error rate, cost asymmetry and refusal rules, as data later gates read | Module 1 |
| 3 | Capacity and Cost Estimation | The estimator that reproduces the roadmap's worked estimate, and the numbers sheet | Module 2 |
| 4 | Architecture Selection | The model port, one question answered on four rungs of the ladder, ADR-001 | Module 3 |
| 5 | Data Architecture | Incremental, idempotent ingestion with redaction, lineage and a dead-letter list | Module 4 |
| 6 | Retrieval Architecture | Permissioned, tenant-isolated retrieval, scored for recall and for leaks | Module 5 |
| 7 | Model Layer | The model gateway: routing, cascade, fallback across providers, budgets, shadow calls | Modules 3 and 4 |
| 8 | Orchestration and State | The Ask workflow in LangGraph, sessions and compaction, memory, the job queue | Module 7 |
| 9 | Agentic Architecture | The bounded Cases agent over MCP, with ceilings, approvals, a sandbox and an audit trail | Module 8 |
| 10 | Deployment and Serving | The FastAPI service, cache layers, isolation tiers, Docker Compose and CI with eval gates | Modules 7 to 9 |
| 11 | Reliability | Timeouts, a retry budget, a circuit breaker, bulkheads and rate limits; the 22 September incident replayed | Modules 7 and 10 |
| 12 | Trust Boundaries | The trust boundary map, least privilege, output validation and defensive control checks | Modules 6 and 9 |
| 13 | Quality Architecture | The eval harness with gates, a prompt registry, OpenTelemetry traces, drift checks | Modules 6 to 10 |
| 14 | Scale and Evolution | A 10x simulation that shows what breaks first, and an embedding-model migration | Modules 3 and 10 |
| 15 | Communicating a Design | The whole design in the ten-step order, practice designs, and a debugging case from the traces | Modules 1 to 14 |
| 16 | Capstone | The Northdesk design review: every number regenerated, every component passing, two practice designs in full | All |
54 lessons, 359 topics (330 Essential, 29 Recommended). Each taught module ends with a lab and an incident file.
Open source first, managed beside it
Every design area is built with open-source tools the course runs, and compared with the managed or closed options a real team might choose, shown as official snippets labelled "not run here".
| Area | The course runs | Shown beside it |
|---|---|---|
| Models | Groq, Gemini and Ollama through one setup cell | OpenAI, Anthropic, Amazon Bedrock, Google Gemini Enterprise Agent Platform, Microsoft Foundry |
| Gateway | A hand-built gateway, then LiteLLM | Cloud AI gateways |
| Serving | vLLM and SGLang (commands; no GPU in Colab) | Managed model endpoints |
| Retrieval | sentence-transformers, FAISS, Chroma, Qdrant, pgvector, rank_bm25 | Managed vector and search services |
| Orchestration and durability | LangGraph, Temporal | Cloud workflow services |
| Jobs | RQ on Redis | Cloud queues |
| Tools and agents | MCP, A2A | Hosted agent and tool platforms |
| Sandboxing | Subprocess limits, then Docker; gVisor, Firecracker, WASM described | Hosted sandboxes |
| Tracing | A hand-built tracer, OpenTelemetry, Phoenix, Langfuse | Hosted tracing and APM products |
| Service and delivery | FastAPI, Docker, Docker Compose, GitHub Actions | One cloud platform, walked through from its docs |
How each lesson works
Every lesson is a walk through one Northdesk decision, one picture at a time:
- The situation: a decision Northdesk has to make.
- A real case, first: something that really happened, from an engineering blog, incident write-up, paper or talk, cited.
- The idea: fifteen to thirty figures, one idea each, one running example.
- Run it: code with a walkthrough of every line, proving the claim.
- Break it: a failure you cause on purpose.
- In production: what teams do at scale, open source and managed.
- The question a reviewer will ask, one exercise with a runnable check, key terms and sources.
Every output shown in the course comes from a real run. More detail: course-guide/01-how-this-course-works.md.
Course guide
| File | Read it when |
|---|---|
| 01-how-this-course-works.md | Before your first lesson |
| 02-setup-colab-and-llm-providers.md | Before you run any code; the setup cell, the pinned libraries and the one price table |
| 03-northdesk.md | To meet the company, the people, the tenants, the dates and the files each module adds |
| 06-shared-data.md | To see the data every module reuses, and the code that makes it |
| 07-run-locally.md | To run the repository on your own computer, with Ollama and Docker Compose |
| 04-style-guide.md | Only if you are writing or editing lessons |
| 05-image-style-guide.md | Only if you are drawing the course figures |
Where other courses go deeper
This course decides what goes where and proves it with small components. For the internals of each layer:
- Retrieval pipelines in depth: the RAG course.
- Agents, tool design and the agent loop: the Agentic AI Engineer course.
- The Model Context Protocol itself: the MCP course.
- Tokens, decoding, prompting and evaluation of models: the Large Language Models course.
- How serving works inside the model (KV cache, batching, parallelism): the Transformers course.
- Backend, data stores and deployment for AI applications: the AI Engineering course.
The one idea
As the roadmap puts it, the strongest signal in any AI design discussion is restraint. Most proposed architectures are more autonomous, more multi-agent and more fine-tuned than the problem requires, and the engineer who can explain why they chose the boring version, with the numbers, is usually the one you want building it.