Case Studies

An online store, a chat app, a URL shortener, file upload, search, an analytics dashboard, an AI assistant — each started from one sentence, each grown only as far as its requirements justify.

Case: Build an Online Store
▶ lab

One sentence — "build an online store" — taken from actors and actions through data, state, interfaces, a walking skeleton, the cart decision, checkout in pseudocode, payment research, failure cases, and scale only on evidence. The whole loop, on the running example, with nothing added before it was needed.

Q · You have "build an online store" and nothing else. How do you grow it from a sentence into a system, and how do you know at each step that the next piece was justified rather than merely available?
Case: A Chat App

"Users send messages to each other" → Users, Conversation, Messages, Participants → Send, Store, Retrieve, Realtime, Read State. The word "realtime" is the unknown; the decomposition puts it fourth, and the first version works without it.

Q · You are asked for a chat app and the word "realtime" is doing most of the work in the request. How do you decompose it so that realtime is one capability among six rather than the whole problem?
Case: A URL Shortener

Long URL → Short Code → Redirect. The first version is one table and two endpoints; the interesting engineering arrives only when the requirements do — uniqueness under concurrency, read-heavy traffic, click logging — and the ladder for "we need a distributed ID generator" ends somewhere much smaller.

Q · The URL shortener is the system-design interview's favourite, so you already know the "final" architecture. How do you build the first version without it, and what would have to be measured before any of it is justified?
Case: A File Upload Service

Upload, Storage, Metadata, Permissions, Download. The first version streams through the server; the requirement that changes the shape is size, and the prototype question — can the browser upload a large file directly to object storage? — is answered in an afternoon before any architecture depends on it.

Q · You need to let users upload files, and someone says "just use object storage". What are the five capabilities, which one forces the architecture, and what is the smallest prototype that tells you whether the browser can talk to storage directly?
Case: Search Products by Name

"Search products by name" is a SQL query until a requirement says otherwise. The case runs the why ladder for Elasticsearch honestly: the first version is a filtered query, the second is a database full-text index, and a dedicated search engine is justified by requirements the store may or may not ever have.

Q · The store needs "search products by name", and the first suggestion is a search engine. What is the sequence of solutions from a WHERE clause upward, and which requirement moves you from one to the next?
Case: An Analytics Dashboard

Metric, Source, Aggregation, Freshness, Visualization. "We need a dashboard" is a request for a chart; the requirement is a metric someone will act on, with a definition, a source and a freshness that decide whether the first version is a query against production, a nightly summary table, or a pipeline into a warehouse.

Q · The founder wants "a dashboard for the store". How do you find the metric behind the chart, and which of its properties — definition, source, aggregation, freshness — decides how much data engineering the first version needs?
Case: An AI Assistant for Company Documentation
▶ lab

"Answer questions about company documentation" → Documents, Retrieval, Context, Model, Answer, Evaluation. The first version is retrieval plus one prompt, measured against a question set; the why ladder for "we need a multi-agent system" ends at a retrieval fix most of the time — and says when it would not.

Q · You are asked for an assistant that answers questions about internal documentation. What are the six capabilities, which one do people skip, and what would have to be true before "we need agents" is the right next move?