Two engineers propose the same design for Tiffin's live order tracking. Both use WebSockets, Redis and a pub/sub channel per order. One gets approval in ten minutes. The other spends an hour defending it and gets sent back to "think about it more".
The difference isn't the design. It's how they explained it. The first said what she chose, what she gave up, and why that trade was right for Tiffin. The second listed the technologies.
Design is a set of decisions (Module 1). If nobody can see the decisions, all they can judge is the diagram.
The basic sentence
Almost every good design explanation follows one shape:
We chose X over Y, because of Z. The cost is W, which is acceptable because V.
Here it is on a real Tiffin decision from Module 2, made when Tiffin had 800 restaurants:
"We chose polling every 5 seconds over WebSockets for the kitchen tablets, because restaurants need orders within 10 seconds and polling meets that with no new infrastructure. The cost is about 160 extra requests a second, which is acceptable because one server handles that easily. We'll revisit if we need orders on screen in under 2 seconds."
Every part of that sentence does work:
| Part | What it shows |
|---|---|
| X over Y | You considered at least one real alternative |
| Because Z | The reason ties to a requirement or a number |
| The cost is W | You know what you gave up |
| Acceptable because V | You checked the cost against the requirements |
| We'll revisit if... | You know when the decision stops being right |
Compare: "We'll use polling because it's simpler." Simpler than what? By how much? Does it meet the 10-second need? That sentence isn't wrong, it just doesn't let anyone check it.
Tie every reason to a requirement or a number
The strongest reasons point back at something you already agreed on. Weak reasons point at the tool.
| Weak reason | Strong reason |
|---|---|
| "Redis is really fast" | "The menu page gets 500 reads a second at dinner and must load in 200 ms. Redis serves a cached menu in about a millisecond" |
| "Kafka is industry standard" | "Four teams need the same order events, and each needs to replay the last day after an outage. A log that keeps events and lets each reader track its own position fits that" |
| "NoSQL scales better" | "We write 2,500 pings a second, read only the latest per rider, and never join. A key-value store fits that access pattern exactly" |
| "Microservices are more maintainable" | "The search team ships three times a day and waits up to 24 hours for the shared deploy" |
If you can't finish the strong version of a sentence, that's useful information. It probably means the box doesn't need to be there yet.
Say what you gave up
Every choice costs something (Module 1's tradeoffs lesson). Saying the cost out loud does two things. It shows you understand the choice, and it lets others tell you if the cost is worse than you think.
Some common pairs, with Tiffin examples:
- Freshness for speed. "We cache menus for 5 minutes, so a price change can take 5 minutes to show. Checkout re-reads prices from the database, so nobody is charged a stale price."
- Consistency for read capacity. "Order status reads from replicas, so a just-placed order might not be on the replica yet. The app shows the order from the checkout response, and if the replica says 'not found', the server checks the primary."
- Simplicity for scale. "One primary database caps our writes, at roughly 5,000 a second for our kind of rows. We're at about 1,200."
- Latency for durability. "We wait for the payment provider's confirmation before saying 'order placed'. It adds 800 ms but we never confirm an unpaid order."
When someone asks "what's the downside?", the worst answer is "there isn't one". There always is. The best answer is the downside, plus why it's fine here.
Rewrite a weak explanation
An engineer writes in a design doc: "We'll put a message queue between checkout and the restaurant notification for scalability and decoupling." Rewrite it using the basic sentence.
Show one answer
"We'll send the restaurant notification through a queue instead of calling the notification provider directly in checkout, because the provider sometimes takes 3 seconds to respond and checkout must return within 1 second. The cost is that the notification goes out a moment after the order is saved rather than in the same request, and we need workers and retries to run. That's fine because restaurants only need the order within 10 seconds, and the job is safe to run twice. We'd reconsider only if the provider became consistently fast."
The original words "scalability" and "decoupling" were replaced by the actual problem (a slow provider), the requirement it threatens (1 second checkout) and the cost.
Show the alternatives you rejected
Mention one or two options you didn't pick, briefly, and why. You don't need to compare five databases. You need to show the choice was a choice.
A good format for anything bigger than a sentence is a short table:
| Option | Meets 10 s target? | New infrastructure | Works on bad Wi-Fi? | Verdict |
|---|---|---|---|---|
| Polling every 5 s | Yes, worst case ~5 s | None | Yes, each poll is independent | Chosen |
| Long polling | Yes, ~1 s | None, but long-held connections | Mostly | Reconsider if we need faster |
| WebSockets | Yes, under 1 s | Connection servers, pub/sub | Needs reconnect logic | Overkill today |
The table makes the trade visible at a glance. A reviewer who disagrees can point at a cell instead of arguing in circles.
Say when you'd change your mind
Decisions have a shelf life. Saying when yours expires is one of the strongest signals that you understand it.
- "One primary is fine until about 5,000 writes a second. We're at about 1,200. Past 3,000, we start planning sharding by city."
- "Polling is fine with 800 tablets. At 20,000, that's 4,000 requests a second just for polling, and we'd move to server push."
- "The search team stays in the monolith unless their deploy wait becomes a weekly complaint."
This turns "is this the right design?" into "is this the right design for now, and what will tell us when it isn't?" That's a much easier question to agree on.
"It depends" is the start of an answer
You'll often hear that the right answer in system design is "it depends". That's true, and it's useless on its own. Finish the sentence: it depends on what, and here's what I'd do in each case.
"Should order history live in SQL or a document store? It depends on how we read it. If customers only ever see their own orders, newest first, either works and I'd keep Postgres because we already run it. If support needs to search orders by any field, SQL with indexes fits better. If we had billions of orders and only ever looked them up by customer, a key-value store would scale more cheaply."
Write it down
Spoken explanations disappear. For decisions that matter, write a short record that someone joining next year can read. A common format is an architecture decision record: a page or less, with the context, the decision, the alternatives considered and the consequences. Keep them in the repository next to the code.
The best time to write one is the moment you decide. Six months later, nobody will remember why polling was chosen, and someone will "fix" it.
Explain a choice out loud
Pick one decision from the lab in Module 9: moving rider ping history out of Postgres into batched files in object storage. Say it as one basic sentence plus a "we'd revisit if".
Show one answer
"We'll store rider ping history as batched files in object storage instead of rows in Postgres, because pings will reach 3,750 writes a second and would dominate the primary, while we only read them for occasional disputes. The cost is that looking up a delivery's path takes a second or two and we need a batching worker, which is fine for a support-only feature. We'd revisit if a product feature needed to query ping history in real time, such as live heatmaps."
What to remember
- A design is judged by its decisions. Make them visible.
- Use the basic sentence: we chose X over Y because Z; the cost is W, acceptable because V.
- Tie every reason to a requirement or a number, not to a tool's reputation.
- Always name what you gave up. "No downside" is never true.
- Show the alternatives you rejected, briefly. A small table makes the trade visible.
- Say when you'd change your mind. Decisions have a shelf life.
- "It depends" must be followed by what it depends on and what you'd do in each case. Write important decisions down.