@daowolf/system-design-quest 0.0.0-stage → 1.1.1

package/dist/chapters.json

@@ -0,0 +1,4154 @@
+{
+ "version": 1,
+ "built": "2026-10-28",
+ "chapters": [
+  {
+   "chapter": 1,
+   "slug": "method",
+   "title": "The method",
+   "emoji": "🧭",
+   "pillar": "The interview",
+   "blurb": "Run the round in the right order, decide instead of asking, and land a whole design before going deep.",
+   "boss": "m-boss",
+   "challenges": [
+    {
+     "id": "m-01",
+     "type": "order",
+     "bloom": "remember",
+     "prompt": "Put the steps of a system design round in order.",
+     "items": [
+      "Functional requirements",
+      "Non-functional requirements",
+      "Core entities",
+      "API",
+      "High-level design",
+      "Deep dives"
+     ],
+     "explain": "Requirements first, because every later box has to serve one. The high-level design meets the functional requirements; the deep dives meet the non-functional ones. Say it as your plan in the first minute.",
+     "source": "https://www.hellointerview.com/learn/system-design/in-a-hurry/delivery"
+    },
+    {
+     "id": "m-02",
+     "type": "multi",
+     "bloom": "understand",
+     "prompt": "Which of these are non-functional requirements?",
+     "options": [
+      "Users can upload a photo",
+      "Reads return in under 200 ms for 99% of requests",
+      "The system stays up if one data centre goes down",
+      "Users can follow other users",
+      "A payment is never applied twice",
+      "Admins can delete posts"
+     ],
+     "correct": [
+      1,
+      2,
+      4
+     ],
+     "explain": "Functional requirements say what users can do (\"users should be able to…\"). Non-functional ones say how well the system must do it (\"the system should…\"), and they carry numbers. They decide your deep dives.",
+     "source": "https://www.hellointerview.com/learn/system-design/in-a-hurry/delivery"
+    },
+    {
+     "id": "m-03",
+     "type": "duel",
+     "bloom": "evaluate",
+     "prompt": "The interviewer says \"up to you\" about whether refunds are in scope. What do you say?",
+     "choices": [
+      "\"Do you want refunds in scope?\"",
+      "\"I'll assume refunds are out. Tell me if that's wrong.\"",
+      "\"Let's include everything, to be safe.\""
+     ],
+     "correct": 1,
+     "reasons": [
+      "It shows judgement and keeps the time for the hard parts",
+      "Interviewers mark you on how many questions you ask",
+      "It means you can never be wrong"
+     ],
+     "reason": 0,
+     "costs": [
+      "If they did want refunds, you adjust in one sentence",
+      "Nothing; assumptions are free",
+      "You lose the marks for problem navigation"
+     ],
+     "cost": 0,
+     "explain": "Asking hands the decision back to them; deciding and checking shows you can lead. The cost is tiny, because \"tell me if that's wrong\" invites a correction. Say it as a decision, then check.",
+     "source": "https://www.hellointerview.com/blog/staff-level-system-design"
+    },
+    {
+     "id": "m-04",
+     "type": "recall",
+     "bloom": "remember",
+     "prompt": "The interviewer has just given you the problem. What's your first move?",
+     "answer": "Write it down in their words and read it back: \"So we're building X for Y. Have I got that right?\"",
+     "explain": "Reading it back catches a misheard problem before you spend twenty minutes on it, and it shows you listen. It takes ten seconds.",
+     "source": "https://www.hellointerview.com/learn/system-design/in-a-hurry/delivery"
+    },
+    {
+     "id": "m-05",
+     "type": "multi",
+     "bloom": "analyse",
+     "prompt": "Fifty minutes isn't enough to go deep on everything. Which of these usually earn deep-dive time?",
+     "options": [
+      "Money moving",
+      "Work that runs on a schedule",
+      "Calls to an outside partner",
+      "Very high read or write volume",
+      "A static help page",
+      "A profile settings form",
+      "Changing a display name"
+     ],
+     "correct": [
+      0,
+      1,
+      2,
+      3
+     ],
+     "explain": "Go deep where things break or cost money: money, timing, partners and scale. The rest take the simple path, one sentence each. Say \"I'll go deep on X, Y and Z; the rest take the simple path.\"",
+     "source": "https://www.hellointerview.com/blog/staff-level-system-design"
+    },
+    {
+     "id": "m-06",
+     "type": "write",
+     "bloom": "apply",
+     "prompt": "Write the non-functional requirements for a URL shortener, with numbers. Don't forget the busiest time.",
+     "key_points": [
+      "A scale figure (redirects or new links a day)",
+      "A peak figure, not just the average",
+      "A latency target for a redirect",
+      "Availability: redirects must stay up",
+      "Reads far outnumber writes"
+     ],
+     "model": "About 100 million redirects a day, ten times the average rate at the peak; a redirect in under 100 ms for 99% of requests; redirects available 99.99% of the time; reads outnumber new links about 100 to 1; a short link never points at the wrong place.",
+     "explain": "Numbers turn \"fast and reliable\" into decisions. The peak, not the average, sizes the system, and the read-to-write ratio tells you a cache will pay off. Say \"the system should…\" and put a number on each.",
+     "source": "https://www.hellointerview.com/learn/system-design/problem-breakdowns/bitly"
+    },
+    {
+     "id": "m-07",
+     "type": "recall",
+     "bloom": "understand",
+     "prompt": "Why land a simple design end to end before going deep on any part?",
+     "answer": "A working whole proves every requirement has a path and lets the interviewer steer the deep dive. Not reaching a working system is a common way to fail.",
+     "explain": "Depth on one box with gaps elsewhere reads as poor navigation. Say \"Let me land a simple version end to end first\", then deepen where the requirements push.",
+     "source": "https://www.hellointerview.com/learn/system-design/in-a-hurry/delivery"
+    },
+    {
+     "id": "m-08",
+     "type": "duel",
+     "bloom": "evaluate",
+     "prompt": "Ten minutes into the high-level design, you can see reads will be heavy. Nobody has asked about performance yet. Best move?",
+     "choices": [
+      "Design the cache in full now",
+      "Say where a cache would go, note it, and keep landing the design",
+      "Leave caching out; it's an optimisation"
+     ],
+     "correct": 1,
+     "reasons": [
+      "It shows you see the bottleneck without derailing the whole design",
+      "Caches are always marked down in interviews",
+      "Interviewers never ask about performance"
+     ],
+     "reason": 0,
+     "costs": [
+      "You owe it a proper look in the deep dive",
+      "The design gets slower",
+      "None"
+     ],
+     "cost": 0,
+     "explain": "Naming it shows judgement; designing it now spends deep-dive time before the whole exists. Say \"A cache would go here; I'll come back to it\", and do.",
+     "source": "https://www.hellointerview.com/learn/system-design/in-a-hurry/delivery"
+    },
+    {
+     "id": "m-09",
+     "type": "lightning",
+     "bloom": "remember",
+     "prompt": "When this happens, say what? 90 seconds.",
+     "pairs": [
+      [
+       "They say \"you decide\"",
+       "\"I'll assume X. Tell me if that's wrong.\""
+      ],
+      [
+       "You're stuck or going round in circles",
+       "\"Let me park that and land the rest.\""
+      ],
+      [
+       "They push back on a choice",
+       "\"Good challenge.\" Weigh it, decide, move on"
+      ],
+      [
+       "It's time to draw",
+       "\"Let me land a simple version end to end first.\""
+      ],
+      [
+       "A tool you haven't run in production",
+       "\"I haven't run X in production. What I'd need from it is Y.\""
+      ],
+      [
+       "The wrap-up starts",
+       "\"Three things I'd do next.\""
+      ],
+      [
+       "You need a moment to think",
+       "\"Let me think for ten seconds.\""
+      ],
+      [
+       "You're about to add a box",
+       "Say what it solves and what it costs"
+      ]
+     ],
+     "explain": "Pre-loaded lines stop silence and stop you handing decisions back. Each one buys time and keeps you leading.",
+     "source": "https://www.hellointerview.com/blog/staff-level-system-design"
+    },
+    {
+     "id": "m-boss",
+     "type": "sprint",
+     "bloom": "create",
+     "prompt": "Requirements for a Pastebin (people paste text and share a link). Out loud, against the clock: read it back, who uses it and what they do, your three hard parts, how busy (with the peak), what can't break, what's out.",
+     "minutes": 10,
+     "checks": [
+      "Read the problem back in one line",
+      "Named each type of user and what they do",
+      "Picked my own three hard parts",
+      "Asked for the scale and the peak",
+      "Said \"I'll assume…\" instead of asking \"do you want…?\"",
+      "Said what's out of scope",
+      "Finished inside the time"
+     ],
+     "explain": "This is the shape of every round's first quarter. If one check missed, that's the line to rehearse before the next round.",
+     "source": "https://github.com/donnemartin/system-design-primer"
+    }
+   ]
+  },
+  {
+   "chapter": 2,
+   "slug": "requirements",
+   "title": "Requirements and numbers",
+   "emoji": "🟣",
+   "pillar": "Core concepts",
+   "blurb": "Turn a vague brief into numbers. Functional versus non-functional, sizing for the peak, and the yardsticks you do the sums with.",
+   "boss": "r-boss",
+   "challenges": [
+    {
+     "id": "r-01",
+     "type": "multi",
+     "bloom": "analyse",
+     "prompt": "A cloud documents app. Which of these non-functional requirements could you actually test as written?",
+     "options": [
+      "The app should be fast",
+      "Opening a document takes under 300 ms (milliseconds) for 99% of requests",
+      "The system should be highly available",
+      "Up 99.9% of the time, so at most about 9 hours down a year",
+      "A saved edit survives the loss of a whole data centre",
+      "Other readers see an edit within 2 seconds",
+      "It should scale well",
+      "Users can share a document with a link"
+     ],
+     "correct": [
+      1,
+      3,
+      4,
+      5
+     ],
+     "explain": "A figure can be checked and drives a decision; \"fast\", \"highly available\" and \"scales well\" can't. Sharing a link is a functional requirement, not a quality. Fix: give each quality a number (a latency for 99% of requests, nines of availability, what loss is tolerable, how stale a read may be). Say \"the system should open a document in under 300 ms for 99% of requests\".",
+     "source": "https://www.hellointerview.com/learn/system-design/in-a-hurry/delivery"
+    },
+    {
+     "id": "r-02",
+     "type": "recall",
+     "bloom": "understand",
+     "prompt": "Why size a system for its busiest second rather than the daily average?",
+     "answer": "Traffic bunches into busy hours and spikes. A system built for the average falls over exactly when most people use it. Work out the average, multiply by a peak factor, and say the factor out loud.",
+     "explain": "An average hides the evening rush, a launch or a post that takes off. Interview sums use a multiplier: this game uses 10, and worked examples range from about 2 to 100. Say \"about 2,000 a second on average; I'll call the peak 20,000 and design for that\".",
+     "source": "https://www.hellointerview.com/learn/system-design/problem-breakdowns/bitly"
+    },
+    {
+     "id": "r-03",
+     "type": "estimate",
+     "bloom": "apply",
+     "prompt": "A photo-sharing app. Size its busiest second. Use about 100,000 seconds in a day and a peak of about 10 times the average.",
+     "generator": {
+      "kind": "peak_rps",
+      "params": {
+       "users": [
+        1000000,
+        50000000
+       ],
+       "actions": [
+        5,
+        50
+       ]
+      }
+     },
+     "explain": "A day has 86,400 seconds. Rounding up to 100,000 turns the division into dropping five zeros, and the small error vanishes inside the peak factor. Then multiply by 10. Say the working aloud, because the method earns the marks, not the exact digits.",
+     "source": "https://www.hellointerview.com/learn/system-design/problem-breakdowns/top-k"
+    },
+    {
+     "id": "r-04",
+     "type": "duel",
+     "bloom": "evaluate",
+     "prompt": "An online shop's catalogue. Shoppers view product pages about 1,000 times for every edit the staff make. The database is starting to struggle. What do you add first?",
+     "choices": [
+      "Split the database across several machines (sharding)",
+      "A cache in front of the database for product pages",
+      "A queue to buffer the writes",
+      "A bigger machine that only takes writes"
+     ],
+     "correct": 1,
+     "reasons": [
+      "Nearly all the load is reads, and a cache read takes about 1 ms, a query 20-50 ms",
+      "A cache makes writes faster",
+      "A shop never needs sharding"
+     ],
+     "reason": 0,
+     "costs": [
+      "A product page can be slightly out of date until its cached copy is refreshed",
+      "Every read now hits the database twice",
+      "Nothing, because caches are free"
+     ],
+     "cost": 0,
+     "explain": "The read-to-write ratio tells you where to spend. At 1,000 reads per write the writes are tiny, so sharding solves a problem you don't have. A cache takes most reads off the database. Say \"Reads dominate, so a cache first. I'll accept a few seconds of staleness and refresh a page's cached copy when it's edited.\"",
+     "source": "https://www.hellointerview.com/learn/system-design/in-a-hurry/core-concepts"
+    },
+    {
+     "id": "r-05",
+     "type": "estimate",
+     "bloom": "apply",
+     "prompt": "An invoicing service keeps a file copy of every invoice it issues. How much storage does a year of new invoices need? Each step from KB to MB to GB to TB (kilobytes up to terabytes) is about 1,000 times the last.",
+     "generator": {
+      "kind": "storage_year",
+      "params": {
+       "items": [
+        10000,
+        1000000
+       ],
+       "kb": [
+        50,
+        500
+       ]
+      }
+     },
+     "explain": "Size a day (items times size), times 365 for a year, then step the units up: a thousand KB is an MB, a thousand MB a GB, a thousand GB a TB. Name the unit at every step so a slip shows. Files like these belong in object storage, with only their details in the database; a single database copes comfortably with a few TB.",
+     "source": "https://www.hellointerview.com/learn/system-design/in-a-hurry/core-concepts"
+    },
+    {
+     "id": "r-06",
+     "type": "write",
+     "bloom": "apply",
+     "prompt": "A podcast hosting site: creators upload episodes, listeners stream them. Rewrite this brief with numbers: \"It must be fast, always up, never lose an upload and cope with growth.\"",
+     "key_points": [
+      "Latency with a percentile, e.g. an episode starts playing within 1 second for 99% of plays",
+      "Availability as nines, with what that allows, e.g. 99.9% is about 9 hours down a year",
+      "Durability, e.g. once an upload is confirmed it survives losing a data centre",
+      "Scale with a peak: plays a day, and the busiest second at about 10 times the average",
+      "The read-to-write ratio, e.g. plays far outnumber uploads"
+     ],
+     "model": "Episodes start within 1 second for 99% of plays. Listening is up 99.9% of the time (about 9 hours down a year); uploads can tolerate a little more. Once an upload is confirmed it survives losing a data centre. 10 million plays a day, peaking at about 10 times the average. Around 10,000 plays per upload, so reads dominate.",
+     "explain": "Each vague word hides a decision. A number for each one tells the interviewer what you're designing for and gives every deep dive a target. Say \"the system should…\", then the figure, then which part it applies to, because listening may need more nines than uploading.",
+     "source": "https://www.hellointerview.com/learn/system-design/in-a-hurry/delivery"
+    },
+    {
+     "id": "r-07",
+     "type": "multi",
+     "bloom": "analyse",
+     "prompt": "A page must load in under 250 ms. The app server makes its database reads one after another. Which set-ups fit inside that budget?",
+     "options": [
+      "Four queries to a database in the same data centre",
+      "Four queries to a database in another region",
+      "Four reads that all hit a cache in the same data centre",
+      "One combined query to a database in another region",
+      "Four calls to a service in another region, each running one query"
+     ],
+     "correct": [
+      0,
+      2,
+      3
+     ],
+     "explain": "Round trips decide it. Inside one data centre a hop costs under 1-2 ms; to another region it costs 50-150 ms, before the query's own 20-50 ms. Four in a row across regions blow the budget; one does not. Fix: keep chatty calls in one region, batch them, or cache. Ask \"how many round trips, and how far?\"",
+     "source": "https://www.hellointerview.com/learn/system-design/deep-dives/numbers-to-know"
+    },
+    {
+     "id": "r-08",
+     "type": "estimate",
+     "bloom": "analyse",
+     "prompt": "A web analytics product records every click on its customers' websites. Work out the peak writes a second, then decide whether one database copes or the data needs splitting.",
+     "generator": {
+      "kind": "shard_or_not",
+      "params": {
+       "users": [
+        100000,
+        50000000
+       ],
+       "writes": [
+        10,
+        200
+       ]
+      }
+     },
+     "explain": "One well-tuned SQL (Structured Query Language) database handles up to about 50,000 simple transactions a second, but writes strain it first. Past about 10,000 writes a second, consider splitting the data across machines (sharding). Below that, say \"one database plus a standby copy; no sharding yet\". Sharding early buys complexity you don't need.",
+     "source": "https://www.hellointerview.com/learn/system-design/in-a-hurry/core-concepts"
+    },
+    {
+     "id": "r-09",
+     "type": "order",
+     "bloom": "understand",
+     "prompt": "Put these in order, fastest first.",
+     "items": [
+      "Reading a value from the app's own memory",
+      "Reading a small block from a local solid-state drive (SSD)",
+      "Reading from a cache server in the same data centre",
+      "Running a typical database query",
+      "A round trip to another region"
+     ],
+     "explain": "Memory takes nanoseconds, an SSD microseconds, a cache about 1 ms, a database query 20-50 ms and another region 50-150 ms. That ladder is why a cache pays off and why chatty calls across regions hurt. Say the number whenever you add a box or a hop.",
+     "source": "https://www.hellointerview.com/learn/system-design/in-a-hurry/core-concepts"
+    },
+    {
+     "id": "r-boss",
+     "type": "lightning",
+     "bloom": "remember",
+     "prompt": "The yardsticks. You hear the phrase; give the number or the rule. 90 seconds.",
+     "seconds": 90,
+     "pairs": [
+      [
+       "Seconds in a day, for interview sums",
+       "About 100,000"
+      ],
+      [
+       "The peak, compared with the average",
+       "About 10 times the average"
+      ],
+      [
+       "One step from KB to MB, or from GB to TB",
+       "Times 1,000"
+      ],
+      [
+       "What one well-tuned SQL database can take",
+       "Up to about 50,000 transactions a second"
+      ],
+      [
+       "When to think about splitting the database",
+       "Past about 10,000 writes a second"
+      ],
+      [
+       "A read from a cache",
+       "About 1 ms"
+      ],
+      [
+       "A typical database query",
+       "20-50 ms"
+      ],
+      [
+       "A call inside one data centre",
+       "Under 1-2 ms"
+      ],
+      [
+       "A round trip to another region",
+       "50-150 ms"
+      ],
+      [
+       "Reads far outnumber writes",
+       "Cache first, then read copies"
+      ]
+     ],
+     "explain": "These numbers turn hand-waving into decisions in seconds. If one was slow, write it on a card and say it aloud before the next round.",
+     "source": "https://www.hellointerview.com/learn/system-design/in-a-hurry/core-concepts"
+    }
+   ]
+  },
+  {
+   "chapter": 3,
+   "slug": "apis",
+   "title": "APIs and live updates",
+   "emoji": "🔌",
+   "pillar": "Core concepts",
+   "blurb": "APIs (application programming interfaces) over HTTP (Hypertext Transfer Protocol): pick a style, make retries safe, page through lists, stream live updates.",
+   "boss": "a-boss",
+   "challenges": [
+    {
+     "id": "a-01",
+     "type": "duel",
+     "bloom": "evaluate",
+     "prompt": "Two of your own backend services call each other thousands of times a second, and no browser ever uses this path. Which style fits: REST (representational state transfer), GraphQL, or gRPC (a remote procedure call, or RPC, framework)?",
+     "choices": [
+      "REST, with JSON (JavaScript Object Notation) bodies",
+      "GraphQL",
+      "gRPC, with Protocol Buffers over HTTP/2"
+     ],
+     "correct": 2,
+     "reasons": [
+      "Compact binary messages and generated, typed clients suit busy internal calls",
+      "It is the only style that works between two services",
+      "Browsers support it better than REST"
+     ],
+     "reason": 0,
+     "costs": [
+      "Browsers can't call it directly, and binary messages are harder to eyeball",
+      "It can't stream results",
+      "Its messages are bigger than JSON"
+     ],
+     "cost": 0,
+     "explain": "gRPC sends Protocol Buffers, a compact binary format, over HTTP/2 and generates typed client code, so busy internal calls get cheaper and safer. REST stays the default for anything public or called from a browser. Say \"REST at the edge, gRPC between services\" and move on: it's worth a mention, not a deep dive.",
+     "source": "https://www.hellointerview.com/learn/system-design/core-concepts/networking-essentials"
+    },
+    {
+     "id": "a-02",
+     "type": "multi",
+     "bloom": "analyse",
+     "prompt": "Which of these point towards GraphQL rather than REST?",
+     "options": [
+      "Web, mobile and watch apps each need different fields from the same data",
+      "One screen would otherwise take five round trips to put together",
+      "Responses must be cached by URL (web address) in shared caches",
+      "A small public API for outside developers",
+      "High-volume calls between two internal services",
+      "Clients fetch large objects but only use two fields of each"
+     ],
+     "correct": [
+      0,
+      1,
+      5
+     ],
+     "explain": "GraphQL lets each client ask for exactly the fields it needs in one request, which fixes over-fetching and extra round trips. It has costs: one endpoint makes plain HTTP caching harder, nested fields can set off many small queries (the N+1 problem, fixed by batching), and access checks move to each field. Say \"REST by default; GraphQL when clients' needs really differ\".",
+     "source": "https://www.hellointerview.com/learn/system-design/core-concepts/api-design"
+    },
+    {
+     "id": "a-03",
+     "type": "write",
+     "bloom": "apply",
+     "prompt": "Sketch the API for a photo-sharing app: upload a photo, list one person's photos, and like a photo. For each endpoint give the method, the path and what it returns.",
+     "key_points": [
+      "Plural nouns for resources, e.g. /photos and /users/{id}/photos",
+      "The caller comes from the authentication token, never a user id in the body",
+      "Upload with POST and an idempotency key, so a retry doesn't create a second photo",
+      "The list is paged with a cursor and returns the next cursor",
+      "Liking can be repeated safely, e.g. PUT /photos/{id}/like",
+      "Status codes: 201 on create, 401 without a valid token, 404 for a missing photo"
+     ],
+     "model": "POST /photos with an Idempotency-Key header returns 201 and the new photo. GET /users/{id}/photos?cursor=abc&limit=20 returns 200, a page of photos and nextCursor. PUT /photos/{id}/like returns 204; DELETE on the same path removes the like. The caller always comes from the token. 401 without a valid token, 404 if the photo is gone.",
+     "explain": "Nouns for things and HTTP methods for actions keep an API predictable. Taking the caller from the signed token stops anyone acting as someone else by editing a field in the body. Say \"the user comes from the token\" as you write each endpoint: interviewers listen for it.",
+     "source": "https://www.hellointerview.com/learn/system-design/in-a-hurry/delivery"
+    },
+    {
+     "id": "a-04",
+     "type": "multi",
+     "bloom": "understand",
+     "prompt": "Which HTTP methods are idempotent: sending the same request twice leaves the server as one request would?",
+     "options": [
+      "GET",
+      "POST",
+      "PUT",
+      "DELETE",
+      "PATCH",
+      "HEAD"
+     ],
+     "correct": [
+      0,
+      2,
+      3,
+      5
+     ],
+     "explain": "GET and HEAD only read. PUT sets a resource to a given state. DELETE removes it, and a second DELETE may answer 404 but changes nothing more. POST creates something new each time, and PATCH isn't guaranteed safe to repeat (think \"add 1 to the count\"). Retry the idempotent ones freely; give POST an idempotency key.",
+     "source": "https://developer.mozilla.org/en-US/docs/Glossary/Idempotent"
+    },
+    {
+     "id": "a-05",
+     "type": "duel",
+     "bloom": "evaluate",
+     "prompt": "A client sends POST /invoices. The response times out, the client retries, and the customer now has two identical invoices. What's the fix?",
+     "choices": [
+      "The client sends a unique key; the server replays the first result for repeats",
+      "Turn off retries in the client",
+      "Wait longer before retrying",
+      "Skip any new invoice that looks like a recent one"
+     ],
+     "correct": 0,
+     "reasons": [
+      "A retry with the same key gets the stored first answer, so nothing is made twice",
+      "POST is idempotent already, so the key is only for logs",
+      "Keys make each request faster"
+     ],
+     "reason": 0,
+     "costs": [
+      "The server stores each key and its result for a while and checks it on every create",
+      "Clients can never retry again",
+      "Every invoice needs a manual check"
+     ],
+     "cost": 0,
+     "explain": "A timeout doesn't tell the client whether the invoice was made, so retrying is right, and POST isn't idempotent. A unique key per attempt (an idempotency key) lets the server spot a repeat and replay the first answer. Guessing from the contents would drop genuine look-alikes. Say \"POST with an idempotency key, kept for a day or so\".",
+     "source": "https://www.hellointerview.com/learn/system-design/core-concepts/api-design"
+    },
+    {
+     "id": "a-06",
+     "type": "duel",
+     "bloom": "evaluate",
+     "prompt": "A photo app's home timeline gets new posts every second while people scroll down it. The list endpoint takes ?offset=40&limit=20. What do you change?",
+     "choices": [
+      "Keep offset paging, because it's simpler",
+      "Switch to a cursor: an opaque token for the last item seen",
+      "Return the whole timeline in one response"
+     ],
+     "correct": 1,
+     "reasons": [
+      "New posts shift every offset, so pages repeat or skip items; a cursor sticks to an item",
+      "Cursors are part of the REST standard",
+      "Offset responses can't be cached"
+     ],
+     "reason": 0,
+     "costs": [
+      "You can't jump straight to page 37",
+      "Readers see more repeated posts",
+      "The client downloads every post"
+     ],
+     "cost": 0,
+     "explain": "With offsets, ten new posts at the top push everything down, so the next page repeats ten the reader has already seen. A cursor means \"after this item\" and stays put. Offsets are fine for lists that rarely change, such as search results. Say \"cursor paging, because the list changes while people scroll\".",
+     "source": "https://www.hellointerview.com/learn/system-design/core-concepts/api-design"
+    },
+    {
+     "id": "a-07",
+     "type": "lightning",
+     "bloom": "remember",
+     "prompt": "Status codes. You hear what happened; give the code. 90 seconds.",
+     "seconds": 90,
+     "pairs": [
+      [
+       "A POST made a new resource",
+       "201 Created"
+      ],
+      [
+       "The delete worked and there's nothing to send back",
+       "204 No Content"
+      ],
+      [
+       "Your cached copy is still current",
+       "304 Not Modified"
+      ],
+      [
+       "The request body is malformed",
+       "400 Bad Request"
+      ],
+      [
+       "No token, or the token isn't valid",
+       "401 Unauthorized"
+      ],
+      [
+       "Signed in, but not allowed to see this",
+       "403 Forbidden"
+      ],
+      [
+       "There's no such resource",
+       "404 Not Found"
+      ],
+      [
+       "The client is calling too often",
+       "429 Too Many Requests"
+      ],
+      [
+       "An unhandled error on the server",
+       "500 Internal Server Error"
+      ],
+      [
+       "The server is overloaded or down for maintenance; try later",
+       "503 Service Unavailable"
+      ]
+     ],
+     "explain": "4xx codes mean the caller must change something; 5xx mean the server failed and a retry may work. 401 means \"who are you?\", 403 means \"I know who you are, and no\". If one tripped you, say its pair aloud: 401 versus 403 is the usual slip.",
+     "source": "https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status"
+    },
+    {
+     "id": "a-08",
+     "type": "sticker",
+     "bloom": "apply",
+     "prompt": "A web app and a mobile app reach your services through one front door. Put each job on the box that should do it.",
+     "diagram": {
+      "width": 640,
+      "height": 300,
+      "nodes": [
+       {
+        "id": "web",
+        "label": "Web app",
+        "x": 20,
+        "y": 60
+       },
+       {
+        "id": "mob",
+        "label": "Mobile app",
+        "x": 20,
+        "y": 190
+       },
+       {
+        "id": "gw",
+        "label": "API gateway",
+        "x": 250,
+        "y": 125
+       },
+       {
+        "id": "photos",
+        "label": "Photo service",
+        "x": 490,
+        "y": 40
+       },
+       {
+        "id": "search",
+        "label": "Search service",
+        "x": 490,
+        "y": 125
+       },
+       {
+        "id": "accounts",
+        "label": "Account service",
+        "x": 490,
+        "y": 210
+       }
+      ],
+      "edges": [
+       [
+        "web",
+        "gw"
+       ],
+       [
+        "mob",
+        "gw"
+       ],
+       [
+        "gw",
+        "photos"
+       ],
+       [
+        "gw",
+        "search"
+       ],
+       [
+        "gw",
+        "accounts"
+       ]
+      ]
+     },
+     "stickers": [
+      "Check the access token",
+      "Rate-limit each client",
+      "Route by URL path",
+      "Decrypt incoming HTTPS",
+      "Check who may see this photo",
+      "Rank search results"
+     ],
+     "answers": {
+      "gw": [
+       "Check the access token",
+       "Rate-limit each client",
+       "Route by URL path",
+       "Decrypt incoming HTTPS"
+      ],
+      "photos": [
+       "Check who may see this photo"
+      ],
+      "search": [
+       "Rank search results"
+      ]
+     },
+     "explain": "The gateway does the jobs every request needs: decrypting HTTPS (encrypted HTTP), checking who is calling, limiting how often, and routing by path. Rules about one photo, or how to rank results, need a service's own data, so they stay in that service. Say \"a gateway for routing, authentication and rate limits\" in one line, then move on.",
+     "source": "https://www.hellointerview.com/learn/system-design/deep-dives/api-gateway"
+    },
+    {
+     "id": "a-09",
+     "type": "multi",
+     "bloom": "analyse",
+     "prompt": "Which of these really need WebSockets (two-way, always open) rather than server-sent events (SSE, one-way from the server) or polling?",
+     "options": [
+      "Several people editing one document, keystrokes flowing both ways",
+      "A browser game sending each player's moves many times a second",
+      "A sales dashboard that refreshes every 5 minutes",
+      "Showing the progress of a large file export",
+      "Streaming a chatbot's answer word by word",
+      "A shared whiteboard where everyone's pen strokes appear live"
+     ],
+     "correct": [
+      0,
+      1,
+      5
+     ],
+     "explain": "WebSockets earn their cost when clients send often as well as receive: shared editing, games, whiteboards. Each connection is stateful, which makes load balancing and deploys harder. One-way streams suit SSE; slow refreshes suit plain polling. Ask \"does the client send often?\" If not, SSE or polling.",
+     "source": "https://www.hellointerview.com/learn/system-design/core-concepts/networking-essentials"
+    },
+    {
+     "id": "a-boss",
+     "type": "duel",
+     "bloom": "evaluate",
+     "prompt": "A build dashboard shows live progress to 20,000 viewers. Updates come every few seconds, and viewers never send anything back. A colleague proposes WebSockets. What do you choose?",
+     "choices": [
+      "WebSockets, as proposed",
+      "Server-sent events",
+      "Polling every second",
+      "Long polling"
+     ],
+     "correct": 1,
+     "reasons": [
+      "Updates flow one way, and SSE does that over ordinary HTTP, reconnecting by itself",
+      "SSE lets viewers send commands back, like WebSockets",
+      "SSE needs no open connection at all",
+      "Browsers block WebSockets on dashboards"
+     ],
+     "reason": 0,
+     "costs": [
+      "Each viewer keeps a connection open: 20,000 long-lived connections to run",
+      "Updates arrive later than with polling",
+      "Each viewer can only get one update",
+      "Every proxy on the path must support a new protocol"
+     ],
+     "cost": 0,
+     "explain": "WebSockets bring two-way traffic you won't use, and every proxy on the path must allow the upgrade. Polling every second means 20,000 requests a second that mostly say \"nothing new\"; long polling cuts that but reconnects after every update. SSE fits a one-way stream. Say \"One-way, so SSE. I'll watch connection counts and let clients resume from the last update.\"",
+     "source": "https://www.hellointerview.com/learn/system-design/core-concepts/networking-essentials"
+    }
+   ]
+  },
+  {
+   "chapter": 4,
+   "slug": "storage",
+   "title": "Storage and key technologies",
+   "emoji": "🗄️",
+   "pillar": "Key technologies",
+   "blurb": "Start with a relational database, add a store only when a requirement forces it, and say what each one costs.",
+   "boss": "stor-boss",
+   "challenges": [
+    {
+     "id": "stor-01",
+     "type": "write",
+     "bloom": "evaluate",
+     "prompt": "The interviewer asks why you chose PostgreSQL, a relational (SQL, Structured Query Language) database, over a NoSQL (non-relational) store for a photo-sharing app's users, albums and comments. Write your answer in two or three sentences.",
+     "key_points": [
+      "The data relates to itself, so joins, transactions and indexes fit it",
+      "Relational is the sound default; another store comes in when a requirement forces it",
+      "Names the requirement that would change the choice, such as a huge write volume",
+      "No sweeping claims like \"SQL doesn't scale\"",
+      "PostgreSQL goes a long way with indexes, read replicas and caching"
+     ],
+     "model": "Users, albums and comments all relate to each other, so joins, transactions and indexes fit, and PostgreSQL goes a long way with indexes, read replicas and caching. I'd add another store only when a requirement forces it. If comment writes grew past what one database handles, that table is where I'd look at a wide-column store.",
+     "explain": "A clear default plus the condition that would change it shows judgement; a tour of every database shows none. Broad claims like \"NoSQL scales, SQL doesn't\" invite a hard follow-up. Say: \"Relational until a requirement forces otherwise, and here's the one that would.\"",
+     "source": "https://www.hellointerview.com/learn/system-design/core-concepts/data-modeling"
+    },
+    {
+     "id": "stor-02",
+     "type": "multi",
+     "bloom": "understand",
+     "prompt": "An invoices table is slow to answer \"show this customer's invoices\". You add an index on the customer column. Which of these are true?",
+     "options": [
+      "Lookups by customer no longer read the whole table",
+      "Every insert and update now writes to the index as well",
+      "The index takes extra disk space",
+      "Inserts get faster",
+      "Queries that filter only on the amount speed up too",
+      "It's worth indexing every column, just in case"
+     ],
+     "correct": [
+      0,
+      1,
+      2
+     ],
+     "explain": "An index (usually a B-tree, kept sorted) lets the database jump to matching rows instead of reading every row. The price is paid on every write, which must update each index too, plus disk space. Say: \"I'll index the columns my main queries filter on, and no more, because each index slows writes.\"",
+     "source": "https://www.hellointerview.com/learn/system-design/core-concepts/db-indexing"
+    },
+    {
+     "id": "stor-03",
+     "type": "duel",
+     "bloom": "evaluate",
+     "prompt": "Users upload photos of up to 20 megabytes (MB) each. How do the files get stored?",
+     "choices": [
+      "The app server takes the file and saves it in a database column",
+      "The phone uploads straight to object storage with a presigned URL",
+      "The app server takes the file and passes it on to object storage"
+     ],
+     "correct": 1,
+     "reasons": [
+      "Big files skip your servers; the database keeps only small metadata rows",
+      "Object storage can be queried like a database",
+      "Presigned URLs never expire, so retries are simple"
+     ],
+     "reason": 0,
+     "costs": [
+      "Two steps to track: the upload and its metadata row can drift apart",
+      "Every photo becomes public",
+      "None at all"
+     ],
+     "cost": 0,
+     "explain": "A presigned URL is a short-lived signed web link that lets the client put one file straight into object storage, such as Amazon S3 (Simple Storage Service), with no credentials of its own. The bytes never load your servers. Keep the metadata in the database, marked pending until the upload completes. Say: \"Presigned upload to S3, metadata in Postgres.\"",
+     "source": "https://docs.aws.amazon.com/AmazonS3/latest/userguide/PresignedUrlUploadObject.html"
+    },
+    {
+     "id": "stor-04",
+     "type": "estimate",
+     "bloom": "apply",
+     "prompt": "A photo-sharing app. Uploads a day and the average photo size are below. Roughly how much object storage does a year of photos need?",
+     "generator": {
+      "kind": "storage_year",
+      "params": {
+       "items": [
+        500000,
+        20000000
+       ],
+       "kb": [
+        200,
+        4000
+       ]
+      }
+     },
+     "explain": "Uploads a day, times the size, times 365, then round. Two million photos at 2 MB is 4 terabytes (TB) a day, about 1.5 petabytes a year. That is object storage's job, never the database's. Say the sum out loud and round hard; the order of magnitude is what counts.",
+     "source": "https://www.hellointerview.com/learn/system-design/in-a-hurry/key-technologies"
+    },
+    {
+     "id": "stor-05",
+     "type": "duel",
+     "bloom": "apply",
+     "prompt": "Comments on photos live in DynamoDB, and each photo and comment has an ID (identifier). The main read is \"all comments on one photo, newest first\". Which primary key?",
+     "choices": [
+      "Partition key: photo ID. Sort key: time plus comment ID",
+      "Partition key: the date the comment was posted",
+      "Partition key: comment ID, then scan for the photo"
+     ],
+     "correct": 0,
+     "reasons": [
+      "One query reads one partition, already in order",
+      "Dates spread writes evenly across partitions",
+      "Scans are cheap in DynamoDB"
+     ],
+     "reason": 0,
+     "costs": [
+      "A viral photo's comments all land on one partition",
+      "Comments can't be sorted",
+      "Every read becomes a full-table scan"
+     ],
+     "cost": 0,
+     "explain": "DynamoDB hashes the partition key to decide where an item lives; the sort key orders items inside it. Design keys around your main query, because ad-hoc questions need a planned index or a costly scan. A date key sends every new write to today's partition. Say: \"Partition by photo, sort by time, and a secondary index if we need comments by user.\"",
+     "source": "https://www.hellointerview.com/learn/system-design/deep-dives/dynamodb"
+    },
+    {
+     "id": "stor-06",
+     "type": "duel",
+     "bloom": "apply",
+     "prompt": "A photo app shows \"top 100 photos today\" by likes, updated live, plus each photo's rank. Counting with SQL on every page view is too slow. What do you reach for?",
+     "choices": [
+      "A Redis sorted set for the day: each photo's score is its like count",
+      "Cache the SQL result in app memory for an hour",
+      "Elasticsearch, sorted by likes"
+     ],
+     "correct": 0,
+     "reasons": [
+      "Members stay sorted by score; updates and rank reads take log time",
+      "Redis is a durable system of record",
+      "Sorted sets take no memory"
+     ],
+     "reason": 0,
+     "costs": [
+      "It lives in memory: rebuild it from the database after a failure",
+      "Ranks are only right once an hour",
+      "Each like needs a full re-sort"
+     ],
+     "cost": 0,
+     "explain": "A sorted set keeps members ordered by score, so updating a score and reading the top 100 or one photo's rank are both fast. Give each day's set an expiry (TTL, time to live) so old days clean themselves up. Redis can lose recent writes in a crash, so likes still go to the database. Say: \"Sorted set for the board, database for the truth.\"",
+     "source": "https://www.hellointerview.com/learn/system-design/deep-dives/redis"
+    },
+    {
+     "id": "stor-07",
+     "type": "flaw",
+     "bloom": "analyse",
+     "prompt": "A document search product. Find the weak box, then pick the fix.",
+     "diagram": {
+      "width": 640,
+      "height": 300,
+      "nodes": [
+       {
+        "id": "client",
+        "label": "Web app",
+        "x": 20,
+        "y": 126
+       },
+       {
+        "id": "api",
+        "label": "App servers",
+        "x": 180,
+        "y": 126
+       },
+       {
+        "id": "cache",
+        "label": "Redis cache",
+        "x": 180,
+        "y": 20
+       },
+       {
+        "id": "pg",
+        "label": "PostgreSQL: users, teams",
+        "x": 380,
+        "y": 20
+       },
+       {
+        "id": "es",
+        "label": "Elasticsearch: all documents",
+        "x": 380,
+        "y": 126
+       },
+       {
+        "id": "s3",
+        "label": "Object storage: attachments",
+        "x": 380,
+        "y": 232
+       }
+      ],
+      "edges": [
+       [
+        "client",
+        "api"
+       ],
+       [
+        "api",
+        "cache"
+       ],
+       [
+        "api",
+        "pg"
+       ],
+       [
+        "api",
+        "es",
+        "writes and searches"
+       ],
+       [
+        "api",
+        "s3"
+       ]
+      ]
+     },
+     "flaw": "es",
+     "fixes": [
+      "Keep documents in PostgreSQL and feed Elasticsearch from it with change data capture",
+      "Add more Elasticsearch nodes",
+      "Put a Redis cache in front of Elasticsearch",
+      "Drop Elasticsearch and search with SQL LIKE queries on PostgreSQL"
+     ],
+     "fix": 0,
+     "explain": "Elasticsearch is a search engine built on an inverted index (each word points to the documents that contain it); it shouldn't hold the only copy. Store documents in PostgreSQL and stream changes into the index with change data capture (CDC). Search then lags a little behind, so say: \"Search is a read copy, a moment behind the database.\"",
+     "source": "https://www.hellointerview.com/learn/system-design/deep-dives/elasticsearch"
+    },
+    {
+     "id": "stor-08",
+     "type": "duel",
+     "bloom": "evaluate",
+     "prompt": "Every click on a product catalogue must feed three teams' jobs: search ranking, reporting and recommendations. A buggy job must be able to re-read last week's clicks. What carries the clicks?",
+     "choices": [
+      "A Kafka topic, with one consumer group per team",
+      "A Redis list that each job pops clicks from",
+      "A database table that each job polls every second"
+     ],
+     "correct": 0,
+     "reasons": [
+      "Kafka keeps records for a set time; each group tracks its own offset and can rewind",
+      "Kafka keeps one global order across the whole topic",
+      "Kafka deletes a record once any job reads it"
+     ],
+     "reason": 0,
+     "costs": [
+      "Order is kept only within a partition, so pick the key with care",
+      "Only one team can read each click",
+      "Clicks vanish once read"
+     ],
+     "cost": 0,
+     "explain": "Kafka is a durable log split into partitions. Each consumer group reads every record at its own position (offset), so teams don't slow each other and a fixed job can replay. Order is kept within a partition only: key by product if per-product order matters. Say: \"Kafka, a group per team, a week's retention.\"",
+     "source": "https://www.hellointerview.com/learn/system-design/deep-dives/kafka"
+    },
+    {
+     "id": "stor-09",
+     "type": "lightning",
+     "bloom": "remember",
+     "prompt": "When you hear this, reach for what? 90 seconds.",
+     "pairs": [
+      [
+       "Photos, videos and other big files",
+       "Object storage (S3), metadata in the database"
+      ],
+      [
+       "Search for words inside text",
+       "Elasticsearch (an inverted index)"
+      ],
+      [
+       "A live top 100 by score",
+       "Redis sorted set"
+      ],
+      [
+       "Joins, transactions and a clear schema",
+       "PostgreSQL"
+      ],
+      [
+       "A huge, steady, append-heavy write volume",
+       "Cassandra (wide-column)"
+      ],
+      [
+       "Several teams replaying one stream of records",
+       "Kafka"
+      ],
+      [
+       "Simple lookups by key at enormous scale",
+       "DynamoDB"
+      ],
+      [
+       "The same data read again and again, fast",
+       "Redis cache with a TTL"
+      ]
+     ],
+     "explain": "Each store earns its place with one requirement. Name the requirement as you add the box, and its cost straight after: search lags, memory can be lost in a crash, scans are slow. Say: \"I'm adding X because of Y; it costs Z.\"",
+     "source": "https://www.hellointerview.com/learn/system-design/in-a-hurry/key-technologies"
+    },
+    {
+     "id": "stor-boss",
+     "type": "fill",
+     "bloom": "evaluate",
+     "prompt": "A photo-sharing app. Drag the right store onto each need on the arrows: photo files, users and albums, caption search, today's top photos, view records as they happen, and a year of views written all day long.",
+     "diagram": {
+      "width": 640,
+      "height": 300,
+      "nodes": [
+       {
+        "id": "client",
+        "label": "Phone app",
+        "x": 20,
+        "y": 126
+       },
+       {
+        "id": "api",
+        "label": "App servers",
+        "x": 180,
+        "y": 126
+       },
+       {
+        "id": "files",
+        "label": "?",
+        "x": 340,
+        "y": 20
+       },
+       {
+        "id": "main",
+        "label": "?",
+        "x": 340,
+        "y": 126
+       },
+       {
+        "id": "stream",
+        "label": "?",
+        "x": 340,
+        "y": 232
+       },
+       {
+        "id": "top",
+        "label": "?",
+        "x": 500,
+        "y": 20
+       },
+       {
+        "id": "search",
+        "label": "?",
+        "x": 500,
+        "y": 126
+       },
+       {
+        "id": "wide",
+        "label": "?",
+        "x": 500,
+        "y": 232
+       }
+      ],
+      "edges": [
+       [
+        "client",
+        "api"
+       ],
+       [
+        "client",
+        "files",
+        "photo files"
+       ],
+       [
+        "api",
+        "main",
+        "users, albums, likes"
+       ],
+       [
+        "api",
+        "top",
+        "today's top photos"
+       ],
+       [
+        "main",
+        "search",
+        "caption search copy"
+       ],
+       [
+        "api",
+        "stream",
+        "view records"
+       ],
+       [
+        "stream",
+        "wide",
+        "a year of views, write-heavy"
+       ]
+      ]
+     },
+     "slots": {
+      "files": "Object storage (S3)",
+      "main": "PostgreSQL",
+      "top": "Redis sorted set",
+      "search": "Elasticsearch",
+      "stream": "Kafka",
+      "wide": "Cassandra"
+     },
+     "palette": [
+      "Object storage (S3)",
+      "PostgreSQL",
+      "Redis sorted set",
+      "Elasticsearch",
+      "Kafka",
+      "Cassandra",
+      "Photos in a PostgreSQL column",
+      "Redis as the main database",
+      "Graph database"
+     ],
+     "explain": "Files go to object storage; related rows to PostgreSQL; word search to Elasticsearch fed from Postgres; a live top list to a Redis sorted set; a replayable stream to Kafka; heavy append-only writes to Cassandra. Photos in a database column bloat it; Redis as the truth can lose data. Say each box's reason as you place it.",
+     "source": "https://www.hellointerview.com/learn/system-design/in-a-hurry/key-technologies"
+    }
+   ]
+  },
+  {
+   "chapter": 5,
+   "slug": "caching-scaling",
+   "title": "Caching and scaling",
+   "emoji": "⚡",
+   "pillar": "Core concepts",
+   "blurb": "Pick a caching pattern, keep it fresh, survive hot keys and stampedes, then scale out with replicas, shards and consistent hashing.",
+   "boss": "scal-boss",
+   "challenges": [
+    {
+     "id": "scal-01",
+     "type": "sticker",
+     "bloom": "understand",
+     "prompt": "Three ways to put a cache in front of a database. Stick each trait on the pattern it belongs to.",
+     "diagram": {
+      "width": 640,
+      "height": 200,
+      "nodes": [
+       {
+        "id": "aside",
+        "label": "Cache-aside",
+        "x": 40,
+        "y": 76
+       },
+       {
+        "id": "through",
+        "label": "Write-through",
+        "x": 260,
+        "y": 76
+       },
+       {
+        "id": "back",
+        "label": "Write-back",
+        "x": 480,
+        "y": 76
+       }
+      ]
+     },
+     "stickers": [
+      "App fills the cache on a miss",
+      "Only data that's read gets cached",
+      "Each write waits for cache and database",
+      "Fastest writes",
+      "A cache crash can lose writes"
+     ],
+     "answers": {
+      "aside": [
+       "App fills the cache on a miss",
+       "Only data that's read gets cached"
+      ],
+      "through": [
+       "Each write waits for cache and database"
+      ],
+      "back": [
+       "Fastest writes",
+       "A cache crash can lose writes"
+      ]
+     },
+     "explain": "Cache-aside is the usual default: the app reads the cache, and on a miss loads from the database and fills it. Write-through keeps the cache current but makes each write wait for both. Write-back (also called write-behind) answers from the cache and flushes later: fast, but a crash loses whatever hadn't flushed. Name the pattern and why in one sentence.",
+     "source": "https://github.com/donnemartin/system-design-primer"
+    },
+    {
+     "id": "scal-02",
+     "type": "duel",
+     "bloom": "evaluate",
+     "prompt": "Product pages are cached with cache-aside and read thousands of times a minute; a page changes a few times a day. When someone edits a page, what does the write path do?",
+     "choices": [
+      "Update the database, then delete the cached copy",
+      "Update the database and wait for the cached copy to expire",
+      "Update the cache now and the database later"
+     ],
+     "correct": 0,
+     "reasons": [
+      "The next read reloads from the database, so no second copy needs updating",
+      "A cache can never serve stale data",
+      "Writing the cache first makes the database optional"
+     ],
+     "reason": 0,
+     "costs": [
+      "One extra miss per edit, and a brief window where a reader may see the old page",
+      "Readers see the old page for up to an hour",
+      "Edits can be lost if the cache crashes"
+     ],
+     "cost": 0,
+     "explain": "Deleting on write keeps one source of truth, and the next read refills the cache. Keep an expiry (TTL, time to live) on every key anyway, so a missed delete corrects itself. Waiting for expiry shows stale pages for the whole TTL; writing the cache first risks lost edits. Say: \"Write the database, delete the key, TTL as a safety net.\"",
+     "source": "https://aws.amazon.com/caching/best-practices/"
+    },
+    {
+     "id": "scal-03",
+     "type": "multi",
+     "bloom": "analyse",
+     "prompt": "The home page's cached data is read 50,000 times a second. Each time its key expires, thousands of requests miss at once and the database falls over. Which fixes help?",
+     "options": [
+      "Let one request rebuild the value while the rest wait for its result",
+      "Refresh the value in the background just before it expires",
+      "Shorten the expiry so the value is always fresh",
+      "Add app servers to absorb the extra misses",
+      "Turn the cache off while the value rebuilds"
+     ],
+     "correct": [
+      0,
+      1
+     ],
+     "explain": "This is a cache stampede: one popular key expires and every request rebuilds it at once. Coalescing lets one request rebuild while the rest share its answer; refreshing early means the key never expires under load. A shorter expiry brings stampedes more often, and more app servers don't shield the database. Say: \"Coalesce the rebuild, and refresh the hottest keys early.\"",
+     "source": "https://www.hellointerview.com/learn/system-design/core-concepts/caching"
+    },
+    {
+     "id": "scal-04",
+     "type": "recall",
+     "bloom": "analyse",
+     "prompt": "A deploy cached 50,000 product pages in the same minute, all with a one-hour TTL. Now database load spikes at that same minute every hour. Why, and what's the fix?",
+     "answer": "They all expire together, so the misses arrive in one burst. Add a random offset to each TTL (an hour plus up to a couple of minutes) so expiries spread out.",
+     "explain": "Identical expiry times line the misses up into one spike. Random jitter on each TTL spreads them into a trickle, at almost no cost. Say: \"TTL plus a little jitter, so popular keys don't all expire at once.\"",
+     "source": "https://aws.amazon.com/caching/best-practices/"
+    },
+    {
+     "id": "scal-05",
+     "type": "duel",
+     "bloom": "evaluate",
+     "prompt": "One viral video's details are read 300,000 times a second. The Redis node that owns that key is maxed out while the other nodes sit idle. Best move?",
+     "choices": [
+      "Keep several copies under suffixed keys and read a random one",
+      "Add more nodes to the Redis cluster",
+      "Give the key a shorter expiry"
+     ],
+     "correct": 0,
+     "reasons": [
+      "One key always lands on one node, so new nodes never share its load",
+      "Short expiries spread a key across nodes",
+      "Redis gets faster as keys get shorter"
+     ],
+     "reason": 0,
+     "costs": [
+      "An update must reach every copy, or readers briefly disagree",
+      "Reads get slower for every other key",
+      "None"
+     ],
+     "cost": 0,
+     "explain": "A hot key overloads the one node that owns it, however big the cluster. Copies under keys like video42-1 to video42-8 spread reads over several nodes, and a small in-process cache on each app server helps too. The cost is updating every copy. Say: \"Hot key, so I'll copy it and spread the reads.\"",
+     "source": "https://www.hellointerview.com/learn/system-design/deep-dives/redis"
+    },
+    {
+     "id": "scal-06",
+     "type": "lightning",
+     "bloom": "remember",
+     "prompt": "When you hear this, reach for what? 90 seconds.",
+     "pairs": [
+      [
+       "Images and scripts for users all over the world",
+       "A CDN (content delivery network)"
+      ],
+      [
+       "Users are logged out when one server restarts",
+       "Stateless servers, sessions in a shared store"
+      ],
+      [
+       "The biggest machine size is already bought",
+       "Scale out: add more machines"
+      ],
+      [
+       "Reads outgrow one database; writes are fine",
+       "Read replicas"
+      ],
+      [
+       "Writes or data outgrow one database",
+       "Shard the data"
+      ],
+      [
+       "Adding a cache node reshuffles almost every key",
+       "Consistent hashing"
+      ],
+      [
+       "Writes must be very fast; losing a few is acceptable",
+       "Write-back (write-behind) cache"
+      ],
+      [
+       "The same data is read again and again",
+       "Cache-aside in front of the database"
+      ]
+     ],
+     "explain": "Each symptom has a standard first move. Scaling up (a bigger machine) is simplest but hits a ceiling and stays one point of failure; scaling out needs stateless servers so any of them can take any request. Say the symptom, then the move: \"Reads are the bottleneck, so replicas.\"",
+     "source": "https://github.com/donnemartin/system-design-primer"
+    },
+    {
+     "id": "scal-07",
+     "type": "write",
+     "bloom": "analyse",
+     "prompt": "You added read replicas. Now a user edits their profile, refreshes, and sees the old version for a second or two. Explain what's going on and how you'd fix it.",
+     "key_points": [
+      "Replicas copy from the primary asynchronously, so they run a little behind",
+      "The refresh read hit a replica that hadn't caught up yet",
+      "Read-your-own-writes: send that user's reads to the primary for a short while after a write",
+      "Other users keep reading replicas; slight staleness is fine for them",
+      "The cost: some read load returns to the primary"
+     ],
+     "model": "Replication is asynchronous, so a replica can be a second behind, and the refresh landed on one that hadn't caught up. I'd give the author read-your-own-writes: for a few seconds after an edit, their own reads go to the primary. Everyone else keeps reading replicas, where a second of staleness is fine. The cost is a little extra load on the primary.",
+     "explain": "Replication lag is normal; the person who just wrote is the one who notices it. Sending only their reads to the primary fixes what they see without giving up the replicas, and adding replicas doesn't remove the lag. Say: \"Read-your-own-writes for the author, replicas for everyone else.\"",
+     "source": "https://www.hellointerview.com/learn/system-design/core-concepts/cap-theorem"
+    },
+    {
+     "id": "scal-08",
+     "type": "duel",
+     "bloom": "apply",
+     "prompt": "An invoicing product's invoices table has outgrown one database. Most queries ask for \"this customer's invoices\". What's the shard key?",
+     "choices": [
+      "The customer's identifier",
+      "The date the invoice was created",
+      "Paid or unpaid"
+     ],
+     "correct": 0,
+     "reasons": [
+      "Many distinct values spread load evenly, and the main query hits one shard",
+      "Recent invoices sit together, which speeds up every write",
+      "Few distinct values keep routing simple"
+     ],
+     "reason": 0,
+     "costs": [
+      "One huge customer can make its shard hot",
+      "All new writes land on the newest shard",
+      "Every query must visit every shard"
+     ],
+     "cost": 0,
+     "explain": "A good shard key has many values, spreads load evenly and fits the main query. A date sends every new write to one shard; a yes-or-no field gives two shards at most. The customer key's risk is a hot partition from one giant customer: give it its own shard. Reports across all customers now hit every shard, so precompute them. Say the key and its risk together.",
+     "source": "https://www.hellointerview.com/learn/system-design/core-concepts/sharding"
+    },
+    {
+     "id": "scal-09",
+     "type": "multi",
+     "bloom": "analyse",
+     "prompt": "Ten cache servers place keys with hash(key) mod 10. You add an eleventh and switch to mod 11. Which of these are true?",
+     "options": [
+      "About 90% of keys now belong to a different server",
+      "The cache hit rate drops sharply until it refills",
+      "With consistent hashing, only about 1 key in 11 would move",
+      "With mod N, only the keys bound for the new server move",
+      "Consistent hashing moves no keys at all"
+     ],
+     "correct": [
+      0,
+      1,
+      2
+     ],
+     "explain": "With mod N, changing N changes almost every key's remainder: about 10 keys in 11 move, and the cache goes nearly cold. On a consistent-hashing ring, a new server takes only the keys between it and its neighbour, about 1 in 11. Say: \"Consistent hashing, so adding a node moves about a tenth of the keys, not nine tenths.\"",
+     "source": "https://en.wikipedia.org/wiki/Consistent_hashing"
+    },
+    {
+     "id": "scal-boss",
+     "type": "flaw",
+     "bloom": "evaluate",
+     "prompt": "Fix this at ten times the load. A link shortener: reads come from the cache and replicas, and the primary database already runs at 70% busy on today's writes alone. Find the box that breaks first, then pick the fix.",
+     "diagram": {
+      "width": 640,
+      "height": 300,
+      "nodes": [
+       {
+        "id": "users",
+        "label": "Users",
+        "x": 20,
+        "y": 126
+       },
+       {
+        "id": "cdn",
+        "label": "CDN: site assets",
+        "x": 170,
+        "y": 20
+       },
+       {
+        "id": "lb",
+        "label": "Load balancer",
+        "x": 170,
+        "y": 126
+       },
+       {
+        "id": "cache",
+        "label": "Redis cluster",
+        "x": 320,
+        "y": 20
+       },
+       {
+        "id": "app",
+        "label": "Stateless app servers",
+        "x": 320,
+        "y": 126
+       },
+       {
+        "id": "primary",
+        "label": "Primary: all writes",
+        "x": 480,
+        "y": 126
+       },
+       {
+        "id": "replicas",
+        "label": "Read replicas x3",
+        "x": 480,
+        "y": 232
+       }
+      ],
+      "edges": [
+       [
+        "users",
+        "cdn",
+        "assets"
+       ],
+       [
+        "users",
+        "lb"
+       ],
+       [
+        "lb",
+        "app"
+       ],
+       [
+        "app",
+        "cache",
+        "link lookups"
+       ],
+       [
+        "app",
+        "primary",
+        "new links"
+       ],
+       [
+        "primary",
+        "replicas",
+        "copies"
+       ],
+       [
+        "app",
+        "replicas",
+        "cache misses"
+       ]
+      ]
+     },
+     "flaw": "primary",
+     "fixes": [
+      "Shard by short code with consistent hashing; each shard keeps its own replicas",
+      "Add more read replicas",
+      "Add more stateless app servers",
+      "Grow the Redis cluster",
+      "Move the primary to a machine twice the size"
+     ],
+     "fix": 0,
+     "explain": "Reads already scale out through the CDN, cache and replicas, but every write still goes through one primary, and ten times 70% is seven machines' worth. Replicas add read capacity, not write capacity; a machine twice the size covers two. Shard by short code, which every lookup carries, with consistent hashing so later shards move few keys. Say: \"Writes are the wall, so shard.\"",
+     "source": "https://www.hellointerview.com/learn/system-design/core-concepts/sharding"
+    }
+   ]
+  },
+  {
+   "chapter": 6,
+   "slug": "consistency",
+   "title": "Consistency and CAP",
+   "emoji": "⚖️",
+   "pillar": "Core concepts",
+   "blurb": "Know what CAP really forces, then choose strong or eventual consistency feature by feature, never for the whole system.",
+   "boss": "cons-boss",
+   "challenges": [
+    {
+     "id": "cons-01",
+     "type": "recall",
+     "bloom": "remember",
+     "prompt": "In one breath: what does the CAP theorem (consistency, availability, partition tolerance) actually force you to choose?",
+     "answer": "When the network splits between nodes, a distributed system must either refuse some requests to stay consistent or keep answering and risk stale data. Splits will happen, so partition tolerance isn't optional.",
+     "explain": "\"Pick two of three\" misleads, because no network is immune to splits. The real choice bites only during a split: stay correct or stay up. Say: \"Partitions happen, so for this feature I'd favour consistency (or availability), because…\"",
+     "source": "https://en.wikipedia.org/wiki/CAP_theorem"
+    },
+    {
+     "id": "cons-02",
+     "type": "multi",
+     "bloom": "understand",
+     "prompt": "Which of these are true? (ACID is the atomicity, consistency, isolation and durability that database transactions promise.)",
+     "options": [
+      "Network splits will happen, so the real choice is consistency or availability during one",
+      "A system can pick consistency and availability and skip partition tolerance",
+      "CAP's C means every read sees the latest write, or gets an error",
+      "CAP's C is the same promise as the C in ACID",
+      "ACID's C means a transaction leaves the data obeying its rules, such as constraints",
+      "Choosing availability means reads are never stale"
+     ],
+     "correct": [
+      0,
+      2,
+      4
+     ],
+     "explain": "Same letter, different promise. CAP's C is about copies agreeing, so a read reflects the latest write. ACID's C is about one database's rules still holding after a transaction. Choosing availability means accepting stale reads during a split. Say which C you mean when you use the word.",
+     "source": "https://en.wikipedia.org/wiki/CAP_theorem"
+    },
+    {
+     "id": "cons-03",
+     "type": "recall",
+     "bloom": "understand",
+     "prompt": "CAP only talks about network splits. What does PACELC (if Partition, Availability or Consistency; Else, Latency or Consistency) add, and why does it matter on a normal day?",
+     "answer": "The \"else\": with no split at all, you still trade latency against consistency. Waiting for replicas to confirm a write, or to agree on a read, makes every request slower.",
+     "explain": "Splits are rare, but the latency cost of strong consistency is paid on every request. That's why many databases default to eventually consistent reads. Say: \"Even without a partition, strong reads cost latency, so I'd only pay that where a stale read hurts.\"",
+     "source": "https://en.wikipedia.org/wiki/PACELC_design_principle"
+    },
+    {
+     "id": "cons-04",
+     "type": "duel",
+     "bloom": "evaluate",
+     "prompt": "A team workspace product has prepaid credit balances, invoices, an activity feed and like counts. The interviewer asks: \"Is your system CP or AP?\" (consistent or available when the network splits). Best answer?",
+     "choices": [
+      "\"CP: correctness matters most.\"",
+      "\"AP: uptime matters most.\"",
+      "\"Neither as a whole: strong for balances and invoices, eventual for feed and likes.\""
+     ],
+     "correct": 2,
+     "reasons": [
+      "A stale read costs a different amount in each feature, so each gets its own choice",
+      "Mixed models are always cheaper to run",
+      "Interviewers mark down any system that is fully CP"
+     ],
+     "reason": 0,
+     "costs": [
+      "Two consistency models to explain, test and operate",
+      "Every read in the system gets slower",
+      "The feed can no longer be cached"
+     ],
+     "cost": 0,
+     "explain": "One label for the whole system forces the wrong trade on half the features: a stale balance costs money, a stale like count costs nothing. Ask per feature \"what breaks if this read is a few seconds old?\" Say: \"Strong where money or totals live, eventual everywhere else.\"",
+     "source": "https://www.hellointerview.com/learn/system-design/in-a-hurry/core-concepts"
+    },
+    {
+     "id": "cons-05",
+     "type": "fill",
+     "bloom": "apply",
+     "prompt": "Fill the boxes. A confirmed write must survive losing the leader, and balance reads must see the latest write. Feed reads can lag a few seconds.",
+     "diagram": {
+      "width": 640,
+      "height": 300,
+      "nodes": [
+       {
+        "id": "app",
+        "label": "App server",
+        "x": 20,
+        "y": 126
+       },
+       {
+        "id": "s-leader",
+        "label": "?",
+        "x": 250,
+        "y": 40
+       },
+       {
+        "id": "s-sync",
+        "label": "?",
+        "x": 490,
+        "y": 40
+       },
+       {
+        "id": "s-async",
+        "label": "?",
+        "x": 250,
+        "y": 222
+       }
+      ],
+      "edges": [
+       [
+        "app",
+        "s-leader",
+        "writes, balance reads"
+       ],
+       [
+        "s-leader",
+        "s-sync",
+        "waits for its confirmation"
+       ],
+       [
+        "s-leader",
+        "s-async",
+        "copies later"
+       ],
+       [
+        "app",
+        "s-async",
+        "feed reads"
+       ]
+      ]
+     },
+     "slots": {
+      "s-leader": "Leader database",
+      "s-sync": "Synchronous replica",
+      "s-async": "Asynchronous replica"
+     },
+     "palette": [
+      "Leader database",
+      "Synchronous replica",
+      "Asynchronous replica",
+      "Cache",
+      "Message queue",
+      "Load balancer"
+     ],
+     "explain": "A synchronous replica holds every confirmed write, so promoting it loses nothing, but each write waits for it. An asynchronous one keeps writes fast and serves reads that may lag, which suits the feed. Say: \"One synchronous replica for safety, asynchronous ones for read scale.\"",
+     "source": "https://github.com/donnemartin/system-design-primer"
+    },
+    {
+     "id": "cons-06",
+     "type": "multi",
+     "bloom": "analyse",
+     "prompt": "Five replicas (N = 5). A write counts once W replicas confirm it; a read asks R replicas. Which settings guarantee every read overlaps the latest confirmed write?",
+     "options": [
+      "W = 3, R = 3",
+      "W = 2, R = 2",
+      "W = 5, R = 1",
+      "W = 1, R = 1",
+      "W = 4, R = 2",
+      "W = 2, R = 3"
+     ],
+     "correct": [
+      0,
+      2,
+      4
+     ],
+     "explain": "Reads and writes overlap when R + W > N: at least one replica in every read saw the latest write. 2 + 3 = 5 is not enough. W = 5 makes reads cheap, but a write fails if any replica is down. Say: \"A quorum: R plus W greater than N, so every read overlaps the last write.\"",
+     "source": "https://en.wikipedia.org/wiki/Quorum_(distributed_computing)"
+    },
+    {
+     "id": "cons-07",
+     "type": "multi",
+     "bloom": "analyse",
+     "prompt": "A user renames their workspace, reloads, and sees the old name. Reads go to replicas that are updated asynchronously. Which two fixes give that user read-your-writes without making every read strong?",
+     "options": [
+      "For a short time after a user writes, send that user's reads to the leader",
+      "Ask for a strongly consistent read only on the page the user just edited",
+      "Send every read in the system to the leader",
+      "Put a cache in front of the replicas",
+      "Add more replicas",
+      "Make the rename asynchronous too"
+     ],
+     "correct": [
+      0,
+      1
+     ],
+     "explain": "Read-your-writes only promises that writers see their own change; everyone else can lag. So aim the fix at that user and that page. Some databases let you choose per read: DynamoDB reads are eventually consistent by default, strongly consistent on request at twice the cost. Say: \"Read-your-writes for the editor, eventual for everyone else.\"",
+     "source": "https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.ReadConsistency.html"
+    },
+    {
+     "id": "cons-08",
+     "type": "write",
+     "bloom": "apply",
+     "prompt": "The interviewer asks: \"You replicate asynchronously. What happens if the leader dies?\" Answer in three or four sentences.",
+     "key_points": [
+      "Writes confirmed to the client but not yet copied can be lost",
+      "A replica is promoted to leader, and it may be slightly behind",
+      "Says which features can live with that, such as the feed or counters",
+      "For money, a synchronous replica, accepting slower writes"
+     ],
+     "model": "A replica gets promoted. Anything the old leader confirmed but hadn't copied yet is lost, so the new leader may be a few writes behind. For the feed and counters that's fine. For balances and invoices I'd keep one synchronous replica, so a confirmed write always exists twice, and accept the slower write.",
+     "explain": "Asynchronous replication buys fast writes by confirming before the copy exists, so a failover can drop the newest writes. Naming the loss and where it's acceptable shows you know the trade. Say the risk, the feature that tolerates it, and the fix for the one that doesn't.",
+     "source": "https://github.com/donnemartin/system-design-primer"
+    },
+    {
+     "id": "cons-09",
+     "type": "lightning",
+     "bloom": "understand",
+     "prompt": "When you hear this, reach for what? 90 seconds.",
+     "pairs": [
+      [
+       "The network splits and the data must stay correct",
+       "Favour consistency: refuse or wait"
+      ],
+      [
+       "The network splits and the page must stay up",
+       "Favour availability: serve possibly stale data"
+      ],
+      [
+       "No split, but every millisecond counts",
+       "PACELC: trade some consistency for latency"
+      ],
+      [
+       "A user must see their own edit on reload",
+       "Read-your-writes"
+      ],
+      [
+       "A confirmed write must survive losing the leader",
+       "Synchronous replication"
+      ],
+      [
+       "Writes must be fast and a little lag is fine",
+       "Asynchronous replication"
+      ],
+      [
+       "Reads must overlap the latest write across replicas",
+       "A quorum: R + W > N"
+      ],
+      [
+       "Like counts, view counters, a feed",
+       "Eventual consistency"
+      ],
+      [
+       "An account balance or an invoice total",
+       "Strong consistency"
+      ]
+     ],
+     "explain": "Each pairing is a trade you should name without stopping to think, which leaves your time for the follow-up question. If one was slow, say that pairing out loud, with what it costs, before the next round.",
+     "source": "https://www.hellointerview.com/learn/system-design/core-concepts/cap-theorem"
+    },
+    {
+     "id": "cons-boss",
+     "type": "sticker",
+     "bloom": "evaluate",
+     "prompt": "A team workspace product. Sticker each feature with what it needs; a box can take more than one sticker. Ask of each one: what breaks if this read is a few seconds old?",
+     "diagram": {
+      "width": 640,
+      "height": 300,
+      "nodes": [
+       {
+        "id": "app",
+        "label": "Workspace app",
+        "x": 260,
+        "y": 126
+       },
+       {
+        "id": "balance",
+        "label": "Credit balance",
+        "x": 20,
+        "y": 20
+       },
+       {
+        "id": "invoice",
+        "label": "Invoice total",
+        "x": 20,
+        "y": 126
+       },
+       {
+        "id": "likes",
+        "label": "Like count",
+        "x": 20,
+        "y": 232
+       },
+       {
+        "id": "views",
+        "label": "Doc view counter",
+        "x": 500,
+        "y": 20
+       },
+       {
+        "id": "feed",
+        "label": "Activity feed",
+        "x": 500,
+        "y": 126
+       },
+       {
+        "id": "profile",
+        "label": "Edit own profile",
+        "x": 500,
+        "y": 232
+       },
+       {
+        "id": "search",
+        "label": "Search results",
+        "x": 260,
+        "y": 232
+       }
+      ],
+      "edges": [
+       [
+        "app",
+        "balance"
+       ],
+       [
+        "app",
+        "invoice"
+       ],
+       [
+        "app",
+        "likes"
+       ],
+       [
+        "app",
+        "views"
+       ],
+       [
+        "app",
+        "feed"
+       ],
+       [
+        "app",
+        "profile"
+       ],
+       [
+        "app",
+        "search"
+       ]
+      ]
+     },
+     "stickers": [
+      "Strong consistency",
+      "Eventual is fine",
+      "Read-your-writes"
+     ],
+     "answers": {
+      "balance": [
+       "Strong consistency"
+      ],
+      "invoice": [
+       "Strong consistency"
+      ],
+      "likes": [
+       "Eventual is fine"
+      ],
+      "views": [
+       "Eventual is fine"
+      ],
+      "feed": [
+       "Eventual is fine"
+      ],
+      "profile": [
+       "Read-your-writes",
+       "Eventual is fine"
+      ],
+      "search": [
+       "Eventual is fine"
+      ]
+     },
+     "explain": "Money and totals need strong consistency: a stale balance can show credit that's already gone, and an invoice total must match its lines. Counters, feeds and search can lag seconds harmlessly, so they stay fast and available. The profile needs read-your-writes for its editor only. Say: \"Strong where a stale read costs money; eventual everywhere else.\"",
+     "source": "https://www.hellointerview.com/learn/system-design/core-concepts/cap-theorem"
+    }
+   ]
+  },
+  {
+   "chapter": 7,
+   "slug": "async-failure",
+   "title": "Async and failure",
+   "emoji": "📮",
+   "pillar": "Core concepts",
+   "blurb": "Move slow work off the request path, and design for the retries, duplicates and slow partners that will happen.",
+   "boss": "async-boss",
+   "challenges": [
+    {
+     "id": "async-01",
+     "type": "multi",
+     "bloom": "understand",
+     "prompt": "A user clicks \"Export my data\". Which are good reasons to put the export on a queue and return a job identifier (ID) straight away?",
+     "options": [
+      "Traffic spikes wait in the queue instead of overwhelming the servers",
+      "The export takes minutes, far longer than a request should be held open",
+      "A failed export can be retried without the user waiting on it",
+      "It makes the export itself finish sooner",
+      "It guarantees each export runs exactly once",
+      "Web servers and workers can be scaled separately"
+     ],
+     "correct": [
+      0,
+      1,
+      2,
+      5
+     ],
+     "explain": "A queue splits \"accepted\" from \"done\": the request returns at once, workers drain the backlog at their own pace, and failures retry out of sight. It adds delay and possible duplicates; it doesn't remove them. Say: \"Accept, return a job ID, process in the background.\" For cheap, instant work, stay synchronous.",
+     "source": "https://github.com/donnemartin/system-design-primer"
+    },
+    {
+     "id": "async-02",
+     "type": "duel",
+     "bloom": "evaluate",
+     "prompt": "Every \"invoice created\" event must reach the email worker, the analytics warehouse and the search indexer. Next quarter a new team wants to reprocess last week's events. A queue (like Amazon Simple Queue Service, SQS) or a log (like Kafka)?",
+     "choices": [
+      "A queue, like SQS: one worker takes each message, then it's deleted",
+      "A log, like Kafka: events are kept, and each consumer group reads at its own pace"
+     ],
+     "correct": 1,
+     "reasons": [
+      "Each consumer group gets every event, and kept events can be replayed",
+      "A log never hands out an event twice",
+      "A queue can only have one worker"
+     ],
+     "reason": 0,
+     "costs": [
+      "More to run: partitions, retention and consumer offsets to manage",
+      "Events vanish once the first consumer reads them",
+      "Nothing extra"
+     ],
+     "cost": 0,
+     "explain": "A queue gives each message to one worker and deletes it once done: ideal for jobs. A log keeps events for a set period, so three consumer groups each see every event and a new one can start from last week. Say: \"Jobs go on a queue; facts that many readers need go on a log.\"",
+     "source": "https://www.hellointerview.com/learn/system-design/deep-dives/kafka"
+    },
+    {
+     "id": "async-03",
+     "type": "recall",
+     "bloom": "understand",
+     "prompt": "Setting up a new customer touches three services, each with its own database. Why reach for a saga rather than two-phase commit (2PC)?",
+     "answer": "2PC makes every service wait on one coordinator, holding its resources, and a coordinator failure can leave them stuck. A saga runs each local step in turn and, if one fails, undoes the finished steps with compensating actions.",
+     "explain": "Across services with their own databases, 2PC is slow, blocks on its coordinator, and often isn't on offer at all. A saga gives up isolation: in-between states are visible and the result is eventually consistent, so every step and every undo must be safe to retry. Say: \"A saga with compensating steps, run by an orchestrator.\"",
+     "source": "https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/saga-orchestration.html"
+    },
+    {
+     "id": "async-04",
+     "type": "fill",
+     "bloom": "apply",
+     "prompt": "Fill the boxes. The export API (application programming interface) returns a job ID at once, the export runs in the background, and a job that keeps failing is set aside for a person to inspect, not retried for ever.",
+     "diagram": {
+      "width": 640,
+      "height": 300,
+      "nodes": [
+       {
+        "id": "client",
+        "label": "Client",
+        "x": 20,
+        "y": 126
+       },
+       {
+        "id": "api",
+        "label": "Export API",
+        "x": 170,
+        "y": 126
+       },
+       {
+        "id": "jobs",
+        "label": "Job status table",
+        "x": 170,
+        "y": 20
+       },
+       {
+        "id": "s-queue",
+        "label": "?",
+        "x": 330,
+        "y": 126
+       },
+       {
+        "id": "s-workers",
+        "label": "?",
+        "x": 500,
+        "y": 126
+       },
+       {
+        "id": "s-dlq",
+        "label": "?",
+        "x": 330,
+        "y": 232
+       },
+       {
+        "id": "files",
+        "label": "File store",
+        "x": 500,
+        "y": 232
+       }
+      ],
+      "edges": [
+       [
+        "client",
+        "api",
+        "start export"
+       ],
+       [
+        "api",
+        "jobs",
+        "job ID, pending"
+       ],
+       [
+        "api",
+        "s-queue",
+        "job"
+       ],
+       [
+        "s-queue",
+        "s-workers"
+       ],
+       [
+        "s-workers",
+        "files",
+        "writes the file"
+       ],
+       [
+        "s-workers",
+        "jobs",
+        "marks done"
+       ],
+       [
+        "s-queue",
+        "s-dlq",
+        "after 5 failed tries"
+       ]
+      ]
+     },
+     "slots": {
+      "s-queue": "Queue",
+      "s-workers": "Worker pool",
+      "s-dlq": "Dead-letter queue"
+     },
+     "palette": [
+      "Queue",
+      "Worker pool",
+      "Dead-letter queue",
+      "Cache",
+      "Load balancer",
+      "Circuit breaker"
+     ],
+     "explain": "The queue absorbs bursts and the worker pool scales on its own. A message that fails every time (a poison message) would otherwise loop for ever, so after a set number of tries it moves to the dead-letter queue (DLQ). Say: \"Retries for blips, a DLQ with an alarm for the rest.\"",
+     "source": "https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html"
+    },
+    {
+     "id": "async-05",
+     "type": "order",
+     "bloom": "apply",
+     "prompt": "A worker's call to an outside partner fails. Put a sensible retry policy in order.",
+     "items": [
+      "The call hits its timeout or fails",
+      "Retry after a short wait",
+      "Retry again, doubling the wait and adding random jitter",
+      "Give up after a capped number of tries",
+      "Move the message to the dead-letter queue",
+      "Alert, fix the cause, then send the messages back"
+     ],
+     "explain": "A timeout stops a slow call holding a worker. Backoff gives the partner room to recover, jitter stops every client retrying in the same instant, and the cap surfaces the failure. Retry at one layer only, or the retries multiply. Say: \"Capped exponential backoff with jitter, then the DLQ.\"",
+     "source": "https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/"
+    },
+    {
+     "id": "async-06",
+     "type": "multi",
+     "bloom": "analyse",
+     "prompt": "The queue delivers at least once, so any message may be processed twice. Which of these consumers are already safe to run twice?",
+     "options": [
+      "Resize an image and save it under a name made from the image's ID",
+      "Set an invoice's status to paid",
+      "Add the payment's amount to the account balance",
+      "Send the invoice email",
+      "Append an audit row with a freshly generated ID",
+      "Build the monthly report and overwrite that month's file"
+     ],
+     "correct": [
+      0,
+      1,
+      5
+     ],
+     "explain": "Setting a value or overwriting a fixed name gives the same result however often it runs. Adding, sending and appending don't. Make those safe with an idempotency key: record the message's ID in the same transaction as the change, and skip IDs already seen. Say: \"At-least-once delivery, so every consumer is idempotent.\"",
+     "source": "https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-apis/"
+    },
+    {
+     "id": "async-07",
+     "type": "duel",
+     "bloom": "evaluate",
+     "prompt": "Every invoice calls an outside tax-rate service. It starts taking 30 seconds, then failing. Your servers' threads pile up waiting and the whole app slows down. Best move?",
+     "choices": [
+      "Retry each failed call three times straight away",
+      "A short timeout and a circuit breaker, with a fallback rate",
+      "Raise the timeout to 60 seconds so calls can finish"
+     ],
+     "correct": 1,
+     "reasons": [
+      "After repeated failures it fails fast, freeing threads and letting the partner recover",
+      "It makes the partner respond faster",
+      "It guarantees no invoice ever fails"
+     ],
+     "reason": 0,
+     "costs": [
+      "While it's open you need a fallback: a cached rate, or \"try again later\"",
+      "It doubles the load on the partner",
+      "Nothing; it's free"
+     ],
+     "cost": 0,
+     "explain": "Waiting on a dying partner ties up threads until your service fails too. A breaker counts failures, trips, and returns an error at once; after a pause it lets one trial call through. Instant retries pile more load on a struggling service. Say: \"Timeout, breaker, fallback, so their outage stays theirs.\"",
+     "source": "https://martinfowler.com/bliki/CircuitBreaker.html"
+    },
+    {
+     "id": "async-08",
+     "type": "write",
+     "bloom": "apply",
+     "prompt": "The invoice service saves an invoice, then publishes \"invoice created\" to the message broker. Sometimes the save works and the publish doesn't. Explain your fix to the interviewer in three or four sentences.",
+     "key_points": [
+      "Names the problem: two systems written separately, so one can succeed alone",
+      "Writes the invoice and an outbox row in one database transaction",
+      "A relay reads the outbox and publishes, retrying until the broker accepts",
+      "The relay can publish twice, so consumers are idempotent"
+     ],
+     "model": "Saving and publishing are two separate writes, so a crash between them loses the event. I'd write the invoice and an outbox row in the same database transaction, so both commit or neither does. A relay reads new outbox rows, publishes them and marks them sent. After a crash it can publish a row twice, so consumers skip event IDs they've already seen.",
+     "explain": "The dual write is the bug: no transaction spans a database and a broker. The outbox puts the event inside the transaction you already have, and the relay makes publishing at-least-once, never zero. Say: \"Outbox table, relay, idempotent consumers.\"",
+     "source": "https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/transactional-outbox.html"
+    },
+    {
+     "id": "async-09",
+     "type": "lightning",
+     "bloom": "understand",
+     "prompt": "When you hear this, reach for what? 90 seconds.",
+     "pairs": [
+      [
+       "Traffic bursts the workers can't keep up with",
+       "A queue to absorb the burst"
+      ],
+      [
+       "The same message may arrive twice",
+       "An idempotent consumer"
+      ],
+      [
+       "One message fails every single time",
+       "A dead-letter queue"
+      ],
+      [
+       "Thousands of clients retry at the same instant",
+       "Exponential backoff with jitter"
+      ],
+      [
+       "A partner keeps failing and threads pile up",
+       "A circuit breaker"
+      ],
+      [
+       "The queue grows faster than it drains, for hours",
+       "Back pressure: cap the queue, push back"
+      ],
+      [
+       "Save a record and publish an event, both or neither",
+       "The outbox pattern"
+      ],
+      [
+       "Steps across services, each undoable if a later one fails",
+       "A saga with compensating steps"
+      ],
+      [
+       "A job that runs for days and must survive restarts",
+       "A workflow engine, like Temporal"
+      ],
+      [
+       "Every call to a partner needs a limit on waiting",
+       "A timeout"
+      ]
+     ],
+     "explain": "Each failure has a standard answer, and naming it fast leaves your time for the trade-off. If one was slow, say that pairing out loud, with what it costs, before the next round.",
+     "source": "https://github.com/donnemartin/system-design-primer"
+    },
+    {
+     "id": "async-boss",
+     "type": "flaw",
+     "bloom": "analyse",
+     "prompt": "This flow credits customers' accounts from the payment provider's webhooks (calls the provider makes to you). The provider retries until it gets a success response, and the queue delivers at least once. Find the weak box, then pick the fix.",
+     "diagram": {
+      "width": 640,
+      "height": 300,
+      "nodes": [
+       {
+        "id": "provider",
+        "label": "Payment provider",
+        "x": 10,
+        "y": 126
+       },
+       {
+        "id": "hook",
+        "label": "Webhook: verify, queue, 200",
+        "x": 150,
+        "y": 126,
+        "w": 150
+       },
+       {
+        "id": "queue",
+        "label": "Queue",
+        "x": 330,
+        "y": 126
+       },
+       {
+        "id": "dlq",
+        "label": "Dead-letter queue",
+        "x": 330,
+        "y": 232
+       },
+       {
+        "id": "worker",
+        "label": "Worker adds amount to balance",
+        "x": 480,
+        "y": 126,
+        "w": 150
+       },
+       {
+        "id": "db",
+        "label": "Accounts database",
+        "x": 480,
+        "y": 232,
+        "w": 150
+       }
+      ],
+      "edges": [
+       [
+        "provider",
+        "hook"
+       ],
+       [
+        "hook",
+        "queue"
+       ],
+       [
+        "queue",
+        "worker"
+       ],
+       [
+        "queue",
+        "dlq",
+        "after 5 tries"
+       ],
+       [
+        "worker",
+        "db",
+        "balance += amount"
+       ]
+      ]
+     },
+     "flaw": "worker",
+     "fixes": [
+      "Record each event's ID with the balance change in one transaction; skip IDs already seen",
+      "Add more workers so events are processed faster",
+      "Have the webhook update the balance itself before replying 200",
+      "Remove the dead-letter queue so no event is set aside",
+      "Move the events to a log so they're kept for a week"
+     ],
+     "fix": 0,
+     "explain": "Duplicates are certain here: the provider retries and the queue redelivers. \"Add the amount\" applies every copy, so one payment can credit twice. The provider's event ID is a ready-made idempotency key: store it in the same transaction as the credit, with a unique constraint, and skip repeats. Say: \"Skip repeats by event ID, atomically with the write.\"",
+     "source": "https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-apis/"
+    }
+   ]
+  },
+  {
+   "chapter": 8,
+   "slug": "patterns",
+   "title": "Patterns",
+   "emoji": "🧱",
+   "pillar": "Patterns",
+   "blurb": "The moves that recur in most designs. Spot which one a problem needs, then say what it costs.",
+   "boss": "pat-boss",
+   "challenges": [
+    {
+     "id": "pat-01",
+     "type": "duel",
+     "bloom": "evaluate",
+     "prompt": "A team dashboard's main query joins six tables and takes 2 seconds. It's read 200 times a minute, and the data under it changes all day. What do you do?",
+     "choices": [
+      "Keep a precomputed read model, updated as the data changes",
+      "Cache the query result for an hour",
+      "Add a read replica and run the same query there"
+     ],
+     "correct": 0,
+     "reasons": [
+      "Readers get a ready-made row in milliseconds, and it stays close to current",
+      "A cache is never stale",
+      "A replica runs the same join faster"
+     ],
+     "reason": 0,
+     "costs": [
+      "Two shapes of the data to keep in step, and the read model lags slightly",
+      "The dashboard can't be filtered any more",
+      "Writes stop working"
+     ],
+     "cost": 0,
+     "explain": "When a read is expensive and constant, do the work once at write time. A separate read model (the idea behind CQRS, command query responsibility segregation) is shaped for the screen, while a cache would be an hour stale and a replica still runs the slow join. Say: \"Precompute the dashboard's view as data changes; accept a second or two of lag.\"",
+     "source": "https://martinfowler.com/bliki/CQRS.html"
+    },
+    {
+     "id": "pat-02",
+     "type": "multi",
+     "bloom": "analyse",
+     "prompt": "A metrics service takes 200,000 small writes a second, and one database can't keep up. Which of these help it scale writes?",
+     "options": [
+      "Buffer writes in memory and flush them in batches every second",
+      "Split the data across machines by a well-spread key",
+      "Use a store built for heavy writes, such as Cassandra",
+      "Add up counts before storing them, one row a minute per metric",
+      "Add read replicas",
+      "Put a cache in front of the database"
+     ],
+     "correct": [
+      0,
+      1,
+      2,
+      3
+     ],
+     "explain": "Writes scale by doing fewer, cheaper or spread-out writes: batch them, pre-aggregate them, shard them, or use a store built for appends. Replicas copy every write, so they add work, and a cache helps reads, not writes. Say: \"Batch and pre-aggregate first, then shard by metric if it's still too much.\"",
+     "source": "https://www.hellointerview.com/learn/system-design/in-a-hurry/patterns"
+    },
+    {
+     "id": "pat-03",
+     "type": "order",
+     "bloom": "apply",
+     "prompt": "A user uploads a 2 GB video from a phone on a patchy connection. Put the steps in order.",
+     "items": [
+      "The app asks the server to start an upload; the server saves a pending record",
+      "The server returns presigned URLs, one for each part",
+      "The app sends the parts straight to object storage, retrying any part that fails",
+      "The app tells the server it has finished",
+      "The server checks the parts and marks the video uploaded",
+      "Workers process the video, such as transcoding it"
+     ],
+     "explain": "Big files go straight from the client to object storage in parts, so your servers never carry the bytes and a dropped connection costs one part, not the whole file. The database keeps only the record and its state. Say: \"Multipart, presigned uploads straight to storage, with a pending record until it completes.\"",
+     "source": "https://docs.aws.amazon.com/AmazonS3/latest/userguide/mpuoverview.html"
+    },
+    {
+     "id": "pat-04",
+     "type": "flaw",
+     "bloom": "analyse",
+     "prompt": "A video course site. Viewers around the world stream lessons. Find the box that will hurt first, then pick the fix.",
+     "diagram": {
+      "width": 640,
+      "height": 300,
+      "nodes": [
+       {
+        "id": "viewers",
+        "label": "Viewers worldwide",
+        "x": 20,
+        "y": 126
+       },
+       {
+        "id": "lb",
+        "label": "Load balancer",
+        "x": 180,
+        "y": 126
+       },
+       {
+        "id": "app",
+        "label": "App servers: stream video bytes",
+        "x": 340,
+        "y": 126,
+        "w": 140
+       },
+       {
+        "id": "s3",
+        "label": "Object storage: videos",
+        "x": 500,
+        "y": 40,
+        "w": 130
+       },
+       {
+        "id": "db",
+        "label": "Database: courses, progress",
+        "x": 500,
+        "y": 212,
+        "w": 130
+       }
+      ],
+      "edges": [
+       [
+        "viewers",
+        "lb"
+       ],
+       [
+        "lb",
+        "app"
+       ],
+       [
+        "app",
+        "s3",
+        "reads whole files"
+       ],
+       [
+        "app",
+        "db"
+       ]
+      ]
+     },
+     "flaw": "app",
+     "fixes": [
+      "Serve videos from a CDN in front of object storage, using signed links",
+      "Add more app servers",
+      "Keep popular videos in a Redis cache",
+      "Store the videos in the database"
+     ],
+     "fix": 0,
+     "explain": "Pushing every byte of video through your own servers wastes them and puts far-away viewers on slow paths. A CDN (content delivery network) serves copies from near each viewer, and signed, short-lived links keep paid lessons private. Say: \"Videos from a CDN with signed links; the app only hands out the link.\"",
+     "source": "https://www.hellointerview.com/learn/system-design/in-a-hurry/patterns"
+    },
+    {
+     "id": "pat-05",
+     "type": "write",
+     "bloom": "apply",
+     "prompt": "A year-end report takes about four minutes to build. Explain how the request works and how the user finds out it's ready.",
+     "key_points": [
+      "The request returns at once (202 Accepted) with a job ID",
+      "The work goes on a queue for workers, not the web server",
+      "A job record tracks its state, such as pending, running, done or failed",
+      "The client checks a status endpoint, or gets a live update or an email when it's done",
+      "The finished file is fetched by a link, such as a presigned URL"
+     ],
+     "model": "POST /reports returns 202 and a job ID straight away. A worker picks the job off a queue and updates the job's state as it goes. The page checks GET /jobs/{id} every few seconds, or listens for a server-sent event; when it's done, the response includes a short-lived link to the file. A failed job shows as failed, with a retry button.",
+     "explain": "Holding a request open for minutes ties up a server and breaks on any timeout or deploy. Accepting the job and reporting its state lets the work survive restarts and lets workers scale on their own. Say: \"Accept, return a job ID, process in the background, report the state.\"",
+     "source": "https://www.hellointerview.com/learn/system-design/in-a-hurry/patterns"
+    },
+    {
+     "id": "pat-06",
+     "type": "duel",
+     "bloom": "evaluate",
+     "prompt": "Onboarding a customer: create the account, take the first payment, set up their workspace, then send a welcome email. Steps can fail or take minutes, and the process must survive a restart. How do you run it?",
+     "choices": [
+      "A workflow engine, such as Temporal or AWS Step Functions, running the steps in order",
+      "All four steps inside one HTTP request",
+      "Each service reacts to the previous one's event, with no central view"
+     ],
+     "correct": 0,
+     "reasons": [
+      "It records each finished step, retries failures, and resumes after a crash",
+      "It makes every step run faster",
+      "It removes the need for idempotent steps"
+     ],
+     "reason": 0,
+     "costs": [
+      "One more system to run, and steps must be safe to replay",
+      "The customer waits for every step",
+      "Nobody can see where a stuck customer is"
+     ],
+     "cost": 0,
+     "explain": "With more than two or three steps, a central orchestrator gives you one place to see progress, retry and undo, and it survives restarts. Chaining events between services works for short flows but hides where a stuck case is. One request breaks on the first slow step. Say: \"A workflow engine for the multi-step part; each step idempotent.\"",
+     "source": "https://www.hellointerview.com/learn/system-design/deep-dives/temporal"
+    },
+    {
+     "id": "pat-07",
+     "type": "sticker",
+     "bloom": "analyse",
+     "prompt": "Live updates for a shared task board. Put each trait on the box it describes.",
+     "diagram": {
+      "width": 640,
+      "height": 300,
+      "nodes": [
+       {
+        "id": "browsers",
+        "label": "Browsers",
+        "x": 20,
+        "y": 126
+       },
+       {
+        "id": "conn",
+        "label": "Connection servers",
+        "x": 180,
+        "y": 126
+       },
+       {
+        "id": "pubsub",
+        "label": "Pub/sub channel",
+        "x": 340,
+        "y": 20
+       },
+       {
+        "id": "app",
+        "label": "App servers",
+        "x": 340,
+        "y": 210
+       },
+       {
+        "id": "db",
+        "label": "Database",
+        "x": 500,
+        "y": 210
+       }
+      ],
+      "edges": [
+       [
+        "browsers",
+        "conn",
+        "SSE or WebSocket"
+       ],
+       [
+        "pubsub",
+        "conn",
+        "update"
+       ],
+       [
+        "app",
+        "pubsub",
+        "publish"
+       ],
+       [
+        "app",
+        "db",
+        "write"
+       ]
+      ]
+     },
+     "stickers": [
+      "Holds open connections",
+      "Needs care on deploys",
+      "Sends one update to every subscriber",
+      "The source of truth",
+      "Any instance takes any request"
+     ],
+     "answers": {
+      "conn": [
+       "Holds open connections",
+       "Needs care on deploys"
+      ],
+      "pubsub": [
+       "Sends one update to every subscriber"
+      ],
+      "db": [
+       "The source of truth"
+      ],
+      "app": [
+       "Any instance takes any request"
+      ]
+     },
+     "explain": "A write lands on any app server, but the reader's connection lives on one of many connection servers. The app server saves to the database and publishes the change; every connection server that subscribed passes it to its own browsers. Connection servers hold state, so deploys must drain connections gently. Say: \"Write, publish, fan out to the connection servers.\"",
+     "source": "https://redis.io/docs/latest/develop/interact/pubsub/"
+    },
+    {
+     "id": "pat-08",
+     "type": "recall",
+     "bloom": "understand",
+     "prompt": "Why does a live-updates design usually put a pub/sub layer between the app servers and the connection servers?",
+     "answer": "The server that handles a write doesn't know which connection server each reader is on. It publishes once; every connection server subscribed to that channel forwards the update to its own readers.",
+     "explain": "Without it, every app server would have to know every connection, which breaks as soon as there's more than one of each. Say: \"Pub/sub decouples who writes from who's connected.\"",
+     "source": "https://redis.io/docs/latest/develop/interact/pubsub/"
+    },
+    {
+     "id": "pat-09",
+     "type": "duel",
+     "bloom": "evaluate",
+     "prompt": "Two fans tap \"Book\" on the last seat in the same second. Seats live in PostgreSQL. How do you make sure exactly one of them gets it?",
+     "choices": [
+      "One conditional update: claim the seat only if it's still free",
+      "Read the seat, check it's free, then write in a second query",
+      "Put a cache in front of the seats table"
+     ],
+     "correct": 0,
+     "reasons": [
+      "Check and claim are one atomic step, so the later claim changes no rows",
+      "It's faster than reading first",
+      "The cache makes requests take turns"
+     ],
+     "reason": 0,
+     "costs": [
+      "The loser needs a clear \"just taken\" message and a way to pick again",
+      "The seat can still be sold twice",
+      "Every booking waits on one global lock"
+     ],
+     "cost": 0,
+     "explain": "Reading, then writing, leaves a gap where both fans see \"free\". Let the database decide in one statement: set the holder WHERE the seat is still free, and treat zero rows changed as \"someone beat you\". A version number checked on write (optimistic locking) is the same idea. Say: \"Claim it with a conditional update; zero rows means it's gone.\"",
+     "source": "https://www.postgresql.org/docs/current/transaction-iso.html"
+    },
+    {
+     "id": "pat-10",
+     "type": "duel",
+     "bloom": "evaluate",
+     "prompt": "Checkout takes a few minutes: the fan picks a seat, then types card details. How do you stop anyone else taking the seat meanwhile, without locking it forever?",
+     "choices": [
+      "Hold the seat with an expiry, say 10 minutes, and free it if payment doesn't finish",
+      "Keep a database row lock open while the fan types",
+      "Reserve nothing: check again at payment and apologise if it's gone"
+     ],
+     "correct": 0,
+     "reasons": [
+      "Nobody else can take it while the clock runs, and an abandoned hold frees itself",
+      "A row lock costs nothing over a few minutes",
+      "Fans rarely abandon checkout"
+     ],
+     "reason": 0,
+     "costs": [
+      "Expired holds must count as free again, and held seats look taken",
+      "Database connections tied up for minutes at a time",
+      "Fans lose their seat at the very last step"
+     ],
+     "cost": 0,
+     "explain": "Database locks suit milliseconds, not minutes of someone typing. A hold is a conditional write that sets a held-until time; once it passes, the seat counts as free again. For a huge rush on a few seats, add a virtual waiting room that lets people in at a pace you can serve. Say: \"A ten-minute hold with an expiry, claimed atomically.\"",
+     "source": "https://www.hellointerview.com/learn/system-design/problem-breakdowns/ticketmaster"
+    },
+    {
+     "id": "pat-11",
+     "type": "recall",
+     "bloom": "understand",
+     "prompt": "Pessimistic or optimistic locking: when does each fit?",
+     "answer": "Pessimistic (lock the row, then change it) when conflicts are frequent and the lock is brief. Optimistic (check a version number as you write, retry if it moved) when conflicts are rare.",
+     "explain": "Locking first makes everyone else wait, which is fine for a busy row held for milliseconds. A version check on write costs nothing until two writers collide, so it suits rare clashes. Neither suits a hold that lasts minutes: that needs a timed reservation. Say: \"Clashes are rare, so optimistic: a version check on write.\"",
+     "source": "https://en.wikipedia.org/wiki/Optimistic_concurrency_control"
+    },
+    {
+     "id": "pat-12",
+     "type": "fill",
+     "bloom": "apply",
+     "prompt": "Find nearby drivers. Each driver's phone sends its location every 5 seconds; riders ask for the closest drivers. Fill the two empty boxes.",
+     "diagram": {
+      "width": 640,
+      "height": 300,
+      "nodes": [
+       {
+        "id": "drivers",
+        "label": "Driver phones",
+        "x": 20,
+        "y": 40
+       },
+       {
+        "id": "ingest",
+        "label": "?",
+        "x": 240,
+        "y": 40
+       },
+       {
+        "id": "index",
+        "label": "?",
+        "x": 460,
+        "y": 126
+       },
+       {
+        "id": "riders",
+        "label": "Rider app",
+        "x": 20,
+        "y": 212
+       },
+       {
+        "id": "match",
+        "label": "Matching service",
+        "x": 240,
+        "y": 212
+       },
+       {
+        "id": "db",
+        "label": "Database: trips",
+        "x": 480,
+        "y": 240
+       }
+      ],
+      "edges": [
+       [
+        "drivers",
+        "ingest",
+        "every 5 s"
+       ],
+       [
+        "ingest",
+        "index",
+        "latest point"
+       ],
+       [
+        "riders",
+        "match"
+       ],
+       [
+        "match",
+        "index",
+        "within 2 km?"
+       ],
+       [
+        "match",
+        "db"
+       ]
+      ]
+     },
+     "slots": {
+      "ingest": "Location service",
+      "index": "In-memory geo index"
+     },
+     "palette": [
+      "Location service",
+      "In-memory geo index",
+      "Nightly batch job",
+      "Full scan of a lat/long table",
+      "CDN"
+     ],
+     "explain": "Locations change every few seconds, so keep only each driver's latest point, in memory, in a structure that answers \"who is near here?\" without checking everyone: a geohash- or grid-based index such as Redis GEO. The database keeps trips, not every ping. Say: \"Pings update an in-memory geo index; matching asks it by radius.\"",
+     "source": "https://redis.io/docs/latest/develop/data-types/geospatial/"
+    },
+    {
+     "id": "pat-13",
+     "type": "multi",
+     "bloom": "analyse",
+     "prompt": "A food app shows restaurants within 3 km: 2 million places that rarely move, searched all day. Which of these make the search fast?",
+     "options": [
+      "Index locations by geohash or quadtree cells",
+      "Look up the rider's cell and its neighbours, then filter by exact distance",
+      "Cache results per cell for busy areas",
+      "Use a spatial index, such as PostGIS or Redis GEO",
+      "Sort every restaurant by distance on each request",
+      "Add read replicas and scan the whole table on each one"
+     ],
+     "correct": [
+      0,
+      1,
+      2,
+      3
+     ],
+     "explain": "A geohash turns a point into a string where a shared prefix means a nearby cell; a quadtree splits busy areas into smaller cells. Search the rider's cell and its neighbours, since a place just over the edge is still near, then filter by real distance. Places rarely move, so busy cells cache well. Say: \"Spatial index, neighbouring cells, then exact distance.\"",
+     "source": "https://en.wikipedia.org/wiki/Geohash"
+    },
+    {
+     "id": "pat-boss",
+     "type": "lightning",
+     "bloom": "understand",
+     "seconds": 120,
+     "prompt": "You hear the problem; name the pattern. Two minutes.",
+     "pairs": [
+      [
+       "Reads dwarf writes and the data changes slowly",
+       "Scale reads: CDN, cache, replicas"
+      ],
+      [
+       "A slow multi-table query read all day",
+       "A precomputed read model (CQRS)"
+      ],
+      [
+       "Hundreds of thousands of small writes a second",
+       "Scale writes: batch, aggregate, shard"
+      ],
+      [
+       "Users upload multi-gigabyte files",
+       "Multipart, presigned uploads to storage"
+      ],
+      [
+       "Serving big files to people everywhere",
+       "A CDN in front of object storage"
+      ],
+      [
+       "A job takes minutes to finish",
+       "Job ID, queue, status endpoint"
+      ],
+      [
+       "Steps across services that must survive a crash",
+       "A workflow engine"
+      ],
+      [
+       "Browsers must see changes as they happen",
+       "SSE or WebSockets, plus pub/sub"
+      ],
+      [
+       "Two people try to book the last seat at once",
+       "An atomic claim: conditional write or version check"
+      ],
+      [
+       "The seat must stay yours while you pay",
+       "A reservation hold with an expiry"
+      ],
+      [
+       "Find the drivers within 2 km of a rider",
+       "A geo index: geohash, quadtree, Redis GEO"
+      ]
+     ],
+     "explain": "Most designs are a few of these patterns joined up. Naming the pattern first gives your answer a shape; then say its cost. If one was slow, say that pairing aloud before the next round.",
+     "source": "https://www.hellointerview.com/learn/system-design/in-a-hurry/patterns"
+    }
+   ]
+  },
+  {
+   "chapter": 9,
+   "slug": "url-shortener",
+   "kind": "quest",
+   "title": "URL shortener (like Bitly)",
+   "emoji": "🔗",
+   "pillar": "Quests",
+   "builds_on": [
+    1,
+    2,
+    4,
+    5
+   ],
+   "blurb": "Turn long links into short ones that redirect fast. Requirements, numbers, API, the design, then the deep dives.",
+   "boss": "fb-boss",
+   "challenges": [
+    {
+     "id": "fb-01",
+     "type": "sprint",
+     "bloom": "create",
+     "minutes": 10,
+     "prompt": "Requirements for a URL shortener (people turn long links into short ones and share them). Out loud, against the clock: read it back, who uses it and what they do, your three hard parts, how busy (with the peak), what can't break, what's out.",
+     "checks": [
+      "Read the problem back in one line",
+      "Named both users: people who create links and people who click them",
+      "Picked my own three hard parts, such as unique codes, fast redirects at the peak, and expiry or click counts",
+      "Asked for the scale, the peak and the read-to-write ratio",
+      "Said what can't break, such as a code never pointing to the wrong place",
+      "Said \"I'll assume…\" for scope, instead of asking \"do you want…?\"",
+      "Said what's out of scope",
+      "Finished inside the time"
+     ],
+     "explain": "This problem rewards the same first quarter as any other: a clear read-back, both kinds of user, numbers with a peak, and your own picks. Redirects vastly outnumber new links, which shapes the whole design. If a check missed, rehearse that line before the next round.",
+     "source": "https://www.hellointerview.com/learn/system-design/problem-breakdowns/bitly"
+    },
+    {
+     "id": "fb-02",
+     "type": "estimate",
+     "bloom": "apply",
+     "prompt": "Redirects for a popular link shortener. Estimate the busiest second.",
+     "generator": {
+      "kind": "peak_rps",
+      "params": {
+       "users": [
+        1000000,
+        200000000
+       ],
+       "actions": [
+        1,
+        10
+       ]
+      }
+     },
+     "explain": "Clicks a day, divided by about 100,000 seconds, times 10 for the peak. Redirects are reads, so this number sizes the cache and the app servers, while new links stay a trickle. Say the working aloud and round hard.",
+     "source": "https://www.hellointerview.com/learn/system-design/in-a-hurry/core-concepts"
+    },
+    {
+     "id": "fb-03",
+     "type": "write",
+     "bloom": "apply",
+     "prompt": "Name the core entities, then sketch the API: create a short link, and follow one.",
+     "key_points": [
+      "Entities: a short link (code, long URL, owner, created, optional expiry) and a user",
+      "POST /urls with the long URL, an optional custom alias and expiry; returns 201 and the code",
+      "GET /{code} answers with a redirect to the long URL",
+      "404 for an unknown code, 410 Gone for an expired one",
+      "The owner comes from the token, never from the request body"
+     ],
+     "model": "Entities: ShortLink (code, long URL, owner, created at, expires at) and User. POST /urls takes the long URL, an optional alias and expiry, and returns 201 with the short code; the owner comes from the token. GET /{code} returns a redirect to the long URL, 404 if the code is unknown and 410 if it has expired.",
+     "explain": "Two endpoints carry the whole product, so name them early and keep them plain. The redirect is the hot path; creating links is rare. Say: \"Entities first, then the API is just verbs on them.\"",
+     "source": "https://www.hellointerview.com/learn/system-design/in-a-hurry/delivery"
+    },
+    {
+     "id": "fb-04",
+     "type": "fill",
+     "bloom": "apply",
+     "prompt": "Land the design end to end. Drag each part into its box: the hot lookup, the source of truth, where new codes come from, and how clicks get counted without slowing the redirect.",
+     "diagram": {
+      "width": 640,
+      "height": 300,
+      "nodes": [
+       {
+        "id": "browser",
+        "label": "Browser",
+        "x": 10,
+        "y": 126
+       },
+       {
+        "id": "lb",
+        "label": "Load balancer",
+        "x": 140,
+        "y": 126
+       },
+       {
+        "id": "app",
+        "label": "App servers",
+        "x": 270,
+        "y": 126
+       },
+       {
+        "id": "s-counter",
+        "label": "?",
+        "x": 270,
+        "y": 20
+       },
+       {
+        "id": "s-cache",
+        "label": "?",
+        "x": 396,
+        "y": 20
+       },
+       {
+        "id": "s-db",
+        "label": "?",
+        "x": 396,
+        "y": 126
+       },
+       {
+        "id": "s-queue",
+        "label": "?",
+        "x": 396,
+        "y": 232
+       },
+       {
+        "id": "workers",
+        "label": "Click-count workers",
+        "x": 522,
+        "y": 232,
+        "w": 114
+       }
+      ],
+      "edges": [
+       [
+        "browser",
+        "lb"
+       ],
+       [
+        "lb",
+        "app"
+       ],
+       [
+        "app",
+        "s-counter",
+        "block of IDs"
+       ],
+       [
+        "app",
+        "s-cache",
+        "look up code"
+       ],
+       [
+        "app",
+        "s-db",
+        "on a miss"
+       ],
+       [
+        "app",
+        "s-queue",
+        "click event"
+       ],
+       [
+        "s-queue",
+        "workers"
+       ]
+      ]
+     },
+     "slots": {
+      "s-cache": "Redis cache",
+      "s-db": "Database: code → long URL",
+      "s-counter": "ID counter",
+      "s-queue": "Queue"
+     },
+     "palette": [
+      "Redis cache",
+      "Database: code → long URL",
+      "ID counter",
+      "Queue",
+      "WebSocket server",
+      "Graph database",
+      "Search index"
+     ],
+     "explain": "The cache answers almost every redirect; the database is the truth behind it; a counter hands out unique numbers for new codes; clicks go onto a queue so counting never slows a redirect. Say each box's reason as you place it, then: \"That's the whole path. The deep dives are codes and redirect speed.\"",
+     "source": "https://www.hellointerview.com/learn/system-design/problem-breakdowns/bitly"
+    },
+    {
+     "id": "fb-05",
+     "type": "duel",
+     "bloom": "evaluate",
+     "prompt": "Marketing wants every click on a short link counted. Which redirect do you send?",
+     "choices": [
+      "302 Found, a temporary redirect",
+      "301 Moved Permanently"
+     ],
+     "correct": 0,
+     "reasons": [
+      "Browsers don't remember a 302, so every click comes back to you and is counted",
+      "A 302 is faster for the person clicking",
+      "A 301 can't carry a long URL"
+     ],
+     "reason": 0,
+     "costs": [
+      "Every click is a request you serve, so the cache and servers carry more load",
+      "Links stop working after a day",
+      "None"
+     ],
+     "cost": 0,
+     "explain": "A 301 tells browsers to remember the target, so repeat clicks skip your servers: less load, but you lose the count. A 302 brings every click back to you. Say: \"302, because counting clicks is a requirement; the cache absorbs the load.\"",
+     "source": "https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/302"
+    },
+    {
+     "id": "fb-06",
+     "type": "multi",
+     "bloom": "analyse",
+     "prompt": "Redirects must answer in under 50 ms at the peak. Which of these help?",
+     "options": [
+      "Cache code → URL in Redis, evicting the least used",
+      "Keep app servers stateless and add more at the peak",
+      "Read replicas for cache misses",
+      "Put link creation on a queue",
+      "Shard the links table by creation date",
+      "Index the long URL column"
+     ],
+     "correct": [
+      0,
+      1,
+      2
+     ],
+     "explain": "A small share of links gets most clicks, so a cache holding the popular codes answers nearly everything in about a millisecond. Stateless servers scale out, and replicas take the misses. Queuing creation doesn't touch the redirect path, sharding by date piles new writes on one shard, and the long-URL index only helps spot duplicates. Say: \"Cache the hot codes; replicas behind it.\"",
+     "source": "https://www.hellointerview.com/learn/system-design/core-concepts/caching"
+    },
+    {
+     "id": "fb-boss",
+     "type": "duel",
+     "bloom": "evaluate",
+     "prompt": "Deep dive: how do you make the short codes? Seven characters, billions of links, and several app servers creating them at once.",
+     "choices": [
+      "A counter, written in base62 and handed out in blocks",
+      "Hash the long URL and keep the first seven characters",
+      "Seven random characters, checked against the database"
+     ],
+     "correct": 0,
+     "reasons": [
+      "Each number is used once, so codes never clash and nothing needs checking first",
+      "Hashing guarantees no two links ever share a code",
+      "Random codes can never clash"
+     ],
+     "reason": 0,
+     "costs": [
+      "Sequential codes are guessable unless scrambled, and the counter must stay up",
+      "Every link needs a lookup in a global index",
+      "Codes get longer every year"
+     ],
+     "cost": 0,
+     "explain": "62 characters in seven places give about 3.5 trillion codes. A counter guarantees uniqueness, and giving each app server a block of 1,000 numbers at a time saves a round trip per link and survives a short counter outage. Truncated hashes collide; random codes need a check that slows as the space fills. Say: \"Counter plus base62, handed out in blocks.\"",
+     "source": "https://www.hellointerview.com/learn/system-design/problem-breakdowns/bitly"
+    }
+   ]
+  },
+  {
+   "chapter": 10,
+   "slug": "rate-limiter",
+   "kind": "quest",
+   "title": "Rate limiter",
+   "emoji": "🚦",
+   "pillar": "Quests",
+   "builds_on": [
+    1,
+    2,
+    5,
+    6
+   ],
+   "blurb": "Cap how often each client can call an API (application programming interface). Requirements, numbers, the interface, the design, deep dives.",
+   "boss": "rl-boss",
+   "challenges": [
+    {
+     "id": "rl-01",
+     "type": "sprint",
+     "bloom": "create",
+     "minutes": 10,
+     "prompt": "Requirements for a rate limiter (a shared check that caps how many requests each client can make to an API in a period of time). Out loud, against the clock: read it back, who uses it and what they do, your three hard parts, how busy (with the peak), what can't break, what's out.",
+     "checks": [
+      "Read the problem back in one line",
+      "Named both users: clients calling the API, and the teams who set the limits",
+      "Picked my own three hard parts, such as counting across many servers, adding almost no delay, and surviving a counter outage",
+      "Asked for the scale and the peak: requests a second, how many clients, how many rules",
+      "Said what can't break, such as the limiter never taking the API down with it",
+      "Said \"I'll assume…\" for scope, instead of asking \"do you want…?\"",
+      "Said what's out of scope, such as billing quotas or blocking network-level floods",
+      "Finished inside the time"
+     ],
+     "explain": "A rate limiter sits on every request's path, so the first quarter should settle who is limited, by which key, how strict the count must be and how busy the API gets. The hard parts follow: shared counts, speed and staying up. If a check missed, rehearse that line before the next round. Say: \"I'll assume limits per user or API key, checked on every request, with counts shared across servers.\"",
+     "source": "https://www.hellointerview.com/learn/system-design/problem-breakdowns/distributed-rate-limiter"
+    },
+    {
+     "id": "rl-02",
+     "type": "estimate",
+     "bloom": "apply",
+     "prompt": "A public API, and every call passes through the rate limiter first. Estimate the busiest second the limiter must check.",
+     "generator": {
+      "kind": "peak_rps",
+      "params": {
+       "users": [
+        1000000,
+        100000000
+       ],
+       "actions": [
+        10,
+        100
+       ]
+      }
+     },
+     "explain": "Calls a day, divided by about 100,000 seconds, times 10 for the peak. Every call costs at least one counter update, so this number sizes the counter store: one Redis node handles very roughly 100,000 simple operations a second, so a big answer means splitting keys across several nodes. Say: \"That many checks a second at the peak, so I'll spread the counters across nodes by key.\"",
+     "source": "https://www.hellointerview.com/learn/system-design/problem-breakdowns/distributed-rate-limiter"
+    },
+    {
+     "id": "rl-03",
+     "type": "write",
+     "bloom": "apply",
+     "prompt": "Name the core entities, then sketch the limiter's interface: what a server asks it on each request, and what the client sees when it's over the limit.",
+     "key_points": [
+      "Entities: a rule (whom it covers, the limit, the window or refill rate) and each key's current count or bucket",
+      "One check per request: given a key and a rule, return allowed or not, what's left and when it resets",
+      "The key names the client: a user ID, an API key, an IP address or a tenant",
+      "Over the limit: status 429 Too Many Requests, with a Retry-After header saying how many seconds to wait",
+      "Headers on every response give the limit, what's left and the reset time, so clients can slow down early",
+      "Rules sit in config that each server caches in memory, never read from a database per request"
+     ],
+     "model": "Entities: Rule (key type, limit, window or refill rate) and Counter (a key's current count or token bucket). Internally, check(key, rule) returns allowed, remaining and reset time. Allowed responses carry headers with the limit, what's left and the reset time, such as X-RateLimit-Remaining. Rejected ones get 429 Too Many Requests with Retry-After: 30 and the same headers; the service behind never sees them.",
+     "explain": "The limiter answers one question per request, so its interface is tiny: is this key allowed, and how much is left? The client's side matters more: a clear 429 and a Retry-After stop well-behaved clients retrying in a tight loop and making the overload worse. Say: \"One check per request; over the limit, 429 with Retry-After and the remaining-quota headers.\"",
+     "source": "https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/429"
+    },
+    {
+     "id": "rl-04",
+     "type": "fill",
+     "bloom": "apply",
+     "prompt": "Land the design end to end. Drag each part into its box: where the check happens before any real work, where counts are shared across servers, and where the limits are defined.",
+     "diagram": {
+      "width": 640,
+      "height": 300,
+      "nodes": [
+       {
+        "id": "clients",
+        "label": "Clients",
+        "x": 10,
+        "y": 126
+       },
+       {
+        "id": "s-gateway",
+        "label": "?",
+        "x": 230,
+        "y": 126
+       },
+       {
+        "id": "s-counters",
+        "label": "?",
+        "x": 450,
+        "y": 10
+       },
+       {
+        "id": "s-rules",
+        "label": "?",
+        "x": 450,
+        "y": 242
+       },
+       {
+        "id": "services",
+        "label": "API services",
+        "x": 510,
+        "y": 126
+       }
+      ],
+      "edges": [
+       [
+        "clients",
+        "s-gateway",
+        "every request"
+       ],
+       [
+        "s-gateway",
+        "services",
+        "allowed"
+       ],
+       [
+        "s-gateway",
+        "s-counters",
+        "count per key"
+       ],
+       [
+        "s-rules",
+        "s-gateway",
+        "limits"
+       ]
+      ]
+     },
+     "slots": {
+      "s-gateway": "API gateway with the limiter",
+      "s-counters": "Redis: a counter per key",
+      "s-rules": "Rules config, cached locally"
+     },
+     "palette": [
+      "API gateway with the limiter",
+      "Redis: a counter per key",
+      "Rules config, cached locally",
+      "Database table: a row per request",
+      "Message queue",
+      "Search index"
+     ],
+     "explain": "The check runs at the front door, in the API gateway, so a rejected request costs a millisecond and never reaches the expensive services. Counts live in Redis because many gateway servers see the same client; each server keeps the rules in memory and refreshes them now and then. Say: \"The gateway checks a shared Redis counter per key, with rules cached locally, and rejects before any real work.\"",
+     "source": "https://www.hellointerview.com/learn/system-design/problem-breakdowns/distributed-rate-limiter"
+    },
+    {
+     "id": "rl-05",
+     "type": "duel",
+     "bloom": "evaluate",
+     "prompt": "Deep dive: ten gateway servers share a Redis counter per API key. Each one reads the count, compares it with the limit, then writes count + 1. Under load, clients get past their limit. What do you change?",
+     "choices": [
+      "Check and count in one atomic step: INCR, or a Lua script",
+      "Keep a separate counter in each gateway's memory",
+      "Wrap each check in a distributed lock on the key"
+     ],
+     "correct": 0,
+     "reasons": [
+      "Redis runs one command or script at a time, so no other server can slip in between",
+      "A Lua script is faster than any single command",
+      "Atomic steps stop the key from ever expiring"
+     ],
+     "reason": 0,
+     "costs": [
+      "Logic moves into Redis scripts, and a slow script holds up every other check",
+      "Each check needs two network round trips instead of one",
+      "Counts reset whenever a gateway restarts"
+     ],
+     "cost": 0,
+     "explain": "Read, compare, write is three steps, so two servers can both read 99 and both let a request through. A single INCR (set its EXPIRE in the same transaction) or a Lua script makes Redis take the whole decision as one step. A lock adds round trips, and local counters each see only a tenth of the traffic. Say: \"Check and count atomically in Redis, in one script per request.\"",
+     "source": "https://redis.io/docs/latest/commands/incr/"
+    },
+    {
+     "id": "rl-06",
+     "type": "multi",
+     "bloom": "analyse",
+     "prompt": "Deep dive: every request waits on the counter store, and the API runs in three regions. Which of these keep the limiter fast and available?",
+     "options": [
+      "Spread counters across Redis nodes by a hash of the key",
+      "Give each node a replica that takes over when it fails",
+      "Count within each region, accepting a small overshoot of the global limit",
+      "Decide per API whether to let requests through or block them when Redis is down",
+      "Send every check to one Redis in a single home region",
+      "Retry each check until Redis answers, however long that takes",
+      "Record every request as a row in the main database"
+     ],
+     "correct": [
+      0,
+      1,
+      2,
+      3
+     ],
+     "explain": "Hashing keys spreads the load, and a replica covers a failure. A cross-ocean check adds tens of milliseconds, so count per region. Failing open (letting requests through) keeps the API up; failing closed guards a fragile backend or a login limit. Endless retries or a row per request turn the limiter into the outage. Say: \"Shard by key, replicate, count per region, fail open or closed per API.\"",
+     "source": "https://www.hellointerview.com/learn/system-design/problem-breakdowns/distributed-rate-limiter"
+    },
+    {
+     "id": "rl-boss",
+     "type": "duel",
+     "bloom": "evaluate",
+     "prompt": "Deep dive: pick the algorithm. Each API key gets 100 requests a minute. Short bursts are fine, but nobody should get 200 through in a few seconds, and the counter store holds millions of keys.",
+     "choices": [
+      "Token bucket: holds 100 tokens, refilled at about 1.7 a second",
+      "Fixed window: one counter per key for each clock minute",
+      "Sliding-window log: a timestamp stored for every request"
+     ],
+     "correct": 0,
+     "reasons": [
+      "It allows a burst up to the bucket's size, then holds the average to the refill rate",
+      "It is exact to the millisecond, like a log",
+      "It needs no state shared between servers"
+     ],
+     "reason": 0,
+     "costs": [
+      "Two settings to tune, and tokens plus a timestamp updated together in one script",
+      "Memory for a timestamp per request",
+      "Up to twice the limit around each window boundary"
+     ],
+     "cost": 0,
+     "explain": "A fixed window lets 100 through just before the minute turns and 100 just after: double the limit in two seconds. A log is exact but keeps up to 100 timestamps per key, for millions of keys. A token bucket keeps two numbers, takes a burst up to its size and holds to the refill rate. A sliding-window counter is the other cheap pick. Say: \"Token bucket: bursts up to 100, then about 1.7 a second.\"",
+     "source": "https://www.hellointerview.com/learn/system-design/problem-breakdowns/distributed-rate-limiter"
+    }
+   ]
+  },
+  {
+   "chapter": 11,
+   "slug": "file-sync",
+   "kind": "quest",
+   "title": "File storage and sync (like Dropbox)",
+   "emoji": "📁",
+   "pillar": "Quests",
+   "builds_on": [
+    1,
+    3,
+    4,
+    8
+   ],
+   "blurb": "Keep every device's files in step. Requirements, numbers, API, the design, then the deep dives: big uploads, sync and clashing edits.",
+   "boss": "fs-boss",
+   "challenges": [
+    {
+     "id": "fs-01",
+     "type": "sprint",
+     "bloom": "create",
+     "minutes": 10,
+     "prompt": "Requirements for a file storage and sync service (people save files in a folder that matches on every device, and share some). Out loud, against the clock: read it back, who uses it and what they do, your three hard parts, how busy (with the peak), what can't break, what's out.",
+     "checks": [
+      "Read the problem back in one line",
+      "Named the users and what they do: save, edit offline, see changes on other devices, share",
+      "Picked my own three hard parts, such as big uploads, fast sync across devices, and offline edits that clash",
+      "Sized it: users, files a day, typical and largest file size, and the peak",
+      "Said what can't break: a saved file is never lost or silently overwritten",
+      "Said \"I'll assume…\" for scope, instead of asking \"do you want…?\"",
+      "Said what's out of scope, such as editing inside the browser or searching file contents",
+      "Finished inside the time"
+     ],
+     "explain": "This product turns on three things: big files, many devices and edits made while offline. Say early what can't break: a saved file is never lost or silently overwritten, while a few seconds' delay before another device sees it is fine. If a check missed, rehearse that line before the next round. Say: \"Never lose a file; sync within seconds is good enough.\"",
+     "source": "https://www.hellointerview.com/learn/system-design/problem-breakdowns/dropbox"
+    },
+    {
+     "id": "fs-02",
+     "type": "estimate",
+     "bloom": "apply",
+     "prompt": "At the peak, devices download changed file chunks of a few MB each. Estimate the outbound bandwidth. (KB, MB and GB are kilobytes, megabytes and gigabytes; each is 1,000 times the last.)",
+     "generator": {
+      "kind": "bandwidth",
+      "params": {
+       "rps": [
+        500,
+        20000
+       ],
+       "kb": [
+        1000,
+        5000
+       ]
+      }
+     },
+     "explain": "Responses a second times the size of each, then divide by 1,000 to turn KB into MB. Thousands of multi-MB chunks a second come to many GB a second, too much for app servers to carry. The bytes come from object storage through a CDN (content delivery network) on signed links, and app servers handle only small metadata calls. Say: \"Bytes from storage and the CDN; the app tier moves metadata.\"",
+     "source": "https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-presigned-url.html"
+    },
+    {
+     "id": "fs-03",
+     "type": "write",
+     "bloom": "apply",
+     "prompt": "Name the core entities, then sketch the API (application programming interface): start an upload, get upload links, commit it, list changes since a cursor, and download a file.",
+     "key_points": [
+      "Entities: file (path, owner), version (number, base version, ordered chunk hashes), chunk (hash, size) and device",
+      "POST /uploads with the path, base version and chunk hashes; returns an upload ID (identifier)",
+      "It also returns presigned URLs (signed, short-lived web addresses), one per chunk storage lacks",
+      "POST /uploads/{id}/commit makes the new version live only once every chunk is stored",
+      "GET /changes?cursor=… returns what changed since then, plus the next cursor to save",
+      "GET /files/{id} returns metadata and short-lived download links; the user comes from the token"
+     ],
+     "model": "Entities: File (ID, owner, path, current version), Version (file, number, base version, chunk hashes in order), Chunk (hash, size) and Device. POST /uploads takes the path, base version and chunk hashes; it returns an upload ID and presigned URLs for the chunks storage lacks. POST /uploads/{id}/commit creates the version once every chunk is there. GET /changes?cursor=c returns changes and the next cursor. GET /files/{id} returns metadata and download links.",
+     "explain": "Start, send, then commit keeps big bytes off your servers and stops a half-sent file from ever looking finished. The changes feed with a cursor is what sync runs on, so name it early. Say: \"The API moves metadata; storage moves the bytes.\"",
+     "source": "https://www.hellointerview.com/learn/system-design/in-a-hurry/delivery"
+    },
+    {
+     "id": "fs-04",
+     "type": "fill",
+     "bloom": "apply",
+     "prompt": "Land the design end to end. Drag each part into its box: where the chunks live, the source of truth for files and versions, what serves downloads near the user, and what tells other devices to sync.",
+     "diagram": {
+      "width": 640,
+      "height": 300,
+      "nodes": [
+       {
+        "id": "apps",
+        "label": "Desktop and phone apps",
+        "x": 10,
+        "y": 126
+       },
+       {
+        "id": "s-cdn",
+        "label": "?",
+        "x": 230,
+        "y": 10
+       },
+       {
+        "id": "s-blob",
+        "label": "?",
+        "x": 480,
+        "y": 10
+       },
+       {
+        "id": "app",
+        "label": "App servers: metadata API",
+        "x": 230,
+        "y": 126
+       },
+       {
+        "id": "s-meta",
+        "label": "?",
+        "x": 480,
+        "y": 126
+       },
+       {
+        "id": "s-notify",
+        "label": "?",
+        "x": 230,
+        "y": 242
+       }
+      ],
+      "edges": [
+       [
+        "apps",
+        "app",
+        "metadata"
+       ],
+       [
+        "apps",
+        "s-blob",
+        "upload chunks"
+       ],
+       [
+        "s-blob",
+        "s-cdn"
+       ],
+       [
+        "s-cdn",
+        "apps",
+        "download"
+       ],
+       [
+        "app",
+        "s-meta",
+        "files, versions"
+       ],
+       [
+        "app",
+        "s-notify"
+       ],
+       [
+        "s-notify",
+        "apps",
+        "nudge"
+       ]
+      ]
+     },
+     "slots": {
+      "s-blob": "Object storage: chunks",
+      "s-meta": "Metadata database",
+      "s-cdn": "CDN",
+      "s-notify": "Notification service"
+     },
+     "palette": [
+      "Object storage: chunks",
+      "Metadata database",
+      "CDN",
+      "Notification service",
+      "Database: file bytes as blobs",
+      "Nightly sync job",
+      "Search index"
+     ],
+     "explain": "Chunks go up to object storage on presigned URLs and come back through the CDN, so app servers handle only small metadata calls. The metadata database records files, versions and chunk lists: it is the truth sync reads. A notification service nudges other devices to ask what changed. Bytes bloat a database; a nightly job is too slow. Say: \"Bytes to storage, truth in metadata, a nudge to sync.\"",
+     "source": "https://www.hellointerview.com/learn/system-design/problem-breakdowns/dropbox"
+    },
+    {
+     "id": "fs-05",
+     "type": "duel",
+     "bloom": "evaluate",
+     "prompt": "A laptop and a phone both edit the same document offline, each starting from version 7. The laptop syncs first and makes version 8. Then the phone syncs. What happens to the phone's edit?",
+     "choices": [
+      "Keep both: save it as a conflicted copy next to the file",
+      "Last write wins: it replaces version 8",
+      "Merge the two versions' bytes automatically",
+      "Reject it and drop the phone's changes"
+     ],
+     "correct": 0,
+     "reasons": [
+      "The phone's commit was based on version 7, so the server can see both devices changed it",
+      "Conflicted copies take less storage",
+      "The later edit is always the one the person wanted",
+      "Any two files can be merged byte by byte"
+     ],
+     "reason": 0,
+     "costs": [
+      "The person compares the two copies and tidies up by hand",
+      "Every edit needs a lock from the server first",
+      "One device's work is silently lost"
+     ],
+     "cost": 0,
+     "explain": "Each commit names the version it started from. If the file has moved on since, both devices changed it: replacing one silently loses work, and an arbitrary file's bytes can't be merged safely. A conflicted copy loses nothing, and the person merges them. Locks fail when devices are offline. Say: \"Commit against a base version; on a clash, keep both.\"",
+     "source": "https://en.wikipedia.org/wiki/File_synchronization"
+    },
+    {
+     "id": "fs-06",
+     "type": "multi",
+     "bloom": "analyse",
+     "prompt": "A small part of a 1 GB file changes on a laptop. The phone should show it within seconds, without wasting data or requests. Which of these help?",
+     "options": [
+      "Upload only the chunks whose hashes changed",
+      "Skip any chunk whose hash storage already holds",
+      "The phone asks for every change since its saved cursor",
+      "A long poll or WebSocket nudge tells the phone when to ask",
+      "Re-upload the whole file, compressed",
+      "The phone lists the whole folder every second",
+      "Send the file's bytes inside the nudge",
+      "Compare each file's modified time with the phone's clock"
+     ],
+     "correct": [
+      0,
+      1,
+      2,
+      3
+     ],
+     "explain": "Chunk hashes show what changed, and skipping hashes storage already holds removes duplicates, so a small edit moves a few MB, not 1 GB. The metadata database logs changes in order; the phone keeps a cursor into that log, and a nudge says when to read it. Polling wastes requests, nudges should stay small, and device clocks drift. Say: \"Changed chunks up, a nudge, then changes since my cursor.\"",
+     "source": "https://www.hellointerview.com/learn/system-design/problem-breakdowns/dropbox"
+    },
+    {
+     "id": "fs-boss",
+     "type": "flaw",
+     "bloom": "evaluate",
+     "prompt": "Big uploads on patchy Wi-Fi fail near the end and start again from zero, and the app servers slow down whenever people upload. Find the box to change, then pick the fix.",
+     "diagram": {
+      "width": 640,
+      "height": 300,
+      "nodes": [
+       {
+        "id": "apps",
+        "label": "Desktop and phone apps",
+        "x": 10,
+        "y": 126
+       },
+       {
+        "id": "cdn",
+        "label": "CDN",
+        "x": 230,
+        "y": 10
+       },
+       {
+        "id": "storage",
+        "label": "Object storage",
+        "x": 480,
+        "y": 10
+       },
+       {
+        "id": "app",
+        "label": "App servers",
+        "x": 230,
+        "y": 126
+       },
+       {
+        "id": "meta",
+        "label": "Metadata database",
+        "x": 480,
+        "y": 126
+       },
+       {
+        "id": "notify",
+        "label": "Notification service",
+        "x": 230,
+        "y": 242
+       }
+      ],
+      "edges": [
+       [
+        "apps",
+        "app",
+        "whole file"
+       ],
+       [
+        "app",
+        "storage",
+        "write file"
+       ],
+       [
+        "storage",
+        "cdn"
+       ],
+       [
+        "cdn",
+        "apps",
+        "download"
+       ],
+       [
+        "app",
+        "meta",
+        "versions"
+       ],
+       [
+        "app",
+        "notify"
+       ],
+       [
+        "notify",
+        "apps",
+        "nudge"
+       ]
+      ]
+     },
+     "flaw": "app",
+     "fixes": [
+      "Chunk files; send missing chunks straight to storage on presigned URLs, then commit",
+      "Add more app servers and raise the upload timeout",
+      "Compress each file before it's sent",
+      "Save the files in the metadata database instead"
+     ],
+     "fix": 0,
+     "explain": "Relaying every byte through app servers ties them up for minutes per upload, and one dropped connection loses the whole file. Split files into chunks of a few MB: the server hands out presigned URLs only for chunks storage lacks, the app sends them straight there and retries just a failed one, then a commit makes the version live. Say: \"Chunks straight to storage, resume per chunk, then commit.\"",
+     "source": "https://docs.aws.amazon.com/AmazonS3/latest/userguide/mpuoverview.html"
+    }
+   ]
+  },
+  {
+   "chapter": 12,
+   "slug": "nearby-places",
+   "kind": "quest",
+   "title": "Nearby places (like Yelp)",
+   "emoji": "📍",
+   "pillar": "Quests",
+   "builds_on": [
+    1,
+    4,
+    5,
+    8
+   ],
+   "blurb": "Find good places near you by distance, type and words, and post reviews. Requirements, numbers, endpoints, the design, then the deep dives.",
+   "boss": "np-boss",
+   "challenges": [
+    {
+     "id": "np-01",
+     "type": "sprint",
+     "bloom": "create",
+     "minutes": 10,
+     "prompt": "Requirements for a nearby-places app (people find businesses near them by distance, type and words, read ratings and post reviews). Out loud, against the clock: read it back, who uses it and what they do, your three hard parts, how busy (with the peak), what can't break, what's out.",
+     "checks": [
+      "Read the problem back in one line",
+      "Named who uses it: people searching nearby, people posting reviews, and owners keeping a place's details current",
+      "Picked my own three hard parts, such as fast search by distance and words, ratings that stay current, and one review per person",
+      "Asked for the scale and the peak, and said searches will far outnumber reviews",
+      "Said what can't break: search stays fast and up, and a posted review is never lost; results may lag a little",
+      "Said \"I'll assume…\" for scope, instead of asking \"do you want…?\"",
+      "Said what's out of scope, such as bookings, photos or personalised ranking",
+      "Finished inside the time"
+     ],
+     "explain": "The first quarter shapes everything after it. Searches dwarf reviews and places hardly ever move, so the design leans on an index built for reading and on caching. Name that ratio out loud with your numbers. If a check missed, rehearse that line before the next round. Say: \"Read-heavy: searches dwarf reviews, and places rarely change.\"",
+     "source": "https://www.hellointerview.com/learn/system-design/problem-breakdowns/yelp"
+    },
+    {
+     "id": "np-02",
+     "type": "estimate",
+     "bloom": "apply",
+     "prompt": "Searches on a popular nearby-places app. Estimate the busiest second.",
+     "generator": {
+      "kind": "peak_rps",
+      "params": {
+       "users": [
+        5000000,
+        50000000
+       ],
+       "actions": [
+        2,
+        10
+       ]
+      }
+     },
+     "explain": "Searches a day, divided by about 100,000 seconds, times 10 for the peak. Reviews are a small share of that and places barely change, so this number sizes the search index, the cache and the servers, not the database's writes. Round hard and say the working aloud. Say: \"Searches over 100,000, times ten: that's the peak, and nearly all of it is reads.\"",
+     "source": "https://www.hellointerview.com/learn/system-design/in-a-hurry/core-concepts"
+    },
+    {
+     "id": "np-03",
+     "type": "write",
+     "bloom": "apply",
+     "prompt": "Name the core entities, then sketch the API (application programming interface): search near a point by radius, category and words, with paging; get a place's details; post a review.",
+     "key_points": [
+      "Entities: a place (name, location, category, average rating, review count), a review (place, user, stars, text) and a user",
+      "GET /places/search with latitude, longitude, radius, category, words, a limit and a cursor; returns a page and the next cursor",
+      "GET /places/{id} returns the details, the rating and the latest reviews",
+      "POST /places/{id}/reviews with stars and text; the user comes from the token",
+      "One review per user per place, enforced by the database; a second one returns 409 Conflict",
+      "Results page with a cursor, so deep pages stay cheap and nothing repeats"
+     ],
+     "model": "Entities: Place (id, name, location, category, average rating, review count), Review (place, user, stars, text, created at) and User. GET /places/search?lat=&lng=&radius=&category=&q=&limit=20&cursor= returns a page of places and nextCursor. GET /places/{id} returns the details, the rating and recent reviews. POST /places/{id}/reviews takes stars and text; the user comes from the token, and a second review of the same place returns 409.",
+     "explain": "Three verbs carry this product, and one of them is nearly all the traffic: search. Put every filter on that one endpoint and page it with a cursor, so a long scroll stays cheap. Keep the rating on the place, so a search never adds up reviews. Say: \"Entities first; search is the hot endpoint, and reviews are the rare write.\"",
+     "source": "https://www.hellointerview.com/learn/system-design/core-concepts/api-design"
+    },
+    {
+     "id": "np-04",
+     "type": "fill",
+     "bloom": "apply",
+     "prompt": "Land the design end to end. Drag each part into its box: what answers \"near here\" with filters, the source of truth, how those two stay in step, and what saves repeat work in busy areas.",
+     "diagram": {
+      "width": 640,
+      "height": 300,
+      "nodes": [
+       {
+        "id": "apps",
+        "label": "Mobile and web apps",
+        "x": 10,
+        "y": 126
+       },
+       {
+        "id": "search",
+        "label": "Search service",
+        "x": 160,
+        "y": 40
+       },
+       {
+        "id": "writes",
+        "label": "Place and review service",
+        "x": 160,
+        "y": 212
+       },
+       {
+        "id": "s-cache",
+        "label": "?",
+        "x": 380,
+        "y": 10
+       },
+       {
+        "id": "s-index",
+        "label": "?",
+        "x": 380,
+        "y": 126
+       },
+       {
+        "id": "s-db",
+        "label": "?",
+        "x": 330,
+        "y": 242
+       },
+       {
+        "id": "s-feed",
+        "label": "?",
+        "x": 510,
+        "y": 242
+       }
+      ],
+      "edges": [
+       [
+        "apps",
+        "search"
+       ],
+       [
+        "apps",
+        "writes"
+       ],
+       [
+        "search",
+        "s-cache",
+        "by cell"
+       ],
+       [
+        "search",
+        "s-index",
+        "on a miss"
+       ],
+       [
+        "writes",
+        "s-db",
+        "save"
+       ],
+       [
+        "s-db",
+        "s-feed"
+       ],
+       [
+        "s-feed",
+        "s-index"
+       ]
+      ]
+     },
+     "slots": {
+      "s-cache": "Cache of results by cell",
+      "s-index": "Geo search index",
+      "s-db": "Database: places, reviews",
+      "s-feed": "Change data capture"
+     },
+     "palette": [
+      "Cache of results by cell",
+      "Geo search index",
+      "Database: places, reviews",
+      "Change data capture",
+      "WebSocket server",
+      "Graph database",
+      "Blob storage"
+     ],
+     "explain": "Search checks a cache keyed by cell and filters, and on a miss asks the geo search index, which applies distance, category and words in one query. The database is the truth for places and reviews; change data capture (CDC) streams each change into the index. Say: \"The database is the truth, a change feed keeps the geo index current, and busy cells are cached.\"",
+     "source": "https://www.hellointerview.com/learn/system-design/deep-dives/elasticsearch"
+    },
+    {
+     "id": "np-05",
+     "type": "duel",
+     "bloom": "evaluate",
+     "prompt": "Deep dive: say a city-centre square kilometre holds 5,000 places, while a 20 km square in the hills holds a dozen. You want every search to read a similar, small number of places. How do you divide the map into cells?",
+     "choices": [
+      "A quadtree: split any cell holding more than about 100 places into four",
+      "Equal cells everywhere, sized for the city centre",
+      "Equal cells everywhere, sized for the countryside"
+     ],
+     "correct": 0,
+     "reasons": [
+      "Cells shrink where places crowd together and stay large where they're sparse",
+      "Equal cells make every search read the same number of places",
+      "Small cells mean a search never needs the cells around it"
+     ],
+     "reason": 0,
+     "costs": [
+      "More to build and keep current: cells split as places are added",
+      "Every search has to read every place in the city",
+      "Results can no longer be sorted by distance"
+     ],
+     "cost": 0,
+     "explain": "Equal cells sized for the centre make a countryside search open many near-empty cells; sized for the countryside, one city cell holds thousands. A quadtree splits only crowded cells, so no leaf holds more than a set number. Either way, read the user's cell and its neighbours, then keep places within the exact distance. Say: \"Quadtree for uneven density; cell plus neighbours, then exact distance.\"",
+     "source": "https://en.wikipedia.org/wiki/Quadtree"
+    },
+    {
+     "id": "np-06",
+     "type": "multi",
+     "bloom": "analyse",
+     "prompt": "Deep dive: someone posts a review, and that place's rating shows on every search result it appears in. Each person may review a place only once. Which of these belong in the design?",
+     "options": [
+      "A unique constraint on user and place together, so a second review is refused",
+      "A review count and star total on the place, updated in the same transaction",
+      "An edit swaps the old stars for the new ones in the place's total",
+      "Average all of a place's reviews each time it appears in a search",
+      "Check in code for an earlier review, then insert, with no constraint",
+      "Let the app send the place's new average along with the review"
+     ],
+     "correct": [
+      0,
+      1,
+      2
+     ],
+     "explain": "Two requests from one user at once can both pass a check-then-insert, so only a unique constraint truly stops a second review. A count and a total on the place, changed with the review, make each rating on a results page one read; a burst on one place can be folded in small batches. Never trust a sum sent by the app. Say: \"Unique on user and place; the rating is precomputed on write.\"",
+     "source": "https://www.postgresql.org/docs/current/ddl-constraints.html"
+    },
+    {
+     "id": "np-boss",
+     "type": "duel",
+     "bloom": "evaluate",
+     "prompt": "Deep dive: how does search answer \"vegan brunch, cafés, within 2 km\" across 10 million places, fast, with distance, category and words all applied?",
+     "choices": [
+      "A search index with geo queries, such as Elasticsearch, fed from the database",
+      "The places table, with separate latitude and longitude indexes, and LIKE for words",
+      "Load every place into each server's memory and measure the distance to each"
+     ],
+     "correct": 0,
+     "reasons": [
+      "One query narrows by area, category and words together, touching only nearby matches",
+      "Two separate indexes together pick out a circle on the map",
+      "Places rarely change, so measuring all of them is cheap"
+     ],
+     "reason": 0,
+     "costs": [
+      "A second copy of the data to keep in step, so changes appear after a short lag",
+      "Every search reads every place on Earth",
+      "Results can no longer be sorted by rating"
+     ],
+     "cost": 0,
+     "explain": "Separate latitude and longitude indexes each match a strip across the whole map, and LIKE with a leading wildcard can't use a normal index, so both read far too many rows. A geo search index applies distance, category and words in one query, kept in step by CDC. PostGIS with full-text search does the same inside PostgreSQL. Say: \"A geo search index fed by the database: one query, every filter.\"",
+     "source": "https://www.hellointerview.com/learn/system-design/deep-dives/elasticsearch"
+    }
+   ]
+  },
+  {
+   "chapter": 13,
+   "slug": "ride-booking",
+   "kind": "quest",
+   "title": "Ride booking (like Uber)",
+   "emoji": "🚗",
+   "pillar": "Quests",
+   "builds_on": [
+    1,
+    3,
+    6,
+    8
+   ],
+   "blurb": "Pair riders with nearby drivers in seconds. Requirements, numbers, entities and calls, the design, then live location, surge pricing and one-to-one matching.",
+   "boss": "rb-boss",
+   "challenges": [
+    {
+     "id": "rb-01",
+     "type": "sprint",
+     "bloom": "create",
+     "minutes": 10,
+     "prompt": "Requirements for a ride-booking app (a rider asks for a car, a nearby driver accepts, and both follow the trip live). Out loud, against the clock: read it back, both kinds of user and what they do, your three hard parts, how busy (with the peak), what can't break, what's out.",
+     "checks": [
+      "Read the problem back in one line",
+      "Named both users: riders who get a price, book and track a ride, and drivers who go online, accept and drive",
+      "Picked my own three hard parts, such as constant location updates, one-to-one matching, and rush-hour peaks",
+      "Gave the scale and the peak: drivers online, a ping every few seconds, rush hour and big events",
+      "Said what can't break: one driver per ride, one ride per driver, and the rider charged once",
+      "Said \"I'll assume…\" for scope, instead of asking \"do you want…?\"",
+      "Said what's out of scope, such as shared rides, booking ahead or signing drivers up",
+      "Finished inside the time"
+     ],
+     "explain": "Ride booking has two live sides: drivers report their position all the time, and riders expect a match within seconds. Naming that early, with peaks by area and time, sets up every later choice. Correctness lives in matching and payment, so say those out loud. If a check missed, rehearse that line before the next round. Say: \"Two live sides, constant location, and one driver per ride.\"",
+     "source": "https://www.hellointerview.com/learn/system-design/problem-breakdowns/uber"
+    },
+    {
+     "id": "rb-02",
+     "type": "estimate",
+     "bloom": "apply",
+     "prompt": "Drivers' phones send their location every few seconds through a shift. Estimate the location writes a second at the peak, then say whether one database copes.",
+     "generator": {
+      "kind": "shard_or_not",
+      "params": {
+       "users": [
+        100000,
+        2000000
+       ],
+       "writes": [
+        2000,
+        10000
+       ]
+      }
+     },
+     "explain": "Drivers × pings a day, divided by about 100,000 seconds, times 10 for the peak. A ping every 5 seconds over 8 hours is about 5,760 a day, so even 100,000 drivers pass 10,000 writes a second at the peak. Each point is stale seconds later, so don't keep every ping: hold each driver's latest point in memory, split by area. Say: \"Hot, short-lived writes, so memory, not the main database.\"",
+     "source": "https://www.hellointerview.com/learn/system-design/problem-breakdowns/uber"
+    },
+    {
+     "id": "rb-03",
+     "type": "write",
+     "bloom": "apply",
+     "prompt": "Name the core entities, then sketch the application programming interface (API): get a fare estimate, request a ride, send a driver's location, accept or decline an offer, and follow the ride's status.",
+     "key_points": [
+      "Entities: rider, driver, ride (pickup, drop-off, fare, driver, status) and each driver's latest location",
+      "POST /fares with pickup and drop-off returns a price and a quote ID that expires after a few minutes",
+      "POST /rides with the quote ID creates the ride as requested and starts matching",
+      "POST /drivers/location every few seconds; POST /rides/{id}/accept or /decline answers an offer",
+      "GET /rides/{id} gives the status, and changes are pushed over a WebSocket or server-sent events (SSE)",
+      "Rider and driver come from the token, never the request body"
+     ],
+     "model": "Entities: Rider, Driver, Ride (pickup, drop-off, quote, driver, status) and Location (driver, point, time). POST /fares returns a price and a quote ID. POST /rides with that ID creates a requested ride. The driver's app sends POST /drivers/location every few seconds and answers offers with POST /rides/{id}/accept or /decline. GET /rides/{id} returns the status, also pushed live. Rider and driver come from the token.",
+     "explain": "Five calls carry the product. Name the ride's states early: requested, matched, driver arriving, in progress, then completed or cancelled. Payment runs once, on completed, with the ride ID as an idempotency key so a retry can't charge twice. Taking the person from the token stops one user acting as another. Say: \"Entities first; the ride's status is a state machine.\"",
+     "source": "https://www.hellointerview.com/learn/system-design/problem-breakdowns/uber"
+    },
+    {
+     "id": "rb-04",
+     "type": "fill",
+     "bloom": "apply",
+     "prompt": "Land the design end to end. Drag each part into its box: what pairs riders with drivers, where drivers' latest positions live, the record of every ride, and how the rider's screen stays current.",
+     "diagram": {
+      "width": 640,
+      "height": 300,
+      "nodes": [
+       {
+        "id": "driver",
+        "label": "Driver app",
+        "x": 10,
+        "y": 20
+       },
+       {
+        "id": "loc",
+        "label": "Location service",
+        "x": 260,
+        "y": 20
+       },
+       {
+        "id": "s-geo",
+        "label": "?",
+        "x": 510,
+        "y": 126
+       },
+       {
+        "id": "rider",
+        "label": "Rider app",
+        "x": 10,
+        "y": 126
+       },
+       {
+        "id": "s-match",
+        "label": "?",
+        "x": 260,
+        "y": 126
+       },
+       {
+        "id": "s-live",
+        "label": "?",
+        "x": 10,
+        "y": 232
+       },
+       {
+        "id": "s-db",
+        "label": "?",
+        "x": 260,
+        "y": 232
+       }
+      ],
+      "edges": [
+       [
+        "driver",
+        "loc",
+        "ping"
+       ],
+       [
+        "loc",
+        "s-geo",
+        "latest point"
+       ],
+       [
+        "rider",
+        "s-match",
+        "request ride"
+       ],
+       [
+        "s-match",
+        "s-geo",
+        "nearest free"
+       ],
+       [
+        "s-match",
+        "driver",
+        "offer"
+       ],
+       [
+        "s-match",
+        "s-db"
+       ],
+       [
+        "s-match",
+        "s-live",
+        "status change"
+       ],
+       [
+        "s-live",
+        "rider"
+       ]
+      ]
+     },
+     "slots": {
+      "s-match": "Matching service",
+      "s-geo": "In-memory geo index",
+      "s-db": "Rides database",
+      "s-live": "Live updates (WebSocket or SSE)"
+     },
+     "palette": [
+      "Matching service",
+      "In-memory geo index",
+      "Rides database",
+      "Live updates (WebSocket or SSE)",
+      "Message queue",
+      "Data warehouse",
+      "Content delivery network"
+     ],
+     "explain": "Pings overwrite each driver's latest point in an in-memory geo index. The matching service asks it for the nearest free drivers, offers the ride to one, and keeps the ride and its state in the database. Status changes go out over a live channel, so the rider app never polls. Give each box its reason as you place it. Say: \"Location, matching, the ride record, live status.\"",
+     "source": "https://www.hellointerview.com/learn/system-design/problem-breakdowns/uber"
+    },
+    {
+     "id": "rb-05",
+     "type": "duel",
+     "bloom": "evaluate",
+     "prompt": "Rush hour, and a concert has just ended: in one district, riders outnumber free drivers ten to one. Every fare quote must show that area's current surge multiplier. How do you produce it?",
+     "choices": [
+      "A job recomputes each area's multiplier every minute; quotes read it from a cache",
+      "Count riders and free drivers in the area on every quote",
+      "Set one multiplier per city each morning"
+     ],
+     "correct": 0,
+     "reasons": [
+      "A quote becomes one cheap lookup, however many riders ask at once",
+      "Counting on every quote costs nothing when the index is in memory",
+      "A cached multiplier is exact to the second"
+     ],
+     "reason": 0,
+     "costs": [
+      "The price trails demand by up to a minute",
+      "Each quote searches the location index, so work grows with the crowd",
+      "Riders can't see a price before booking"
+     ],
+     "cost": 0,
+     "explain": "Demand spikes by place and time, so counting supply and demand on every quote adds the most work just as the crowd arrives. Recompute each area's multiplier on a short schedule from recent requests and free drivers, and serve it as a cached read. Save it in the quote, so the rider pays the price they saw. Say: \"Surge is a precomputed read per area, refreshed every minute.\"",
+     "source": "https://en.wikipedia.org/wiki/Dynamic_pricing"
+    },
+    {
+     "id": "rb-06",
+     "type": "multi",
+     "bloom": "analyse",
+     "prompt": "Drivers worldwide send their position every few seconds, and matching asks for free drivers near each pickup. Which of these keep the location index fast and accurate?",
+     "options": [
+      "Keep only each driver's latest point, overwriting the one before",
+      "Treat a driver who hasn't pinged for about 30 seconds as gone",
+      "Split the index by area, such as city or geohash cell, each shard serving its region",
+      "Ping less often while a driver is parked, more often on the move",
+      "Insert every ping as a new row in the rides database",
+      "Cache each area's list of nearby drivers for an hour",
+      "Run one global index on a single machine"
+     ],
+     "correct": [
+      0,
+      1,
+      2,
+      3
+     ],
+     "explain": "Only the newest point matters, so overwrite it in memory and let silent drivers drop out after a short expiry. Splitting by area keeps writes and searches local. Pinging less while parked cuts writes. A cached list goes stale as drivers move, a row per ping swamps the database, and one machine can't keep up. Say: \"Latest point, in memory, split by area, with an expiry.\"",
+     "source": "https://www.hellointerview.com/learn/system-design/problem-breakdowns/uber"
+    },
+    {
+     "id": "rb-boss",
+     "type": "duel",
+     "bloom": "evaluate",
+     "prompt": "Deep dive: matching. Each driver sees one offer at a time, each ride goes to one driver at a time, and a driver has 10 seconds to answer. Many matching servers run at once. How do you make sure no driver gets two offers, and the ride keeps moving?",
+     "choices": [
+      "Lock the driver for 10 seconds before offering; on a no or a timeout, try the next nearest",
+      "Offer the ride to the five nearest drivers and take the first to accept",
+      "Check the driver's status says free, then send the offer"
+     ],
+     "correct": 0,
+     "reasons": [
+      "Taking the lock is one atomic step, so only one server wins, and it frees itself",
+      "Locks make drivers answer faster",
+      "Checking the status first is already atomic"
+     ],
+     "reason": 0,
+     "costs": [
+      "Each ignored offer costs the rider 10 seconds, and the lock store must stay up",
+      "A driver can still get two offers at once",
+      "Rides can no longer be cancelled"
+     ],
+     "cost": 0,
+     "explain": "Checking \"free\" then offering lets two servers pick the same driver. Claim the driver in one atomic step with a time limit: set a key only if none exists, expiring in 10 seconds. Accepting moves the ride from requested to matched with a conditional write, so it never gets two drivers. A no or a timeout frees the driver for the next offer. Say: \"An expiring lock per driver, one offer at a time.\"",
+     "source": "https://redis.io/docs/latest/develop/clients/patterns/distributed-locks/"
+    }
+   ]
+  }
+ ]
+}