2d:I[794258,["/_next/static/chunks/0x-9rc1bm-510.js","/_next/static/chunks/3etfgtel6aeq6.js","/_next/static/chunks/1ticq_5yu604d.js","/_next/static/chunks/0142u_sqxxm8w.js","/_next/static/chunks/0octqk8ubvx-a.js","/_next/static/chunks/1ce9xh2fw-bmg.js","/_next/static/chunks/3ybj1-ou0fggw.js","/_next/static/chunks/3z45_siy78vwo.js","/_next/static/chunks/3lwmlwojq1xa-.js","/_next/static/chunks/2xh6bmwhs1ke4.js","/_next/static/chunks/3w70e09aowp5u.js","/_next/static/chunks/31brbmtstkuzf.js","/_next/static/chunks/42i78u3qkhg8i.js","/_next/static/chunks/1ncl5-a9kaaog.js","/_next/static/chunks/3ni3xxb0x447g.js","/_next/static/chunks/3piet7o7mzsqv.js","/_next/static/chunks/07g0gi84aplv5.js","/_next/static/chunks/3p1izg_t7ocza.js","/_next/static/chunks/07op-v8xujpem.js","/_next/static/chunks/2pz2-gapwg66o.js","/_next/static/chunks/2fc7re305r2wf.js","/_next/static/chunks/2dy-8et9gm53v.js"],"AnonLessonPage"] 2e:T46f1,This course gets you ready for software engineering interviews. It covers data structures and algorithms, system design (both the foundations and full case studies), low-level design, backend engineering, frontend engineering, and behavioral interviews. This lesson tells you what is in each part, how they fit together, and how to actually study them so the material sticks. ## What this course covers You have seven subjects to work through: - **Data Structures & Algorithms (DSA):** the coding-interview patterns, from arrays to dynamic programming, plus practice tests and a final round of speed drills. - **System Design Foundations:** the building blocks every system design answer is made of, estimation, caching, sharding, consensus, and so on. - **System Design Case Studies:** full designs of real products, a URL shortener, a chat app, Twitter, a ride-sharing app, and more, built using the foundations. - **Low-Level Design (LLD):** object-oriented design, the classic design patterns, and building small systems like a parking lot or an elevator from scratch. - **Backend:** split into Python, Django, FastAPI, databases (PostgreSQL), systems (caching, queues, distributed systems), and APIs. - **Frontend:** JavaScript and CSS fundamentals, React internals, performance, TypeScript, and testing. - **Behavioral & Interview Day:** how to tell your work stories well, company research, and interview-day logistics. Each subject is graded with its own short tests along the way, so you always know where you stand. > **Remember:** this course is seven separate subjects. Start with whichever one you're weakest in and start there. ```knowledge-check { "questions": [ { "id": "ip45-start-overview-q1", "type": "mcq", "prompt": "How many separate subjects does this course cover?", "options": [ {"id": "a", "text": "One long combined track"}, {"id": "b", "text": "Seven subjects: DSA, System Design Foundations, System Design Case Studies, LLD, Backend, Frontend, and Behavioral"}, {"id": "c", "text": "Only DSA and System Design"}, {"id": "d", "text": "Only Backend and Frontend"} ], "correct": "b", "explanation": "The course splits into seven independent subjects so you can study whichever one you need most, in any order." } ] } ``` ## How the subjects fit together Every subject in this course stands on its own. You do not need to finish DSA before starting System Design, and you do not need to finish Backend before starting Frontend. Each subject has its own lessons, its own tests, and its own final "mock round" lesson where you practice under interview conditions. This matters because your own interview loop probably doesn't test everything. If your next interview is pure backend and behavioral, you can skip straight to those two subjects and ignore the rest for now. If you have a full loop (coding, system design, and behavioral in one day), work through all three in parallel using the plan below. Two subjects lean on each other a little: System Design Case Studies uses the vocabulary built in System Design Foundations, so it helps to have looked at Foundations first. Everything else is genuinely independent. > **Remember:** a subject you don't need for your interview is a subject you can skip. This course does not require finishing everything to be useful. ```knowledge-check { "questions": [ { "id": "ip45-start-independence-q1", "type": "mcq", "prompt": "Which pair of subjects is NOT independent, i.e. one builds on the other?", "options": [ {"id": "a", "text": "Frontend and Behavioral"}, {"id": "b", "text": "System Design Foundations and System Design Case Studies"}, {"id": "c", "text": "LLD and Backend"}, {"id": "d", "text": "DSA and Frontend"} ], "correct": "b", "explanation": "System Design Case Studies uses the vocabulary (caching, sharding, consensus, and so on) taught in System Design Foundations, so it helps to see Foundations first. Every other pair of subjects is fully independent." } ] } ``` ## A 45-day study plan You do not have to follow this plan. It's there for people who want a ready-made pace. Expect about 4 to 5 hours a day. Two tracks run side by side: one DSA lesson every morning, and one other subject in the afternoon. Your STAR stories take time to find and polish, so a small behavioral lesson runs every few days from the start instead of being crammed at the end. Lesson numbers below are positions inside each subject. | Days | Morning: DSA | Afternoon: other subjects | |---|---|---| | 1 | Start Here, Arrays and Hashing | System Design Foundations 1-2; Behavioral 1 (resume walkthrough) | | 2-6 | Two Pointers, Sliding Window, Sliding Window (Harder), Binary Search, Stacks | System Design Foundations 3-12, two a day | | 7 | Practice Test 1 | System Design Foundations 13-16 and its test; Behavioral 2 (STAR method) | | 8-14 | Trees Basics, BST, Tries, Heaps, Graphs BFS/DFS, Topological Sort, Union Find | System Design Case Studies 1-14, two a day; Behavioral 3 and 4 on days 10 and 13 | | 15 | Practice Test 2 | Case Studies 15-17 | | 16-21 | DP Basics, DP Intermediate, DP Hard, Backtracking, Backtracking (Advanced), Greedy | Case Studies 18-23 (Mock Design Rounds and test on day 21); Behavioral 5 and 6 on days 17 and 20 | | 22-25 | Intervals, Bit Manipulation, Math and Geometry, Strings | Low-Level Design 1-10 | | 26-27 | Pattern Recall and Mock Coding Rounds, Practice Test 3 | Low-Level Design 11-19 (test on day 27); Behavioral 7 | | 28 | Redo one coding problem from each DSA test, timed | Backend: Python (all) and Django (all) | | 29 | Two timed problems from the Pattern Recall lesson | Backend: FastAPI (all), Databases 1-3 | | 30 | Two timed problems | Backend: Databases 4-6, Caching, Queues and Distributed Systems 1-4 | | 31 | Two timed problems | Backend: Caching, Queues and Distributed Systems 5-8, APIs 1-3 | | 32 | Two timed problems | Backend: APIs 4-9 (Mock Backend Round and test); Behavioral 8 | | 33-35 | One timed problem a day | Frontend 1-12 (HTML, CSS, JavaScript and test 1) | | 36-38 | One timed problem a day | Frontend 13-22 (React and test 2); Behavioral 9 | | 39-41 | One timed problem a day | Frontend 23-38 (performance, security, production, Rapid Recall, test 3) | | 42 | Mock coding round with a friend | Behavioral 10 (company research) for each company on your list | | 43 | Mock coding round | Behavioral 11 (mock behavioral rounds), one mock design round | | 44 | Light review only | Behavioral 12 (interview day) and the Behavioral test | | 45 | Rest | Behavioral 13 (after the interview). Then pick your weakest subject and retake its test cold | If your own interviews only cover some of these subjects, cut the rest and repeat mock rounds in the subjects you actually need instead. > **Remember:** the plan is a default pace, not a rule. Rearrange it around your actual interview date and the subjects your interviews will actually cover. ```knowledge-check { "questions": [ { "id": "ip45-start-plan-q1", "type": "mcq", "prompt": "You have interviews in two weeks that only cover backend and behavioral questions. What should you do with this 45-day plan?", "options": [ {"id": "a", "text": "Follow it exactly from day 1, since skipping days breaks the course"}, {"id": "b", "text": "Skip straight to the Backend and Behavioral subjects and ignore the rest for now"}, {"id": "c", "text": "Wait until you have a full 45 days free before starting"}, {"id": "d", "text": "Only do DSA, since it comes first in the plan"} ], "correct": "b", "explanation": "The subjects are independent. If your interviews only cover backend and behavioral, go directly to those two subjects instead of following the full generic plan." } ] } ``` ## How to study one lesson Every lesson in this course follows the same shape, so the same study method works everywhere: 1. **Read the whole lesson once, without stopping to take notes.** Get the shape of the idea first. 2. **Run any code in the lesson yourself.** Don't just read it. Type it, run it, change one thing, and see what breaks. A concept you've run is a concept you remember; a concept you only read is a concept you'll blank on in an interview. 3. **Answer the knowledge-check question after each section.** If you get it wrong, go back and re-read that section before moving on. These checks are short on purpose, one idea at a time, not a full quiz. 4. **Say the "Remember" line out loud.** Every concept in this course ends with a short blockquote starting with "Remember." Say it in your own words, out loud, like you're explaining it to a friend. If you can't say it without looking, you haven't actually learned it yet, you've only recognized it. This last step matters more than it sounds. Recognizing an idea when you read it and producing that idea from scratch under pressure are two different skills, and only the second one is what an interview actually tests. > **Remember:** reading a lesson once is not the same as learning it. You know a concept once you can say the Remember line without looking back. ```knowledge-check { "questions": [ { "id": "ip45-start-studying-q1", "type": "mcq", "prompt": "You just read a lesson and understood it while reading. What's the real test of whether you actually learned it?", "options": [ {"id": "a", "text": "You recognized the idea while reading it"}, {"id": "b", "text": "You can say the lesson's Remember line out loud, in your own words, without looking back"}, {"id": "c", "text": "You finished the lesson in under 20 minutes"}, {"id": "d", "text": "The lesson's code blocks looked familiar"} ], "correct": "b", "explanation": "Recognizing an idea while reading it is a weaker skill than producing it from scratch. Being able to say the Remember line unprompted is the real signal you've learned it, since that's closer to what an interview actually demands." } ] } ``` ## How to run a mock interview Every subject's last lesson is a set of mock interview rounds with a rubric. Run them like this, whether you're alone or with a friend: - **Use a real timer per round**, and do not pause it. A real interview does not pause either. - **Talk out loud the entire time**, even if no one is listening. Silence is the single worst signal you can give in a real interview, since the interviewer is grading how you think, not just your final answer. If you get stuck, say what you'd ask an interviewer instead of guessing quietly. - **Do not open the reference solution or rubric until you've submitted your own answer or the timer runs out.** Looking early defeats the entire exercise. - **Score yourself honestly against the rubric right after**, like an interviewer would, not like your own cheerleader. - **Write down, immediately, while it's fresh:** the single biggest mistake, why it happened (a knowledge gap, nerves, or running out of time), and one specific fix, a problem to redo, a concept to re-read, or a story to rewrite with real numbers. - **Revisit anything that scored low within 48 hours.** That's the window where practice actually turns into memory. Waiting a week means starting over. If you run several mock rounds over a few days, once you have four or five debriefs written down, go back through all of them together. Group the mistakes by what kind of gap they are, not by which round they happened in: not knowing something, fumbling the mechanics of something you do know, explaining something poorly, running out of time, or freezing up. A mistake that shows up once is bad luck. The same mistake showing up three times across different rounds is a habit, and habits are exactly what a real interview loop exposes. Pick your three most repeated mistakes and write a specific drill for each one, not "get better at system design," but "state the time and space complexity out loud before writing any code, every single round from now on." > **Remember:** score yourself like an interviewer, fix the mistake within 48 hours, and if the same mistake shows up three times across different mock rounds, it's a habit, not bad luck. ```knowledge-check { "questions": [ { "id": "ip45-start-mock-q1", "type": "mcq", "prompt": "During a mock interview, you get stuck on a problem for two minutes. What should you do?", "options": [ {"id": "a", "text": "Stay completely silent while you think, since talking would show you're stuck"}, {"id": "b", "text": "Say out loud what you're thinking and what you'd ask a real interviewer, instead of guessing silently"}, {"id": "c", "text": "Immediately open the reference solution"}, {"id": "d", "text": "Give up and restart the timer"} ], "correct": "b", "explanation": "Silence is the worst signal you can give in an interview. An interviewer grades your thinking process, not just your final answer, so narrating what you're stuck on (and what you'd ask) is far stronger than quiet guessing." } ] } ``` ## How to track your progress Two numbers predict interview readiness better than a raw count of problems solved or lessons finished: **Time per problem, split by phase.** When you solve something, notice where the time actually went: recognizing which pattern to use, writing the code itself, or debugging edge cases afterward. If debugging eats most of your time, your actual weakness is precision, off-by-one errors, missed base cases, not pattern recognition. If recognizing the pattern is what's slow, more coding practice won't help; you need more exposure to how problems get phrased. **How often the same gap repeats.** Keep a running list of what broke in each practice session or mock round, one line each: what happened, why, what you'd do differently. A gap that shows up once is noise. A gap that shows up three times across different problems is a structural hole in your knowledge, and it will show up again in a real interview unless you fix it directly. The habit underneath both of these is the same one from the mock-interview section above: a skill only counts as learned once it survives a cold, timed check with no notes. Recognizing an answer when you read it is not the same as producing it yourself under pressure. If you can't produce something cold in roughly the time a real interview would give you, it goes back on your practice list, no matter how many times you've seen it before. > **Remember:** track where your time goes and which mistakes repeat. A mistake you've made three times is a real gap, not bad luck. ```knowledge-check { "questions": [ { "id": "ip45-start-tracking-q1", "type": "mcq", "prompt": "You solved a medium DSA problem, but it took much longer than expected. Debugging edge cases ate most of the time, not figuring out the approach. What does this actually tell you?", "options": [ {"id": "a", "text": "You need to see more problems to improve pattern recognition"}, {"id": "b", "text": "Your weakness here is precision, things like off-by-one errors and missed base cases, not recognizing the pattern"}, {"id": "c", "text": "The problem was simply too hard and nothing can be learned from it"}, {"id": "d", "text": "You should stop practicing this pattern entirely"} ], "correct": "b", "explanation": "Splitting your time by phase (recognizing the pattern vs. writing the code vs. debugging) tells you exactly what to fix. Time lost to debugging points at precision, not pattern recognition, so more volume of new problems isn't the right fix." } ] } ``` ## What to do after interview season Interview prep does not stop the moment your interviews end, whether you got an offer or not. Skills fade without upkeep, and staying sharp is worth far less effort than building the skill was in the first place. **In the first one to two weeks after your interviews:** read any written feedback you received closely; it is rare and worth more than a dozen more practice problems. Keep a light maintenance pace, around two problems a day, just enough to not lose what you built, not to keep growing quickly. **Over the following one to three months:** revisit one system design a week, rotating through designs you haven't touched in a while rather than replaying your favorites. Run one full mock interview a month with a real person if you can. Reviewing your own answers alone misses delivery problems, filler words, rambling, a flat "tell me about yourself", the same way reading a script hides how it actually sounds out loud. **Keep using real resources, not just this course:** company-tagged problem sets once you're targeting specific employers, a structured mock-interview platform if you want feedback from a stranger, the System Design Primer (a well-known open reference) whenever a specific building block goes rusty, and the engineering blogs of companies you're targeting, which show you the real scale problems they actually care about. > **Remember:** interview skill decays without upkeep. A couple of problems a day and one system design a week is enough to hold onto what you built here. ```knowledge-check { "questions": [ { "id": "ip45-start-after-q1", "type": "mcq", "prompt": "Your interview loop just finished. What is the right amount of practice to keep up over the following months?", "options": [ {"id": "a", "text": "Stop entirely until your next job search"}, {"id": "b", "text": "A light maintenance pace: a couple of problems a day and one system design a week, plus a monthly mock with a real person"}, {"id": "c", "text": "The exact same intensity as the 45-day plan, indefinitely"}, {"id": "d", "text": "Only review written feedback, and nothing else"} ], "correct": "b", "explanation": "Interview skills fade without upkeep, but maintaining them takes far less effort than building them did. A light, steady pace plus periodic real mock interviews keeps the skill without the intensity of active prep." } ] } ``` 2f:T92e6,Say you have a phone book with a million names and you need to find one number fast. Flipping page by page is slow. An index that jumps you straight to the right page is fast. A hash table is that index, built into a data structure. Arrays and hash tables are the base almost every other pattern sits on. Two pointers, sliding window, even a graph's adjacency list: all of them are arrays and hash maps underneath. Interviewers use simple hashing problems as a calibration check. Fumble a basic complement lookup, and they lower their expectations for everything harder you attempt after. Get the mental model right once here, and it stops costing you thinking time later. ## Hash tables: how collisions get resolved Picture a classroom with 8 coat hooks, numbered 0 to 7. Every student's name gets turned into a hook number by a rule, say, add up the letters and divide by 8. Two students can land on the same hook number. That is a **collision**: two different keys landing in the same slot. A hash table works the same way. It maps keys to values by running the key through a hash function to get a bucket index, then storing the entry in that bucket. How you handle two keys wanting the same bucket decides how fast the table stays as more keys arrive. There are two standard ways to resolve a collision: | Strategy | How it works | Trade-off | |---|---|---| | Chaining | Each bucket holds a list of every entry that hashed there. A lookup walks the list comparing keys. | Simple, but a long list in one bucket degrades toward O(n). | | Open addressing | On a collision, probe another slot in the same array until you find an empty one. | No extra list, but the probe sequence itself needs care (see below). | Python's `dict` uses open addressing internally, but for interview purposes you only need the contract: average O(1) insert, lookup, and delete, degrading to O(n) if the hash function is bad or an attacker can force collisions on purpose (called hash-flooding). ```python class HashNode: def __init__(self, key, value): self.key = key self.value = value self.next = None # chaining: next node in this bucket class ChainingHashMap: def __init__(self, capacity=8): self.capacity = capacity self.size = 0 self.buckets = [None] * capacity def _index(self, key): return hash(key) % self.capacity def put(self, key, value): idx = self._index(key) node = self.buckets[idx] while node: if node.key == key: node.value = value # update existing return node = node.next new_node = HashNode(key, value) new_node.next = self.buckets[idx] self.buckets[idx] = new_node self.size += 1 if self.size / self.capacity > 0.75: self._resize() def get(self, key): idx = self._index(key) node = self.buckets[idx] while node: if node.key == key: return node.value node = node.next raise KeyError(key) def _resize(self): old_buckets = self.buckets self.capacity *= 2 self.buckets = [None] * self.capacity self.size = 0 for node in old_buckets: while node: self.put(node.key, node.value) node = node.next ``` ```javascript + class HashNode { constructor(key, value) { this.key = key; this.value = value; this.next = null; // chaining: next node in this bucket } } class ChainingHashMap { constructor(capacity = 8) { this.capacity = capacity; this.size = 0; this.buckets = new Array(capacity).fill(null); } _hash(key) { const str = String(key); let h = 0; for (let i = 0; i < str.length; i++) { h = (h * 31 + str.charCodeAt(i)) | 0; } return Math.abs(h) % this.capacity; } put(key, value) { const idx = this._hash(key); let node = this.buckets[idx]; while (node) { if (node.key === key) { node.value = value; // update existing return; } node = node.next; } const newNode = new HashNode(key, value); newNode.next = this.buckets[idx]; this.buckets[idx] = newNode; this.size += 1; if (this.size / this.capacity > 0.75) { this._resize(); } } get(key) { const idx = this._hash(key); let node = this.buckets[idx]; while (node) { if (node.key === key) return node.value; node = node.next; } throw new Error(`key not found: ${key}`); } _resize() { const oldBuckets = this.buckets; this.capacity *= 2; this.buckets = new Array(this.capacity).fill(null); this.size = 0; for (let node of oldBuckets) { while (node) { this.put(node.key, node.value); node = node.next; } } } } ``` ```java + public class Main { public static void main(String[] args) { ChainingHashMap map = new ChainingHashMap<>(8); map.put("a", 1); map.put("b", 2); map.put("a", 10); System.out.println(map.get("a")); System.out.println(map.get("b")); } } class HashNode { K key; V value; HashNode next; // chaining: next node in this bucket HashNode(K key, V value) { this.key = key; this.value = value; this.next = null; } } class ChainingHashMap { private int capacity; private int size; private HashNode[] buckets; @SuppressWarnings("unchecked") ChainingHashMap(int capacity) { this.capacity = capacity; this.size = 0; this.buckets = new HashNode[capacity]; } private int index(K key) { return Math.abs(key.hashCode()) % capacity; } void put(K key, V value) { int idx = index(key); HashNode node = buckets[idx]; while (node != null) { if (node.key.equals(key)) { node.value = value; // update existing return; } node = node.next; } HashNode newNode = new HashNode<>(key, value); newNode.next = buckets[idx]; buckets[idx] = newNode; size += 1; if ((double) size / capacity > 0.75) { resize(); } } V get(K key) { int idx = index(key); HashNode node = buckets[idx]; while (node != null) { if (node.key.equals(key)) return node.value; node = node.next; } throw new java.util.NoSuchElementException(String.valueOf(key)); } @SuppressWarnings("unchecked") private void resize() { HashNode[] oldBuckets = buckets; capacity *= 2; buckets = new HashNode[capacity]; size = 0; for (HashNode node : oldBuckets) { while (node != null) { put(node.key, node.value); node = node.next; } } } } ``` A load factor (`size / capacity`) above about 0.7 is when you resize. Go higher, and chains get long, dragging lookups toward O(n). Resizing itself is O(n), but spread across n inserts it costs O(1) per insert on average, the same argument that makes dynamic-array growth cheap. ### Open addressing: three ways to probe Open addressing skips the linked lists. Every entry lives directly in the array, and a collision makes you probe other slots until you find an empty one. - **Linear probing:** try `(hash(key) + i) % size` for `i = 0, 1, 2, ...`. Simple, and cache-friendly since the probes are sequential memory addresses. The downside is **primary clustering**: once a run of filled slots forms, every new collision makes the run longer, so long runs snowball toward O(n) lookups. - **Quadratic probing:** try `(hash(key) + i²) % size`. Spreads probes out faster, so it avoids primary clustering. Its downside is **secondary clustering**: two keys that hash to the same first slot always follow the exact same probe path, so they keep colliding with each other. - **Double hashing:** try `(hash1(key) + i * hash2(key)) % size`, where `hash2` is a second, independent hash function. The step size depends on the key, so two colliding keys almost never share a probe path. Best spread of the three, at the cost of computing two hash functions per lookup. ```python class OpenAddressingMap: def __init__(self, capacity=8): self.capacity = capacity self.size = 0 self.keys = [None] * capacity self.values = [None] * capacity def _probe(self, key): # linear probing — swap the +i step for quadratic (+i*i) or double hashing i = 0 idx = hash(key) % self.capacity while self.keys[idx] is not None and self.keys[idx] != key: i += 1 idx = (hash(key) + i) % self.capacity return idx def put(self, key, value): idx = self._probe(key) if self.keys[idx] is None: self.size += 1 self.keys[idx] = key self.values[idx] = value ``` Trace it by hand with `capacity = 8` and linear probing. A key with hash `11` gives `idx = 11 % 8 = 3`: it lands in slot 3. A second key also hashing to `3` finds slot 3 taken, so it checks `(3 + 1) % 8 = 4`, which is empty, and lands there. A third key hashing to `19` (`19 % 8 = 3`) tries slot 3 (taken), slot 4 (taken), then slot 5 (empty). Three different keys packed into three consecutive slots: that is primary clustering happening in real time. Deleting is the classic open-addressing trap. You cannot just set a slot back to empty, because that breaks the probe path for any key that probed past it. In the trace above, clearing slot 3 would make a lookup for the key in slot 4 stop early at the now-empty slot 3 and wrongly report "not found." Real implementations write a tombstone marker instead. Probing continues through tombstones, and a new insert is free to reuse them. **Python's `dict` uses a variation on this.** It does open addressing, but with a pseudo-random probe sequence built from the full hash value, not plain linear or quadratic steps. This scrambles the probe order using hash bits a simple `mod size` would throw away, which keeps `dict` fast even when many keys collide on their low bits. Since Python 3.3, string and bytes hashing is randomized per process specifically to block **hash-flooding attacks**, where an attacker submits keys engineered to all collide and drag a service's hash map down to O(n) per operation. > **Remember:** chaining stores a list per bucket; open addressing stores everything in the array and probes on collision. Say "average O(1), worst case O(n) on bad hashing" and you have covered the interview-relevant part. ```knowledge-check { "questions": [ { "id": "dsa-arrays-and-hashing-hash-collisions-q1", "type": "mcq", "prompt": "Why does linear probing tend to get slower over time as a hash table fills up?", "options": [ {"id": "a", "text": "Primary clustering: filled runs of slots keep growing, so more keys have to probe further"}, {"id": "b", "text": "It recomputes the hash function on every probe"}, {"id": "c", "text": "It always resizes the array on the first collision"}, {"id": "d", "text": "It stores a linked list per slot, like chaining does"} ], "correct": "a", "explanation": "Linear probing checks consecutive slots. Once a run of filled slots forms, every new collision lands at the end of that run and extends it, so runs snowball and lookups get slower." } ] } ``` ## Keeping custom objects hashable Picture a coat-check counter with 100 numbered pegs. Two coats that look identical, same size, same color, must always be hung on the same peg, or the counter loses track of one when it goes searching for it later. If you want your own class to work as a dict key or set member, `__hash__` and `__eq__` (Python's "are these two equal" and "which bucket does this go in" methods) must agree with each other the same way. **The rule: if `a == b`, then `hash(a) == hash(b)`.** The reverse is not required. Different objects can share a hash; that is just an ordinary collision, handled the normal way. But two objects that compare equal must never disagree on their hash, or a dict/set stores them as separate entries it can never look up consistently: a lookup hashes to bucket A, finds nothing, even though an "equal" object sits in bucket B. ```python class Student: def __init__(self, student_id, name): self.student_id = student_id self.name = name # not part of identity — two records can share a name def __eq__(self, other): return isinstance(other, Student) and self.student_id == other.student_id def __hash__(self): return hash(self.student_id) # must derive from the same fields __eq__ uses ``` A common bug is defining `__eq__` without `__hash__`. Python then sets `__hash__` to `None` automatically, making the class unhashable. That is on purpose: a custom `__eq__` without a matching `__hash__` would silently break the rule above. If you override `__eq__`, you must also define `__hash__` (or explicitly keep the default identity-based one, if that is really what you want). > **Remember:** equal objects must hash equal. If you write `__eq__`, write `__hash__` right next to it, using the same fields. ```knowledge-check { "questions": [ { "id": "dsa-arrays-and-hashing-hash-eq-contract-q1", "type": "mcq", "prompt": "A class defines a custom `__eq__` but no `__hash__`. What happens in Python?", "options": [ {"id": "a", "text": "Python sets `__hash__` to `None`, making instances unhashable"}, {"id": "b", "text": "Python keeps the default identity-based `__hash__` automatically"}, {"id": "c", "text": "Python raises a syntax error at class definition time"}, {"id": "d", "text": "Python derives `__hash__` from `__eq__` automatically"} ], "correct": "a", "explanation": "Defining __eq__ without __hash__ sets __hash__ to None, so instances can't be used as dict keys or set members. This stops you from silently breaking the equal-objects-must-hash-equal rule." } ] } ``` ## Time complexity of array operations Picture 1,000 people standing shoulder to shoulder in a numbered line, position 0 to 999. Calling out "person 500, step forward" gets an instant answer: you know exactly where to look. Squeezing a new person into the front of that line means all 1,000 people already there have to shuffle back one spot to make room. That difference, jump straight to a spot versus shift everyone over, is the whole story of array time complexity. | Operation | Complexity | Why | |---|---|---| | Index access `arr[i]` | O(1) | Direct memory offset calculation | | Append at end | O(1) amortized | See below | | Insert or delete at front or middle | O(n) | Every following element shifts | | Search (unsorted) | O(n) | Must check every element | | Search (sorted) | O(log n) | Binary search applies | The common mix-up: candidates say "insert is O(1)" out of habit, thinking of linked lists. For a Python `list`, which is a dynamic array, inserting at index 0 is O(n) because everything after it has to shift right. Only `list.append()` is O(1) amortized. ### Dynamic array from scratch Python's `list` is a dynamic array: a fixed-capacity array underneath that reallocates and copies into a bigger array once it fills up. The "amortized O(1) append" claim rests on doubling the capacity each time, not growing by a fixed amount. ```python import ctypes class DynamicArray: def __init__(self): self.count = 0 # number of elements actually stored self.capacity = 1 # allocated slots self.array = self._make_array(self.capacity) def _make_array(self, capacity): return (capacity * ctypes.py_object)() def __len__(self): return self.count def __getitem__(self, i): if not 0 <= i < self.count: raise IndexError("index out of range") return self.array[i] def append(self, value): if self.count == self.capacity: self._resize(2 * self.capacity) # double capacity self.array[self.count] = value self.count += 1 def _resize(self, new_capacity): new_array = self._make_array(new_capacity) for i in range(self.count): new_array[i] = self.array[i] self.array = new_array self.capacity = new_capacity ``` ```javascript + class DynamicArray { constructor() { this.count = 0; // number of elements actually stored this.capacity = 1; // allocated slots this.array = new Array(this.capacity); } get length() { return this.count; } get(i) { if (i < 0 || i >= this.count) { throw new RangeError("index out of range"); } return this.array[i]; } append(value) { if (this.count === this.capacity) { this._resize(2 * this.capacity); // double capacity } this.array[this.count] = value; this.count += 1; } _resize(newCapacity) { const newArray = new Array(newCapacity); for (let i = 0; i < this.count; i++) { newArray[i] = this.array[i]; } this.array = newArray; this.capacity = newCapacity; } } ``` ```java + public class Main { public static void main(String[] args) { DynamicArray arr = new DynamicArray(); for (int i = 0; i < 5; i++) { arr.append(i * 10); } System.out.println("length: " + arr.length()); System.out.println("arr[3]: " + arr.get(3)); } } class DynamicArray { private int count; // number of elements actually stored private int capacity; // allocated slots private Object[] array; DynamicArray() { this.count = 0; this.capacity = 1; this.array = new Object[capacity]; } int length() { return count; } @SuppressWarnings("unchecked") T get(int i) { if (i < 0 || i >= count) { throw new IndexOutOfBoundsException("index out of range"); } return (T) array[i]; } void append(Object value) { if (count == capacity) { resize(2 * capacity); // double capacity } array[count] = value; count += 1; } private void resize(int newCapacity) { Object[] newArray = new Object[newCapacity]; for (int i = 0; i < count; i++) { newArray[i] = array[i]; } array = newArray; capacity = newCapacity; } } ``` Why is append amortized O(1)? A resize costs O(n) to copy, but doubling means resizes happen at sizes 1, 2, 4, 8, ... 2^k. Add up the copy costs (1 + 2 + 4 + ... + n ≈ 2n) and divide by n appends, and you get O(1) average cost per append. Growing by a fixed amount instead of doubling makes append O(n) amortized, which is the detail interviewers probe for. > **Remember:** doubling capacity is what makes append amortized O(1). A fixed growth step would make it O(n). ```knowledge-check { "questions": [ { "id": "dsa-arrays-and-hashing-array-time-complexity-q1", "type": "mcq", "prompt": "Why is inserting at the front of a Python list O(n) instead of O(1)?", "options": [ {"id": "a", "text": "Every element after the insertion point has to shift one slot to the right"}, {"id": "b", "text": "Python lists are actually linked lists internally"}, {"id": "c", "text": "It triggers a resize every single time"}, {"id": "d", "text": "Front insertion always re-sorts the list"} ], "correct": "a", "explanation": "A Python list is a dynamic array, a contiguous block of memory. Inserting at the front means shifting every existing element one slot over to make room, which is O(n)." } ] } ``` ## Space complexity trade-offs Picture packing for a trip. You can travel light and dig through one bag every time you need something, slow, but no extra weight. Or you can spend a little extra suitcase space on a labeled pouch for each item, so your hand finds it instantly. Space complexity is that second cost: how much extra memory an algorithm uses, not counting the input itself, as the input grows. The trade-off worth knowing cold: a hash set turns an O(n) "does this exist" scan (checking up to all 1,000 items one by one) into an O(1) lookup (one step, every time), at the cost of O(n) extra memory, roughly one labeled pouch per item, to store the set. Say this trade-off out loud whenever you propose a hash-map solution: "I can get O(n) time using O(n) extra space for a hash set. Is that trade-off fine here, or is memory tight?" That one sentence signals you think about trade-offs, not just the fastest possible time complexity. > **Remember:** hashing usually trades O(n) space for O(1) lookup. Say the trade-off out loud before an interviewer has to ask. ```knowledge-check { "questions": [ { "id": "dsa-arrays-and-hashing-space-tradeoffs-q1", "type": "mcq", "prompt": "A hash-set solution turns an O(n) linear scan into an O(1) lookup. What does it cost to get that speed-up?", "options": [ {"id": "a", "text": "O(n) extra space to store the set"}, {"id": "b", "text": "Nothing, hash sets are free in both time and space"}, {"id": "c", "text": "O(log n) extra space"}, {"id": "d", "text": "It requires the input array to be sorted first"} ], "correct": "a", "explanation": "The hash set has to store roughly one entry per input element, so the memory cost is O(n). Time and space are trading against each other here, not both improving for free." } ] } ``` ## Two Sum [Two Sum (LeetCode 1)](https://leetcode.com/problems/two-sum/) You have an array of numbers and a target. Find two numbers that add up to it, and return their positions. **Intuition:** Checking every pair is O(n²). But for each number `x`, all you need to know is whether its complement `target - x` showed up already. That is an existence check, and a hash map answers existence in O(1). **Approach:** Walk the array once. For each element, compute the complement. If the complement is already in the map, you found your pair: return the stored index and the current index. Otherwise, store the current value mapped to its index and keep going. ```python def two_sum(nums: list[int], target: int) -> list[int]: seen = {} # value -> index for i, num in enumerate(nums): complement = target - num if complement in seen: return [seen[complement], i] seen[num] = i raise ValueError("no two sum solution") ``` ```javascript + function twoSum(nums, target) { const seen = new Map(); // value -> index for (let i = 0; i < nums.length; i++) { const complement = target - nums[i]; if (seen.has(complement)) { return [seen.get(complement), i]; } seen.set(nums[i], i); } throw new Error("no two sum solution"); } ``` ```java + public class Main { public static void main(String[] args) { int[] nums = {2, 7, 11, 15}; int[] result = twoSum(nums, 9); System.out.println(result[0] + ", " + result[1]); } static int[] twoSum(int[] nums, int target) { java.util.Map seen = new java.util.HashMap<>(); for (int i = 0; i < nums.length; i++) { int complement = target - nums[i]; if (seen.containsKey(complement)) { return new int[] { seen.get(complement), i }; } seen.put(nums[i], i); } throw new IllegalArgumentException("no two sum solution"); } } ``` **Complexity:** Time O(n), one pass with O(1) map operations. Space O(n) for the map. **Common mistakes:** - Checking `if num in seen` before applying the complement logic. That answers "did I see this number," not "did I see its complement." - Building the map first and scanning separately, which breaks on duplicate values (an element would match itself). - Forgetting the problem asks for indices, not values. > **Remember:** for every number, ask "have I seen its complement," not "have I seen this number." ```knowledge-check { "questions": [ { "id": "dsa-arrays-and-hashing-two-sum-q1", "type": "mcq", "prompt": "In the standard hash-map solution to Two Sum, what should you check on each element?", "options": [ {"id": "a", "text": "Whether target minus the current number is already in the map"}, {"id": "b", "text": "Whether the current number is already in the map"}, {"id": "c", "text": "Whether the current number is negative"}, {"id": "d", "text": "Whether the array is sorted"} ], "correct": "a", "explanation": "You need the complement (target - current number) to already exist in the map. Checking whether the current number itself was seen answers a different question and breaks the solution." } ] } ``` ## Valid Anagram [Valid Anagram (LeetCode 242)](https://leetcode.com/problems/valid-anagram/) **Intuition:** Two strings are anagrams when they hold the same characters with the same counts. Counting frequencies turns this into a comparison, instead of generating every permutation. **Approach:** Count character frequencies in both strings and compare. A length check first is a free O(1) shortcut for the common non-anagram case. ```python from collections import Counter def is_anagram(s: str, t: str) -> bool: if len(s) != len(t): return False return Counter(s) == Counter(t) ``` ```javascript + function isAnagram(s, t) { if (s.length !== t.length) return false; const counts = new Map(); for (const ch of s) counts.set(ch, (counts.get(ch) || 0) + 1); for (const ch of t) { if (!counts.has(ch)) return false; counts.set(ch, counts.get(ch) - 1); } return [...counts.values()].every((c) => c === 0); } ``` ```java + public class Main { public static void main(String[] args) { System.out.println(isAnagram("anagram", "nagaram")); System.out.println(isAnagram("rat", "car")); } static boolean isAnagram(String s, String t) { if (s.length() != t.length()) return false; java.util.Map counts = new java.util.HashMap<>(); for (char ch : s.toCharArray()) { counts.merge(ch, 1, Integer::sum); } for (char ch : t.toCharArray()) { counts.merge(ch, -1, Integer::sum); } for (int count : counts.values()) { if (count != 0) return false; } return true; } } ``` You can also write it without the library, to show you understand the mechanism underneath: ```python def is_anagram_manual(s: str, t: str) -> bool: if len(s) != len(t): return False counts = {} for ch in s: counts[ch] = counts.get(ch, 0) + 1 for ch in t: if ch not in counts: return False counts[ch] -= 1 if counts[ch] == 0: del counts[ch] return len(counts) == 0 ``` ```javascript + function isAnagramManual(s, t) { if (s.length !== t.length) return false; const counts = new Map(); for (const ch of s) counts.set(ch, (counts.get(ch) || 0) + 1); for (const ch of t) { if (!counts.has(ch)) return false; const next = counts.get(ch) - 1; if (next === 0) counts.delete(ch); else counts.set(ch, next); } return counts.size === 0; } ``` ```java + public class Main { public static void main(String[] args) { System.out.println(isAnagramManual("anagram", "nagaram")); System.out.println(isAnagramManual("rat", "car")); } static boolean isAnagramManual(String s, String t) { if (s.length() != t.length()) return false; java.util.Map counts = new java.util.HashMap<>(); for (char ch : s.toCharArray()) { counts.merge(ch, 1, Integer::sum); } for (char ch : t.toCharArray()) { if (!counts.containsKey(ch)) return false; int next = counts.get(ch) - 1; if (next == 0) counts.remove(ch); else counts.put(ch, next); } return counts.isEmpty(); } } ``` **Complexity:** Time O(n) where n is string length. Space O(k) where k is the alphabet size (O(1) if you assume a fixed alphabet like lowercase ASCII). **Common mistakes:** - Sorting both strings and comparing. This works at O(n log n), but it is strictly worse than counting, and interviewers will ask if you can do better. - Skipping the early length check, a cheap and easy win. - Not handling non-ASCII characters if the problem implies them. > **Remember:** anagram means same character counts, not same sorted order. Counting beats sorting. ```knowledge-check { "questions": [ { "id": "dsa-arrays-and-hashing-valid-anagram-q1", "type": "mcq", "prompt": "Why is counting character frequencies a better anagram check than sorting both strings?", "options": [ {"id": "a", "text": "Counting is O(n) while sorting is O(n log n)"}, {"id": "b", "text": "Sorting cannot detect anagrams at all"}, {"id": "c", "text": "Counting uses no extra memory while sorting does"}, {"id": "d", "text": "Sorting only works on numbers, not strings"} ], "correct": "a", "explanation": "Both approaches are correct, but frequency counting runs in O(n) while sorting costs O(n log n). An interviewer will usually push you from the sorting answer to the counting one." } ] } ``` ## Contains Duplicate [Contains Duplicate (LeetCode 217)](https://leetcode.com/problems/contains-duplicate/) **Intuition:** This is the plainest form of "have I seen this before": a hash set existence check. **Approach:** Insert elements into a set one at a time. If an element is already there, return `True` right away. ```python def contains_duplicate(nums: list[int]) -> bool: seen = set() for num in nums: if num in seen: return True seen.add(num) return False ``` ```javascript + function containsDuplicate(nums) { const seen = new Set(); for (const num of nums) { if (seen.has(num)) return true; seen.add(num); } return false; } ``` ```java + public class Main { public static void main(String[] args) { int[] nums = {1, 2, 3, 1}; System.out.println(containsDuplicate(nums)); } static boolean containsDuplicate(int[] nums) { java.util.Set seen = new java.util.HashSet<>(); for (int num : nums) { if (!seen.add(num)) return true; } return false; } } ``` A one-line alternative trades the early exit for brevity: `return len(nums) != len(set(nums))`. It is correct, but it always scans the full list even when a duplicate shows up early, so mention that trade-off if you use it. **Complexity:** Time O(n). Space O(n) worst case (all values unique). **Common mistakes:** - Using nested loops (O(n²)) as the final answer instead of a starting point to optimize from. - Sorting first (O(n log n)): correct and space-efficient, but slower than hashing. Worth mentioning both if asked to compare. > **Remember:** "have I seen this before" is almost always a hash set, one insert-and-check per element. ```knowledge-check { "questions": [ { "id": "dsa-arrays-and-hashing-contains-duplicate-q1", "type": "mcq", "prompt": "What is the time complexity of the hash-set solution to Contains Duplicate?", "options": [ {"id": "a", "text": "O(n)"}, {"id": "b", "text": "O(n log n)"}, {"id": "c", "text": "O(n²)"}, {"id": "d", "text": "O(1)"} ], "correct": "a", "explanation": "Each element is inserted and checked against the set once, and both operations are O(1) on average, giving O(n) total." } ] } ``` ## Sorting algorithms: a complexity cheatsheet Picture 1,000 exam papers in a random pile that need ordering by score. Comparing every pair to place each paper is slow: about 500,000 comparisons. Splitting the pile in half, sorting each half, then merging the two sorted halves needs only about 10 rounds of splitting (since 2 to the 10th power is roughly 1,000), each doing at most 1,000 comparisons: about 10,000 total instead of 500,000. That gap, `n²` versus `n log n`, is why sorting algorithm choice matters, even though sorting rarely stands alone: it shows up as a supporting tool, calling `nums.sort()` before a two-pointer sweep, or reaching for a heap in a top-k problem. This section is the reference for when an interviewer asks about sorting directly. ### Comparison-based sorts | Algorithm | Best | Average | Worst | Space | Stable? | |---|---|---|---|---|---| | Bubble Sort | O(n) | O(n²) | O(n²) | O(1) | Yes | | Selection Sort | O(n²) | O(n²) | O(n²) | O(1) | No | | Insertion Sort | O(n) | O(n²) | O(n²) | O(1) | Yes | | Merge Sort | O(n log n) | O(n log n) | O(n log n) | O(n) | Yes | | Quick Sort | O(n log n) | O(n log n) | O(n²) | O(log n) | No | | Heap Sort | O(n log n) | O(n log n) | O(n log n) | O(1) | No | ### Non-comparison sorts | Algorithm | Best / Average / Worst | Space | Constraint | |---|---|---|---| | Counting Sort | O(n + k) | O(k) | Integers in a known, bounded range `k` | | Radix Sort | O(nk) | O(n + k) | Fixed-width integers or strings, sorted digit by digit | | Bucket Sort | O(n + k) best/avg, O(n²) worst | O(n + k) | Input spread out evenly | These beat the O(n log n) comparison-sort lower bound because they never compare elements pairwise. They exploit structure in the values themselves, a bounded range or a fixed digit count, which is exactly why they do not generalize to arbitrary comparable objects. ### Why Quick Sort's worst case is O(n²) Quick Sort partitions around a pivot. If the pivot always lands on the min or max of the current slice (always picking the first element on already-sorted input, say), one side of the partition is empty and the other holds everything else. Recursion depth becomes O(n) instead of O(log n), giving O(n²) total. Trace it on the already-sorted array `[1, 2, 3, 4, 5]` with "always pick the first element" as the pivot rule: pivot `1` splits into `[]` and `[2, 3, 4, 5]`, pivot `2` splits into `[]` and `[3, 4, 5]`, and so on. Every partition peels off one element instead of splitting the array in half, so recursion goes 5 levels deep instead of the 2-3 levels a balanced split would give. On an array of size n, that becomes n levels deep, each doing O(n) partition work: O(n²) total. The fix is to randomize the pivot (or use median-of-three), which makes this worst case astronomically unlikely instead of triggered by a common shape like "already sorted." ### Choosing a sort in an interview - **Merge Sort** is the only stable O(n log n) option here. It needs O(n) extra space for the merge step. Reach for it when stability matters (sorting by a secondary key after a primary one) or for linked lists, where merging costs O(1) extra space instead of the shifting an array-based sort would need. - **Quick Sort** is in-place, needing only O(log n) space for the recursion stack. It is typically fastest in practice thanks to cache locality, but it is not stable and carries the O(n²) worst case traced above. - **Heap Sort** uses O(1) space with no worst-case blowup, but poor cache locality makes it slower in practice than Quick Sort despite the same O(n log n) bound. It is the classic "same Big-O, different real-world speed" example. Python's built-in `arr.sort()` and `sorted(arr)` use Timsort, a hybrid of Merge Sort and Insertion Sort. It finds already-sorted runs in the input, uses Insertion Sort to extend or build small runs, then merges those runs the way Merge Sort does. It is stable and O(n log n) worst case. Insertion Sort's fast O(n) best case on nearly-sorted data is exactly why it handles the small-run part. Binary search is O(log n) because it halves the search space each step. The general pattern worth stating out loud: - **O(log n):** the algorithm halves the problem each step. Binary search, BST lookup, a single heap push or pop. - **O(n log n):** an O(log n) operation repeated for all n elements. Merge Sort does O(log n) merge levels, each processing all n elements, giving n times log n, not log n alone. Heap Sort has the same shape: n heap operations, each O(log n). | n | log n | n log n | |---|---|---| | 8 | 3 | 24 | | 1,000 | ~10 | ~10,000 | | 1,000,000 | ~20 | ~20,000,000 | One line to keep: O(log n) means divide and ignore half; O(n log n) means divide, and do O(log n) work for every one of the n elements. > **Remember:** Merge Sort is the stable one, Quick Sort is usually the fastest, Heap Sort has no bad case but poor cache behavior. Timsort is what Python actually runs. ```knowledge-check { "questions": [ { "id": "dsa-arrays-and-hashing-sorting-cheatsheet-q1", "type": "mcq", "prompt": "Which sorting algorithm is stable AND guarantees O(n log n) even in the worst case?", "options": [ {"id": "a", "text": "Merge Sort"}, {"id": "b", "text": "Quick Sort"}, {"id": "c", "text": "Heap Sort"}, {"id": "d", "text": "Selection Sort"} ], "correct": "a", "explanation": "Merge Sort is O(n log n) in every case and stable. Quick Sort is not stable and has an O(n²) worst case; Heap Sort is O(n log n) worst case but not stable." } ] } ``` 30:T5088,Picture a sorted row of 1,000 people lined up by height, shortest to tallest. You need to find two people whose heights add up to exactly 300 cm. Put one finger on the shortest person and one on the tallest. Too small a total? Move the left finger one person to the right. Too big? Move the right finger one person to the left. You never check the same pair twice, so you cover the whole row in at most 1,000 steps: O(n), where a nested loop checking every pair would take close to 500,000 checks, O(n²). That is two pointers: the win is not a smarter data structure, it is a smarter scan order, using structure already in the input, usually that it is sorted. Interviewers use it to see whether you reach for hashing out of habit, or actually look at the shape of the problem first. ## Two pointers vs hash maps Both patterns often solve "find a pair or triple with some property," but they use different things about the input. | | Hash map | Two pointers | |---|---|---| | Needs sorted input | No | Usually yes | | Extra space | O(n) | O(1) | | Keeps original indices | Yes | No, unless tracked separately | | Typical time | O(n) | O(n), after an O(n log n) sort if needed | Rule of thumb: if the array is already sorted, or you can sort it without needing the original order or indices, reach for two pointers to save space. If you need the original indices (like Two Sum) or the input cannot be reordered, use a hash map instead. Two pointers works because in a sorted array, moving the left pointer right only increases the value there, and moving the right pointer left only decreases it. This one-directional behavior lets you throw away half the remaining search space at each step, instead of trying every pair. For 3Sum-style problems: fix one element, then run two pointers on the remaining sorted subarray to find pairs that sum to the value you need. That is why sorting first turns an O(n³) triple-nested loop into O(n²). > **Remember:** hash map when you need original indices or the input can't be reordered. Two pointers when the input is sorted (or free to sort) and you can trade indices for O(1) space. ```knowledge-check { "questions": [ { "id": "dsa-two-pointers-vs-hashmap-q1", "type": "mcq", "prompt": "When should you reach for two pointers instead of a hash map?", "options": [ {"id": "a", "text": "When the array is sorted (or free to sort) and you don't need to preserve original indices"}, {"id": "b", "text": "Whenever the array has duplicate values"}, {"id": "c", "text": "Only when the array has fewer than 10 elements"}, {"id": "d", "text": "Whenever you need to return indices, not values"} ], "correct": "a", "explanation": "Two pointers exploits sortedness to save space (O(1) instead of O(n)), but it loses the original index order. Use a hash map instead when you need indices or can't reorder the input." } ] } ``` ## Moving elements in place Picture tidying a shelf of 20 books where some titles repeat, without taking any books off the shelf or using a second shelf. One hand marks the next empty spot for a book you want to keep. The other hand scans ahead, looking for the next book worth keeping and sliding it back to that spot. Many two-pointer problems work exactly like this: removing duplicates, moving zeroes, partitioning, all using O(1) extra space, no second array. One pointer (`write` or `slow`) tracks where the next valid element should go. Another pointer (`read` or `fast`) scans ahead looking for valid elements to bring back. ```python def remove_duplicates(nums: list[int]) -> int: """Removes duplicates from a sorted array in place, returns new length.""" if not nums: return 0 write = 1 for read in range(1, len(nums)): if nums[read] != nums[write - 1]: nums[write] = nums[read] write += 1 return write ``` ```javascript + function removeDuplicates(nums) { // Removes duplicates from a sorted array in place, returns new length. if (nums.length === 0) return 0; let write = 1; for (let read = 1; read < nums.length; read++) { if (nums[read] !== nums[write - 1]) { nums[write] = nums[read]; write += 1; } } return write; } ``` ```java + public class Main { public static void main(String[] args) { int[] nums = {1, 1, 2, 2, 3}; int newLength = removeDuplicates(nums); System.out.println("new length: " + newLength); } // Removes duplicates from a sorted array in place, returns new length. static int removeDuplicates(int[] nums) { if (nums.length == 0) return 0; int write = 1; for (int read = 1; read < nums.length; read++) { if (nums[read] != nums[write - 1]) { nums[write] = nums[read]; write += 1; } } return write; } } ``` In-place two-pointer solutions are easy to get subtly wrong around the boundary condition (`!=` vs `<`, starting `write` at 0 vs 1). Always trace through a small 2-3 element example by hand before calling it correct. > **Remember:** in a write/read pair, `write` marks where the next good value goes; `read` scans ahead to find it. Trace 2-3 elements by hand before you trust it. ```knowledge-check { "questions": [ { "id": "dsa-two-pointers-inplace-q1", "type": "mcq", "prompt": "In the write/read two-pointer pattern for removing duplicates from a sorted array, what does the `write` pointer track?", "options": [ {"id": "a", "text": "The position where the next unique value should be placed"}, {"id": "b", "text": "The current element being scanned"}, {"id": "c", "text": "The number of duplicates removed so far"}, {"id": "d", "text": "The midpoint of the array"} ], "correct": "a", "explanation": "`write` always points at the next slot to fill with a valid (non-duplicate) value. `read` is the pointer that scans ahead looking for the next value worth writing." } ] } ``` ## Valid Palindrome [Valid Palindrome (LeetCode 125)](https://leetcode.com/problems/valid-palindrome/) A palindrome reads the same forwards and backwards. Instead of building a cleaned string and reversing it, which costs extra space, walk from both ends toward the middle and compare characters directly. **Approach:** Use `left` and `right` pointers starting at the two ends. Skip non-alphanumeric characters on either side. Compare lowercase versions of the characters; a mismatch means it is not a palindrome. Pointers crossing means success. ```python def is_palindrome(s: str) -> bool: left, right = 0, len(s) - 1 while left < right: while left < right and not s[left].isalnum(): left += 1 while left < right and not s[right].isalnum(): right -= 1 if s[left].lower() != s[right].lower(): return False left += 1 right -= 1 return True ``` ```javascript + function isPalindrome(s) { const isAlnum = (ch) => /[a-z0-9]/i.test(ch); let left = 0; let right = s.length - 1; while (left < right) { while (left < right && !isAlnum(s[left])) left += 1; while (left < right && !isAlnum(s[right])) right -= 1; if (s[left].toLowerCase() !== s[right].toLowerCase()) return false; left += 1; right -= 1; } return true; } ``` ```java + public class Main { public static void main(String[] args) { System.out.println(isPalindrome("A man, a plan, a canal: Panama")); System.out.println(isPalindrome("race a car")); } static boolean isPalindrome(String s) { int left = 0; int right = s.length() - 1; while (left < right) { while (left < right && !Character.isLetterOrDigit(s.charAt(left))) left += 1; while (left < right && !Character.isLetterOrDigit(s.charAt(right))) right -= 1; if (Character.toLowerCase(s.charAt(left)) != Character.toLowerCase(s.charAt(right))) { return false; } left += 1; right -= 1; } return true; } } ``` **Complexity:** Time O(n), space O(1). No extra string built. **Common mistakes:** - Building a cleaned, lowercased copy of the string first. Correct, but O(n) extra space when O(1) is possible. - Inner `while` loops missing the `left < right` bound, which causes an out-of-range index when the string is all punctuation. - Forgetting `.isalnum()` covers both letters and digits, not just letters. > **Remember:** two pointers walking inward, skipping non-alphanumeric characters as they go, no extra string needed. ```knowledge-check { "questions": [ { "id": "dsa-two-pointers-valid-palindrome-q1", "type": "mcq", "prompt": "What is the space complexity of the two-pointer Valid Palindrome solution that skips non-alphanumeric characters in place?", "options": [ {"id": "a", "text": "O(1)"}, {"id": "b", "text": "O(n)"}, {"id": "c", "text": "O(log n)"}, {"id": "d", "text": "O(n²)"} ], "correct": "a", "explanation": "No cleaned copy of the string is built. Two pointers scan the original string directly, so extra space stays constant." } ] } ``` ## 3Sum [3Sum (LeetCode 15)](https://leetcode.com/problems/3sum/) Extending Two Sum's hash-map trick to three numbers gets messy fast because of duplicate handling. Sorting first and fixing one number turns this into a Two Sum variant you can solve with two pointers, and sorted order makes skipping duplicates mechanical. **Approach:** Sort the array. For each index `i` (skipping duplicate values of `nums[i]`), run two pointers (`left = i+1`, `right = n-1`) across the rest of the array looking for pairs that sum to `-nums[i]`. Skip duplicate values at `left` and `right` after finding a match, so you do not record the same triplet twice. ```python def three_sum(nums: list[int]) -> list[list[int]]: nums.sort() result = [] n = len(nums) for i in range(n - 2): if i > 0 and nums[i] == nums[i - 1]: continue # skip duplicate anchors if nums[i] > 0: break # smallest remaining value is positive, no triplet can sum to 0 left, right = i + 1, n - 1 while left < right: total = nums[i] + nums[left] + nums[right] if total < 0: left += 1 elif total > 0: right -= 1 else: result.append([nums[i], nums[left], nums[right]]) left += 1 right -= 1 while left < right and nums[left] == nums[left - 1]: left += 1 while left < right and nums[right] == nums[right + 1]: right -= 1 return result ``` ```javascript + function threeSum(nums) { nums.sort((a, b) => a - b); const result = []; const n = nums.length; for (let i = 0; i < n - 2; i++) { if (i > 0 && nums[i] === nums[i - 1]) continue; // skip duplicate anchors if (nums[i] > 0) break; // smallest remaining value is positive, no triplet can sum to 0 let left = i + 1; let right = n - 1; while (left < right) { const total = nums[i] + nums[left] + nums[right]; if (total < 0) { left += 1; } else if (total > 0) { right -= 1; } else { result.push([nums[i], nums[left], nums[right]]); left += 1; right -= 1; while (left < right && nums[left] === nums[left - 1]) left += 1; while (left < right && nums[right] === nums[right + 1]) right -= 1; } } } return result; } ``` ```java + public class Main { public static void main(String[] args) { int[] nums = {-1, 0, 1, 2, -1, -4}; java.util.List> result = threeSum(nums); System.out.println(result); } static java.util.List> threeSum(int[] nums) { java.util.Arrays.sort(nums); java.util.List> result = new java.util.ArrayList<>(); int n = nums.length; for (int i = 0; i < n - 2; i++) { if (i > 0 && nums[i] == nums[i - 1]) continue; // skip duplicate anchors if (nums[i] > 0) break; // smallest remaining value is positive, no triplet can sum to 0 int left = i + 1; int right = n - 1; while (left < right) { int total = nums[i] + nums[left] + nums[right]; if (total < 0) { left += 1; } else if (total > 0) { right -= 1; } else { result.add(java.util.Arrays.asList(nums[i], nums[left], nums[right])); left += 1; right -= 1; while (left < right && nums[left] == nums[left - 1]) left += 1; while (left < right && nums[right] == nums[right + 1]) right -= 1; } } } return result; } } ``` **Complexity:** Time O(n²): O(n log n) to sort plus an O(n) outer loop times an O(n) two-pointer scan. Space O(1) extra, not counting the sort and output. **Common mistakes:** - Forgetting to skip duplicate anchors, which produces duplicate triplets in the result. - Skipping duplicates for `left`/`right` before recording the match instead of after. - Deduplicating the output with a hash set as a patch, instead of the sorted-skip technique. It works, but it is slower and messier. > **Remember:** sort first, fix one number, then two-pointer the rest. Skip duplicates right after recording a match, not before. ```knowledge-check { "questions": [ { "id": "dsa-two-pointers-3sum-q1", "type": "mcq", "prompt": "What is the overall time complexity of the sort-then-two-pointer solution to 3Sum?", "options": [ {"id": "a", "text": "O(n²)"}, {"id": "b", "text": "O(n log n)"}, {"id": "c", "text": "O(n³)"}, {"id": "d", "text": "O(n)"} ], "correct": "a", "explanation": "Sorting costs O(n log n). The outer loop runs n times, and for each anchor the two-pointer scan is O(n), giving O(n²) total, which dominates the sort." } ] } ``` ## Container With Most Water [Container With Most Water (LeetCode 11)](https://leetcode.com/problems/container-with-most-water/) **Intuition:** The area between two lines is `min(height[left], height[right]) * (right - left)`. Starting pointers at both ends maximizes the width term first. The key insight: moving the pointer at the taller line inward can never increase the area, since the width shrinks and the height is still capped by the shorter line either way. So you always move the shorter line's pointer. **Approach:** Start `left = 0`, `right = n - 1`. Track the max area seen. Move whichever pointer points to the shorter line inward. Repeat until the pointers meet. ```python def max_area(height: list[int]) -> int: left, right = 0, len(height) - 1 best = 0 while left < right: h = min(height[left], height[right]) best = max(best, h * (right - left)) if height[left] < height[right]: left += 1 else: right -= 1 return best ``` ```javascript + function maxArea(height) { let left = 0; let right = height.length - 1; let best = 0; while (left < right) { const h = Math.min(height[left], height[right]); best = Math.max(best, h * (right - left)); if (height[left] < height[right]) { left += 1; } else { right -= 1; } } return best; } ``` ```java + public class Main { public static void main(String[] args) { int[] height = {1, 8, 6, 2, 5, 4, 8, 3, 7}; System.out.println(maxArea(height)); } static int maxArea(int[] height) { int left = 0; int right = height.length - 1; int best = 0; while (left < right) { int h = Math.min(height[left], height[right]); best = Math.max(best, h * (right - left)); if (height[left] < height[right]) { left += 1; } else { right -= 1; } } return best; } } ``` **Complexity:** Time O(n), a single pass with each pointer moving at most n times total. Space O(1). **Common mistakes:** - Trying every pair (O(n²)) instead of recognizing the "move the shorter side" argument. - Moving the taller pointer, or moving both pointers every step. Both break the correctness proof. - Forgetting the area formula uses `min`, not `max`, of the two heights, since water cannot rise above the shorter wall. > **Remember:** always move the pointer at the shorter line. Moving the taller one can only ever shrink the area. ```knowledge-check { "questions": [ { "id": "dsa-two-pointers-container-water-q1", "type": "mcq", "prompt": "In Container With Most Water, when the left line is shorter than the right line, which pointer should you move?", "options": [ {"id": "a", "text": "The left pointer, since the shorter line is what caps the area"}, {"id": "b", "text": "The right pointer, since it's taller and safer to move"}, {"id": "c", "text": "Both pointers together"}, {"id": "d", "text": "Neither; stop once you see the shorter line"} ], "correct": "a", "explanation": "The shorter line caps the area no matter what. Moving it is the only move that has a chance of finding a taller line and a bigger area; moving the taller pointer can only shrink the width while keeping the same cap." } ] } ``` ## A reusable linked list node Linked list and tree problems reuse a minimal node class like this one. Get this boilerplate right once so it is not a distraction later. ```python class ListNode: def __init__(self, val=0, next=None): self.val = val self.next = next def __repr__(self): return f"ListNode({self.val})" def build_linked_list(values: list[int]) -> ListNode | None: dummy = ListNode() tail = dummy for v in values: tail.next = ListNode(v) tail = tail.next return dummy.next ``` ```javascript + class ListNode { constructor(val = 0, next = null) { this.val = val; this.next = next; } } function buildLinkedList(values) { const dummy = new ListNode(); let tail = dummy; for (const v of values) { tail.next = new ListNode(v); tail = tail.next; } return dummy.next; } ``` ```java + public class Main { public static void main(String[] args) { ListNode head = buildLinkedList(new int[] {1, 2, 3}); StringBuilder sb = new StringBuilder(); while (head != null) { sb.append(head.val).append(" -> "); head = head.next; } sb.append("null"); System.out.println(sb); } static ListNode buildLinkedList(int[] values) { ListNode dummy = new ListNode(); ListNode tail = dummy; for (int v : values) { tail.next = new ListNode(v); tail = tail.next; } return dummy.next; } } class ListNode { int val; ListNode next; ListNode() { this(0, null); } ListNode(int val) { this(val, null); } ListNode(int val, ListNode next) { this.val = val; this.next = next; } } ``` The `dummy` head node is the trick worth remembering: it removes the special case of "is this the first node?" from insertion logic, since `dummy.next` always points at the real head. > **Remember:** a dummy head node turns "is this the first insert?" into a non-question. `dummy.next` is always the real head. ```knowledge-check { "questions": [ { "id": "dsa-two-pointers-linked-list-node-q1", "type": "mcq", "prompt": "Why do linked-list building functions often start with a dummy head node?", "options": [ {"id": "a", "text": "It removes the special case of handling the first insertion separately"}, {"id": "b", "text": "It makes the list doubly linked"}, {"id": "c", "text": "It is required for the list to be mutable"}, {"id": "d", "text": "It reduces the time complexity of insertion"} ], "correct": "a", "explanation": "Without a dummy head, inserting the very first real node needs special-case code (there's no previous node to attach to). With a dummy head, dummy.next always points to the real head, so every insertion follows the same code path." } ] } ``` 31:T682a,Picture a train with exactly 3 connected cars, rolling forward one station at a time along a track of 100 stations. At every station, the car at the back detaches and a new one joins at the front, so you always see exactly 3 cars, just a different 3. A sliding window works the same way over an array or a string: a contiguous stretch that grows and shrinks as you scan forward once, instead of checking every possible stretch from scratch (which for 100 elements means checking up to 5,000 different stretches). Sliding window is two pointers' sibling pattern for subarray and substring problems. Instead of pointers moving toward each other from both ends, both pointers move forward, marking out a contiguous window. Reach for it first on "longest, shortest, or best contiguous substring/subarray satisfying X" questions, which show up constantly in string-heavy interviews. ## Fixed vs variable window size There are two flavors of sliding window, and the train picture above splits neatly into both. - **Fixed-size window:** the window size `k` is given upfront (for example, "max sum of any subarray of size k"). Slide it by adding the new right element and removing the leftmost element every step: O(1) work per step, O(n) total. - **Variable-size window:** the window grows and shrinks based on a condition (for example, "longest substring with no repeating characters"). The right pointer always moves forward; the left pointer moves forward only when the window becomes invalid, catching it back up to valid. Recognizing which flavor a problem needs is the first decision to make. If the problem states a fixed length, it is fixed-size. If it says "longest," "shortest," or "minimum" without a fixed length, it is almost always variable-size. > **Remember:** a fixed length in the problem means fixed-size window. "Longest" or "shortest" with no fixed length means variable-size. ```knowledge-check { "questions": [ { "id": "dsa-sliding-window-fixed-vs-variable-q1", "type": "mcq", "prompt": "A problem asks for the \"longest substring with no repeating characters.\" Which sliding-window flavor does it need?", "options": [ {"id": "a", "text": "Variable-size window, since there's no fixed length given"}, {"id": "b", "text": "Fixed-size window with k equal to the string length"}, {"id": "c", "text": "Neither; this needs a hash map only, no window"}, {"id": "d", "text": "Fixed-size window with k = 2"} ], "correct": "a", "explanation": "No specific window length is given, and the word \"longest\" signals the window should grow and shrink based on a condition, which is exactly what a variable-size window does." } ] } ``` ## Expanding and contracting the window Picture a rubber band stretched across a row of 100 seats, covering more seats as you pull it right. The moment it covers a seat that breaks a rule, say two people with the same ticket number both under the band, you let go of the left end until the rule holds again, then keep stretching right. The variable-window template captures that exact motion, and is worth knowing cold: ```python def variable_window_template(s: str) -> int: left = 0 best = 0 window_state = {} # whatever tracking the problem needs for right in range(len(s)): # 1. Expand: bring s[right] into the window window_state[s[right]] = window_state.get(s[right], 0) + 1 # 2. Contract: while window is invalid, shrink from the left while window_is_invalid(window_state): window_state[s[left]] -= 1 if window_state[s[left]] == 0: del window_state[s[left]] left += 1 # 3. Record: window [left, right] is now valid — update the answer best = max(best, right - left + 1) return best ``` ```javascript + // Generic template — for this demo, "invalid" means a character appears // more than once in the window, which is exactly the "longest substring // without repeating characters" case walked through later in this lesson. function windowIsInvalid(windowState) { return Object.values(windowState).some((count) => count > 1); } function variableWindowTemplate(s) { let left = 0; let best = 0; const windowState = {}; // whatever tracking the problem needs for (let right = 0; right < s.length; right++) { // 1. Expand: bring s[right] into the window windowState[s[right]] = (windowState[s[right]] || 0) + 1; // 2. Contract: while window is invalid, shrink from the left while (windowIsInvalid(windowState)) { windowState[s[left]] -= 1; if (windowState[s[left]] === 0) delete windowState[s[left]]; left += 1; } // 3. Record: window [left, right] is now valid — update the answer best = Math.max(best, right - left + 1); } return best; } ``` ```java + public class Main { public static void main(String[] args) { System.out.println(variableWindowTemplate("abcabcbb")); } // Generic template — for this demo, "invalid" means a character appears // more than once in the window, which is exactly the "longest substring // without repeating characters" case walked through later in this lesson. static boolean windowIsInvalid(java.util.Map windowState) { for (int count : windowState.values()) { if (count > 1) return true; } return false; } static int variableWindowTemplate(String s) { int left = 0; int best = 0; java.util.Map windowState = new java.util.HashMap<>(); // whatever tracking the problem needs for (int right = 0; right < s.length(); right++) { // 1. Expand: bring s[right] into the window char rightCh = s.charAt(right); windowState.merge(rightCh, 1, Integer::sum); // 2. Contract: while window is invalid, shrink from the left while (windowIsInvalid(windowState)) { char leftCh = s.charAt(left); windowState.put(leftCh, windowState.get(leftCh) - 1); if (windowState.get(leftCh) == 0) windowState.remove(leftCh); left += 1; } // 3. Record: window [left, right] is now valid — update the answer best = Math.max(best, right - left + 1); } return best; } } ``` The invariant that matters: the right pointer visits each index once, and the left pointer visits each index at most once, since it only moves forward. That is what makes the whole thing O(n) instead of O(n²): every index is added to the window once and removed at most once. Harder sliding-window problems, like Minimum Window Substring below, need to track more than a simple count. The real question is whether the window currently satisfies every required character count, not just how many characters it holds. The standard trick is a `have`/`need` counter pair: `need` is fixed, the number of distinct characters that must be satisfied, and `have` increments only when a character's count in the window first reaches its required count. Comparing `have == need` in O(1) avoids rescanning the whole frequency map on every step. > **Remember:** expand right always. Contract left only while the window is invalid. `have == need` checks validity in O(1) instead of rescanning. ```knowledge-check { "questions": [ { "id": "dsa-sliding-window-expand-contract-q1", "type": "mcq", "prompt": "In the variable-window template, why does the total work stay O(n) even though there's a while loop nested inside a for loop?", "options": [ {"id": "a", "text": "The left pointer only ever moves forward, so across the whole run it advances at most n times total"}, {"id": "b", "text": "The while loop only ever runs once per problem"}, {"id": "c", "text": "The right pointer resets to 0 after each contraction"}, {"id": "d", "text": "Hash map operations are always O(n)"} ], "correct": "a", "explanation": "Even though the while loop is nested, left never moves backward. Summed across every iteration of the outer loop, left advances at most n times in total, so the whole thing is O(n), not O(n²)." } ] } ``` ## Best Time to Buy and Sell Stock [Best Time to Buy and Sell Stock (LeetCode 121)](https://leetcode.com/problems/best-time-to-buy-and-sell-stock/) **Intuition:** This is a sliding window in disguise. The window is "buy day to sell day," and you want to maximize `price[sell] - price[buy]`. Instead of nested loops trying every pair, track the minimum price seen so far as you scan. That is an implicit left pointer that only ever moves forward when it finds a new minimum. **Approach:** Walk the array once. Track `min_price` seen so far. At each day, compute the profit if you sold today (`price - min_price`) and update the best profit. Update `min_price` if today's price is lower. ```python def max_profit(prices: list[int]) -> int: min_price = float("inf") best_profit = 0 for price in prices: min_price = min(min_price, price) best_profit = max(best_profit, price - min_price) return best_profit ``` ```javascript + function maxProfit(prices) { let minPrice = Infinity; let bestProfit = 0; for (const price of prices) { minPrice = Math.min(minPrice, price); bestProfit = Math.max(bestProfit, price - minPrice); } return bestProfit; } ``` ```java + public class Main { public static void main(String[] args) { int[] prices = {7, 1, 5, 3, 6, 4}; System.out.println(maxProfit(prices)); } static int maxProfit(int[] prices) { int minPrice = Integer.MAX_VALUE; int bestProfit = 0; for (int price : prices) { minPrice = Math.min(minPrice, price); bestProfit = Math.max(bestProfit, price - minPrice); } return bestProfit; } } ``` **Complexity:** Time O(n), space O(1). **Common mistakes:** - Nested loops checking every buy/sell pair: O(n²), works, but interviewers expect the O(n) version. - Updating `best_profit` before updating `min_price` on the same day. The order does not actually break this problem, since you cannot buy and sell on the same day at a profit from the exact same price, but get the order right by habit for variants. - Confusing this with the "multiple transactions allowed" variant (LeetCode 122), which needs a different, greedy approach. > **Remember:** track the minimum price seen so far. The best profit at any day is today's price minus that running minimum. ```knowledge-check { "questions": [ { "id": "dsa-sliding-window-buy-sell-stock-q1", "type": "mcq", "prompt": "What single running value does the O(n) solution to Best Time to Buy and Sell Stock track?", "options": [ {"id": "a", "text": "The minimum price seen so far"}, {"id": "b", "text": "The maximum price seen so far"}, {"id": "c", "text": "The average price so far"}, {"id": "d", "text": "The index of the first price"} ], "correct": "a", "explanation": "Tracking the minimum price seen so far lets you compute, at every day, the best possible profit if you sold today: current price minus that running minimum." } ] } ``` ## Longest Substring Without Repeating Characters [Longest Substring Without Repeating Characters (LeetCode 3)](https://leetcode.com/problems/longest-substring-without-repeating-characters/) **Intuition:** A classic variable-size window. Expand right, adding characters to a map. The moment you would add a duplicate, the window is invalid, so shrink from the left until the duplicate is gone. **Approach:** Use a hash map storing the last seen index of each character, instead of a boolean set. That lets you jump the left pointer straight to just past the duplicate's previous position, instead of moving it one step at a time. ```python def length_of_longest_substring(s: str) -> int: last_seen = {} # char -> most recent index left = 0 best = 0 for right, ch in enumerate(s): if ch in last_seen and last_seen[ch] >= left: left = last_seen[ch] + 1 last_seen[ch] = right best = max(best, right - left + 1) return best ``` ```javascript + function lengthOfLongestSubstring(s) { const lastSeen = new Map(); // char -> most recent index let left = 0; let best = 0; for (let right = 0; right < s.length; right++) { const ch = s[right]; if (lastSeen.has(ch) && lastSeen.get(ch) >= left) { left = lastSeen.get(ch) + 1; } lastSeen.set(ch, right); best = Math.max(best, right - left + 1); } return best; } ``` ```java + public class Main { public static void main(String[] args) { System.out.println(lengthOfLongestSubstring("abcabcbb")); } static int lengthOfLongestSubstring(String s) { java.util.Map lastSeen = new java.util.HashMap<>(); int left = 0; int best = 0; for (int right = 0; right < s.length(); right++) { char ch = s.charAt(right); if (lastSeen.containsKey(ch) && lastSeen.get(ch) >= left) { left = lastSeen.get(ch) + 1; } lastSeen.put(ch, right); best = Math.max(best, right - left + 1); } return best; } } ``` **Complexity:** Time O(n): each index visited once by `right`, and `left` jumps but never revisits. Space O(min(n, alphabet size)) for the map. **Common mistakes:** - Using a plain set and shrinking `left` one step at a time. Still O(n) amortized, but the last-seen-index version is cleaner and the standard answer. - Forgetting the `last_seen[ch] >= left` check. Without it, a stale index from before the current window yanks `left` backward incorrectly. - Off-by-one on window length: it is `right - left + 1`, not `right - left`. > **Remember:** store the last seen index of each character, and jump `left` straight past a duplicate instead of stepping one at a time. ```knowledge-check { "questions": [ { "id": "dsa-sliding-window-longest-substring-q1", "type": "mcq", "prompt": "Why must the check be `last_seen[ch] >= left`, and not just `ch in last_seen`?", "options": [ {"id": "a", "text": "A stale index from before the current window would otherwise pull `left` backward"}, {"id": "b", "text": "It makes the algorithm run in O(1) instead of O(n)"}, {"id": "c", "text": "It is only a style preference, not a correctness issue"}, {"id": "d", "text": "Without it, the map would grow unbounded"} ], "correct": "a", "explanation": "A character might have been seen before, but outside the current window (its last-seen index is less than left). Moving left backward to that stale position would be wrong; the >= left check makes sure only in-window duplicates matter." } ] } ``` ## Minimum Window Substring [Minimum Window Substring (LeetCode 76)](https://leetcode.com/problems/minimum-window-substring/) **Intuition:** Find the smallest window in `s` that contains every character of `t`, counting repeats. This needs the `have`/`need` tracking from earlier: expand right until the window satisfies every requirement in `t`, then greedily contract left as far as possible while staying valid, recording the smallest valid window found. **Approach:** 1. Build a frequency map of `t`. `need` is the number of distinct characters in `t`. 2. Expand `right` across `s`, updating a window frequency map. When a character's window count first equals its required count, increment `have`. 3. While `have == need` (window is valid), record the window if it is the smallest so far, then contract `left`, decrementing `have` if shrinking breaks a satisfied requirement. ```python from collections import Counter def min_window(s: str, t: str) -> str: if not s or not t: return "" need_counts = Counter(t) need = len(need_counts) window_counts = {} have = 0 left = 0 best_len = float("inf") best_left = 0 for right, ch in enumerate(s): window_counts[ch] = window_counts.get(ch, 0) + 1 if ch in need_counts and window_counts[ch] == need_counts[ch]: have += 1 while have == need: if (right - left + 1) < best_len: best_len = right - left + 1 best_left = left left_ch = s[left] window_counts[left_ch] -= 1 if left_ch in need_counts and window_counts[left_ch] < need_counts[left_ch]: have -= 1 left += 1 return "" if best_len == float("inf") else s[best_left:best_left + best_len] ``` ```javascript + function minWindow(s, t) { if (!s || !t) return ""; const needCounts = new Map(); for (const ch of t) needCounts.set(ch, (needCounts.get(ch) || 0) + 1); const need = needCounts.size; const windowCounts = new Map(); let have = 0; let left = 0; let bestLen = Infinity; let bestLeft = 0; for (let right = 0; right < s.length; right++) { const ch = s[right]; windowCounts.set(ch, (windowCounts.get(ch) || 0) + 1); if (needCounts.has(ch) && windowCounts.get(ch) === needCounts.get(ch)) { have += 1; } while (have === need) { if (right - left + 1 < bestLen) { bestLen = right - left + 1; bestLeft = left; } const leftCh = s[left]; windowCounts.set(leftCh, windowCounts.get(leftCh) - 1); if (needCounts.has(leftCh) && windowCounts.get(leftCh) < needCounts.get(leftCh)) { have -= 1; } left += 1; } } return bestLen === Infinity ? "" : s.slice(bestLeft, bestLeft + bestLen); } ``` ```java + public class Main { public static void main(String[] args) { System.out.println(minWindow("ADOBECODEBANC", "ABC")); } static String minWindow(String s, String t) { if (s.isEmpty() || t.isEmpty()) return ""; java.util.Map needCounts = new java.util.HashMap<>(); for (char ch : t.toCharArray()) { needCounts.merge(ch, 1, Integer::sum); } int need = needCounts.size(); java.util.Map windowCounts = new java.util.HashMap<>(); int have = 0; int left = 0; int bestLen = Integer.MAX_VALUE; int bestLeft = 0; for (int right = 0; right < s.length(); right++) { char ch = s.charAt(right); windowCounts.merge(ch, 1, Integer::sum); if (needCounts.containsKey(ch) && windowCounts.get(ch).equals(needCounts.get(ch))) { have += 1; } while (have == need) { if (right - left + 1 < bestLen) { bestLen = right - left + 1; bestLeft = left; } char leftCh = s.charAt(left); windowCounts.put(leftCh, windowCounts.get(leftCh) - 1); if (needCounts.containsKey(leftCh) && windowCounts.get(leftCh) < needCounts.get(leftCh)) { have -= 1; } left += 1; } } return bestLen == Integer.MAX_VALUE ? "" : s.substring(bestLeft, bestLeft + bestLen); } } ``` **Complexity:** Time O(|s| + |t|): building the `t` counter is O(|t|), and both pointers over `s` move forward only, giving O(|s|). Space O(|t|) for the need map, O(alphabet) for the window map. **Common mistakes:** - Recomputing "is the window valid" by scanning the whole frequency map every step, instead of tracking `have`/`need` incrementally. That turns O(n) into O(n·k). - Off-by-one when decrementing `have`: it must trigger only when the count drops below the required amount, not merely when it changes. - Not handling characters in `s` that are not in `t` at all. They should still count in `window_counts` (harmless) but never affect `have`. The five problems in this lesson split into two families it is easy to mix up under time pressure. Buy/Sell Stock and Longest Substring are single-condition windows: one running value (`min_price`, `last_seen`) is enough to decide when to move the left pointer. Minimum Window Substring is a multi-condition window: validity depends on satisfying several counts at once, which is why it needs `have`/`need` instead of a single tracked value. Before coding, ask how many conditions define "valid" for this window. One condition, track a running value. Several conditions, reach for `have`/`need`. > **Remember:** one condition to satisfy, track a single running value. Several conditions at once, use `have`/`need`. ```knowledge-check { "questions": [ { "id": "dsa-sliding-window-min-window-substring-q1", "type": "mcq", "prompt": "Why does Minimum Window Substring need a `have`/`need` counter pair instead of a single running value?", "options": [ {"id": "a", "text": "Validity depends on satisfying several distinct character counts at once, not one condition"}, {"id": "b", "text": "Because the strings can contain digits"}, {"id": "c", "text": "Because the window must be fixed size"}, {"id": "d", "text": "Because Python dictionaries can't store single counters"} ], "correct": "a", "explanation": "The window is valid only when every distinct character in t has been matched to its required count. That is multiple simultaneous conditions, which is exactly what have (satisfied so far) versus need (total required) is built to track in O(1)." } ] } ``` ## When sliding window doesn't apply Picture the rubber band again, stretched over seats with only positive ticket numbers written on them. Adding a seat to the band only ever adds to the running total, it never subtracts, so once the total is too high, letting go of seats on the left is the only way to bring it back down: stretching further right never helps. That is the one assumption every sliding-window template leans on: once a window becomes invalid, it stays invalid until you contract it. Expanding never fixes an invalid window; only contracting does. This holds when the tracked property moves in one direction as the window grows: a sum only increases as you add non-negative numbers, a distinct-count only increases as you add elements. It breaks the moment that stops being true. "Smallest subarray with sum at least target" works cleanly with non-negative numbers, because growing the window can only help reach the target, and shrinking can only hurt. Allow negative numbers, and adding an element can decrease the sum, so a window that looks invalid might become valid again by expanding further instead of contracting. At that point "contract while invalid" no longer proves anything. The test to run before reaching for sliding window: can you prove that once the window is invalid, it stays invalid until contracted? If you cannot, sliding window will not crash. It will silently return a wrong answer, which is the dangerous failure mode: no exception, nothing obviously wrong to warn you. For "subarray with sum exactly equal to k" where negatives are allowed, there is no one-directional property to exploit, so sliding window does not work. The standard tool instead is a prefix sum with a hash map of sums seen so far: ```python def subarray_sum(nums: list[int], k: int) -> int: count = 0 running_sum = 0 seen = {0: 1} # prefix sum 0 occurs once, before any elements for num in nums: running_sum += num # if (running_sum - k) was seen before, the subarray between # that point and here sums to exactly k count += seen.get(running_sum - k, 0) seen[running_sum] = seen.get(running_sum, 0) + 1 return count ``` This runs in O(n) time and space, the same complexity class as sliding window, but it is a different technique: no left/right pointers, no expand/contract. It applies exactly where sliding window's one-directional requirement fails. | Signal | Technique | |---|---| | Fixed size `k` given | Sliding window (fixed) | | "Longest/shortest subarray such that..." with a one-directional property | Sliding window (variable) | | Negative numbers and an exact sum target | Prefix sum + hash map | | Pointers start at both ends, move inward (like Container With Most Water) | Two pointers (a different technique despite the name) | Before submitting a sliding-window solution, check: - The one-directional assumption holds, or you have switched to prefix sum instead. - Window size is `right - left + 1`, not `right - left`. - Contract order: remove using the current `left`, then `left += 1`. - `if` vs `while` matches whether more than one contraction step is possible: fixed-size windows contract by exactly one (`if`), variable-size windows can need zero to many contractions per step (`while`). Using `if` where `while` is needed leaves the window invalid after only one contraction, the most common sliding-window bug. - The answer is recorded at the right point. For a longest-valid-subarray problem, record it after the contraction loop exits, once the window is valid again. For a shortest-valid-subarray problem, record it inside the contraction loop, on every contraction, since that is the smallest the window gets before it goes invalid again. - `left` never moves backward anywhere in the code. That is what makes the amortized O(n) argument hold. > **Remember:** sliding window needs "once invalid, stays invalid until contracted." Negative numbers usually break that; reach for prefix sum + hash map instead. ```knowledge-check { "questions": [ { "id": "dsa-sliding-window-when-it-fails-q1", "type": "mcq", "prompt": "Why doesn't sliding window work for \"subarray with sum exactly equal to k\" when the array can contain negative numbers?", "options": [ {"id": "a", "text": "Adding an element can decrease the sum, so an invalid window might become valid again by expanding, not just by contracting"}, {"id": "b", "text": "Sliding window only works on strings, never on numeric arrays"}, {"id": "c", "text": "The window size would need to be negative"}, {"id": "d", "text": "Hash maps can't store negative numbers as values"} ], "correct": "a", "explanation": "Sliding window depends on the window staying invalid once it becomes invalid, until you shrink it. With negative numbers, the running sum isn't one-directional as the window grows, so that assumption breaks and the technique gives wrong answers silently." } ] } ``` 32:T5f68,The Sliding Window lesson covered a window tracked by one running number, a sum, a minimum, a single count. Picture that same train of connected cars, but now the conductor also has to track something more detailed about the 3 cars in view: how many different colors are among them, or whether at most 2 of them are red. This lesson covers exactly that: windows that need a whole frequency count instead of one number, and windows that must satisfy more than one rule at once. This is the pattern behind most "longest/shortest substring or subarray with property X" interview questions once they get past the beginner stage. ## Fixed window with data structures Picture a security guard watching the last 4 people to badge through a door, keeping a running tally of how many different departments are among those 4. When a 5th person badges in, the guard does not recount all 4 people from scratch: they add the new person's department to the tally and remove the department of whoever just aged out the back of the window. A fixed-size window slides the same way, one element at a time. Instead of just a running sum, you often keep a frequency map or count that updates incrementally as elements enter and leave. ```python from collections import Counter def max_distinct_in_window(nums: list[int], k: int) -> int: counts = Counter(nums[:k]) best = len(counts) for i in range(k, len(nums)): counts[nums[i]] += 1 # element entering left = nums[i - k] counts[left] -= 1 # element leaving if counts[left] == 0: del counts[left] # keep the map accurate for len() checks best = max(best, len(counts)) return best ``` ```javascript + function maxDistinctInWindow(nums, k) { const counts = new Map(); for (let i = 0; i < k; i++) { counts.set(nums[i], (counts.get(nums[i]) || 0) + 1); } let best = counts.size; for (let i = k; i < nums.length; i++) { counts.set(nums[i], (counts.get(nums[i]) || 0) + 1); // element entering const left = nums[i - k]; counts.set(left, counts.get(left) - 1); // element leaving if (counts.get(left) === 0) { counts.delete(left); // keep the map accurate for size checks } best = Math.max(best, counts.size); } return best; } ``` ```java + import java.util.*; public class Main { public static void main(String[] args) { int[] nums = {1, 2, 1, 3, 4, 2, 3}; System.out.println(maxDistinctInWindow(nums, 4)); } static int maxDistinctInWindow(int[] nums, int k) { Map counts = new HashMap<>(); for (int i = 0; i < k; i++) { counts.merge(nums[i], 1, Integer::sum); } int best = counts.size(); for (int i = k; i < nums.length; i++) { counts.merge(nums[i], 1, Integer::sum); // element entering int left = nums[i - k]; counts.merge(left, -1, Integer::sum); // element leaving if (counts.get(left) == 0) { counts.remove(left); // keep the map accurate for size checks } best = Math.max(best, counts.size()); } return best; } } ``` Every fixed-window problem does exactly two things per step: add the incoming element's effect, remove the outgoing element's effect. That "effect" can be a sum, a frequency count, a max-tracking deque, or anything else you can maintain incrementally. Never recompute the whole window from scratch each step, since that turns an O(n) sliding window into O(n·k). > **Remember:** a fixed window does two things per step, add the new element's effect, remove the old element's effect. Never rescan the whole window. ```knowledge-check { "questions": [ { "id": "dsa-sliding-window-harder-fixed-window-q1", "type": "mcq", "prompt": "What mistake turns an O(n) fixed-size sliding window into O(n·k)?", "options": [ {"id": "a", "text": "Recomputing the window's state from scratch on every step instead of updating incrementally"}, {"id": "b", "text": "Using a Counter instead of a plain dictionary"}, {"id": "c", "text": "Starting the window at index 0 instead of index k"}, {"id": "d", "text": "Using k as the window size instead of n"} ], "correct": "a", "explanation": "The whole point of a fixed window is that each step does O(1) work: add the entering element, remove the leaving one. Rescanning all k elements every step multiplies the total cost by k." } ] } ``` ## Variable window tracking multiple conditions Picture that same guard, but now with two rules at once: "let at most 2 departments through together, and never let the group at the door grow past 15 people." The guard still does the same two things as before, let people in from the front, remove people from the back only when a rule breaks, just checking two rules instead of one. A variable-size window grows by advancing `right` and shrinks by advancing `left`, expanding while a condition holds and contracting when it is violated. The harder version tracks several conditions at once, for example "at most 2 distinct characters and window length under some bound." ```python def variable_window_skeleton(s: str, is_valid) -> int: left = 0 best = 0 window_state = {} # whatever data the condition needs: counts, max-freq, etc. for right in range(len(s)): # 1. expand: absorb s[right] into window_state window_state[s[right]] = window_state.get(s[right], 0) + 1 # 2. contract while the window violates the condition while not is_valid(window_state, right - left + 1): window_state[s[left]] -= 1 if window_state[s[left]] == 0: del window_state[s[left]] left += 1 # 3. record the best valid window at this right boundary best = max(best, right - left + 1) return best ``` ```javascript + function variableWindowSkeleton(s, isValid) { let left = 0; let best = 0; const windowState = new Map(); // whatever data the condition needs: counts, max-freq, etc. for (let right = 0; right < s.length; right++) { // 1. expand: absorb s[right] into windowState windowState.set(s[right], (windowState.get(s[right]) || 0) + 1); // 2. contract while the window violates the condition while (!isValid(windowState, right - left + 1)) { const leftChar = s[left]; windowState.set(leftChar, windowState.get(leftChar) - 1); if (windowState.get(leftChar) === 0) { windowState.delete(leftChar); } left++; } // 3. record the best valid window at this right boundary best = Math.max(best, right - left + 1); } return best; } ``` ```java + import java.util.*; import java.util.function.BiFunction; public class Main { public static void main(String[] args) { // Example: window valid while it has at most 2 distinct characters BiFunction, Integer, Boolean> atMostTwoDistinct = (state, length) -> state.size() <= 2; System.out.println(variableWindowSkeleton("eceba", atMostTwoDistinct)); } static int variableWindowSkeleton(String s, BiFunction, Integer, Boolean> isValid) { int left = 0; int best = 0; Map windowState = new HashMap<>(); // whatever data the condition needs for (int right = 0; right < s.length(); right++) { // 1. expand: absorb s[right] into windowState char rightChar = s.charAt(right); windowState.merge(rightChar, 1, Integer::sum); // 2. contract while the window violates the condition while (!isValid.apply(windowState, right - left + 1)) { char leftChar = s.charAt(left); windowState.merge(leftChar, -1, Integer::sum); if (windowState.get(leftChar) == 0) { windowState.remove(leftChar); } left++; } // 3. record the best valid window at this right boundary best = Math.max(best, right - left + 1); } return best; } } ``` The invariant to hold onto: `left` only ever moves forward. It never resets to 0 and rescans. That is what makes the whole algorithm O(n) instead of O(n²): each index enters and leaves the window at most once across the entire run. > **Remember:** `is_valid` can check any number of conditions at once, the expand/contract skeleton around it never changes. ```knowledge-check { "questions": [ { "id": "dsa-sliding-window-harder-multi-condition-q1", "type": "mcq", "prompt": "What changes between a simple sliding-window problem and one with multiple conditions to satisfy?", "options": [ {"id": "a", "text": "Only the validity check gets more complex; the expand/contract skeleton stays the same"}, {"id": "b", "text": "The left pointer must move backward sometimes"}, {"id": "c", "text": "You need two separate windows instead of one"}, {"id": "d", "text": "The time complexity becomes O(n²)"} ], "correct": "a", "explanation": "The expand-contract-record skeleton is unchanged. Only `is_valid` grows to check more than one condition against the window's tracked state. The algorithm is still O(n)." } ] } ``` ## Longest Repeating Character Replacement [LeetCode 424](https://leetcode.com/problems/longest-repeating-character-replacement/) **Intuition:** You can change up to `k` characters in a window to make every character the same. A window is valid if `window_length - count_of_most_frequent_char <= k`, which is exactly the number of characters you would need to replace. **Approach:** Expand `right`, tracking a frequency count and the running max frequency seen. `max_freq` never needs to decrease even as the window shrinks. It only ever underestimates slightly, but that is safe, since the answer only grows when a new max_freq is achieved, so a stale max_freq cannot produce a wrong, too-large answer. Shrink `left` only when the window becomes invalid. ```python def characterReplacement(s: str, k: int) -> int: counts = {} left = 0 max_freq = 0 best = 0 for right in range(len(s)): counts[s[right]] = counts.get(s[right], 0) + 1 max_freq = max(max_freq, counts[s[right]]) window_len = right - left + 1 if window_len - max_freq > k: counts[s[left]] -= 1 left += 1 best = max(best, right - left + 1) return best ``` ```javascript + function characterReplacement(s, k) { const counts = new Map(); let left = 0; let maxFreq = 0; let best = 0; for (let right = 0; right < s.length; right++) { const ch = s[right]; counts.set(ch, (counts.get(ch) || 0) + 1); maxFreq = Math.max(maxFreq, counts.get(ch)); const windowLen = right - left + 1; if (windowLen - maxFreq > k) { const leftChar = s[left]; counts.set(leftChar, counts.get(leftChar) - 1); left++; } best = Math.max(best, right - left + 1); } return best; } ``` ```java + import java.util.*; public class Main { public static void main(String[] args) { System.out.println(characterReplacement("AABABBA", 1)); } static int characterReplacement(String s, int k) { int[] counts = new int[26]; int left = 0; int maxFreq = 0; int best = 0; for (int right = 0; right < s.length(); right++) { int idx = s.charAt(right) - 'A'; counts[idx]++; maxFreq = Math.max(maxFreq, counts[idx]); int windowLen = right - left + 1; if (windowLen - maxFreq > k) { counts[s.charAt(left) - 'A']--; left++; } best = Math.max(best, right - left + 1); } return best; } } ``` **Complexity:** Time O(n), space O(1) (at most 26 letters in `counts`). **Common mistakes:** Trying to decrement `max_freq` when the window shrinks is unnecessary, and actually breaks the O(n) guarantee if done with a full rescan. Also, forgetting that `best` can be computed from the window length even mid-shrink, since the window never needs to shrink below the best length found so far; it can only stay the same or grow. > **Remember:** `max_freq` never needs to shrink, even when the window does. The answer can only grow. ```knowledge-check { "questions": [ { "id": "dsa-sliding-window-harder-char-replacement-q1", "type": "mcq", "prompt": "In Longest Repeating Character Replacement, what condition makes the current window invalid?", "options": [ {"id": "a", "text": "window_length minus the count of the most frequent character exceeds k"}, {"id": "b", "text": "The window contains more than 26 distinct characters"}, {"id": "c", "text": "The window length exceeds k"}, {"id": "d", "text": "The most frequent character's count exceeds k"} ], "correct": "a", "explanation": "window_length - max_freq is exactly the number of characters you'd need to change to make the whole window one repeated character. If that exceeds k, you can't afford it and must shrink." } ] } ``` ## Fruit Into Baskets [LeetCode 904](https://leetcode.com/problems/fruit-into-baskets/) **Intuition:** This is "longest subarray with at most 2 distinct values" wearing a word problem's clothes. Two baskets means at most 2 distinct fruit types in the window. **Approach:** Expand `right`, tracking fruit-type counts in a map. While the map has more than 2 keys, shrink `left`. ```python def totalFruit(fruits: list[int]) -> int: counts = {} left = 0 best = 0 for right, fruit in enumerate(fruits): counts[fruit] = counts.get(fruit, 0) + 1 while len(counts) > 2: left_fruit = fruits[left] counts[left_fruit] -= 1 if counts[left_fruit] == 0: del counts[left_fruit] left += 1 best = max(best, right - left + 1) return best ``` ```javascript + function totalFruit(fruits) { const counts = new Map(); let left = 0; let best = 0; for (let right = 0; right < fruits.length; right++) { const fruit = fruits[right]; counts.set(fruit, (counts.get(fruit) || 0) + 1); while (counts.size > 2) { const leftFruit = fruits[left]; counts.set(leftFruit, counts.get(leftFruit) - 1); if (counts.get(leftFruit) === 0) { counts.delete(leftFruit); } left++; } best = Math.max(best, right - left + 1); } return best; } ``` ```java + import java.util.*; public class Main { public static void main(String[] args) { int[] fruits = {1, 2, 1, 2, 3, 3, 1}; System.out.println(totalFruit(fruits)); } static int totalFruit(int[] fruits) { Map counts = new HashMap<>(); int left = 0; int best = 0; for (int right = 0; right < fruits.length; right++) { int fruit = fruits[right]; counts.merge(fruit, 1, Integer::sum); while (counts.size() > 2) { int leftFruit = fruits[left]; counts.merge(leftFruit, -1, Integer::sum); if (counts.get(leftFruit) == 0) { counts.remove(leftFruit); } left++; } best = Math.max(best, right - left + 1); } return best; } } ``` **Complexity:** Time O(n), space O(1) (at most 3 keys in `counts` at any moment, since you shrink the instant it hits 3). **Common mistakes:** Not recognizing the "2 baskets" framing as "at most 2 distinct values." Translating a word problem into the underlying pattern is the real skill being tested. Also, forgetting to delete zero-count entries from the map, which corrupts the `len(counts) > 2` check. > **Remember:** "2 baskets" is just "at most 2 distinct values" in a costume. Learn to spot the pattern under the wording. ```knowledge-check { "questions": [ { "id": "dsa-sliding-window-harder-fruit-baskets-q1", "type": "mcq", "prompt": "What underlying pattern does \"Fruit Into Baskets\" (2 baskets) map to?", "options": [ {"id": "a", "text": "Longest subarray with at most 2 distinct values"}, {"id": "b", "text": "Longest subarray with exactly 2 equal values"}, {"id": "c", "text": "Shortest subarray containing 2 distinct values"}, {"id": "d", "text": "Fixed-size window of length 2"} ], "correct": "a", "explanation": "Two baskets can each hold one fruit type, so the problem is really: find the longest contiguous run with at most 2 distinct values, the same variable-window-with-a-distinct-count-cap pattern used elsewhere." } ] } ``` ## Minimum Size Subarray Sum [LeetCode 209](https://leetcode.com/problems/minimum-size-subarray-sum/) **Intuition:** Find the shortest contiguous subarray with sum at least `target`. This flips the usual "maximize the window" pattern into "minimize the window while a condition holds," but the two-pointer mechanics are identical. **Approach:** Expand `right`, adding to a running sum. While the sum meets or exceeds `target`, record the window length and shrink `left`, continuing to shrink while it is still valid, since a smaller valid window is always better here. ```python def minSubArrayLen(target: int, nums: list[int]) -> int: left = 0 total = 0 best = float('inf') for right, num in enumerate(nums): total += num while total >= target: best = min(best, right - left + 1) total -= nums[left] left += 1 return best if best != float('inf') else 0 ``` ```javascript + function minSubArrayLen(target, nums) { let left = 0; let total = 0; let best = Infinity; for (let right = 0; right < nums.length; right++) { total += nums[right]; while (total >= target) { best = Math.min(best, right - left + 1); total -= nums[left]; left++; } } return best === Infinity ? 0 : best; } ``` ```java + public class Main { public static void main(String[] args) { int[] nums = {2, 3, 1, 2, 4, 3}; System.out.println(minSubArrayLen(7, nums)); } static int minSubArrayLen(int target, int[] nums) { int left = 0; int total = 0; int best = Integer.MAX_VALUE; for (int right = 0; right < nums.length; right++) { total += nums[right]; while (total >= target) { best = Math.min(best, right - left + 1); total -= nums[left]; left++; } } return best == Integer.MAX_VALUE ? 0 : best; } } ``` **Complexity:** Time O(n), space O(1). **Common mistakes:** Using `if` instead of `while` when shrinking. A single conditional shrink misses shorter valid windows that stay valid after one shrink step. Also, forgetting the "no valid subarray exists" case, which needs to return 0, not `inf` or -1. > **Remember:** when minimizing, shrink with a `while`, not an `if`, and record the answer on every shrink, not just once. ```knowledge-check { "questions": [ { "id": "dsa-sliding-window-harder-min-subarray-sum-q1", "type": "mcq", "prompt": "Why must the shrink step in Minimum Size Subarray Sum use `while total >= target` instead of `if`?", "options": [ {"id": "a", "text": "A single `if` could miss shorter valid windows that remain valid after more than one shrink"}, {"id": "b", "text": "`if` would cause an infinite loop"}, {"id": "c", "text": "`while` is required for Python syntax reasons"}, {"id": "d", "text": "`if` only works for negative numbers"} ], "correct": "a", "explanation": "After adding one element, the running sum might exceed target by a lot, meaning several elements could be removed from the left while staying valid. `if` only removes one; `while` finds the true minimum window at this right boundary." } ] } ``` ## Longest Subarray with Ones after Replacement Also known as Max Consecutive Ones III ([LeetCode 1004](https://leetcode.com/problems/max-consecutive-ones-iii/)), the array version of Longest Repeating Character Replacement. **Intuition:** You can flip up to `k` zeros to ones. Find the longest subarray you can make this way. This is structurally identical to Longest Repeating Character Replacement: a window is valid if `zero_count_in_window <= k`. **Approach:** Expand `right`, tracking the count of zeros in the window. Shrink `left` while the zero count exceeds `k`. ```python def longestOnes(nums: list[int], k: int) -> int: left = 0 zero_count = 0 best = 0 for right, num in enumerate(nums): if num == 0: zero_count += 1 while zero_count > k: if nums[left] == 0: zero_count -= 1 left += 1 best = max(best, right - left + 1) return best ``` ```javascript + function longestOnes(nums, k) { let left = 0; let zeroCount = 0; let best = 0; for (let right = 0; right < nums.length; right++) { if (nums[right] === 0) { zeroCount++; } while (zeroCount > k) { if (nums[left] === 0) { zeroCount--; } left++; } best = Math.max(best, right - left + 1); } return best; } ``` ```java + public class Main { public static void main(String[] args) { int[] nums = {1, 1, 1, 0, 0, 0, 1, 1, 1, 1, 0}; System.out.println(longestOnes(nums, 2)); } static int longestOnes(int[] nums, int k) { int left = 0; int zeroCount = 0; int best = 0; for (int right = 0; right < nums.length; right++) { if (nums[right] == 0) { zeroCount++; } while (zeroCount > k) { if (nums[left] == 0) { zeroCount--; } left++; } best = Math.max(best, right - left + 1); } return best; } } ``` **Complexity:** Time O(n), space O(1). **Common mistakes:** Building a full frequency map when a simple zero counter is enough. Only two values exist here, 0 and 1, so there is no need for a map, unlike the character-replacement version with 26 possible letters. Also, off-by-one when computing window length after the shrink loop exits. Step back, and the four problems above split into just two templates: "at most K distinct" (Fruit Into Baskets) and "longest valid window after up to K changes" (Character Replacement, Max Consecutive Ones III). Minimum Size Subarray Sum is the mirror image of both, shrinking instead of growing. Once you can name which template a new problem matches, the two-pointer skeleton writes itself. > **Remember:** four problems, two templates. Name the template first, then the code is mechanical. ```knowledge-check { "questions": [ { "id": "dsa-sliding-window-harder-ones-replacement-q1", "type": "mcq", "prompt": "Why doesn't Longest Subarray with Ones after Replacement need a full frequency map like Character Replacement does?", "options": [ {"id": "a", "text": "There are only two possible values (0 and 1), so a single zero counter is enough"}, {"id": "b", "text": "The array is always sorted"}, {"id": "c", "text": "It uses a fixed-size window instead of a variable one"}, {"id": "d", "text": "Frequency maps don't work on integer arrays"} ], "correct": "a", "explanation": "Character Replacement needs to track up to 26 letter counts, so a map earns its keep. Here there are only two possible values, so one integer counter for zeros captures everything the window needs to know." } ] } ``` 33:T5e33,Picture a guessing game: someone picks a whole number from 1 to 100, and after each guess they only say "higher" or "lower," never the number itself. Guess 50. Told "higher," guess 75. Told "lower," guess 62. Keep splitting whatever range is left in half, and you land on the exact number within 7 guesses, out of 100 possibilities. That is binary search: throw away half of what is left at every single step. It looks simple on paper, but small mistakes in exactly where the two boundaries sit cause an infinite loop the moment you write it live. Get the pattern right once, and it stops being just "search a sorted array." It also handles rotated arrays, 2D grids, and "find the best possible answer" optimization problems. ## Search space reduction In the guessing game above, the answer to "is the number higher than my guess?" flips from true to false exactly once as your guesses climb from 1 to 100. That one-way flip is what let you throw away half the range with full confidence every time. The technical name for that shape is **monotonic**: false for a run of values, then true for the rest (or the other way around), with exactly one flip point in between. Binary search works whenever you can define a monotonic yes/no rule over the search space. At each step you check the rule at the midpoint and throw away the half that cannot contain the answer. That guarantees the remaining space halves every step, which is what gives O(log n): a range of 100 shrinks to 50, then 25, then 12, then 6, then 3, then 1, about 7 steps, not 100 one-by-one guesses. ```python def binary_search(nums: list[int], target: int) -> int: lo, hi = 0, len(nums) - 1 while lo <= hi: mid = lo + (hi - lo) // 2 # avoids overflow in other languages, good habit if nums[mid] == target: return mid elif nums[mid] < target: lo = mid + 1 else: hi = mid - 1 return -1 ``` ```javascript + function binarySearch(nums, target) { let lo = 0; let hi = nums.length - 1; while (lo <= hi) { const mid = lo + Math.floor((hi - lo) / 2); if (nums[mid] === target) { return mid; } else if (nums[mid] < target) { lo = mid + 1; } else { hi = mid - 1; } } return -1; } ``` ```java + public class Main { public static void main(String[] args) { int[] nums = {1, 3, 5, 7, 9, 11}; System.out.println(binarySearch(nums, 7)); } static int binarySearch(int[] nums, int target) { int lo = 0; int hi = nums.length - 1; while (lo <= hi) { int mid = lo + (hi - lo) / 2; // avoids overflow, standard habit if (nums[mid] == target) { return mid; } else if (nums[mid] < target) { lo = mid + 1; } else { hi = mid - 1; } } return -1; } } ``` `lo + (hi - lo) // 2` instead of `(lo + hi) // 2` is a habit worth keeping even in Python, where integers never overflow. It shows you understand why the naive version breaks in languages with fixed-width integers. > **Remember:** binary search needs a monotonic yes/no rule: false, then true, with one flip point. Halving only works because of that. ```knowledge-check { "questions": [ { "id": "dsa-binary-search-search-space-q1", "type": "mcq", "prompt": "What property must a search space have for binary search to work on it?", "options": [ {"id": "a", "text": "A monotonic condition: false for a prefix, then true for the rest (or the reverse)"}, {"id": "b", "text": "It must contain only positive numbers"}, {"id": "c", "text": "It must have an even number of elements"}, {"id": "d", "text": "It must be a linked list, not an array"} ], "correct": "a", "explanation": "Binary search discards half the space at each step by evaluating a condition at the midpoint. That only works if the condition flips exactly once across the space, from false to true or true to false." } ] } ``` ## Finding boundaries (lower bound, upper bound) Picture a shelf of 1,000 books sorted by page count, with several books tied at exactly 300 pages. You want the position of the first 300-page book on the shelf, not just whether one exists. Many real problems ask exactly that: not "does target exist" but "where would target go" or "what is the first or last position satisfying a condition." That is a boundary search, and it needs a variant template that never lets `lo` and `hi` cross too early: ```python def lower_bound(nums: list[int], target: int) -> int: """First index where nums[index] >= target.""" lo, hi = 0, len(nums) while lo < hi: mid = lo + (hi - lo) // 2 if nums[mid] < target: lo = mid + 1 else: hi = mid return lo def upper_bound(nums: list[int], target: int) -> int: """First index where nums[index] > target.""" lo, hi = 0, len(nums) while lo < hi: mid = lo + (hi - lo) // 2 if nums[mid] <= target: lo = mid + 1 else: hi = mid return lo ``` ```javascript + function lowerBound(nums, target) { // First index where nums[index] >= target. let lo = 0; let hi = nums.length; while (lo < hi) { const mid = lo + Math.floor((hi - lo) / 2); if (nums[mid] < target) { lo = mid + 1; } else { hi = mid; } } return lo; } function upperBound(nums, target) { // First index where nums[index] > target. let lo = 0; let hi = nums.length; while (lo < hi) { const mid = lo + Math.floor((hi - lo) / 2); if (nums[mid] <= target) { lo = mid + 1; } else { hi = mid; } } return lo; } ``` ```java + public class Main { public static void main(String[] args) { int[] nums = {1, 2, 2, 2, 3, 5}; System.out.println(lowerBound(nums, 2)); System.out.println(upperBound(nums, 2)); } // First index where nums[index] >= target. static int lowerBound(int[] nums, int target) { int lo = 0; int hi = nums.length; while (lo < hi) { int mid = lo + (hi - lo) / 2; if (nums[mid] < target) { lo = mid + 1; } else { hi = mid; } } return lo; } // First index where nums[index] > target. static int upperBound(int[] nums, int target) { int lo = 0; int hi = nums.length; while (lo < hi) { int mid = lo + (hi - lo) / 2; if (nums[mid] <= target) { lo = mid + 1; } else { hi = mid; } } return lo; } } ``` The key differences from the exact-match template: `hi` starts at `len(nums)` (one past the end, meaning "not found, insert here"), the loop condition is `lo < hi` (not `<=`), and there is no early return, since the loop converges with `lo == hi` landing on the answer. Mixing one template's conventions with the other's is the number one source of infinite loops. > **Remember:** exact match uses `lo <= hi` and `mid ± 1`. Boundary search uses `lo < hi` and `hi = mid`. Never mix them. ```knowledge-check { "questions": [ { "id": "dsa-binary-search-boundaries-q1", "type": "mcq", "prompt": "What is the most common cause of an infinite loop when writing a boundary-search binary search?", "options": [ {"id": "a", "text": "Mixing the exact-match template's loop condition or update rule with the boundary-search template's"}, {"id": "b", "text": "Starting lo at 1 instead of 0"}, {"id": "c", "text": "Using recursion instead of a loop"}, {"id": "d", "text": "Forgetting to sort the array first"} ], "correct": "a", "explanation": "The exact-match template uses lo <= hi with mid ± 1 updates; boundary search uses lo < hi with hi = mid. Borrowing one template's loop condition while using the other's update rule is what causes lo and hi to never converge." } ] } ``` ## Monotonic functions and searching the answer Picture 10 packages that need to ship within 5 days on trucks of some capacity `C`. With `C = 1`, the trucks crawl and shipping takes 20 days: too slow. With `C = 1000`, everything fits on one truck and ships in 1 day: done. Somewhere between 1 and 1000, the answer to "can we finish within 5 days?" flips from no to yes and stays yes. "Search the answer" problems like this one are not phrased as array search at all, but they hide that same monotonic rule. Binary search over the answer space itself, capacities from 1 to the total weight, applying the boundary-search template to find the smallest `C` where the rule flips to true. Recognizing this shape, a yes/no question that flips one-directionally as some parameter increases, is what separates candidates who only know "binary search on a sorted array" from those who can apply it broadly. > **Remember:** if a yes/no question flips exactly once as a parameter grows, you can binary search that parameter, even if there's no array in sight. ```knowledge-check { "questions": [ { "id": "dsa-binary-search-monotonic-functions-q1", "type": "mcq", "prompt": "What lets you binary search a problem like \"minimum capacity to ship packages within D days\", which has no array to search?", "options": [ {"id": "a", "text": "The yes/no question \"can we ship within D days with capacity C?\" is monotonic in C"}, {"id": "b", "text": "The packages must already be sorted by weight"}, {"id": "c", "text": "Binary search always applies to any optimization problem"}, {"id": "d", "text": "D must be a power of two"} ], "correct": "a", "explanation": "As capacity C increases, \"can we ship within D days?\" goes from false to true and stays true. That one-directional flip is exactly the property binary search needs, letting you search over capacities instead of array indices." } ] } ``` ## Binary Search [Binary Search (LeetCode 704)](https://leetcode.com/problems/binary-search/) **Intuition:** The baseline exact-match template. Confirm you can write it cold, with correct bounds, in under a minute. **Approach:** Standard `lo <= hi` loop, compare the midpoint to target, narrow to the half that cannot contain it. ```python def search(nums: list[int], target: int) -> int: lo, hi = 0, len(nums) - 1 while lo <= hi: mid = lo + (hi - lo) // 2 if nums[mid] == target: return mid elif nums[mid] < target: lo = mid + 1 else: hi = mid - 1 return -1 ``` ```javascript + function search(nums, target) { let lo = 0; let hi = nums.length - 1; while (lo <= hi) { const mid = lo + Math.floor((hi - lo) / 2); if (nums[mid] === target) { return mid; } else if (nums[mid] < target) { lo = mid + 1; } else { hi = mid - 1; } } return -1; } ``` ```java + public class Main { public static void main(String[] args) { int[] nums = {-1, 0, 3, 5, 9, 12}; System.out.println(search(nums, 9)); } static int search(int[] nums, int target) { int lo = 0; int hi = nums.length - 1; while (lo <= hi) { int mid = lo + (hi - lo) / 2; if (nums[mid] == target) { return mid; } else if (nums[mid] < target) { lo = mid + 1; } else { hi = mid - 1; } } return -1; } } ``` **Complexity:** Time O(log n), space O(1). **Common mistakes:** - Using `hi = len(nums)` together with `lo <= hi` (mixing template conventions): causes an out-of-range access at `nums[hi]` when `hi == len(nums)`. - Forgetting `mid + 1` / `mid - 1` and instead setting `lo = mid` / `hi = mid`, which can infinite-loop when `lo` and `hi` are adjacent. > **Remember:** the exact-match template narrows with `mid + 1` / `mid - 1`, never plain `mid`. ```knowledge-check { "questions": [ { "id": "dsa-binary-search-basic-search-q1", "type": "mcq", "prompt": "What bug does setting `lo = mid` instead of `lo = mid + 1` in the exact-match template usually cause?", "options": [ {"id": "a", "text": "An infinite loop when lo and hi become adjacent"}, {"id": "b", "text": "It makes the search run in O(n) instead of O(log n)"}, {"id": "c", "text": "It skips half the array unnecessarily"}, {"id": "d", "text": "It only affects arrays with duplicate values"} ], "correct": "a", "explanation": "If nums[mid] < target and you set lo = mid, and mid happens to equal lo, the loop never makes progress, and lo/hi keep circling the same value forever." } ] } ``` ## Search in Rotated Sorted Array [Search in Rotated Sorted Array (LeetCode 33)](https://leetcode.com/problems/search-in-rotated-sorted-array/) **Intuition:** The array is not fully sorted, but at any midpoint, at least one half (left-of-mid or mid-to-right) is guaranteed to be normally sorted. Figure out which half is sorted, then check whether the target lies in that half's range. If so, recurse there; if not, recurse into the other half. **Approach:** Standard binary search loop, but before narrowing, check whether `nums[lo..mid]` is sorted by comparing `nums[lo]` and `nums[mid]`. ```python def search_rotated(nums: list[int], target: int) -> int: lo, hi = 0, len(nums) - 1 while lo <= hi: mid = lo + (hi - lo) // 2 if nums[mid] == target: return mid if nums[lo] <= nums[mid]: # left half is sorted if nums[lo] <= target < nums[mid]: hi = mid - 1 else: lo = mid + 1 else: # right half is sorted if nums[mid] < target <= nums[hi]: lo = mid + 1 else: hi = mid - 1 return -1 ``` ```javascript + function searchRotated(nums, target) { let lo = 0; let hi = nums.length - 1; while (lo <= hi) { const mid = lo + Math.floor((hi - lo) / 2); if (nums[mid] === target) return mid; if (nums[lo] <= nums[mid]) { // left half is sorted if (nums[lo] <= target && target < nums[mid]) { hi = mid - 1; } else { lo = mid + 1; } } else { // right half is sorted if (nums[mid] < target && target <= nums[hi]) { lo = mid + 1; } else { hi = mid - 1; } } } return -1; } ``` ```java + public class Main { public static void main(String[] args) { int[] nums = {4, 5, 6, 7, 0, 1, 2}; System.out.println(searchRotated(nums, 0)); } static int searchRotated(int[] nums, int target) { int lo = 0; int hi = nums.length - 1; while (lo <= hi) { int mid = lo + (hi - lo) / 2; if (nums[mid] == target) return mid; if (nums[lo] <= nums[mid]) { // left half is sorted if (nums[lo] <= target && target < nums[mid]) { hi = mid - 1; } else { lo = mid + 1; } } else { // right half is sorted if (nums[mid] < target && target <= nums[hi]) { lo = mid + 1; } else { hi = mid - 1; } } } return -1; } } ``` **Complexity:** Time O(log n), space O(1). **Common mistakes:** - Using `<` instead of `<=` when checking `nums[lo] <= nums[mid]`. With only one element, or two equal boundary values, this misclassifies which half is sorted. - Getting the boundary comparisons wrong (`nums[lo] <= target < nums[mid]`), missing a target that sits exactly at a boundary. > **Remember:** one half of a rotated array is always fully sorted. Find which one, then check if the target's range fits inside it. ```knowledge-check { "questions": [ { "id": "dsa-binary-search-rotated-array-q1", "type": "mcq", "prompt": "In Search in Rotated Sorted Array, how do you decide which half of the array to search next?", "options": [ {"id": "a", "text": "Determine which half is fully sorted, then check if the target's value falls within that half's range"}, {"id": "b", "text": "Always search the left half first"}, {"id": "c", "text": "Re-sort the whole array before searching"}, {"id": "d", "text": "Search whichever half is shorter"} ], "correct": "a", "explanation": "At least one half around any midpoint is guaranteed normally sorted. Once you know which one, you can check with plain range comparisons whether the target could be in it, and recurse into the correct half." } ] } ``` ## Find Minimum in Rotated Sorted Array [Find Minimum in Rotated Sorted Array (LeetCode 153)](https://leetcode.com/problems/find-minimum-in-rotated-sorted-array/) **Intuition:** The minimum is the rotation's "pivot point," the one place where `nums[i] > nums[i+1]`. Compare the midpoint to the rightmost element: if `nums[mid] > nums[hi]`, the minimum must be to the right of mid, since the rotation point has not been passed yet. Otherwise it is at or to the left of mid. **Approach:** A boundary-search style loop narrowing toward the pivot. ```python def find_min(nums: list[int]) -> int: lo, hi = 0, len(nums) - 1 while lo < hi: mid = lo + (hi - lo) // 2 if nums[mid] > nums[hi]: lo = mid + 1 else: hi = mid return nums[lo] ``` ```javascript + function findMin(nums) { let lo = 0; let hi = nums.length - 1; while (lo < hi) { const mid = lo + Math.floor((hi - lo) / 2); if (nums[mid] > nums[hi]) { lo = mid + 1; } else { hi = mid; } } return nums[lo]; } ``` ```java + public class Main { public static void main(String[] args) { int[] nums = {4, 5, 6, 7, 0, 1, 2}; System.out.println(findMin(nums)); } static int findMin(int[] nums) { int lo = 0; int hi = nums.length - 1; while (lo < hi) { int mid = lo + (hi - lo) / 2; if (nums[mid] > nums[hi]) { lo = mid + 1; } else { hi = mid; } } return nums[lo]; } } ``` **Complexity:** Time O(log n), space O(1). **Common mistakes:** - Comparing `nums[mid]` to `nums[lo]` instead of `nums[hi]`. This breaks when the left half itself is the sorted, non-rotated portion. - Using `lo <= hi` here instead of `lo < hi`. This template converges to a single index and does not need the equality case. > **Remember:** compare `nums[mid]` against `nums[hi]`, not `nums[lo]`, to find which side the rotation pivot is on. ```knowledge-check { "questions": [ { "id": "dsa-binary-search-find-min-rotated-q1", "type": "mcq", "prompt": "Why does Find Minimum in Rotated Sorted Array compare `nums[mid]` to `nums[hi]` instead of `nums[lo]`?", "options": [ {"id": "a", "text": "Comparing to nums[hi] correctly identifies which side of the pivot mid is on, even when the left half is the sorted, non-rotated part"}, {"id": "b", "text": "Comparing to nums[lo] would be faster"}, {"id": "c", "text": "It doesn't matter which one you compare to"}, {"id": "d", "text": "nums[hi] is always the minimum value"} ], "correct": "a", "explanation": "If nums[mid] > nums[hi], the rotation point (and the minimum) must be to the right of mid. Comparing against nums[lo] instead gives the wrong answer when the array's left half happens to be the unrotated, sorted side." } ] } ``` ## Search a 2D Matrix [Search a 2D Matrix (LeetCode 74)](https://leetcode.com/problems/search-a-2d-matrix/) **Intuition:** If each row is sorted and the first element of each row is greater than the last element of the previous row, the whole matrix is really a single sorted 1D array wearing a 2D shape. You can binary search over the flattened index space and convert back to `(row, col)`. **Approach:** Binary search over indices `0` to `rows*cols - 1`, converting a flat index to `(row, col)` with divmod. ```python def search_matrix(matrix: list[list[int]], target: int) -> bool: if not matrix or not matrix[0]: return False rows, cols = len(matrix), len(matrix[0]) lo, hi = 0, rows * cols - 1 while lo <= hi: mid = lo + (hi - lo) // 2 row, col = divmod(mid, cols) val = matrix[row][col] if val == target: return True elif val < target: lo = mid + 1 else: hi = mid - 1 return False ``` ```javascript + function searchMatrix(matrix, target) { if (!matrix.length || !matrix[0].length) return false; const rows = matrix.length; const cols = matrix[0].length; let lo = 0; let hi = rows * cols - 1; while (lo <= hi) { const mid = lo + Math.floor((hi - lo) / 2); const row = Math.floor(mid / cols); const col = mid % cols; const val = matrix[row][col]; if (val === target) { return true; } else if (val < target) { lo = mid + 1; } else { hi = mid - 1; } } return false; } ``` ```java + public class Main { public static void main(String[] args) { int[][] matrix = {{1, 3, 5, 7}, {10, 11, 16, 20}, {23, 30, 34, 60}}; System.out.println(searchMatrix(matrix, 3)); } static boolean searchMatrix(int[][] matrix, int target) { if (matrix.length == 0 || matrix[0].length == 0) return false; int rows = matrix.length; int cols = matrix[0].length; int lo = 0; int hi = rows * cols - 1; while (lo <= hi) { int mid = lo + (hi - lo) / 2; int row = mid / cols; int col = mid % cols; int val = matrix[row][col]; if (val == target) { return true; } else if (val < target) { lo = mid + 1; } else { hi = mid - 1; } } return false; } } ``` **Complexity:** Time O(log(rows·cols)), space O(1). **Common mistakes:** - Running two separate binary searches, one to find the row and one within it. Correct and still O(log n), but more code and more places to get bounds wrong than the flattened-index trick. - Getting `divmod(mid, cols)` backwards (`col, row` instead of `row, col`). Every problem in this lesson is one of two templates wearing a different costume: exact-match (`lo <= hi`, `mid ± 1`) or boundary-search (`lo < hi`, `hi = mid` on the "keep" branch). The rotated-array and matrix problems still narrow to an exact target, so they use the exact-match shape. Finding a boundary or a pivot uses the converging shape instead. Pick the template from what the problem asks (exact value vs. a boundary), then apply it mechanically. Most binary search bugs come from borrowing one template's loop condition with the other's update rule. > **Remember:** a sorted-rows matrix with each row starting above the previous row's end is one flat sorted array in disguise. Binary search the flat index. ```knowledge-check { "questions": [ { "id": "dsa-binary-search-2d-matrix-q1", "type": "mcq", "prompt": "What makes it possible to binary search a 2D matrix as if it were a single sorted array?", "options": [ {"id": "a", "text": "Each row is sorted, and each row's first element is greater than the previous row's last element"}, {"id": "b", "text": "The matrix must be square (same number of rows and columns)"}, {"id": "c", "text": "Every value in the matrix must be unique"}, {"id": "d", "text": "The matrix must contain only positive integers"} ], "correct": "a", "explanation": "Those two conditions together mean reading the matrix row by row produces one fully sorted sequence, so a flat index from 0 to rows*cols-1 behaves exactly like an index into a normal sorted array." } ] } ``` 34:T7404,Picture a stack of plates on a kitchen counter, 20 plates high. You add a new plate on top, and you take one off the top too. You never grab a plate from the middle without knocking the rest over. That is a stack, one of the simplest data structures there is, and the monotonic stack pattern built on top of it solves a whole family of "next greater or smaller element" problems in O(n), about 20 steps for 20 elements, that look like they need O(n²), about 400 comparisons, at first glance. ## LIFO principle Like the plate stack, a data-structure stack supports two core operations, both O(1) (one step, regardless of how many plates are underneath): `push` (add to the top) and `pop` (remove from the top). Last-In-First-Out (LIFO) means the most recently added element leaves first, the same way the plate you set down last is the one you pick back up first. A queue (FIFO, First-In-First-Out) is the opposite: like a line at a coffee shop, the oldest person waiting is served first. ```python stack = [] stack.append(1) # push stack.append(2) stack.append(3) stack.pop() # removes 3 stack[-1] # peek: 2, without removing ``` ```javascript + const stack = []; stack.push(1); // push stack.push(2); stack.push(3); stack.pop(); // removes 3 stack[stack.length - 1]; // peek: 2, without removing ``` ```java + import java.util.ArrayDeque; import java.util.Deque; public class Main { public static void main(String[] args) { Deque stack = new ArrayDeque<>(); stack.push(1); // push stack.push(2); stack.push(3); stack.pop(); // removes 3 int peek = stack.peek(); // peek: 2, without removing System.out.println("Peek: " + peek); } } ``` Python's `list` is a perfectly good stack (`append`/`pop` from the end are both O(1) amortized). Do not use `list.insert(0, x)` or `list.pop(0)` as a stack; those are O(n) because they shift every element. > **Remember:** a stack is last-in-first-out. In Python, `append`/`pop` from the end. Never insert or pop from the front of a list-backed stack. ```knowledge-check { "questions": [ { "id": "dsa-stacks-lifo-q1", "type": "mcq", "prompt": "Why is `list.pop(0)` a poor choice for popping from a Python-list-backed stack?", "options": [ {"id": "a", "text": "It is O(n) because every remaining element has to shift left"}, {"id": "b", "text": "It raises an exception on an empty list"}, {"id": "c", "text": "It removes the wrong element"}, {"id": "d", "text": "Python lists don't support pop(0) at all"} ], "correct": "a", "explanation": "Removing from the front of a Python list shifts every remaining element one slot left, an O(n) operation. Popping from the end with plain pop() is O(1) amortized, which is what a stack should cost." } ] } ``` ## Stack vs recursion Picture a stack of sticky notes, one added every time you pause a task to start a smaller sub-task, and removed the moment that sub-task finishes and you go back to the one below it. That is exactly what a computer does on every recursive function call: it is an implicit stack. Each call pushes a new frame, its local variables and where to return to, onto the call stack, and returning pops it off. Any recursive algorithm can be rewritten iteratively with an explicit stack you manage yourself. That matters for two reasons. 1. Deep recursion can hit Python's recursion limit (1,000 calls deep by default) or overflow the real call stack, the same way a pile of 1,000 sticky notes eventually topples. An explicit stack has no such limit, bounded only by however much heap memory is free. 2. Interviewers sometimes ask directly for the iterative version, to check that you understand what recursion is doing underneath. The mechanical translation: whatever you would pass as arguments to the recursive call, push as a tuple onto an explicit stack instead. A `while stack:` loop replaces the call. ```python # Recursive DFS def dfs_recursive(node, visited): if node in visited: return visited.add(node) for neighbor in node.neighbors: dfs_recursive(neighbor, visited) # Iterative DFS using an explicit stack def dfs_iterative(start): visited = set() stack = [start] while stack: node = stack.pop() if node in visited: continue visited.add(node) for neighbor in node.neighbors: if neighbor not in visited: stack.append(neighbor) return visited ``` ```javascript + // Recursive DFS function dfsRecursive(node, visited) { if (visited.has(node)) { return; } visited.add(node); for (const neighbor of node.neighbors) { dfsRecursive(neighbor, visited); } } // Iterative DFS using an explicit stack function dfsIterative(start) { const visited = new Set(); const stack = [start]; while (stack.length > 0) { const node = stack.pop(); if (visited.has(node)) { continue; } visited.add(node); for (const neighbor of node.neighbors) { if (!visited.has(neighbor)) { stack.push(neighbor); } } } return visited; } ``` ```java + import java.util.ArrayDeque; import java.util.ArrayList; import java.util.HashSet; import java.util.List; import java.util.Set; public class Main { public static void main(String[] args) { GraphNode a = new GraphNode("A"); GraphNode b = new GraphNode("B"); GraphNode c = new GraphNode("C"); a.neighbors.add(b); b.neighbors.add(c); c.neighbors.add(a); // cycle Set visitedRecursive = new HashSet<>(); dfsRecursive(a, visitedRecursive); System.out.println("Recursive visited: " + visitedRecursive.size()); Set visitedIterative = dfsIterative(a); System.out.println("Iterative visited: " + visitedIterative.size()); } // Recursive DFS static void dfsRecursive(GraphNode node, Set visited) { if (visited.contains(node)) { return; } visited.add(node); for (GraphNode neighbor : node.neighbors) { dfsRecursive(neighbor, visited); } } // Iterative DFS using an explicit stack static Set dfsIterative(GraphNode start) { Set visited = new HashSet<>(); ArrayDeque stack = new ArrayDeque<>(); stack.push(start); while (!stack.isEmpty()) { GraphNode node = stack.pop(); if (visited.contains(node)) { continue; } visited.add(node); for (GraphNode neighbor : node.neighbors) { if (!visited.contains(neighbor)) { stack.push(neighbor); } } } return visited; } } class GraphNode { String label; List neighbors = new ArrayList<>(); GraphNode(String label) { this.label = label; } } ``` > **Remember:** every recursive call is a push; every return is a pop. An explicit stack turns recursion into a loop with no depth limit. ```knowledge-check { "questions": [ { "id": "dsa-stacks-vs-recursion-q1", "type": "mcq", "prompt": "What is the main advantage of an iterative DFS using an explicit stack over a recursive DFS?", "options": [ {"id": "a", "text": "It avoids hitting the language's recursion depth limit on deep graphs"}, {"id": "b", "text": "It visits nodes in a different order that's always faster"}, {"id": "c", "text": "It uses less memory in every case"}, {"id": "d", "text": "It doesn't need a visited set"} ], "correct": "a", "explanation": "A recursive call stack has a fixed depth limit (1000 in Python by default) and can overflow on deep or highly connected graphs. An explicit stack on the heap has no such limit." } ] } ``` ## Monotonic stack pattern Picture 100 people lined up by height, and every time a taller person walks up to join the back of the line, everyone shorter than them steps out, because they just found the next taller person behind them. Whoever is left in line is always ordered shortest to tallest. A monotonic stack works the same way: it keeps its elements in strictly increasing or strictly decreasing order at all times. When a new element would break that order, you pop elements off the top until the order holds again, and each pop is a signal: the element just popped just found its next greater (or smaller) element. This is the trick behind "next greater element" style problems. Instead of scanning forward from each element to find the next bigger one, which for 100 elements can mean close to 10,000 comparisons (O(n²)), you keep a stack of indices whose answer is not known yet, and resolve them as you scan once, left to right, about 100 steps total (O(n), since each index is pushed once and popped at most once). ```python def next_greater_elements(nums: list[int]) -> list[int]: n = len(nums) result = [-1] * n stack = [] # indices, values decreasing bottom to top for i in range(n): while stack and nums[stack[-1]] < nums[i]: idx = stack.pop() result[idx] = nums[i] stack.append(i) return result ``` ```javascript + function nextGreaterElements(nums) { const n = nums.length; const result = new Array(n).fill(-1); const stack = []; // indices, values decreasing bottom to top for (let i = 0; i < n; i++) { while (stack.length > 0 && nums[stack[stack.length - 1]] < nums[i]) { const idx = stack.pop(); result[idx] = nums[i]; } stack.push(i); } return result; } ``` ```java + import java.util.ArrayDeque; import java.util.Arrays; import java.util.Deque; public class Main { public static void main(String[] args) { int[] nums = {2, 1, 2, 4, 3}; System.out.println(Arrays.toString(nextGreaterElements(nums))); } static int[] nextGreaterElements(int[] nums) { int n = nums.length; int[] result = new int[n]; Arrays.fill(result, -1); Deque stack = new ArrayDeque<>(); // indices, values decreasing bottom to top for (int i = 0; i < n; i++) { while (!stack.isEmpty() && nums[stack.peek()] < nums[i]) { int idx = stack.pop(); result[idx] = nums[i]; } stack.push(i); } return result; } } ``` ### Stack using a linked list Arrays make a fine stack, but interviewers sometimes ask for one implemented over a singly linked list, where push and pop happen at the head so both stay O(1) with no resizing: ```python class StackNode: def __init__(self, val, next=None): self.val = val self.next = next class LinkedListStack: def __init__(self): self.head = None self.size = 0 def push(self, val) -> None: self.head = StackNode(val, self.head) self.size += 1 def pop(self): if not self.head: raise IndexError("pop from empty stack") val = self.head.val self.head = self.head.next self.size -= 1 return val def peek(self): if not self.head: raise IndexError("peek from empty stack") return self.head.val def is_empty(self) -> bool: return self.head is None ``` ```javascript + class StackNode { constructor(val, next = null) { this.val = val; this.next = next; } } class LinkedListStack { constructor() { this.head = null; this.size = 0; } push(val) { this.head = new StackNode(val, this.head); this.size += 1; } pop() { if (!this.head) { throw new Error('pop from empty stack'); } const val = this.head.val; this.head = this.head.next; this.size -= 1; return val; } peek() { if (!this.head) { throw new Error('peek from empty stack'); } return this.head.val; } isEmpty() { return this.head === null; } } ``` ```java + public class Main { public static void main(String[] args) { LinkedListStack stack = new LinkedListStack(); stack.push(1); stack.push(2); stack.push(3); System.out.println("Popped: " + stack.pop()); System.out.println("Peek: " + stack.peek()); System.out.println("Empty? " + stack.isEmpty()); } } class StackNode { int val; StackNode next; StackNode(int val, StackNode next) { this.val = val; this.next = next; } } class LinkedListStack { private StackNode head; private int size; void push(int val) { head = new StackNode(val, head); size += 1; } int pop() { if (head == null) { throw new IllegalStateException("pop from empty stack"); } int val = head.val; head = head.next; size -= 1; return val; } int peek() { if (head == null) { throw new IllegalStateException("peek from empty stack"); } return head.val; } boolean isEmpty() { return head == null; } } ``` No amortized cost here. Every operation is worst-case O(1) since there is never a resize, at the cost of the per-node pointer overhead an array-backed stack does not pay. > **Remember:** a monotonic stack turns "find the next greater element for everyone" into one O(n) pass. Each index is pushed once, popped at most once. ```knowledge-check { "questions": [ { "id": "dsa-stacks-monotonic-q1", "type": "mcq", "prompt": "In a monotonic decreasing stack used for \"next greater element,\" what does popping an index off the stack signal?", "options": [ {"id": "a", "text": "The current element is the popped index's next greater element"}, {"id": "b", "text": "The stack is now empty"}, {"id": "c", "text": "An error occurred and the algorithm should restart"}, {"id": "d", "text": "The popped index has no next greater element"} ], "correct": "a", "explanation": "You only pop when the current value breaks the decreasing order, meaning the current value is bigger than the value at the popped index. That's exactly the definition of \"next greater element\" for the popped index." } ] } ``` ## Valid Parentheses [Valid Parentheses (LeetCode 20)](https://leetcode.com/problems/valid-parentheses/) **Intuition:** Every closing bracket must match the most recently opened, unclosed bracket. "Most recent unmatched" is exactly what a stack tracks. **Approach:** Push opening brackets. On a closing bracket, pop and check it matches the expected opener; a mismatch or an empty stack means invalid. The string is valid only if the stack is empty at the end. ```python def is_valid(s: str) -> bool: pairs = {")": "(", "]": "[", "}": "{"} stack = [] for ch in s: if ch in pairs: if not stack or stack.pop() != pairs[ch]: return False else: stack.append(ch) return not stack ``` ```javascript + function isValid(s) { const pairs = { ')': '(', ']': '[', '}': '{' }; const stack = []; for (const ch of s) { if (ch in pairs) { if (stack.length === 0 || stack.pop() !== pairs[ch]) { return false; } } else { stack.push(ch); } } return stack.length === 0; } ``` ```java + import java.util.ArrayDeque; import java.util.Deque; import java.util.Map; public class Main { public static void main(String[] args) { System.out.println(isValid("()[]{}")); System.out.println(isValid("(]")); } static boolean isValid(String s) { Map pairs = Map.of(')', '(', ']', '[', '}', '{'); Deque stack = new ArrayDeque<>(); for (char ch : s.toCharArray()) { if (pairs.containsKey(ch)) { if (stack.isEmpty() || stack.pop() != pairs.get(ch)) { return false; } } else { stack.push(ch); } } return stack.isEmpty(); } } ``` **Complexity:** Time O(n), space O(n) worst case (all openers). **Common mistakes:** - Forgetting to check `not stack` before popping on a closing bracket. A lone `")"` would crash or misbehave without that guard. - Forgetting the final `not stack` check. A string like `"((("` never triggers a mismatch mid-scan, but is still invalid. > **Remember:** push openers, pop and match on closers, and the stack must end empty. ```knowledge-check { "questions": [ { "id": "dsa-stacks-valid-parentheses-q1", "type": "mcq", "prompt": "Why does Valid Parentheses need to check that the stack is empty at the very end, not just during the scan?", "options": [ {"id": "a", "text": "A string of only unmatched openers, like \"(((\", never triggers a mismatch mid-scan but is still invalid"}, {"id": "b", "text": "The final check improves the time complexity"}, {"id": "c", "text": "It's only needed for strings longer than 10 characters"}, {"id": "d", "text": "It prevents integer overflow"} ], "correct": "a", "explanation": "Unmatched openers never cause a mismatch while scanning; they just sit on the stack. Only checking the stack is empty at the end catches a string that opened brackets it never closed." } ] } ``` ## Daily Temperatures [Daily Temperatures (LeetCode 739)](https://leetcode.com/problems/daily-temperatures/) **Intuition:** For each day, find how many days until a warmer temperature. This is "next greater element," but returning the distance instead of the value. **Approach:** A monotonic decreasing stack of indices. When the current temperature beats the temperature at the stack's top index, pop and record `current_index - popped_index` as the wait. ```python def daily_temperatures(temperatures: list[int]) -> list[int]: n = len(temperatures) result = [0] * n stack = [] # indices with temps not yet resolved, decreasing order for i, temp in enumerate(temperatures): while stack and temperatures[stack[-1]] < temp: prev_idx = stack.pop() result[prev_idx] = i - prev_idx stack.append(i) return result ``` ```javascript + function dailyTemperatures(temperatures) { const n = temperatures.length; const result = new Array(n).fill(0); const stack = []; // indices with temps not yet resolved, decreasing order for (let i = 0; i < n; i++) { while (stack.length > 0 && temperatures[stack[stack.length - 1]] < temperatures[i]) { const prevIdx = stack.pop(); result[prevIdx] = i - prevIdx; } stack.push(i); } return result; } ``` ```java + import java.util.ArrayDeque; import java.util.Arrays; import java.util.Deque; public class Main { public static void main(String[] args) { int[] temperatures = {73, 74, 75, 71, 69, 72, 76, 73}; System.out.println(Arrays.toString(dailyTemperatures(temperatures))); } static int[] dailyTemperatures(int[] temperatures) { int n = temperatures.length; int[] result = new int[n]; Deque stack = new ArrayDeque<>(); // indices with temps not yet resolved, decreasing order for (int i = 0; i < n; i++) { while (!stack.isEmpty() && temperatures[stack.peek()] < temperatures[i]) { int prevIdx = stack.pop(); result[prevIdx] = i - prevIdx; } stack.push(i); } return result; } } ``` **Complexity:** Time O(n): each index pushed once, popped at most once. Space O(n) worst case (strictly decreasing input). **Common mistakes:** - Brute-forcing with a nested loop (O(n²)). Works, but it is the naive baseline interviewers expect you to improve on. - Storing values instead of indices on the stack. You need the index to compute the distance, not the temperature. > **Remember:** store indices, not values, so you can compute the distance once you find the warmer day. ```knowledge-check { "questions": [ { "id": "dsa-stacks-daily-temperatures-q1", "type": "mcq", "prompt": "In Daily Temperatures, why does the monotonic stack store indices instead of temperature values?", "options": [ {"id": "a", "text": "The index is needed to compute the distance (days to wait) once a warmer temperature is found"}, {"id": "b", "text": "Indices take less memory than temperatures"}, {"id": "c", "text": "Temperatures can't be compared directly"}, {"id": "d", "text": "It makes the stack strictly increasing instead of decreasing"} ], "correct": "a", "explanation": "The answer needed is a distance in days, current index minus the stored index. You can always look up the temperature at a stored index, but you can't recover the index from just a temperature value." } ] } ``` ## Largest Rectangle in Histogram [Largest Rectangle in Histogram (LeetCode 84)](https://leetcode.com/problems/largest-rectangle-in-histogram/) **Intuition:** For each bar, the largest rectangle using that bar as its shortest (limiting) height extends as far left and right as neighboring bars stay at least as tall. A monotonic increasing stack finds, for each bar, the nearest shorter bar on both sides in a single O(n) pass; those boundaries set the max width for that bar's height. **Approach:** Keep a stack of indices with increasing heights. When the current bar is shorter than the stack's top, pop and compute the area using the popped bar's height, with width equal to the current index minus the new stack top's index minus 1 (or just the current index if the stack is empty). Append a sentinel height of `0` at the end to flush the remaining bars. ```python def largest_rectangle_area(heights: list[int]) -> int: stack = [] # indices, increasing height max_area = 0 heights = heights + [0] # sentinel to flush the stack for i, h in enumerate(heights): while stack and heights[stack[-1]] > h: height = heights[stack.pop()] width = i if not stack else i - stack[-1] - 1 max_area = max(max_area, height * width) stack.append(i) return max_area ``` ```javascript + function largestRectangleArea(heights) { const stack = []; // indices, increasing height let maxArea = 0; const withSentinel = [...heights, 0]; // sentinel to flush the stack for (let i = 0; i < withSentinel.length; i++) { const h = withSentinel[i]; while (stack.length > 0 && withSentinel[stack[stack.length - 1]] > h) { const height = withSentinel[stack.pop()]; const width = stack.length === 0 ? i : i - stack[stack.length - 1] - 1; maxArea = Math.max(maxArea, height * width); } stack.push(i); } return maxArea; } ``` ```java + import java.util.ArrayDeque; import java.util.Deque; public class Main { public static void main(String[] args) { int[] heights = {2, 1, 5, 6, 2, 3}; System.out.println(largestRectangleArea(heights)); } static int largestRectangleArea(int[] heights) { int n = heights.length; int[] withSentinel = new int[n + 1]; System.arraycopy(heights, 0, withSentinel, 0, n); // sentinel 0 to flush the stack Deque stack = new ArrayDeque<>(); // indices, increasing height int maxArea = 0; for (int i = 0; i < withSentinel.length; i++) { int h = withSentinel[i]; while (!stack.isEmpty() && withSentinel[stack.peek()] > h) { int height = withSentinel[stack.pop()]; int width = stack.isEmpty() ? i : i - stack.peek() - 1; maxArea = Math.max(maxArea, height * width); } stack.push(i); } return maxArea; } } ``` **Complexity:** Time O(n): each index pushed and popped once. Space O(n). **Common mistakes:** - Forgetting the sentinel `0` at the end, which leaves bars still on the stack unresolved. - Getting the width formula wrong. It is `i - stack[-1] - 1` (excluding both boundary indices), not `i - stack[-1]`. - Trying brute force (checking every pair of left/right boundaries, O(n²) or O(n³)) as the final answer instead of a starting point. > **Remember:** a monotonic increasing stack finds each bar's nearest shorter neighbor on both sides in one pass. Add a sentinel zero to flush the stack at the end. ```knowledge-check { "questions": [ { "id": "dsa-stacks-largest-rectangle-q1", "type": "mcq", "prompt": "Why does the Largest Rectangle in Histogram solution append a sentinel value of 0 at the end of the heights array?", "options": [ {"id": "a", "text": "It forces every remaining bar on the stack to be popped and its area computed"}, {"id": "b", "text": "It increases the maximum possible area"}, {"id": "c", "text": "It is required to make the array length even"}, {"id": "d", "text": "It prevents the stack from ever being empty"} ], "correct": "a", "explanation": "Without a final value shorter than everything on the stack, some bars would never get popped and their rectangle areas would never be computed. The sentinel 0 guarantees every bar eventually gets resolved." } ] } ``` ## Min Stack [Min Stack (LeetCode 155)](https://leetcode.com/problems/min-stack/) **Intuition:** A normal stack gives O(1) push, pop, and top, but O(n) minimum, since you would have to scan. Track the running minimum alongside each element, so every push carries "the minimum including me," giving O(1) minimum retrieval too. **Approach:** Store `(value, current_min)` pairs in a single stack, where `current_min` is the smaller of the new value and the previous entry's minimum. ```python class MinStack: def __init__(self): self.stack = [] # each entry: (value, min_so_far) def push(self, val: int) -> None: current_min = val if not self.stack else min(val, self.stack[-1][1]) self.stack.append((val, current_min)) def pop(self) -> None: self.stack.pop() def top(self) -> int: return self.stack[-1][0] def getMin(self) -> int: return self.stack[-1][1] ``` ```javascript + class MinStack { constructor() { this.stack = []; // each entry: [value, minSoFar] } push(val) { const currentMin = this.stack.length === 0 ? val : Math.min(val, this.stack[this.stack.length - 1][1]); this.stack.push([val, currentMin]); } pop() { this.stack.pop(); } top() { return this.stack[this.stack.length - 1][0]; } getMin() { return this.stack[this.stack.length - 1][1]; } } ``` ```java + import java.util.ArrayDeque; import java.util.Deque; public class Main { public static void main(String[] args) { MinStack minStack = new MinStack(); minStack.push(3); minStack.push(1); minStack.push(2); System.out.println("Min: " + minStack.getMin()); minStack.pop(); System.out.println("Top: " + minStack.top()); System.out.println("Min: " + minStack.getMin()); } } class MinStack { private static class Entry { int value; int minSoFar; Entry(int value, int minSoFar) { this.value = value; this.minSoFar = minSoFar; } } private final Deque stack = new ArrayDeque<>(); void push(int val) { int currentMin = stack.isEmpty() ? val : Math.min(val, stack.peek().minSoFar); stack.push(new Entry(val, currentMin)); } void pop() { stack.pop(); } int top() { return stack.peek().value; } int getMin() { return stack.peek().minSoFar; } } ``` **Complexity:** Time O(1) for every operation. Space O(n): double the per-element storage, for the min tracking. **Common mistakes:** - Recomputing `min(self.stack)` inside `getMin()`. Correct, but O(n), defeating the purpose. - Using one global `min` variable with no way to restore the previous minimum on `pop()`. That only works if you never pop the current minimum, which is not guaranteed. > **Remember:** store the running minimum alongside every value, so popping an old minimum automatically reveals the one before it. ```knowledge-check { "questions": [ { "id": "dsa-stacks-min-stack-q1", "type": "mcq", "prompt": "Why does Min Stack store a (value, min_so_far) pair at every level instead of one global minimum variable?", "options": [ {"id": "a", "text": "So that popping the current minimum automatically restores the correct previous minimum"}, {"id": "b", "text": "It makes push and pop run faster"}, {"id": "c", "text": "A single global variable can't be updated inside a class"}, {"id": "d", "text": "It reduces the space complexity to O(1)"} ], "correct": "a", "explanation": "A single global minimum has no way to know the previous minimum once the current one is popped. Storing the minimum-so-far at each stack level means popping always reveals the correct minimum for what remains." } ] } ``` 35:T7ab3,Picture a company org chart: a CEO at the top, managers below, workers below them. That shape, one node with children, children with their own children, is a tree. Most tree problems have a simple trick: the answer for a node is built from the answers of its children. Write a function that trusts its own recursive calls, and the tree problem nearly solves itself. ## Visiting every node in a tree Take this small tree of numbers: ``` 5 / \ 3 8 / \ \ 1 4 9 ``` There are four common ways to walk through it, and they differ only in *when* you record a node compared to its children. - **Preorder** (node, left, right): record the node first, then its subtrees. `5, 3, 1, 4, 8, 9`. Good for copying or serializing a tree, since you write the parent before you write its children. - **Inorder** (left, node, right): record the node between its subtrees. `1, 3, 4, 5, 8, 9`. For a search tree (covered in the next lesson), this always comes out sorted. - **Postorder** (left, right, node): record the node last. `1, 4, 3, 9, 8, 5`. Use this whenever children must be fully handled before the parent, such as deleting a tree from the bottom up, or totaling up a subtree's values. - **Level order**: visit row by row, left to right: `[5], [3, 8], [1, 4, 9]`. This one isn't recursive at all; it uses a queue, the same tool BFS uses on graphs later in this course. ```python class TreeNode: def __init__(self, val=0, left=None, right=None): self.val = val self.left = left self.right = right def preorder(root): if root is None: return [] return [root.val] + preorder(root.left) + preorder(root.right) def inorder(root): if root is None: return [] return inorder(root.left) + [root.val] + inorder(root.right) def postorder(root): if root is None: return [] return postorder(root.left) + postorder(root.right) + [root.val] from collections import deque def level_order(root): if root is None: return [] result = [] queue = deque([root]) while queue: level = [] for _ in range(len(queue)): node = queue.popleft() level.append(node.val) if node.left: queue.append(node.left) if node.right: queue.append(node.right) result.append(level) return result ``` ```javascript + class TreeNode { constructor(val = 0, left = null, right = null) { this.val = val; this.left = left; this.right = right; } } function preorder(root) { if (root === null) { return []; } return [root.val, ...preorder(root.left), ...preorder(root.right)]; } function inorder(root) { if (root === null) { return []; } return [...inorder(root.left), root.val, ...inorder(root.right)]; } function postorder(root) { if (root === null) { return []; } return [...postorder(root.left), ...postorder(root.right), root.val]; } function levelOrder(root) { if (root === null) { return []; } const result = []; const queue = [root]; while (queue.length > 0) { const level = []; const levelSize = queue.length; for (let i = 0; i < levelSize; i++) { const node = queue.shift(); level.push(node.val); if (node.left) { queue.push(node.left); } if (node.right) { queue.push(node.right); } } result.push(level); } return result; } ``` ```java + import java.util.ArrayDeque; import java.util.ArrayList; import java.util.Deque; import java.util.List; public class Main { public static void main(String[] args) { TreeNode root = new TreeNode(1, new TreeNode(2), new TreeNode(3)); System.out.println("Preorder: " + preorder(root)); System.out.println("Inorder: " + inorder(root)); System.out.println("Postorder: " + postorder(root)); System.out.println("Level order: " + levelOrder(root)); } static List preorder(TreeNode root) { List result = new ArrayList<>(); if (root == null) { return result; } result.add(root.val); result.addAll(preorder(root.left)); result.addAll(preorder(root.right)); return result; } static List inorder(TreeNode root) { List result = new ArrayList<>(); if (root == null) { return result; } result.addAll(inorder(root.left)); result.add(root.val); result.addAll(inorder(root.right)); return result; } static List postorder(TreeNode root) { List result = new ArrayList<>(); if (root == null) { return result; } result.addAll(postorder(root.left)); result.addAll(postorder(root.right)); result.add(root.val); return result; } static List> levelOrder(TreeNode root) { List> result = new ArrayList<>(); if (root == null) { return result; } Deque queue = new ArrayDeque<>(); queue.add(root); while (!queue.isEmpty()) { List level = new ArrayList<>(); int levelSize = queue.size(); for (int i = 0; i < levelSize; i++) { TreeNode node = queue.poll(); level.add(node.val); if (node.left != null) { queue.add(node.left); } if (node.right != null) { queue.add(node.right); } } result.add(level); } return result; } } class TreeNode { int val; TreeNode left; TreeNode right; TreeNode(int val) { this(val, null, null); } TreeNode(int val, TreeNode left, TreeNode right) { this.val = val; this.left = left; this.right = right; } } ``` The versions above build small lists and glue them together with `+`. That reads well, but real code usually passes one shared list down through the recursion instead, so it doesn't keep building and throwing away little lists. Know both; be ready to write the faster one if asked. > **Remember:** preorder writes the parent first, postorder writes it last, inorder puts it in the middle. Level order is the odd one out: no recursion, just a queue. ```knowledge-check { "questions": [ { "id": "dsa-trees-basics-traversal-order-q1", "type": "mcq", "prompt": "For the tree 5 (left 3, right 8), where 3 has children 1 and 4, what does an inorder traversal produce?", "options": [ {"id": "a", "text": "1, 3, 4, 5, 8"}, {"id": "b", "text": "5, 3, 1, 4, 8"}, {"id": "c", "text": "1, 4, 3, 8, 5"}, {"id": "d", "text": "5, 8, 3, 4, 1"} ], "correct": "a", "explanation": "Inorder visits left subtree, then the node, then right subtree. That order for this tree is 1, 3, 4 (left side), then 5, then 8." } ] } ``` ## Doing it without recursion Every recursive traversal above has an iterative version that uses an explicit stack instead of the call stack. Interviewers ask for this to check that you understand what the recursion was actually doing, not that you memorized three lines. Preorder is the easiest to convert: push right before left, so left comes off the stack first. ```python def preorder_iterative(root): if root is None: return [] result = [] stack = [root] while stack: node = stack.pop() result.append(node.val) if node.right: stack.append(node.right) if node.left: stack.append(node.left) return result ``` ```javascript + function preorderIterative(root) { if (root === null) { return []; } const result = []; const stack = [root]; while (stack.length > 0) { const node = stack.pop(); result.push(node.val); if (node.right) { stack.push(node.right); } if (node.left) { stack.push(node.left); } } return result; } ``` ```java + import java.util.ArrayDeque; import java.util.ArrayList; import java.util.Deque; import java.util.List; public class Main { public static void main(String[] args) { TreeNode root = new TreeNode(1, new TreeNode(2), new TreeNode(3)); System.out.println(preorderIterative(root)); } static List preorderIterative(TreeNode root) { List result = new ArrayList<>(); if (root == null) { return result; } Deque stack = new ArrayDeque<>(); stack.push(root); while (!stack.isEmpty()) { TreeNode node = stack.pop(); result.add(node.val); if (node.right != null) { stack.push(node.right); } if (node.left != null) { stack.push(node.left); } } return result; } } class TreeNode { int val; TreeNode left; TreeNode right; TreeNode(int val) { this(val, null, null); } TreeNode(int val, TreeNode left, TreeNode right) { this.val = val; this.left = left; this.right = right; } } ``` Inorder is trickier, since you can't just push both children at once. You have to walk all the way left first, process the node you land on, then step right: ```python def inorder_iterative(root): result = [] stack = [] node = root while stack or node: while node: # go as far left as possible stack.append(node) node = node.left node = stack.pop() # process the node result.append(node.val) node = node.right # then explore the right subtree return result ``` ```javascript + function inorderIterative(root) { const result = []; const stack = []; let node = root; while (stack.length > 0 || node !== null) { while (node !== null) { // go as far left as possible stack.push(node); node = node.left; } node = stack.pop(); // process the node result.push(node.val); node = node.right; // then explore the right subtree } return result; } ``` ```java + import java.util.ArrayDeque; import java.util.ArrayList; import java.util.Deque; import java.util.List; public class Main { public static void main(String[] args) { TreeNode root = new TreeNode(2, new TreeNode(1), new TreeNode(3)); System.out.println(inorderIterative(root)); } static List inorderIterative(TreeNode root) { List result = new ArrayList<>(); Deque stack = new ArrayDeque<>(); TreeNode node = root; while (!stack.isEmpty() || node != null) { while (node != null) { // go as far left as possible stack.push(node); node = node.left; } node = stack.pop(); // process the node result.add(node.val); node = node.right; // then explore the right subtree } return result; } } class TreeNode { int val; TreeNode left; TreeNode right; TreeNode(int val) { this(val, null, null); } TreeNode(int val, TreeNode left, TreeNode right) { this.val = val; this.left = left; this.right = right; } } ``` Postorder iteratively is the fiddly one. Do a "node, right, left" walk (swap the push order from preorder above), then reverse the result. That flips it into "left, right, node" for free. ```python def postorder_iterative(root): if root is None: return [] result = [] stack = [root] while stack: node = stack.pop() result.append(node.val) if node.left: stack.append(node.left) if node.right: stack.append(node.right) return result[::-1] ``` ```javascript + function postorderIterative(root) { if (root === null) { return []; } const result = []; const stack = [root]; while (stack.length > 0) { const node = stack.pop(); result.push(node.val); if (node.left) { stack.push(node.left); } if (node.right) { stack.push(node.right); } } return result.reverse(); } ``` ```java + import java.util.ArrayDeque; import java.util.ArrayList; import java.util.Collections; import java.util.Deque; import java.util.List; public class Main { public static void main(String[] args) { TreeNode root = new TreeNode(1, new TreeNode(2), new TreeNode(3)); System.out.println(postorderIterative(root)); } static List postorderIterative(TreeNode root) { List result = new ArrayList<>(); if (root == null) { return result; } Deque stack = new ArrayDeque<>(); stack.push(root); while (!stack.isEmpty()) { TreeNode node = stack.pop(); result.add(node.val); if (node.left != null) { stack.push(node.left); } if (node.right != null) { stack.push(node.right); } } Collections.reverse(result); return result; } } class TreeNode { int val; TreeNode left; TreeNode right; TreeNode(int val) { this(val, null, null); } TreeNode(int val, TreeNode left, TreeNode right) { this.val = val; this.left = left; this.right = right; } } ``` > **Remember:** preorder-iterative pushes right then left. Postorder-iterative is preorder's "node, right, left" twin, reversed at the end. Inorder needs a "walk left, then pop" loop. ```knowledge-check { "questions": [ { "id": "dsa-trees-basics-iterative-q1", "type": "mcq", "prompt": "Why do interviewers sometimes ask for the iterative version of a tree traversal instead of the recursive one?", "options": [ {"id": "a", "text": "To check you understand what the recursion is doing, not just that you memorized it"}, {"id": "b", "text": "Because recursive traversals are always incorrect"}, {"id": "c", "text": "Because iterative versions run in less time"}, {"id": "d", "text": "Because trees can't be traversed recursively in most languages"} ], "correct": "a", "explanation": "Recursive and iterative traversals have the same time complexity. The iterative version forces you to make the call stack's behavior explicit with your own stack, which shows real understanding." } ] } ``` ## Two facts about a tree's shape Two properties come up again and again, so get them cold. **Height**: how many edges are on the longest path from a node down to a leaf. A single node has height 0. Height is naturally computed bottom-up, a postorder-shaped recursion: a node's height is 1 more than the taller of its two children's heights. **Balance**: a tree is height-balanced if, at every node, the heights of its left and right subtrees differ by at most 1. Checking this the naive way, calling a height function at every node, costs O(n²) in the worst case on a long, skewed tree, since you recompute overlapping heights over and over. The fast version computes height and checks balance in the same single postorder pass, O(n) total. > **Remember:** compute height bottom-up. Check balance in the same pass as computing height, don't call a separate height function per node. ```knowledge-check { "questions": [ { "id": "dsa-trees-basics-height-balance-q1", "type": "mcq", "prompt": "Why is checking tree balance by calling a separate height function at every node slow?", "options": [ {"id": "a", "text": "It recomputes overlapping subtree heights many times, giving O(n²) on a skewed tree"}, {"id": "b", "text": "Height cannot be computed recursively"}, {"id": "c", "text": "It only works on balanced trees"}, {"id": "d", "text": "It requires level-order traversal, which needs extra memory"} ], "correct": "a", "explanation": "Calling height() at every node re-walks the subtrees below it again and again. Folding the balance check into one postorder pass that returns height avoids the repeated work, giving O(n)." } ] } ``` ## Invert Binary Tree [Invert Binary Tree (LeetCode 226)](https://leetcode.com/problems/invert-binary-tree/) Flip a photo of the tree left to right: every left child becomes a right child and vice versa, all the way down. That is the whole problem. It is a postorder-shaped recursion: invert both subtrees, then swap them onto the node. **Approach:** Base case: `None` inverts to `None`. Recursive case: swap `root.left` and `root.right`, after first inverting each of them. ```python def invert_tree(root): if root is None: return None root.left, root.right = invert_tree(root.right), invert_tree(root.left) return root ``` ```javascript + function invertTree(root) { if (root === null) { return null; } [root.left, root.right] = [invertTree(root.right), invertTree(root.left)]; return root; } ``` ```java + public class Main { public static void main(String[] args) { TreeNode root = new TreeNode(1, new TreeNode(2), new TreeNode(3)); TreeNode inverted = invertTree(root); System.out.println("New left: " + inverted.left.val + ", new right: " + inverted.right.val); } static TreeNode invertTree(TreeNode root) { if (root == null) { return null; } TreeNode newLeft = invertTree(root.right); TreeNode newRight = invertTree(root.left); root.left = newLeft; root.right = newRight; return root; } } class TreeNode { int val; TreeNode left; TreeNode right; TreeNode(int val) { this(val, null, null); } TreeNode(int val, TreeNode left, TreeNode right) { this.val = val; this.left = left; this.right = right; } } ``` **Complexity:** Time O(n), visits every node once. Space O(h) for the recursion stack, where h is the tree's height (O(log n) if balanced, O(n) if it's a long chain). **Common mistakes:** - Swapping `root.left`/`root.right` before recursing on the original children. That inverts the wrong subtree. The simultaneous-assignment version above sidesteps this by finishing both recursive calls before either assignment happens. - Forgetting the `None` base case, which causes infinite recursion. > **Remember:** invert the children first, then swap them onto the parent, not the other way around. ```knowledge-check { "questions": [ { "id": "dsa-trees-basics-invert-q1", "type": "mcq", "prompt": "What bug happens if you swap root.left and root.right before recursing into the original children?", "options": [ {"id": "a", "text": "You end up inverting the wrong subtree, since the children were swapped before you descended into them"}, {"id": "b", "text": "Nothing, order doesn't matter here"}, {"id": "c", "text": "The tree becomes unbalanced"}, {"id": "d", "text": "It only fails on trees with more than 100 nodes"} ], "correct": "a", "explanation": "If you swap first, the recursive calls that follow now walk into the swapped subtrees, not the original ones, corrupting the result. Evaluate both recursive calls first, then assign." } ] } ``` ## Maximum Depth of Binary Tree [Maximum Depth of Binary Tree (LeetCode 104)](https://leetcode.com/problems/maximum-depth-of-binary-tree/) The depth of a tree is 1 (for the current node) plus whichever of its two subtrees goes deeper. That's the entire recursion, a textbook postorder shape. **Approach:** Base case: an empty tree has depth 0. Recursive case: `1 + max(depth(left), depth(right))`. ```python def max_depth(root) -> int: if root is None: return 0 return 1 + max(max_depth(root.left), max_depth(root.right)) ``` ```javascript + function maxDepth(root) { if (root === null) { return 0; } return 1 + Math.max(maxDepth(root.left), maxDepth(root.right)); } ``` ```java + public class Main { public static void main(String[] args) { TreeNode root = new TreeNode(1, new TreeNode(2, new TreeNode(4), null), new TreeNode(3)); System.out.println(maxDepth(root)); } static int maxDepth(TreeNode root) { if (root == null) { return 0; } return 1 + Math.max(maxDepth(root.left), maxDepth(root.right)); } } class TreeNode { int val; TreeNode left; TreeNode right; TreeNode(int val) { this(val, null, null); } TreeNode(int val, TreeNode left, TreeNode right) { this.val = val; this.left = left; this.right = right; } } ``` **Complexity:** Time O(n), space O(h) for the recursion stack. **Common mistakes:** - Off-by-one: forgetting the `+ 1` for the current node, or adding it twice. - Writing an iterative BFS version without correctly counting levels; you need to count levels, not nodes. > **Remember:** depth is 1 plus the deeper child's depth. An empty tree has depth 0. ```knowledge-check { "questions": [ { "id": "dsa-trees-basics-max-depth-q1", "type": "mcq", "prompt": "What is the space complexity of the recursive max-depth solution, in terms of tree height h?", "options": [ {"id": "a", "text": "O(h), for the recursion call stack"}, {"id": "b", "text": "O(1), constant space"}, {"id": "c", "text": "O(n), always, regardless of shape"}, {"id": "d", "text": "O(log n), always"} ], "correct": "a", "explanation": "Every recursive call adds a frame to the call stack until it hits a leaf. The deepest that stack ever gets is the tree's height h, so space is O(h): O(log n) if balanced, O(n) on a skewed chain." } ] } ``` ## Same Tree [Same Tree (LeetCode 100)](https://leetcode.com/problems/same-tree/) Two trees match if their roots hold the same value and both pairs of subtrees also match. That's a direct structural recursion comparing two trees side by side, step by step. **Approach:** Base cases: both `None` means equal; exactly one `None` means not equal. Recursive case: values match AND left subtrees match AND right subtrees match. ```python def is_same_tree(p, q) -> bool: if p is None and q is None: return True if p is None or q is None: return False return ( p.val == q.val and is_same_tree(p.left, q.left) and is_same_tree(p.right, q.right) ) ``` ```javascript + function isSameTree(p, q) { if (p === null && q === null) { return true; } if (p === null || q === null) { return false; } return ( p.val === q.val && isSameTree(p.left, q.left) && isSameTree(p.right, q.right) ); } ``` ```java + public class Main { public static void main(String[] args) { TreeNode p = new TreeNode(1, new TreeNode(2), new TreeNode(3)); TreeNode q = new TreeNode(1, new TreeNode(2), new TreeNode(3)); System.out.println(isSameTree(p, q)); } static boolean isSameTree(TreeNode p, TreeNode q) { if (p == null && q == null) { return true; } if (p == null || q == null) { return false; } return p.val == q.val && isSameTree(p.left, q.left) && isSameTree(p.right, q.right); } } class TreeNode { int val; TreeNode left; TreeNode right; TreeNode(int val) { this(val, null, null); } TreeNode(int val, TreeNode left, TreeNode right) { this.val = val; this.left = left; this.right = right; } } ``` **Complexity:** Time O(min(n, m)), stops the instant the trees diverge. Space O(min(h_p, h_q)) recursion stack. **Common mistakes:** - Reading `p.val` before checking whether `p` is `None`. That crashes with an attribute error on `None`. > **Remember:** check both-None and either-None first. Only then compare values and recurse into both children. ```knowledge-check { "questions": [ { "id": "dsa-trees-basics-same-tree-q1", "type": "mcq", "prompt": "In Same Tree, why must you check for None before reading p.val or q.val?", "options": [ {"id": "a", "text": "Reading a value on a None node crashes the program"}, {"id": "b", "text": "None nodes always have value 0, which would give a wrong answer"}, {"id": "c", "text": "It's only a style preference, not a correctness issue"}, {"id": "d", "text": "Trees can never legally contain a None node"} ], "correct": "a", "explanation": "A None (or null) node has no .val attribute. Comparing values before ruling out None causes a crash, so the None checks must come first." } ] } ``` ## Binary Tree Level Order Traversal [Binary Tree Level Order Traversal (LeetCode 102)](https://leetcode.com/problems/binary-tree-level-order-traversal/) "Group nodes by their depth" is exactly what BFS gives you for free, as long as you process the queue one full level at a time instead of one node at a time. **Approach:** Use a queue. At each step, note the current queue length; that number is exactly how many nodes belong to the current level. Pop that many, collect their values, and enqueue their children for the next round. ```python from collections import deque def level_order_traversal(root): if root is None: return [] result = [] queue = deque([root]) while queue: level_size = len(queue) level_values = [] for _ in range(level_size): node = queue.popleft() level_values.append(node.val) if node.left: queue.append(node.left) if node.right: queue.append(node.right) result.append(level_values) return result ``` ```javascript + function levelOrderTraversal(root) { if (root === null) { return []; } const result = []; const queue = [root]; while (queue.length > 0) { const levelSize = queue.length; const levelValues = []; for (let i = 0; i < levelSize; i++) { const node = queue.shift(); levelValues.push(node.val); if (node.left) { queue.push(node.left); } if (node.right) { queue.push(node.right); } } result.push(levelValues); } return result; } ``` ```java + import java.util.ArrayDeque; import java.util.ArrayList; import java.util.Deque; import java.util.List; public class Main { public static void main(String[] args) { TreeNode root = new TreeNode(3, new TreeNode(9), new TreeNode(20, new TreeNode(15), new TreeNode(7))); System.out.println(levelOrderTraversal(root)); } static List> levelOrderTraversal(TreeNode root) { List> result = new ArrayList<>(); if (root == null) { return result; } Deque queue = new ArrayDeque<>(); queue.add(root); while (!queue.isEmpty()) { int levelSize = queue.size(); List levelValues = new ArrayList<>(); for (int i = 0; i < levelSize; i++) { TreeNode node = queue.poll(); levelValues.add(node.val); if (node.left != null) { queue.add(node.left); } if (node.right != null) { queue.add(node.right); } } result.add(levelValues); } return result; } } class TreeNode { int val; TreeNode left; TreeNode right; TreeNode(int val) { this(val, null, null); } TreeNode(int val, TreeNode left, TreeNode right) { this.val = val; this.left = left; this.right = right; } } ``` **Complexity:** Time O(n), every node is enqueued and dequeued exactly once. Space O(w) for the queue, where w is the widest level, plus O(n) for the output. **Common mistakes:** - Not snapshotting the queue's length before the inner loop. Checking the live length inside the loop lets it grow as you enqueue children, which merges levels together. - Using `list.pop(0)` (O(n) per call) instead of `deque.popleft()` (O(1)), or using a stack where a queue is needed. > **Remember:** snapshot the queue length before draining it. That number is exactly one level's worth of nodes. ```knowledge-check { "questions": [ { "id": "dsa-trees-basics-level-order-q1", "type": "mcq", "prompt": "In the level-order BFS pattern, what does snapshotting len(queue) before the inner loop accomplish?", "options": [ {"id": "a", "text": "It fixes exactly how many nodes belong to the current level, before their children start getting enqueued"}, {"id": "b", "text": "It reduces the time complexity from O(n) to O(log n)"}, {"id": "c", "text": "It prevents the queue from ever being empty"}, {"id": "d", "text": "It is only a style choice with no effect on correctness"} ], "correct": "a", "explanation": "If you check the queue's length again mid-loop, newly enqueued children of the current level get counted into it, silently merging two levels into one. Snapshotting the count first keeps levels separate." } ] } ``` ## Naming the shape before you code Every problem in this lesson reduces to one of three shapes: does a node's answer depend only on its children's answers (postorder: Invert, Max Depth)? Does it depend on walking two trees in lockstep (Same Tree)? Or does it need to go level by level (Level Order)? Spend ten seconds naming which shape a new tree problem fits before writing any code. Guessing at the recursion instead of naming the shape first is where most tree bugs start. > **Remember:** name the shape (postorder, lockstep comparison, or level-by-level) before you write a single line. ```knowledge-check { "questions": [ { "id": "dsa-trees-basics-naming-shape-q1", "type": "mcq", "prompt": "What are the three recurring 'shapes' tree problems in this lesson fall into?", "options": [ {"id": "a", "text": "Postorder (children answer first), lockstep comparison of two trees, and level-by-level (BFS)"}, {"id": "b", "text": "Sorting, searching, and hashing"}, {"id": "c", "text": "Recursive, iterative, and parallel"}, {"id": "d", "text": "Insert, delete, and update"} ], "correct": "a", "explanation": "Invert and Max Depth build their answer from the children first (postorder). Same Tree walks two trees together. Level Order needs a queue instead of recursion. Naming which shape fits saves time before coding." } ] } ``` 36:T6d34,Think of a filing cabinet where every folder to the left of a given folder holds a smaller number, and every folder to the right holds a bigger one. That one rule, repeated at every level, is what turns a plain binary tree into a binary search tree (BST). It is a small rule with a big payoff: it makes search, insert, and delete run in O(log n) instead of O(n), and it opens up a whole family of "rebuild or validate this tree" interview problems. ## The BST rule For every node in a BST: everything in its left subtree is smaller than the node's value, and everything in its right subtree is bigger. That rule holds transitively across the whole subtree, not just against the immediate children. A common bug, covered below, comes from checking it only one level down. ```python class TreeNode: def __init__(self, val=0, left=None, right=None): self.val = val self.left = left self.right = right ``` ```javascript + class TreeNode { constructor(val = 0, left = null, right = null) { this.val = val; this.left = left; this.right = right; } } ``` ```java + public class Main { public static void main(String[] args) { TreeNode root = new TreeNode(5, new TreeNode(3), new TreeNode(8)); System.out.println("Root: " + root.val + ", left: " + root.left.val + ", right: " + root.right.val); } } class TreeNode { int val; TreeNode left; TreeNode right; TreeNode(int val) { this(val, null, null); } TreeNode(int val, TreeNode left, TreeNode right) { this.val = val; this.left = left; this.right = right; } } ``` Take the tree built from inserting `5, 3, 8, 1, 4` in that order: ``` 5 / \ 3 8 / \ 1 4 ``` Search, insert, and delete all cost O(h), where h is the tree's height. On a balanced tree that is O(log n), but on a degenerate tree, one built by inserting already-sorted data with no rebalancing, it collapses to a straight line and costs O(n). That's exactly why production databases and language runtimes use self-balancing trees (AVL, red-black) under the hood, even though building one yourself is outside interview scope. > **Remember:** left is always smaller, right is always bigger, at every level, not just the first. That single rule is the whole BST. ```knowledge-check { "questions": [ { "id": "dsa-bst-rule-q1", "type": "mcq", "prompt": "In a BST holding 5 at the root with left child 3 and right child 8, where can a value of 4 legally live?", "options": [ {"id": "a", "text": "In 3's right subtree, since 4 is bigger than 3 but smaller than 5"}, {"id": "b", "text": "Anywhere in the tree, position doesn't matter"}, {"id": "c", "text": "Only as a direct child of the root"}, {"id": "d", "text": "In 8's subtree, since 4 is a small number"} ], "correct": "a", "explanation": "4 is less than the root (5), so it belongs somewhere in the left subtree. Inside that subtree, 4 is greater than 3, so it lands as 3's right child." } ] } ``` ## Why an inorder walk of a BST comes out sorted Inorder visits left, then the node, then right. In a BST, left is always smaller and right is always bigger, so an inorder walk visits nodes in strictly increasing order. This one fact is the engine behind most BST-specific problems: find the kth smallest, check whether a tree is a valid BST, or turn a BST into a sorted list are all inorder traversal wearing a different name. ```python def inorder_values(root): result = [] def visit(node): if node is None: return visit(node.left) result.append(node.val) visit(node.right) visit(root) return result ``` ```javascript + function inorderValues(root) { const result = []; function visit(node) { if (node === null) { return; } visit(node.left); result.push(node.val); visit(node.right); } visit(root); return result; } ``` ```java + import java.util.ArrayList; import java.util.List; public class Main { public static void main(String[] args) { TreeNode root = new TreeNode(2, new TreeNode(1), new TreeNode(3)); System.out.println(inorderValues(root)); } static List inorderValues(TreeNode root) { List result = new ArrayList<>(); visit(root, result); return result; } static void visit(TreeNode node, List result) { if (node == null) { return; } visit(node.left, result); result.add(node.val); visit(node.right, result); } } class TreeNode { int val; TreeNode left; TreeNode right; TreeNode(int val) { this(val, null, null); } TreeNode(int val, TreeNode left, TreeNode right) { this.val = val; this.left = left; this.right = right; } } ``` Running this on the `5, 3, 8, 1, 4` tree from above gives `1, 3, 4, 5, 8`, in order, for free. > **Remember:** inorder of a BST is always sorted. If a problem mentions "kth smallest" or "sorted", think inorder first. ```knowledge-check { "questions": [ { "id": "dsa-bst-inorder-sorted-q1", "type": "mcq", "prompt": "Why does an inorder traversal of a BST always come out sorted?", "options": [ {"id": "a", "text": "Because inorder visits left (smaller), then the node, then right (bigger), matching the BST's own ordering rule"}, {"id": "b", "text": "Because BSTs sort their values automatically on insert"}, {"id": "c", "text": "It only works if the tree is balanced"}, {"id": "d", "text": "It's a coincidence specific to small trees"} ], "correct": "a", "explanation": "Inorder's visiting order (left, node, right) lines up exactly with the BST invariant (left smaller, right bigger) at every node, so the output is always ascending, on any BST shape." } ] } ``` ## Inserting and searching Both operations walk down from the root, comparing the target value at each node and choosing left or right, exactly the way you'd narrow down a phone book by comparing names. ```python def bst_insert(root, val): if root is None: return TreeNode(val) if val < root.val: root.left = bst_insert(root.left, val) elif val > root.val: root.right = bst_insert(root.right, val) # val == root.val: no-op, assumes no duplicates return root def bst_search(root, val) -> bool: if root is None: return False if val == root.val: return True return bst_search(root.left, val) if val < root.val else bst_search(root.right, val) ``` ```javascript + function bstInsert(root, val) { if (root === null) { return new TreeNode(val); } if (val < root.val) { root.left = bstInsert(root.left, val); } else if (val > root.val) { root.right = bstInsert(root.right, val); } // val === root.val: no-op, assumes no duplicates return root; } function bstSearch(root, val) { if (root === null) { return false; } if (val === root.val) { return true; } return val < root.val ? bstSearch(root.left, val) : bstSearch(root.right, val); } ``` ```java + public class Main { public static void main(String[] args) { TreeNode root = null; int[] values = {5, 3, 8, 1, 4}; for (int v : values) { root = bstInsert(root, v); } System.out.println("Search 4: " + bstSearch(root, 4)); System.out.println("Search 9: " + bstSearch(root, 9)); } static TreeNode bstInsert(TreeNode root, int val) { if (root == null) { return new TreeNode(val); } if (val < root.val) { root.left = bstInsert(root.left, val); } else if (val > root.val) { root.right = bstInsert(root.right, val); } // val == root.val: no-op, assumes no duplicates return root; } static boolean bstSearch(TreeNode root, int val) { if (root == null) { return false; } if (val == root.val) { return true; } return val < root.val ? bstSearch(root.left, val) : bstSearch(root.right, val); } } class TreeNode { int val; TreeNode left; TreeNode right; TreeNode(int val) { this(val, null, null); } TreeNode(int val, TreeNode left, TreeNode right) { this.val = val; this.left = left; this.right = right; } } ``` Both run in O(h) time and O(h) space for the recursion stack. Written iteratively with a plain `while` loop instead of recursion, the space drops to O(1); mention that if asked to optimize space. > **Remember:** insert and search both just follow the BST rule downward: smaller goes left, bigger goes right, until you fall off the tree or find the value. ```knowledge-check { "questions": [ { "id": "dsa-bst-insert-search-q1", "type": "mcq", "prompt": "Why does writing bst_search iteratively instead of recursively save space?", "options": [ {"id": "a", "text": "It avoids growing a call stack, dropping space from O(h) to O(1)"}, {"id": "b", "text": "It makes the search faster in time complexity, from O(h) to O(1)"}, {"id": "c", "text": "Recursive search doesn't work correctly on BSTs"}, {"id": "d", "text": "It changes the result returned"} ], "correct": "a", "explanation": "Each recursive call adds a stack frame, costing O(h) space. A while loop reuses the same variables on each step instead, so no extra memory grows with the tree's height." } ] } ``` ## Rebuilding a tree from two traversals Given two of the three DFS traversals, you can rebuild the exact original tree, but only certain pairs work. - **Preorder + inorder**: works. Preorder's first element is always the root. Inorder tells you which values sit in the left subtree (everything before the root's position) and which sit in the right subtree (everything after). - **Postorder + inorder**: also works, the mirror image: postorder's *last* element is the root. - **Preorder + postorder, with no inorder**: does not uniquely rebuild the tree if any node has only one child, since there's no way to tell whether that lone child is a left or right child. It only works if every node has either 0 or 2 children. - **Preorder alone, or inorder alone**: never enough. Many different trees can share the same single traversal. This is exactly the kind of "why does this work but not that" follow-up interviewers ask once you've solved the reconstruction problem below, so know the reasoning, not just the code. > **Remember:** preorder or postorder tells you the root; inorder tells you how to split left from right. You need one of each. ```knowledge-check { "questions": [ { "id": "dsa-bst-rebuild-pairs-q1", "type": "mcq", "prompt": "Which pair of traversals is NOT guaranteed to uniquely rebuild a binary tree?", "options": [ {"id": "a", "text": "Preorder + postorder, when some node has exactly one child"}, {"id": "b", "text": "Preorder + inorder"}, {"id": "c", "text": "Postorder + inorder"}, {"id": "d", "text": "All three pairs always work equally well"} ], "correct": "a", "explanation": "Without inorder, there's no way to know whether a node's single child is on the left or the right, so preorder + postorder alone can match more than one tree shape unless every node has 0 or 2 children." } ] } ``` ## Validate Binary Search Tree [Validate Binary Search Tree (LeetCode 98)](https://leetcode.com/problems/validate-binary-search-tree/) The tempting but wrong check is comparing each node only to its immediate children. That misses violations further down, like a left-subtree node that's bigger than an ancestor two levels up. The fix: carry a `(low, high)` range down through the recursion, and tighten it as you go. **Approach:** Recursively validate each node against a `(low, high)` bound. Going left tightens `high` to the current node's value; going right tightens `low`. ```python def is_valid_bst(root) -> bool: def validate(node, low, high): if node is None: return True if not (low < node.val < high): return False return validate(node.left, low, node.val) and validate(node.right, node.val, high) return validate(root, float("-inf"), float("inf")) ``` ```javascript + function isValidBst(root) { function validate(node, low, high) { if (node === null) { return true; } if (!(low < node.val && node.val < high)) { return false; } return validate(node.left, low, node.val) && validate(node.right, node.val, high); } return validate(root, -Infinity, Infinity); } ``` ```java + public class Main { public static void main(String[] args) { TreeNode root = new TreeNode(5, new TreeNode(3), new TreeNode(8)); System.out.println(isValidBst(root)); } static boolean isValidBst(TreeNode root) { return validate(root, Long.MIN_VALUE, Long.MAX_VALUE); } static boolean validate(TreeNode node, long low, long high) { if (node == null) { return true; } if (!(low < node.val && node.val < high)) { return false; } return validate(node.left, low, node.val) && validate(node.right, node.val, high); } } class TreeNode { int val; TreeNode left; TreeNode right; TreeNode(int val) { this(val, null, null); } TreeNode(int val, TreeNode left, TreeNode right) { this.val = val; this.left = left; this.right = right; } } ``` **Complexity:** Time O(n), space O(h) recursion stack. **Common mistakes:** - Checking only immediate children instead of carrying a range down. That passes trees which are locally fine but globally broken. - An alternative correct approach: run an inorder traversal and check the result is strictly increasing. Also O(n)/O(h), and arguably simpler to reason about, though it can't stop early when an invalid tree is found near the root. > **Remember:** pass a shrinking (low, high) range down the recursion. A local left/right check alone is not enough. ```knowledge-check { "questions": [ { "id": "dsa-bst-validate-q1", "type": "mcq", "prompt": "Why does checking only 'node.left.val < node.val < node.right.val' fail to validate a BST correctly?", "options": [ {"id": "a", "text": "It misses violations further down the tree, such as a left-subtree node bigger than an ancestor two levels up"}, {"id": "b", "text": "It's actually correct and sufficient"}, {"id": "c", "text": "It only fails on trees with duplicate values"}, {"id": "d", "text": "It runs in exponential time"} ], "correct": "a", "explanation": "A purely local check can't see the whole ancestor chain. A node deep in the left subtree could still be larger than some ancestor far above it, which only a range carried down through recursion catches." } ] } ``` ## Lowest Common Ancestor of a BST [Lowest Common Ancestor (LeetCode 235)](https://leetcode.com/problems/lowest-common-ancestor-of-a-binary-search-tree/) In a plain binary tree, finding the lowest common ancestor (LCA) needs a full traversal. A BST's ordering gives a shortcut: if both target values are smaller than the current node, the LCA must be in the left subtree; if both are bigger, it's in the right subtree. The moment they land on opposite sides, or one equals the current node, that node is the split point, and the LCA. **Approach:** Walk down from the root using the BST-ordering shortcut, stopping as soon as `p` and `q` diverge (or one matches the current node). ```python def lowest_common_ancestor(root, p, q): node = root while node: if p.val < node.val and q.val < node.val: node = node.left elif p.val > node.val and q.val > node.val: node = node.right else: return node return None ``` ```javascript + function lowestCommonAncestor(root, p, q) { let node = root; while (node) { if (p.val < node.val && q.val < node.val) { node = node.left; } else if (p.val > node.val && q.val > node.val) { node = node.right; } else { return node; } } return null; } ``` ```java + public class Main { public static void main(String[] args) { TreeNode root = new TreeNode(6, new TreeNode(2, new TreeNode(0), new TreeNode(4)), new TreeNode(8)); TreeNode p = root.left; TreeNode q = root.left.right; TreeNode lca = lowestCommonAncestor(root, p, q); System.out.println("LCA: " + lca.val); } static TreeNode lowestCommonAncestor(TreeNode root, TreeNode p, TreeNode q) { TreeNode node = root; while (node != null) { if (p.val < node.val && q.val < node.val) { node = node.left; } else if (p.val > node.val && q.val > node.val) { node = node.right; } else { return node; } } return null; } } class TreeNode { int val; TreeNode left; TreeNode right; TreeNode(int val) { this(val, null, null); } TreeNode(int val, TreeNode left, TreeNode right) { this.val = val; this.left = left; this.right = right; } } ``` **Complexity:** Time O(h), space O(1), since it's iterative with no recursion stack. **Common mistakes:** - Using a general-tree LCA algorithm (search both subtrees, O(n)) when the BST property gives an O(h) shortcut. Interviewers read this as missing the BST constraint. - Getting the divergence condition backwards, or forgetting that when one of `p`/`q` equals the current node, that node itself is the LCA. > **Remember:** both smaller means go left, both bigger means go right, otherwise you've found the split point, and that's the LCA. ```knowledge-check { "questions": [ { "id": "dsa-bst-lca-q1", "type": "mcq", "prompt": "In a BST, when should you stop walking down and declare the current node the lowest common ancestor of p and q?", "options": [ {"id": "a", "text": "The moment p and q are no longer both smaller or both bigger than the current node"}, {"id": "b", "text": "Only when you reach a leaf node"}, {"id": "c", "text": "Only when p and q are equal to each other"}, {"id": "d", "text": "Never; you must always search both subtrees fully"} ], "correct": "a", "explanation": "As long as both values are on the same side, the LCA must be further down that side. The split point, where they stop agreeing on a direction, is exactly the LCA." } ] } ``` ## Construct Binary Tree from Preorder and Inorder Traversal [Construct Binary Tree from Preorder and Inorder (LeetCode 105)](https://leetcode.com/problems/construct-binary-tree-from-preorder-and-inorder-traversal/) Preorder's first element is always the root. Find that value's position in inorder: everything to its left belongs to the left subtree, everything to its right belongs to the right subtree. Recurse on each side using the matching slices of both traversals. **Approach:** Build a hash map from value to inorder index for O(1) lookups, instead of scanning inorder each time, which would make the naive version O(n²). Track a moving pointer into preorder, since each recursive call consumes exactly one preorder element, the current subtree's root, before recursing further. ```python def build_tree(preorder: list[int], inorder: list[int]): inorder_index = {val: i for i, val in enumerate(inorder)} self_preorder_idx = [0] # mutable pointer into preorder def build(left, right): if left > right: return None root_val = preorder[self_preorder_idx[0]] self_preorder_idx[0] += 1 root = TreeNode(root_val) mid = inorder_index[root_val] root.left = build(left, mid - 1) root.right = build(mid + 1, right) return root return build(0, len(inorder) - 1) ``` ```javascript + function buildTree(preorder, inorder) { const inorderIndex = new Map(); inorder.forEach((val, i) => inorderIndex.set(val, i)); let preorderIdx = 0; // mutable pointer into preorder function build(left, right) { if (left > right) { return null; } const rootVal = preorder[preorderIdx]; preorderIdx += 1; const root = new TreeNode(rootVal); const mid = inorderIndex.get(rootVal); root.left = build(left, mid - 1); root.right = build(mid + 1, right); return root; } return build(0, inorder.length - 1); } ``` ```java + import java.util.HashMap; import java.util.Map; public class Main { static int preorderIdx; public static void main(String[] args) { int[] preorder = {3, 9, 20, 15, 7}; int[] inorder = {9, 3, 15, 20, 7}; TreeNode root = buildTree(preorder, inorder); System.out.println("Root: " + root.val + ", left: " + root.left.val + ", right: " + root.right.val); } static TreeNode buildTree(int[] preorder, int[] inorder) { Map inorderIndex = new HashMap<>(); for (int i = 0; i < inorder.length; i++) { inorderIndex.put(inorder[i], i); } preorderIdx = 0; // mutable pointer into preorder return build(preorder, inorderIndex, 0, inorder.length - 1); } static TreeNode build(int[] preorder, Map inorderIndex, int left, int right) { if (left > right) { return null; } int rootVal = preorder[preorderIdx]; preorderIdx += 1; TreeNode root = new TreeNode(rootVal); int mid = inorderIndex.get(rootVal); root.left = build(preorder, inorderIndex, left, mid - 1); root.right = build(preorder, inorderIndex, mid + 1, right); return root; } } class TreeNode { int val; TreeNode left; TreeNode right; TreeNode(int val) { this(val, null, null); } TreeNode(int val, TreeNode left, TreeNode right) { this.val = val; this.left = left; this.right = right; } } ``` **Complexity:** Time O(n), each node is processed once with an O(1) map lookup. Space O(n) for the map plus O(h) recursion stack. **Common mistakes:** - Using `inorder.index(root_val)`, a linear scan, instead of a precomputed hash map. That turns O(n) into O(n²). - Slicing lists (`preorder[1:mid+1]`) instead of tracking indices. Correct, but it adds O(n) copying at every level, another hidden O(n²). - Forgetting to advance the preorder pointer before recursing left. The left subtree's preorder elements come right after the root, so building the right side before consuming the left side's elements corrupts the indices. > **Remember:** preorder's first element is the root; find it in inorder to split left from right; use a hash map, not a linear scan. ```knowledge-check { "questions": [ { "id": "dsa-bst-build-tree-q1", "type": "mcq", "prompt": "Why precompute a value-to-index hash map for the inorder array before rebuilding the tree?", "options": [ {"id": "a", "text": "It turns each root lookup into O(1) instead of an O(n) scan, avoiding a hidden O(n²) overall"}, {"id": "b", "text": "It's required for the tree to be a valid BST"}, {"id": "c", "text": "It reduces the space complexity to O(1)"}, {"id": "d", "text": "It removes the need for a preorder pointer"} ], "correct": "a", "explanation": "Without the map, finding each root's split point in inorder means scanning it every time, O(n) per call across O(n) calls, which is O(n²) total. The map makes each lookup O(1)." } ] } ``` ## Kth Smallest Element in a BST [Kth Smallest Element in BST (LeetCode 230)](https://leetcode.com/problems/kth-smallest-element-in-a-bst/) "Kth smallest" is exactly "the kth value visited during an inorder walk." No sorting needed; the BST's own structure hands you the order. **Approach:** Do an inorder traversal, but stop the moment you've visited k elements. There's no need to build the full sorted list when k is small relative to n. ```python def kth_smallest(root, k: int) -> int: stack = [] node = root count = 0 while stack or node: while node: stack.append(node) node = node.left node = stack.pop() count += 1 if count == k: return node.val node = node.right raise ValueError("k is out of range") ``` ```javascript + function kthSmallest(root, k) { const stack = []; let node = root; let count = 0; while (stack.length > 0 || node !== null) { while (node !== null) { stack.push(node); node = node.left; } node = stack.pop(); count += 1; if (count === k) { return node.val; } node = node.right; } throw new RangeError('k is out of range'); } ``` ```java + import java.util.ArrayDeque; import java.util.Deque; public class Main { public static void main(String[] args) { TreeNode root = new TreeNode(5, new TreeNode(3, new TreeNode(2), new TreeNode(4)), new TreeNode(8)); System.out.println(kthSmallest(root, 3)); } static int kthSmallest(TreeNode root, int k) { Deque stack = new ArrayDeque<>(); TreeNode node = root; int count = 0; while (!stack.isEmpty() || node != null) { while (node != null) { stack.push(node); node = node.left; } node = stack.pop(); count += 1; if (count == k) { return node.val; } node = node.right; } throw new IllegalArgumentException("k is out of range"); } } class TreeNode { int val; TreeNode left; TreeNode right; TreeNode(int val) { this(val, null, null); } TreeNode(int val, TreeNode left, TreeNode right) { this.val = val; this.left = left; this.right = right; } } ``` **Complexity:** Time O(h + k): descending to the leftmost node costs O(h), then visiting k more nodes, worst case O(n) if k is close to n. Space O(h) for the stack. **Common mistakes:** - Building the entire inorder list first, then indexing into it. Correct, but it wastes time and space when k is small, since there's no early exit. - Off-by-one: k is usually 1-indexed, so return when `count == k`, not `count == k - 1`. > **Remember:** an iterative inorder walk that stops at count k, no need to build the full sorted list first. ```knowledge-check { "questions": [ { "id": "dsa-bst-kth-smallest-q1", "type": "mcq", "prompt": "Why is stopping the inorder traversal early, as soon as count equals k, better than building the full sorted list first?", "options": [ {"id": "a", "text": "It avoids wasted time and space visiting nodes beyond the kth one when k is small relative to n"}, {"id": "b", "text": "It changes the time complexity from O(n) to O(1)"}, {"id": "c", "text": "The full list approach gives a wrong answer"}, {"id": "d", "text": "It only matters for unbalanced trees"} ], "correct": "a", "explanation": "Stopping at k avoids visiting the remaining n - k nodes. When k is much smaller than n, this saves real time and space; when k is close to n, the cost is about the same either way." } ] } ``` 37:T82c7,Type "ca" into your phone's contacts search and it instantly shows "Carl," "Carol," and "Cathy." That's a trie at work: a tree built for exactly one job, answering "what starts with this prefix?" Autocomplete, spell-check, IP routing tables, and word-search puzzles all reduce to that same question, one a hash table answers poorly since it can only match whole keys, not prefixes. This lesson builds a trie from scratch, then uses it on two escalating problems, one of them a hard. ## What a trie node holds Each node represents one character position. It holds links to its children, one per possible next character, plus a flag marking "a word ends here." ```python class TrieNode: def __init__(self): self.children = {} # char -> TrieNode self.is_end_of_word = False ``` ```javascript + class TrieNode { constructor() { this.children = new Map(); // char -> TrieNode this.isEndOfWord = false; } } ``` ```java + import java.util.HashMap; import java.util.Map; public class Main { public static void main(String[] args) { TrieNode node = new TrieNode(); System.out.println(node.isEndOfWord); } } class TrieNode { Map children = new HashMap<>(); // char -> TrieNode boolean isEndOfWord = false; } ``` A path from the root spelling `c-a-t` represents the word `"cat"`. Words that share a prefix share nodes: `"cat"` and `"car"` both walk `c -> a`, then split at the third letter. That sharing is exactly what makes prefix queries cheap; you're not comparing "cat" against "car" character by character, you're walking one shared path and branching only where the words actually differ. ``` root / c | a / \ t r * * (* marks is_end_of_word = True) ``` > **Remember:** a trie node is a character position, not a whole word. Shared prefixes share the same nodes. ```knowledge-check { "questions": [ { "id": "dsa-tries-node-structure-q1", "type": "mcq", "prompt": "In a trie storing both 'cat' and 'car', at which point do the two words stop sharing nodes?", "options": [ {"id": "a", "text": "After 'ca', where the paths split into 't' and 'r'"}, {"id": "b", "text": "They never share any nodes"}, {"id": "c", "text": "Only the root is shared"}, {"id": "d", "text": "They share every node, including the final one"} ], "correct": "a", "explanation": "Both words start c -> a, walking the same two nodes. They diverge only at the third character, where one path goes to 't' and the other to 'r'." } ] } ``` ## Insert, search, and prefix search All three operations walk the tree one character at a time: O(m), where m is the length of the word or prefix. That cost never depends on how many other words are already stored, only on the length of what you're looking up. ```python class Trie: def __init__(self): self.root = TrieNode() def insert(self, word: str) -> None: node = self.root for ch in word: if ch not in node.children: node.children[ch] = TrieNode() node = node.children[ch] node.is_end_of_word = True def _find_node(self, prefix: str): node = self.root for ch in prefix: if ch not in node.children: return None node = node.children[ch] return node def search(self, word: str) -> bool: node = self._find_node(word) return node is not None and node.is_end_of_word def startsWith(self, prefix: str) -> bool: return self._find_node(prefix) is not None ``` ```javascript + class TrieNode { constructor() { this.children = new Map(); // char -> TrieNode this.isEndOfWord = false; } } class Trie { constructor() { this.root = new TrieNode(); } insert(word) { let node = this.root; for (const ch of word) { if (!node.children.has(ch)) { node.children.set(ch, new TrieNode()); } node = node.children.get(ch); } node.isEndOfWord = true; } _findNode(prefix) { let node = this.root; for (const ch of prefix) { if (!node.children.has(ch)) { return null; } node = node.children.get(ch); } return node; } search(word) { const node = this._findNode(word); return node !== null && node.isEndOfWord; } startsWith(prefix) { return this._findNode(prefix) !== null; } } ``` ```java + import java.util.HashMap; import java.util.Map; public class Main { public static void main(String[] args) { Trie trie = new Trie(); trie.insert("cat"); System.out.println(trie.search("cat")); System.out.println(trie.startsWith("ca")); } } class TrieNode { Map children = new HashMap<>(); // char -> TrieNode boolean isEndOfWord = false; } class Trie { TrieNode root = new TrieNode(); void insert(String word) { TrieNode node = root; for (char ch : word.toCharArray()) { node = node.children.computeIfAbsent(ch, c -> new TrieNode()); } node.isEndOfWord = true; } private TrieNode findNode(String prefix) { TrieNode node = root; for (char ch : prefix.toCharArray()) { if (!node.children.containsKey(ch)) { return null; } node = node.children.get(ch); } return node; } boolean search(String word) { TrieNode node = findNode(word); return node != null && node.isEndOfWord; } boolean startsWith(String prefix) { return findNode(prefix) != null; } } ``` The detail that trips people up: `search` needs `is_end_of_word == True` at the final node, meaning the exact word was inserted. `startsWith` only needs the path to exist; some word *starting with* this prefix was inserted, but the prefix itself might not be a whole word on its own. Mixing these two up is the most common trie bug. > **Remember:** `search` needs the path AND the end-of-word flag. `startsWith` needs only the path. ```knowledge-check { "questions": [ { "id": "dsa-tries-insert-search-q1", "type": "mcq", "prompt": "After inserting only the word 'card' into a trie, what does startsWith('car') return, and why?", "options": [ {"id": "a", "text": "True, because the path c-a-r exists, even though 'car' itself was never inserted as a full word"}, {"id": "b", "text": "False, because 'car' was never inserted as its own word"}, {"id": "c", "text": "True only if is_end_of_word is set on the 'r' node"}, {"id": "d", "text": "It throws an error since 'car' is not a complete word"} ], "correct": "a", "explanation": "startsWith only checks that the path exists in the trie, not that a word ends there. Since 'card' was inserted, the path c-a-r exists as a prefix of it, so startsWith('car') is true regardless of the end-of-word flag." } ] } ``` ## Trading memory for speed A naive trie node using a fixed 26-slot array (`children = [None] * 26`) wastes memory whenever the alphabet in a given subtree is small or sparse. A dict-based node (`children = {}`) only allocates entries for characters actually present, at the cost of slightly slower lookups: hashing instead of a direct array index. | | Array of 26 | Dict | |---|---|---| | Lookup | O(1), direct index | O(1) average, hash overhead | | Space per node | Fixed 26 slots always | Only used characters | | Best for | Lowercase-only, dense tries | Unicode, sparse tries, unknown alphabet | A further optimization for memory-constrained cases is the **compressed trie (radix tree)**: it merges chains of single-child nodes into one edge labeled with a substring instead of one character, cutting node count sharply for tries with many long, unique suffixes. You're rarely asked to implement this in an interview, but naming it is worth doing if asked how you'd scale a trie to millions of entries. > **Remember:** array children are faster but always cost 26 slots; dict children only pay for characters actually used. ```knowledge-check { "questions": [ { "id": "dsa-tries-space-optimization-q1", "type": "mcq", "prompt": "When is a dict-based trie node a better choice than a fixed 26-slot array?", "options": [ {"id": "a", "text": "When the alphabet is large or sparse, such as Unicode text, so you don't allocate unused slots"}, {"id": "b", "text": "Always, since dicts are faster in every case"}, {"id": "c", "text": "Never, arrays are always better for tries"}, {"id": "d", "text": "Only when the trie has fewer than 26 words"} ], "correct": "a", "explanation": "An array always reserves 26 slots per node even if only one child is used. A dict only pays for characters actually present, which wins when the alphabet is large or most nodes are sparse." } ] } ``` ## Implement Trie [LeetCode 208](https://leetcode.com/problems/implement-trie-prefix-tree/) — Trie — Basic implementation This problem is the concept section above, asked as a standalone exercise: build `insert`, `search`, and `startsWith` directly. **Approach:** `TrieNode` holds a children dict and an end-of-word flag. `insert` walks or creates nodes as needed. `search` and `startsWith` walk and check existence; `search` additionally checks the end-of-word flag. ```python class Trie: def __init__(self): self.root = TrieNode() def insert(self, word: str) -> None: node = self.root for ch in word: node = node.children.setdefault(ch, TrieNode()) node.is_end_of_word = True def search(self, word: str) -> bool: node = self.root for ch in word: if ch not in node.children: return False node = node.children[ch] return node.is_end_of_word def startsWith(self, prefix: str) -> bool: node = self.root for ch in prefix: if ch not in node.children: return False node = node.children[ch] return True ``` ```javascript + class TrieNode { constructor() { this.children = new Map(); this.isEndOfWord = false; } } class Trie { constructor() { this.root = new TrieNode(); } insert(word) { let node = this.root; for (const ch of word) { if (!node.children.has(ch)) { node.children.set(ch, new TrieNode()); } node = node.children.get(ch); } node.isEndOfWord = true; } search(word) { let node = this.root; for (const ch of word) { if (!node.children.has(ch)) { return false; } node = node.children.get(ch); } return node.isEndOfWord; } startsWith(prefix) { let node = this.root; for (const ch of prefix) { if (!node.children.has(ch)) { return false; } node = node.children.get(ch); } return true; } } ``` ```java + import java.util.HashMap; import java.util.Map; public class Main { public static void main(String[] args) { Trie trie = new Trie(); trie.insert("apple"); System.out.println(trie.search("apple")); System.out.println(trie.search("app")); System.out.println(trie.startsWith("app")); } } class TrieNode { Map children = new HashMap<>(); boolean isEndOfWord = false; } class Trie { TrieNode root = new TrieNode(); void insert(String word) { TrieNode node = root; for (char ch : word.toCharArray()) { node = node.children.computeIfAbsent(ch, c -> new TrieNode()); } node.isEndOfWord = true; } boolean search(String word) { TrieNode node = root; for (char ch : word.toCharArray()) { if (!node.children.containsKey(ch)) { return false; } node = node.children.get(ch); } return node.isEndOfWord; } boolean startsWith(String prefix) { TrieNode node = root; for (char ch : prefix.toCharArray()) { if (!node.children.containsKey(ch)) { return false; } node = node.children.get(ch); } return true; } } ``` **Complexity:** `insert`/`search`/`startsWith` are all O(m) time, where m is the word or prefix length. Space O(total characters across all inserted words) in the worst case, when no prefixes are shared. **Common mistakes:** Returning `True` from `search` just because the path exists, forgetting the end-of-word check. Also, unconditionally writing `node.children[ch] = TrieNode()` on insert instead of checking first, which wipes out existing subtrees and loses previously inserted words. > **Remember:** this problem IS the concept section. If you can write insert/search/startsWith from memory, you know tries. ```knowledge-check { "questions": [ { "id": "dsa-tries-implement-trie-q1", "type": "mcq", "prompt": "What bug happens if insert always does `node.children[ch] = TrieNode()` instead of checking if the child already exists?", "options": [ {"id": "a", "text": "It overwrites an existing subtree, losing every word previously stored below that point"}, {"id": "b", "text": "Nothing, the trie still works correctly"}, {"id": "c", "text": "It makes search run in O(n) instead of O(m)"}, {"id": "d", "text": "It causes an infinite loop"} ], "correct": "a", "explanation": "Overwriting the child node discards any words that were already stored in that subtree. Insert must reuse an existing child if one is there, only creating a new node when the character path doesn't exist yet." } ] } ``` ## Word Search II [LeetCode 212](https://leetcode.com/problems/word-search-ii/) — Trie + Backtracking — Hard Searching the board separately for each word in a word list, one full DFS per word, is far too slow when both the board and the word list are large. Instead, build one trie from every word, then run a single DFS pass over the board, walking the trie and the board together, step for step. This shares work across words with common prefixes and lets you prune a board path the instant it stops matching *any* word's prefix. **Approach:** Build a trie from `words` (mark word ends). DFS from every board cell; at each step, only continue if the current character exists as a trie child of the current trie node. When a trie node marks a complete word, record it (and mark that trie node as spent, to avoid duplicate results). Backtrack the board cell after exploring. ```python def findWords(board: list[list[str]], words: list[str]) -> list[str]: root = TrieNode() for word in words: node = root for ch in word: node = node.children.setdefault(ch, TrieNode()) node.is_end_of_word = True node.word = word # stash the full word at the terminal node rows, cols = len(board), len(board[0]) result = [] def dfs(r, c, node): ch = board[r][c] if ch not in node.children: return nxt = node.children[ch] if nxt.is_end_of_word: result.append(nxt.word) nxt.is_end_of_word = False # avoid duplicate matches board[r][c] = '#' # mark visited in place for dr, dc in ((1, 0), (-1, 0), (0, 1), (0, -1)): nr, nc = r + dr, c + dc if 0 <= nr < rows and 0 <= nc < cols and board[nr][nc] != '#': dfs(nr, nc, nxt) board[r][c] = ch # backtrack if not nxt.children: # prune dead trie branches for efficiency node.children.pop(ch) for r in range(rows): for c in range(cols): dfs(r, c, root) return result ``` ```javascript + class TrieNode { constructor() { this.children = new Map(); this.isEndOfWord = false; this.word = null; } } function findWords(board, words) { const root = new TrieNode(); for (const word of words) { let node = root; for (const ch of word) { if (!node.children.has(ch)) { node.children.set(ch, new TrieNode()); } node = node.children.get(ch); } node.isEndOfWord = true; node.word = word; // stash the full word at the terminal node } const rows = board.length; const cols = board[0].length; const result = []; function dfs(r, c, node) { const ch = board[r][c]; if (!node.children.has(ch)) return; const nxt = node.children.get(ch); if (nxt.isEndOfWord) { result.push(nxt.word); nxt.isEndOfWord = false; // avoid duplicate matches } board[r][c] = '#'; // mark visited in place for (const [dr, dc] of [[1, 0], [-1, 0], [0, 1], [0, -1]]) { const nr = r + dr; const nc = c + dc; if (nr >= 0 && nr < rows && nc >= 0 && nc < cols && board[nr][nc] !== '#') { dfs(nr, nc, nxt); } } board[r][c] = ch; // backtrack if (nxt.children.size === 0) { // prune dead trie branches for efficiency node.children.delete(ch); } } for (let r = 0; r < rows; r++) { for (let c = 0; c < cols; c++) { dfs(r, c, root); } } return result; } ``` ```java + import java.util.ArrayList; import java.util.HashMap; import java.util.List; import java.util.Map; public class Main { public static void main(String[] args) { char[][] board = { {'o', 'a', 'a', 'n'}, {'e', 't', 'a', 'e'}, {'i', 'h', 'k', 'r'}, {'i', 'f', 'l', 'v'} }; String[] words = {"oath", "pea", "eat", "rain"}; System.out.println(findWords(board, words)); } static int rows, cols; static char[][] board; static List result; static List findWords(char[][] inputBoard, String[] words) { board = inputBoard; TrieNode root = new TrieNode(); for (String word : words) { TrieNode node = root; for (char ch : word.toCharArray()) { node = node.children.computeIfAbsent(ch, c -> new TrieNode()); } node.isEndOfWord = true; node.word = word; // stash the full word at the terminal node } rows = board.length; cols = board[0].length; result = new ArrayList<>(); for (int r = 0; r < rows; r++) { for (int c = 0; c < cols; c++) { dfs(r, c, root); } } return result; } static void dfs(int r, int c, TrieNode node) { char ch = board[r][c]; if (!node.children.containsKey(ch)) return; TrieNode nxt = node.children.get(ch); if (nxt.isEndOfWord) { result.add(nxt.word); nxt.isEndOfWord = false; // avoid duplicate matches } board[r][c] = '#'; // mark visited in place int[][] dirs = {{1, 0}, {-1, 0}, {0, 1}, {0, -1}}; for (int[] dir : dirs) { int nr = r + dir[0], nc = c + dir[1]; if (nr >= 0 && nr < rows && nc >= 0 && nc < cols && board[nr][nc] != '#') { dfs(nr, nc, nxt); } } board[r][c] = ch; // backtrack if (nxt.children.isEmpty()) { // prune dead trie branches for efficiency node.children.remove(ch); } } } class TrieNode { Map children = new HashMap<>(); boolean isEndOfWord = false; String word; } ``` **Complexity:** Time O(rows × cols × 4^L) in the worst case (L = longest word length), but trie pruning, stopping as soon as no word's prefix matches and removing exhausted branches, makes it far faster in practice than a per-word DFS. Space O(total trie nodes + recursion depth). **Common mistakes:** Running a separate DFS search per word instead of one shared trie-guided DFS. Correct, but too slow for the hard-tier constraints. Forgetting to backtrack the board mutation after recursion, which corrupts later searches. Skipping the guard against duplicate results when the same word can be found via multiple paths; resetting the end-of-word flag after the first match handles this. > **Remember:** one trie built from all words, one shared DFS over the board, pruning dead branches as you go. ```knowledge-check { "questions": [ { "id": "dsa-tries-word-search-ii-q1", "type": "mcq", "prompt": "Why build one trie from all target words instead of running a separate DFS search for each word?", "options": [ {"id": "a", "text": "A shared trie lets one DFS pass share work across words with common prefixes and prune paths early"}, {"id": "b", "text": "A trie is required for DFS to work on a grid at all"}, {"id": "c", "text": "It reduces the answer's correctness requirements"}, {"id": "d", "text": "It only matters when the board has fewer than 4 cells"} ], "correct": "a", "explanation": "Separate per-word DFS repeats work for every word independently. A shared trie lets one DFS walk match multiple words' prefixes at once, and stop exploring the moment no word's prefix matches anymore." } ] } ``` ## Replace Words [LeetCode 648](https://leetcode.com/problems/replace-words/) — Trie For each word in a sentence, find its *shortest* dictionary root, if one exists, and swap the word for that root. A trie built from the roots lets you walk each word one character at a time and stop at the very first end-of-word flag you hit, which is automatically the shortest matching root. **Approach:** Insert all roots into a trie. For each word in the sentence, walk the trie; the moment you hit an end-of-word flag (or run out of characters or trie path), replace the word with the prefix walked so far, or keep the original word if no root matched. ```python def replaceWords(dictionary: list[str], sentence: str) -> str: root_trie = TrieNode() for root in dictionary: node = root_trie for ch in root: node = node.children.setdefault(ch, TrieNode()) node.is_end_of_word = True def find_root(word: str) -> str: node = root_trie prefix = [] for ch in word: if ch not in node.children: return word # no matching root, keep original prefix.append(ch) node = node.children[ch] if node.is_end_of_word: return "".join(prefix) return word return " ".join(find_root(word) for word in sentence.split()) ``` ```javascript + class TrieNode { constructor() { this.children = new Map(); this.isEndOfWord = false; } } function replaceWords(dictionary, sentence) { const rootTrie = new TrieNode(); for (const root of dictionary) { let node = rootTrie; for (const ch of root) { if (!node.children.has(ch)) { node.children.set(ch, new TrieNode()); } node = node.children.get(ch); } node.isEndOfWord = true; } function findRoot(word) { let node = rootTrie; let prefix = ""; for (const ch of word) { if (!node.children.has(ch)) { return word; // no matching root, keep original } prefix += ch; node = node.children.get(ch); if (node.isEndOfWord) { return prefix; } } return word; } return sentence.split(" ").map(findRoot).join(" "); } ``` ```java + import java.util.HashMap; import java.util.Map; public class Main { public static void main(String[] args) { String[] dictionary = {"cat", "bat", "rat"}; String sentence = "the cattle was rattled by the battery"; System.out.println(replaceWords(dictionary, sentence)); } static TrieNode rootTrie; static String replaceWords(String[] dictionary, String sentence) { rootTrie = new TrieNode(); for (String root : dictionary) { TrieNode node = rootTrie; for (char ch : root.toCharArray()) { node = node.children.computeIfAbsent(ch, c -> new TrieNode()); } node.isEndOfWord = true; } StringBuilder result = new StringBuilder(); for (String word : sentence.split(" ")) { if (result.length() > 0) result.append(" "); result.append(findRoot(word)); } return result.toString(); } static String findRoot(String word) { TrieNode node = rootTrie; StringBuilder prefix = new StringBuilder(); for (char ch : word.toCharArray()) { if (!node.children.containsKey(ch)) { return word; // no matching root, keep original } prefix.append(ch); node = node.children.get(ch); if (node.isEndOfWord) { return prefix.toString(); } } return word; } } class TrieNode { Map children = new HashMap<>(); boolean isEndOfWord = false; } ``` **Complexity:** Time O(total characters in the dictionary + total characters in the sentence), space O(total characters in the dictionary) for the trie. **Common mistakes:** Not stopping at the *first* end-of-word flag reached. The problem wants the shortest matching root, so continuing past it would wrongly look for a longer one. Also, using a naive "try every root as a prefix" approach with string methods, which is O(words × roots × root length) instead of the trie's near-linear scan. > **Remember:** stop at the first end-of-word flag you hit while walking down; that's always the shortest matching root. ```knowledge-check { "questions": [ { "id": "dsa-tries-replace-words-q1", "type": "mcq", "prompt": "Why must find_root stop at the FIRST end-of-word flag it encounters while walking the trie?", "options": [ {"id": "a", "text": "The problem asks for the shortest matching root, and continuing past the first match could find a longer, wrong one"}, {"id": "b", "text": "Stopping early is only an optimization with no effect on correctness"}, {"id": "c", "text": "Because tries can only store one word ending per path"}, {"id": "d", "text": "Because longer roots are always invalid"} ], "correct": "a", "explanation": "If multiple roots are prefixes of each other (like 'cat' and 'catalog'), the shortest one that matches the word is the correct replacement. Stopping at the first end-of-word flag guarantees you get that shortest root." } ] } ``` ## Maximum XOR of Two Numbers in an Array [LeetCode 421](https://leetcode.com/problems/maximum-xor-of-two-numbers-in-an-array/) — Trie — Hard To maximize the XOR of two numbers, you want their bits to differ at the highest positions possible, since a higher bit position contributes more to the result. A **binary trie**, where each node has at most 2 children (bit 0 or bit 1), lets you, for each number, greedily walk toward the *opposite* bit at every position. That greedy walk finds the best XOR partner for that number in O(32) steps instead of comparing it against every other number. It's the same prefix-tree idea from earlier in this lesson, applied to bits instead of letters. **Approach:** Insert every number into a binary trie, most-significant-bit first (fixed 32-bit width). For each number, walk the trie trying to go the opposite direction of each of its bits; when the opposite branch doesn't exist, take the only branch available. Track the best XOR found. ```python class BinaryTrieNode: def __init__(self): self.children = {} # 0 or 1 -> BinaryTrieNode def findMaximumXOR(nums: list[int]) -> int: root = BinaryTrieNode() BITS = 31 # enough for LeetCode's constraint (nums < 2^31) def insert(num): node = root for i in range(BITS, -1, -1): bit = (num >> i) & 1 node = node.children.setdefault(bit, BinaryTrieNode()) def query(num): node = root xor = 0 for i in range(BITS, -1, -1): bit = (num >> i) & 1 desired = 1 - bit # the opposite bit maximizes this position's contribution if desired in node.children: xor |= (1 << i) node = node.children[desired] else: node = node.children[bit] return xor for num in nums: insert(num) return max(query(num) for num in nums) ``` ```javascript + class BinaryTrieNode { constructor() { this.children = new Map(); // 0 or 1 -> BinaryTrieNode } } function findMaximumXOR(nums) { const root = new BinaryTrieNode(); const BITS = 31; // enough for LeetCode's constraint (nums < 2^31) function insert(num) { let node = root; for (let i = BITS; i >= 0; i--) { const bit = (num >> i) & 1; if (!node.children.has(bit)) { node.children.set(bit, new BinaryTrieNode()); } node = node.children.get(bit); } } function query(num) { let node = root; let xor = 0; for (let i = BITS; i >= 0; i--) { const bit = (num >> i) & 1; const desired = 1 - bit; // the opposite bit maximizes this position's contribution if (node.children.has(desired)) { xor |= (1 << i); node = node.children.get(desired); } else { node = node.children.get(bit); } } return xor; } for (const num of nums) { insert(num); } return Math.max(...nums.map(query)); } ``` ```java + import java.util.HashMap; import java.util.Map; public class Main { public static void main(String[] args) { int[] nums = {3, 10, 5, 25, 2, 8}; System.out.println(findMaximumXOR(nums)); } static BinaryTrieNode root = new BinaryTrieNode(); static final int BITS = 31; // enough for LeetCode's constraint (nums < 2^31) static int findMaximumXOR(int[] nums) { for (int num : nums) { insert(num); } int best = 0; for (int num : nums) { best = Math.max(best, query(num)); } return best; } static void insert(int num) { BinaryTrieNode node = root; for (int i = BITS; i >= 0; i--) { int bit = (num >> i) & 1; node = node.children.computeIfAbsent(bit, b -> new BinaryTrieNode()); } } static int query(int num) { BinaryTrieNode node = root; int xor = 0; for (int i = BITS; i >= 0; i--) { int bit = (num >> i) & 1; int desired = 1 - bit; // the opposite bit maximizes this position's contribution if (node.children.containsKey(desired)) { xor |= (1 << i); node = node.children.get(desired); } else { node = node.children.get(bit); } } return xor; } } class BinaryTrieNode { Map children = new HashMap<>(); // 0 or 1 -> BinaryTrieNode } ``` **Complexity:** Time O(n × 32) = O(n), space O(n × 32) for the trie nodes. Far better than the naive O(n²) pairwise XOR comparison. **Common mistakes:** Iterating bits least-significant-first instead of most-significant-first. The greedy "prefer the opposite bit" strategy only produces the true maximum when higher bit positions are locked in before lower ones. Also, forgetting a fixed bit width, which lets negative numbers or inconsistent trie depths break the comparisons. > **Remember:** a binary trie over bits, most significant first, walking toward the opposite bit at every step, turns "best XOR partner" into an O(32) walk. ```knowledge-check { "questions": [ { "id": "dsa-tries-max-xor-q1", "type": "mcq", "prompt": "Why must the binary trie for Maximum XOR be built most-significant-bit first, not least-significant-bit first?", "options": [ {"id": "a", "text": "The greedy 'take the opposite bit' strategy only maximizes the result if higher bit positions are decided before lower ones"}, {"id": "b", "text": "Least-significant-first would make insertion run in O(n^2)"}, {"id": "c", "text": "It only matters for negative numbers"}, {"id": "d", "text": "Bit order makes no difference to correctness"} ], "correct": "a", "explanation": "A higher bit position contributes more to the XOR value than any combination of lower bits. Deciding bits from most significant to least, greedily, guarantees the largest possible value, which only works if higher bits are fixed first." } ] } ``` 38:T7109,Think of a hospital emergency room. Patients don't get treated in the order they arrived; the most critical case always goes next, no matter where they are in the waiting line. A heap is that triage system for data: it always hands you the smallest (or largest) item first, cheaply, even as new items keep arriving. That's the engine behind top-K problems, merging sorted data, scheduling, and streaming statistics. ## A heap's shape: a complete binary tree in an array A heap is a **complete binary tree** stored in a plain array: every level is fully filled except possibly the last, which fills left to right with no gaps. That completeness is exactly what lets you store the tree in an array with no pointers wasted, since a node's children live at predictable index offsets. For a node at index `i` (0-indexed array): ```python def parent(i): return (i - 1) // 2 def left(i): return 2 * i + 1 def right(i): return 2 * i + 2 ``` ```javascript + function parent(i) { return Math.floor((i - 1) / 2); } function left(i) { return 2 * i + 1; } function right(i) { return 2 * i + 2; } ``` ```java + public class Main { public static void main(String[] args) { int i = 5; System.out.println("parent(" + i + ") = " + parent(i)); System.out.println("left(" + i + ") = " + left(i)); System.out.println("right(" + i + ") = " + right(i)); } static int parent(int i) { return (i - 1) / 2; } static int left(int i) { return 2 * i + 1; } static int right(int i) { return 2 * i + 2; } } ``` ``` Array: [1, 3, 2, 7, 5, 4, 8] Tree: 1(0) / \ 3(1) 2(2) / \ / \ 7(3) 5(4) 4(5) 8(6) ``` Because the tree is always complete, its height is always `O(log n)` for `n` elements. That height bound is exactly why every heap operation costs `O(log n)`, not more. > **Remember:** a heap is a complete binary tree living inside a flat array. Index math (`2i+1`, `2i+2`, `(i-1)//2`) replaces pointers. ```knowledge-check { "questions": [ { "id": "dsa-heaps-shape-q1", "type": "mcq", "prompt": "Why can a heap be stored as a plain array instead of needing left/right pointers like a general binary tree?", "options": [ {"id": "a", "text": "Because a heap is always a complete binary tree, so a child's array index can be computed from its parent's index"}, {"id": "b", "text": "Because heaps never have more than 2 levels"}, {"id": "c", "text": "Because heap values are always sorted"}, {"id": "d", "text": "Arrays are required for all binary trees, not just heaps"} ], "correct": "a", "explanation": "Completeness (every level full except possibly the last, filled left to right) means there are no gaps, so a simple index formula always finds a node's children and parent without storing explicit pointers." } ] } ``` ## Min heap vs max heap **Min heap:** every parent is less than or equal to both its children. The smallest element always sits at the root, index 0. Python's `heapq` module implements a min heap. **Max heap:** every parent is greater than or equal to both children. The largest element always sits at the root. ```python import heapq min_heap = [] for x in [5, 1, 8, 3]: heapq.heappush(min_heap, x) print(min_heap[0]) # 1 — smallest, always at index 0 # Python has no max-heap; negate values as the standard workaround max_heap = [] for x in [5, 1, 8, 3]: heapq.heappush(max_heap, -x) print(-max_heap[0]) # 8 — largest ``` ```javascript + // JavaScript has no built-in heap; keeping the array sorted after each // insert reproduces the same "smallest at index 0" behavior for small demos. const minHeap = []; for (const x of [5, 1, 8, 3]) { minHeap.push(x); minHeap.sort((a, b) => a - b); } minHeap[0]; // 1 — smallest, always at index 0 // No max-heap either; negate values as the standard workaround const maxHeap = []; for (const x of [5, 1, 8, 3]) { maxHeap.push(-x); maxHeap.sort((a, b) => a - b); } -maxHeap[0]; // 8 — largest ``` ```java + import java.util.*; public class Main { public static void main(String[] args) { PriorityQueue minHeap = new PriorityQueue<>(); for (int x : new int[]{5, 1, 8, 3}) minHeap.add(x); System.out.println(minHeap.peek()); // 1 — smallest, always at the head // Java's PriorityQueue supports a custom comparator directly — // no negation trick needed for a max-heap, unlike Python's heapq. PriorityQueue maxHeap = new PriorityQueue<>(Comparator.reverseOrder()); for (int x : new int[]{5, 1, 8, 3}) maxHeap.add(x); System.out.println(maxHeap.peek()); // 8 — largest } } ``` **Pitfall with the negation trick:** when you push tuples for a max heap, such as `(priority, item)`, negate only the priority field, and remember to negate it back when you pop. When priorities tie, Python compares the next tuple element. If that's an unorderable object, like a custom class, you get a `TypeError`, so add an index or unique tiebreaker as a third tuple element to sidestep this. | | Min heap | Max heap | |---|---|---| | Root | Smallest | Largest | | `heapq` support | Native | Simulate via negation | | Use for | Top-K largest (keep heap size K), Dijkstra, merge-K-lists | Top-K smallest, task scheduling by highest priority first | > **Remember:** Python's `heapq` is min-heap only. For a max heap, negate values going in and negate the result coming out. ```knowledge-check { "questions": [ { "id": "dsa-heaps-min-vs-max-q1", "type": "mcq", "prompt": "How do you simulate a max heap using Python's heapq, which only implements a min heap?", "options": [ {"id": "a", "text": "Push negated values, and negate the result again when reading them back"}, {"id": "b", "text": "heapq has a separate max-heap mode you can enable"}, {"id": "c", "text": "Sort the list after every push"}, {"id": "d", "text": "It's impossible to build a max heap in Python"} ], "correct": "a", "explanation": "heapq only ever keeps the smallest value at the root. Negating values before pushing flips 'largest' into 'most negative,' which heapq's min-heap logic then surfaces correctly; negate again when reading a value out." } ] } ``` ## Building a heap from scratch in O(n) `heapify` builds a valid heap from an arbitrary array in O(n) time, not the O(n log n) you might guess from "n inserts of O(log n) each." The trick: start from the last non-leaf node and sift each node down, working backward toward the root. Most nodes sit near the bottom of the tree, where a sift-down is cheap, so the total work sums to O(n), not O(n log n). ```python def sift_down(arr, i, n): while True: smallest = i l, r = 2 * i + 1, 2 * i + 2 if l < n and arr[l] < arr[smallest]: smallest = l if r < n and arr[r] < arr[smallest]: smallest = r if smallest == i: break arr[i], arr[smallest] = arr[smallest], arr[i] i = smallest def heapify(arr): n = len(arr) for i in range(n // 2 - 1, -1, -1): # start at last non-leaf, go to root sift_down(arr, i, n) ``` ```javascript + function siftDown(arr, i, n) { while (true) { let smallest = i; const l = 2 * i + 1, r = 2 * i + 2; if (l < n && arr[l] < arr[smallest]) smallest = l; if (r < n && arr[r] < arr[smallest]) smallest = r; if (smallest === i) break; [arr[i], arr[smallest]] = [arr[smallest], arr[i]]; i = smallest; } } function heapify(arr) { const n = arr.length; for (let i = Math.floor(n / 2) - 1; i >= 0; i--) { // start at last non-leaf, go to root siftDown(arr, i, n); } } ``` ```java + public class Main { public static void main(String[] args) { int[] data = {9, 4, 7, 1, 3, 8}; heapify(data); System.out.println(java.util.Arrays.toString(data)); // a valid min-heap array } static void siftDown(int[] arr, int i, int n) { while (true) { int smallest = i; int l = 2 * i + 1, r = 2 * i + 2; if (l < n && arr[l] < arr[smallest]) smallest = l; if (r < n && arr[r] < arr[smallest]) smallest = r; if (smallest == i) break; int tmp = arr[i]; arr[i] = arr[smallest]; arr[smallest] = tmp; i = smallest; } } static void heapify(int[] arr) { int n = arr.length; for (int i = n / 2 - 1; i >= 0; i--) { // start at last non-leaf, go to root siftDown(arr, i, n); } } } ``` ```python data = [9, 4, 7, 1, 3, 8] heapify(data) print(data) # a valid min-heap array, e.g. [1, 3, 7, 9, 4, 8] ``` ```javascript + function siftDown(arr, i, n) { while (true) { let smallest = i; const l = 2 * i + 1, r = 2 * i + 2; if (l < n && arr[l] < arr[smallest]) smallest = l; if (r < n && arr[r] < arr[smallest]) smallest = r; if (smallest === i) break; [arr[i], arr[smallest]] = [arr[smallest], arr[i]]; i = smallest; } } function heapify(arr) { const n = arr.length; for (let i = Math.floor(n / 2) - 1; i >= 0; i--) { siftDown(arr, i, n); } } const data = [9, 4, 7, 1, 3, 8]; heapify(data); data; // a valid min-heap array, e.g. [1, 3, 7, 9, 4, 8] ``` ```java + import java.util.Arrays; public class Main { public static void main(String[] args) { int[] data = {9, 4, 7, 1, 3, 8}; heapify(data); System.out.println(Arrays.toString(data)); // a valid min-heap array } static void siftDown(int[] arr, int i, int n) { while (true) { int smallest = i; int l = 2 * i + 1, r = 2 * i + 2; if (l < n && arr[l] < arr[smallest]) smallest = l; if (r < n && arr[r] < arr[smallest]) smallest = r; if (smallest == i) break; int tmp = arr[i]; arr[i] = arr[smallest]; arr[smallest] = tmp; i = smallest; } } static void heapify(int[] arr) { int n = arr.length; for (int i = n / 2 - 1; i >= 0; i--) { siftDown(arr, i, n); } } } ``` Python's `heapq.heapify(list)` does exactly this in place, in O(n). > **Remember:** heapify is O(n), not O(n log n), because it starts from the bottom, where most nodes live and sifting is cheap. ```knowledge-check { "questions": [ { "id": "dsa-heaps-heapify-q1", "type": "mcq", "prompt": "Why is building a heap from an array with heapify O(n), rather than O(n log n) like n separate inserts?", "options": [ {"id": "a", "text": "Most nodes sit near the bottom of the tree, where a sift-down is cheap, so the total work across all nodes sums to O(n)"}, {"id": "b", "text": "heapify skips checking half the array"}, {"id": "c", "text": "It only works on arrays that are already partially sorted"}, {"id": "d", "text": "It's actually O(n log n); the O(n) claim is a common myth"} ], "correct": "a", "explanation": "A node near the bottom has a short distance to sift down, and most nodes in a complete tree are near the bottom. Summing sift-down cost across all nodes, weighted by how many nodes are at each height, totals O(n), a real amortized-analysis result, not a myth." } ] } ``` ## Kth Largest Element in Array [LeetCode 215](https://leetcode.com/problems/kth-largest-element-in-an-array/), Heap, QuickSelect alternative Keep a min heap that never holds more than `k` elements. After scanning every number, the heap's root is the k-th largest: everything smaller has already been evicted, leaving exactly the top `k` values, the smallest of which sits at the root. **Approach:** Push each number; if the heap grows past `k`, pop the smallest. At the end, the root is the answer. ```python def findKthLargest(nums: list[int], k: int) -> int: heap = [] for num in nums: heapq.heappush(heap, num) if len(heap) > k: heapq.heappop(heap) return heap[0] ``` ```javascript + function findKthLargest(nums, k) { const heap = []; for (const num of nums) { heap.push(num); heap.sort((a, b) => a - b); if (heap.length > k) heap.shift(); } return heap[0]; } ``` ```java + import java.util.*; public class Main { public static void main(String[] args) { int[] nums = {3, 2, 1, 5, 6, 4}; System.out.println(findKthLargest(nums, 2)); } static int findKthLargest(int[] nums, int k) { PriorityQueue heap = new PriorityQueue<>(); for (int num : nums) { heap.add(num); if (heap.size() > k) heap.poll(); } return heap.peek(); } } ``` **Complexity:** Time O(n log k), space O(k), much better than sorting's O(n log n) when k is small. QuickSelect reaches average O(n) but worst-case O(n²) and mutates the input, so the heap approach is the safer one to lead with, mentioning QuickSelect as the follow-up optimization. **Common mistakes:** Using a max heap of all n elements and popping k times: O(n + k log n), but it needlessly builds a heap over the whole array when a size-k min heap is smaller and easier to reason about. Forgetting the size check lets the heap grow unbounded. > **Remember:** a size-k min heap; whatever survives eviction, its root is the k-th largest. ```knowledge-check { "questions": [ { "id": "dsa-heaps-kth-largest-q1", "type": "mcq", "prompt": "In the size-k min-heap approach to Kth Largest, what does the heap's root represent once every number has been processed?", "options": [ {"id": "a", "text": "The k-th largest element overall"}, {"id": "b", "text": "The single largest element overall"}, {"id": "c", "text": "The smallest element overall"}, {"id": "d", "text": "The average of the top k elements"} ], "correct": "a", "explanation": "The heap only ever holds the k largest values seen so far, evicting the smallest whenever it overflows past k. Since it's a min heap, the smallest of those k survivors, at the root, is exactly the k-th largest overall." } ] } ``` ## Top K Frequent Elements [LeetCode 347](https://leetcode.com/problems/top-k-frequent-elements/), Heap, Frequency counting Count frequencies first; then you need the k elements with the highest counts. This is the same "maintain a size-k heap" pattern as Kth Largest, just ordered by frequency instead of raw value. **Approach:** `Counter` for frequencies, then a min heap of size k keyed by frequency, evicting the lowest-frequency entry whenever the heap exceeds k. ```python from collections import Counter def topKFrequent(nums: list[int], k: int) -> list[int]: counts = Counter(nums) heap = [] for num, freq in counts.items(): heapq.heappush(heap, (freq, num)) if len(heap) > k: heapq.heappop(heap) return [num for freq, num in heap] ``` ```javascript + function topKFrequent(nums, k) { const counts = new Map(); for (const num of nums) counts.set(num, (counts.get(num) || 0) + 1); const heap = []; // [freq, num] pairs, kept sorted by freq for (const [num, freq] of counts) { heap.push([freq, num]); heap.sort((a, b) => a[0] - b[0]); if (heap.length > k) heap.shift(); } return heap.map(([freq, num]) => num); } ``` ```java + import java.util.*; public class Main { public static void main(String[] args) { int[] nums = {1, 1, 1, 2, 2, 3}; System.out.println(topKFrequent(nums, 2)); } static List topKFrequent(int[] nums, int k) { Map counts = new HashMap<>(); for (int num : nums) counts.merge(num, 1, Integer::sum); PriorityQueue heap = new PriorityQueue<>(Comparator.comparingInt(a -> a[0])); for (Map.Entry entry : counts.entrySet()) { heap.add(new int[]{entry.getValue(), entry.getKey()}); if (heap.size() > k) heap.poll(); } List result = new ArrayList<>(); for (int[] pair : heap) result.add(pair[1]); return result; } } ``` **Complexity:** Time O(n log k), space O(n) for the counter. `heapq.nlargest(k, counts.keys(), key=counts.get)` is the idiomatic one-liner if the interviewer allows library shortcuts, but be ready to write it by hand, since that's usually the actual ask. **Common mistakes:** Sorting the full frequency map, O(n log n), when k is small and a heap does better. Forgetting the answer only needs the numbers, not the frequencies, when building the return list. ### The full menu: three ways to find top K, in order of when to reach for each Every "find the K elements with the highest count" problem builds on the same first step: ```python from collections import Counter freq = Counter(arr) # O(n) — {element: count} ``` From there, three approaches, from simplest to fastest: | Approach | How | Time | When to use | |---|---|---|---| | A. Sort | `sorted(freq.items(), key=lambda x: -x[1])[:k]` | O(n log n) | Default, safe answer. Correct and easy to write under pressure. | | B. Size-k heap | The pattern above: push, evict past k | O(n log k) | The standard "top-k" answer once asked to optimize. Best when k is much smaller than n. | | C. Bucket sort | Index directly by frequency (below) | O(n) | When pushed further: "can you beat O(n log k)?" | Approach C's insight: a value's frequency can never exceed `n` (the array's length), so instead of comparing or sorting, index an array directly by frequency. ```python def top_k_frequent_bucket(arr, k): freq = Counter(arr) buckets = [[] for _ in range(len(arr) + 1)] # index = frequency for num, count in freq.items(): buckets[count].append(num) result = [] for count in range(len(buckets) - 1, 0, -1): # walk from highest frequency down for num in buckets[count]: result.append(num) if len(result) == k: return result return result ``` Bucket sort trades a general-purpose comparison sort for an array indexed by the bounded range of possible frequencies (`0..n`), which gives true linear time. It's the answer to give when an interviewer pushes for something better than O(n log n). > **Remember:** sort is the safe default, a size-k heap is the expected optimization, bucket sort is the answer when asked to beat O(n log k). ```knowledge-check { "questions": [ { "id": "dsa-heaps-top-k-frequent-q1", "type": "mcq", "prompt": "What makes the bucket-sort approach to Top K Frequent run in O(n) instead of O(n log n)?", "options": [ {"id": "a", "text": "Frequency is bounded by the array length, so you can index buckets directly by frequency instead of comparing and sorting"}, {"id": "b", "text": "It secretly uses a heap internally"}, {"id": "c", "text": "It only works when k equals 1"}, {"id": "d", "text": "It skips counting frequencies entirely"} ], "correct": "a", "explanation": "Since no element can occur more than n times, you can allocate n+1 buckets indexed by frequency and place each element directly, avoiding any comparison-based sort. Walking buckets from highest to lowest frequency then reads off the answer in linear time." } ] } ``` ## Merge K Sorted Lists [LeetCode 23](https://leetcode.com/problems/merge-k-sorted-lists/), Heap, Merge technique At any point in the merge, the next smallest overall value is the smallest among the current heads of all k lists. A min heap holding one candidate per list gives you that smallest value in O(log k), instead of scanning all k heads in O(k) at every step. **Approach:** Push the head of each list into a min heap keyed by value (with a tiebreaker index, since comparing `ListNode` objects directly would fail). Pop the minimum, append it to the result, and push its `.next` if one exists. ```python class ListNode: def __init__(self, val=0, next=None): self.val = val self.next = next def mergeKLists(lists: list[ListNode]) -> ListNode: heap = [] for i, node in enumerate(lists): if node: heapq.heappush(heap, (node.val, i, node)) # i breaks value ties dummy = ListNode() tail = dummy while heap: val, i, node = heapq.heappop(heap) tail.next = node tail = tail.next if node.next: heapq.heappush(heap, (node.next.val, i, node.next)) return dummy.next ``` ```javascript + class ListNode { constructor(val = 0, next = null) { this.val = val; this.next = next; } } function mergeKLists(lists) { const heap = []; // [val, index, node] triples, index breaks value ties lists.forEach((node, i) => { if (node) heap.push([node.val, i, node]); }); heap.sort((a, b) => a[0] - b[0]); const dummy = new ListNode(); let tail = dummy; while (heap.length > 0) { const [val, i, node] = heap.shift(); tail.next = node; tail = tail.next; if (node.next) { heap.push([node.next.val, i, node.next]); heap.sort((a, b) => a[0] - b[0]); } } return dummy.next; } ``` ```java + import java.util.*; public class Main { public static void main(String[] args) { ListNode a = new ListNode(1, new ListNode(4, new ListNode(5))); ListNode b = new ListNode(1, new ListNode(3, new ListNode(4))); ListNode c = new ListNode(2, new ListNode(6)); ListNode merged = mergeKLists(new ListNode[]{a, b, c}); StringBuilder sb = new StringBuilder(); while (merged != null) { sb.append(merged.val).append(" "); merged = merged.next; } System.out.println(sb.toString().trim()); } static ListNode mergeKLists(ListNode[] lists) { PriorityQueue heap = new PriorityQueue<>(Comparator.comparingInt(n -> n.val)); for (ListNode node : lists) { if (node != null) heap.add(node); } ListNode dummy = new ListNode(); ListNode tail = dummy; while (!heap.isEmpty()) { ListNode node = heap.poll(); tail.next = node; tail = tail.next; if (node.next != null) heap.add(node.next); } return dummy.next; } } class ListNode { int val; ListNode next; ListNode() {} ListNode(int val) { this.val = val; } ListNode(int val, ListNode next) { this.val = val; this.next = next; } } ``` **Complexity:** Time O(N log k), where N is the total node count across all lists. Space O(k) for the heap. **Common mistakes:** Pushing `(val, node)` without a tiebreaker; comparing `ListNode` objects when values tie raises a type error. Forgetting the dummy-head pattern makes assembling the result list awkward. > **Remember:** the heap only ever holds k candidates, one per list's current head. Popping the smallest and pushing its successor keeps that invariant. ```knowledge-check { "questions": [ { "id": "dsa-heaps-merge-k-lists-q1", "type": "mcq", "prompt": "Why does the heap-based Merge K Sorted Lists solution push a tiebreaker index alongside each value?", "options": [ {"id": "a", "text": "So the heap has something orderable to compare when two nodes have equal values, avoiding a comparison error on the node objects themselves"}, {"id": "b", "text": "To track which list each node originally came from, for the final answer"}, {"id": "c", "text": "It's required to make the heap operations O(log k) instead of O(k)"}, {"id": "d", "text": "To sort the output list alphabetically"} ], "correct": "a", "explanation": "heapq compares tuples element by element. If two nodes have the same value, it would try to compare the ListNode objects next, which usually isn't supported. The index breaks the tie before that comparison is needed." } ] } ``` ## Find Median from Data Stream [LeetCode 295](https://leetcode.com/problems/find-median-from-data-stream/), Heap, Two heaps pattern Split the stream into two halves: a max heap holding the smaller half, a min heap holding the larger half. Keep the two halves balanced in size, never differing by more than 1. The median is then either the max heap's root, the min heap's root, or the average of both, with no full sort needed on every insert. **Approach:** Add each new number to the appropriate heap, then rebalance so the sizes never differ by more than 1. ```python class MedianFinder: def __init__(self): self.small = [] # max heap (negated), holds the smaller half self.large = [] # min heap, holds the larger half def addNum(self, num: int) -> None: heapq.heappush(self.small, -num) # ensure every element in small <= every element in large heapq.heappush(self.large, -heapq.heappop(self.small)) if len(self.large) > len(self.small): heapq.heappush(self.small, -heapq.heappop(self.large)) def findMedian(self) -> float: if len(self.small) > len(self.large): return -self.small[0] return (-self.small[0] + self.large[0]) / 2.0 ``` ```javascript + class MedianFinder { constructor() { this.small = []; // "max heap" (kept sorted desc), holds the smaller half this.large = []; // "min heap" (kept sorted asc), holds the larger half } addNum(num) { this.small.push(num); this.small.sort((a, b) => b - a); // ensure every element in small <= every element in large this.large.push(this.small.shift()); this.large.sort((a, b) => a - b); if (this.large.length > this.small.length) { this.small.push(this.large.shift()); this.small.sort((a, b) => b - a); } } findMedian() { if (this.small.length > this.large.length) return this.small[0]; return (this.small[0] + this.large[0]) / 2.0; } } ``` ```java + import java.util.*; public class Main { public static void main(String[] args) { MedianFinder mf = new MedianFinder(); mf.addNum(1); mf.addNum(2); System.out.println(mf.findMedian()); // 1.5 mf.addNum(3); System.out.println(mf.findMedian()); // 2.0 } } class MedianFinder { private final PriorityQueue small = new PriorityQueue<>(Comparator.reverseOrder()); // max heap, smaller half private final PriorityQueue large = new PriorityQueue<>(); // min heap, larger half public void addNum(int num) { small.add(num); // ensure every element in small <= every element in large large.add(small.poll()); if (large.size() > small.size()) { small.add(large.poll()); } } public double findMedian() { if (small.size() > large.size()) return small.peek(); return (small.peek() + large.peek()) / 2.0; } } ``` **Complexity:** Time O(log n) per `addNum`, O(1) per `findMedian`. Space O(n) to hold the stream. **Common mistakes:** Forgetting to route every insert through `small` first. The push-then-pop-then-rebalance sequence above guarantees correctness even when the new number actually belongs in `large`. Allowing a size imbalance greater than 1, which breaks the median formula. A plain sorted list with insertion also works, with O(n) insert, but it doesn't scale as well as the two-heap approach for large streams; mention it as the naive baseline. > **Remember:** two heaps, split at the midpoint, rebalanced after every insert so sizes never differ by more than 1. The median is at the two roots. ```knowledge-check { "questions": [ { "id": "dsa-heaps-median-stream-q1", "type": "mcq", "prompt": "In the two-heap median-finder, why must every new number be pushed into 'small' first, even if it actually belongs in the larger half?", "options": [ {"id": "a", "text": "It guarantees correctness through a consistent push-then-rebalance sequence, regardless of which half the number truly belongs in"}, {"id": "b", "text": "It makes addNum run in O(1) instead of O(log n)"}, {"id": "c", "text": "Because 'large' can never accept a direct insert"}, {"id": "d", "text": "It has no effect; either heap works equally well as the entry point"} ], "correct": "a", "explanation": "Always pushing into small first, then moving its top into large, then rebalancing if needed, is a fixed routine that always ends with a correct split, without needing to first figure out which half the new number belongs in." } ] } ``` 39:T74a6,Think of a map of friendships: you, your friends, and their friends, connected by lines. Finding out if two people are connected, or how many steps separate them, means walking those lines without retracing your steps. That is graph traversal, the single most reused pattern in interviews. Grids, dependency chains, social networks, and state-space search all reduce to "visit nodes without visiting the same one twice." ## Two ways to draw a graph in code A graph is a set of nodes (vertices) connected by edges. You almost always represent it one of two ways. **Adjacency list**: a dict or array mapping each node to its neighbors. ```python from collections import defaultdict graph = defaultdict(list) edges = [(0, 1), (0, 2), (1, 2), (2, 3)] for u, v in edges: graph[u].append(v) graph[v].append(u) # omit this line for a directed graph print(dict(graph)) # {0: [1, 2], 1: [0, 2], 2: [0, 1, 3], 3: [2]} ``` ```javascript + const graph = new Map(); const edges = [[0, 1], [0, 2], [1, 2], [2, 3]]; for (const [u, v] of edges) { if (!graph.has(u)) graph.set(u, []); if (!graph.has(v)) graph.set(v, []); graph.get(u).push(v); graph.get(v).push(u); // omit this line for a directed graph } console.log(Object.fromEntries(graph)); // { '0': [ 1, 2 ], '1': [ 0, 2 ], '2': [ 0, 1, 3 ], '3': [ 2 ] } ``` ```java + import java.util.ArrayList; import java.util.LinkedHashMap; import java.util.List; import java.util.Map; public class Main { public static void main(String[] args) { Map> graph = new LinkedHashMap<>(); int[][] edges = {{0, 1}, {0, 2}, {1, 2}, {2, 3}}; for (int[] edge : edges) { int u = edge[0]; int v = edge[1]; graph.computeIfAbsent(u, k -> new ArrayList<>()).add(v); graph.computeIfAbsent(v, k -> new ArrayList<>()).add(u); // omit this line for a directed graph } System.out.println(graph); // {0=[1, 2], 1=[0, 2], 2=[0, 1, 3], 3=[2]} } } ``` **Adjacency matrix**: an `n x n` grid where `matrix[i][j] = 1` if an edge exists. ```python n = 4 matrix = [[0] * n for _ in range(n)] for u, v in edges: matrix[u][v] = 1 matrix[v][u] = 1 ``` ```javascript + const n = 4; const edges = [[0, 1], [0, 2], [1, 2], [2, 3]]; const matrix = Array.from({ length: n }, () => new Array(n).fill(0)); for (const [u, v] of edges) { matrix[u][v] = 1; matrix[v][u] = 1; } ``` ```java + import java.util.Arrays; public class Main { public static void main(String[] args) { int n = 4; int[][] edges = {{0, 1}, {0, 2}, {1, 2}, {2, 3}}; int[][] matrix = new int[n][n]; for (int[] edge : edges) { int u = edge[0]; int v = edge[1]; matrix[u][v] = 1; matrix[v][u] = 1; } for (int[] row : matrix) { System.out.println(Arrays.toString(row)); } } } ``` | | Adjacency list | Adjacency matrix | |---|---|---| | Space | O(V + E) | O(V²) | | "Are u, v connected?" | O(degree(u)) | O(1) | | Iterate neighbors of u | O(degree(u)) | O(V) | | Best for | Sparse graphs (most interview problems) | Dense graphs, small V, or when you need O(1) edge lookup | **Pitfall:** grid problems (Number of Islands, Rotting Oranges) don't hand you a graph object at all. The 2D grid itself is the implicit adjacency structure, with a cell's neighbors being the 4 (or 8) cells around it. Recognizing that a grid IS a graph is half the battle. > **Remember:** most interview graphs are sparse, so default to an adjacency list. A grid is a graph in disguise; its cells are nodes, adjacency is "next door." ```knowledge-check { "questions": [ { "id": "dsa-graphs-bfs-dfs-representation-q1", "type": "mcq", "prompt": "Why do most interview problems default to an adjacency list instead of an adjacency matrix?", "options": [ {"id": "a", "text": "Most interview graphs are sparse, and a list uses O(V + E) space instead of O(V²)"}, {"id": "b", "text": "Adjacency matrices can't represent directed graphs"}, {"id": "c", "text": "Adjacency lists are always faster for every operation"}, {"id": "d", "text": "Matrices can only hold numeric node labels"} ], "correct": "a", "explanation": "A sparse graph has far fewer edges than the V² an adjacency matrix would allocate. The list only stores space proportional to the edges that actually exist, which is the common case in interview problems." } ] } ``` ## Choosing BFS or DFS Both visit every reachable node exactly once, but they explore in different orders and answer different questions. | | BFS | DFS | |---|---|---| | Data structure | Queue (FIFO) | Stack (explicit) or recursion (call stack) | | Explores | Level by level, outward from the source | One path all the way down before backtracking | | Use for | Shortest path in an unweighted graph, "minimum steps", spreading from multiple sources | Path existence, connected components, cycle detection, backtracking, topological order | | Space | O(V), can hold a full level | O(V) worst case (deep recursion), often less for wide, shallow graphs | Rule of thumb: **if the question says "shortest," "minimum," or "fewest steps," reach for BFS.** If it says "does a path exist," "find all paths," or "explore everything," DFS, often recursive, is simpler to write and reason about. > **Remember:** "shortest" or "fewest steps" means BFS. "Does a path exist" or "find all X" means DFS. ```knowledge-check { "questions": [ { "id": "dsa-graphs-bfs-dfs-choosing-q1", "type": "mcq", "prompt": "A problem asks for the minimum number of moves to reach a target cell. Which traversal should you reach for first?", "options": [ {"id": "a", "text": "BFS, since it explores level by level and finds the shortest path in an unweighted graph"}, {"id": "b", "text": "DFS, since it's simpler to write"}, {"id": "c", "text": "Either works equally well for shortest-path questions"}, {"id": "d", "text": "Neither; shortest path always needs Dijkstra's algorithm"} ], "correct": "a", "explanation": "BFS visits nodes in order of distance from the source, so the first time it reaches the target is guaranteed to be via the shortest path, as long as edges are unweighted." } ] } ``` ## Marking nodes visited at the right moment Without tracking visited nodes, a cyclic graph causes an infinite loop. The detail interviewers probe hardest: **mark a node visited the moment you enqueue or push it, not when you pop it.** ```python from collections import deque def bfs(graph, start): visited = {start} # mark on enqueue queue = deque([start]) order = [] while queue: node = queue.popleft() order.append(node) for neighbor in graph[node]: if neighbor not in visited: visited.add(neighbor) # mark here, not after popping queue.append(neighbor) return order ``` ```javascript + function bfs(graph, start) { const visited = new Set([start]); // mark on enqueue const queue = [start]; const order = []; while (queue.length > 0) { const node = queue.shift(); order.push(node); for (const neighbor of graph.get(node) ?? []) { if (!visited.has(neighbor)) { visited.add(neighbor); // mark here, not after popping queue.push(neighbor); } } } return order; } ``` ```java + import java.util.ArrayDeque; import java.util.ArrayList; import java.util.Deque; import java.util.HashSet; import java.util.List; import java.util.Map; import java.util.Set; public class Main { public static void main(String[] args) { Map> graph = Map.of( 0, List.of(1, 2), 1, List.of(0, 2), 2, List.of(0, 1, 3), 3, List.of(2) ); System.out.println(bfs(graph, 0)); } static List bfs(Map> graph, int start) { Set visited = new HashSet<>(); visited.add(start); // mark on enqueue Deque queue = new ArrayDeque<>(); queue.add(start); List order = new ArrayList<>(); while (!queue.isEmpty()) { int node = queue.poll(); order.add(node); for (int neighbor : graph.getOrDefault(node, List.of())) { if (!visited.contains(neighbor)) { visited.add(neighbor); // mark here, not after popping queue.add(neighbor); } } } return order; } } ``` Mark visited only at pop time instead, and the same node can land in the queue multiple times before it's ever processed. That's wasted work at best, and in multi-source variants it can produce wrong answers. For grids, `visited` is usually a 2D boolean array, or you mutate the grid in place (flipping `'1'` to `'0'`, say) to save space. > **Remember:** mark visited at enqueue/push time, not at pop/process time. Marking late lets duplicates pile into the queue. ```knowledge-check { "questions": [ { "id": "dsa-graphs-bfs-dfs-visited-q1", "type": "mcq", "prompt": "What goes wrong if you mark a node visited only when you pop it from the BFS queue, instead of when you enqueue it?", "options": [ {"id": "a", "text": "The same node can be enqueued multiple times before it's processed, wasting work or breaking multi-source variants"}, {"id": "b", "text": "BFS will visit nodes in the wrong order entirely"}, {"id": "c", "text": "It has no effect either way"}, {"id": "d", "text": "It makes BFS behave like DFS"} ], "correct": "a", "explanation": "If visited is only checked, not set, at enqueue time, a node can be discovered as a neighbor of several different nodes before it's ever popped, so it gets pushed into the queue more than once." } ] } ``` ## Number of Islands [LeetCode 200](https://leetcode.com/problems/number-of-islands/), DFS/BFS, Grid traversal Each connected group of `'1'`s is one island. Scan every cell; whenever you find an unvisited `'1'`, that's a brand-new island, so flood-fill it (DFS or BFS) to mark every connected land cell and avoid counting it twice. **Approach:** Iterate all cells. On an unvisited land cell, increment the island count and run DFS/BFS to sink the entire connected component (mutate it to `'0'` as "visited"). ```python def numIslands(grid: list[list[str]]) -> int: if not grid: return 0 rows, cols = len(grid), len(grid[0]) def dfs(r, c): if r < 0 or r >= rows or c < 0 or c >= cols or grid[r][c] != '1': return grid[r][c] = '0' # sink it so we never revisit dfs(r + 1, c) dfs(r - 1, c) dfs(r, c + 1) dfs(r, c - 1) islands = 0 for r in range(rows): for c in range(cols): if grid[r][c] == '1': islands += 1 dfs(r, c) return islands ``` ```javascript + function numIslands(grid) { if (grid.length === 0) { return 0; } const rows = grid.length; const cols = grid[0].length; function dfs(r, c) { if (r < 0 || r >= rows || c < 0 || c >= cols || grid[r][c] !== '1') { return; } grid[r][c] = '0'; // sink it so we never revisit dfs(r + 1, c); dfs(r - 1, c); dfs(r, c + 1); dfs(r, c - 1); } let islands = 0; for (let r = 0; r < rows; r++) { for (let c = 0; c < cols; c++) { if (grid[r][c] === '1') { islands += 1; dfs(r, c); } } } return islands; } ``` ```java + public class Main { static int rows; static int cols; public static void main(String[] args) { char[][] grid = { {'1', '1', '0', '0'}, {'1', '1', '0', '0'}, {'0', '0', '1', '0'}, {'0', '0', '0', '1'} }; System.out.println(numIslands(grid)); } static int numIslands(char[][] grid) { if (grid.length == 0) { return 0; } rows = grid.length; cols = grid[0].length; int islands = 0; for (int r = 0; r < rows; r++) { for (int c = 0; c < cols; c++) { if (grid[r][c] == '1') { islands += 1; dfs(grid, r, c); } } } return islands; } static void dfs(char[][] grid, int r, int c) { if (r < 0 || r >= rows || c < 0 || c >= cols || grid[r][c] != '1') { return; } grid[r][c] = '0'; // sink it so we never revisit dfs(grid, r + 1, c); dfs(grid, r - 1, c); dfs(grid, r, c + 1); dfs(grid, r, c - 1); } } ``` **Complexity:** Time O(rows × cols), each cell is visited a constant number of times. Space O(rows × cols) worst case for the recursion stack, when the grid is entirely land. **Common mistakes:** Forgetting boundary checks before indexing, which crashes with an out-of-range error. Mutating the grid without realizing the interviewer may not want the input destroyed; mention the trade-off and offer a separate `visited` set as an alternative. Using DFS recursion on a huge grid can hit a recursion-depth limit, something BFS with an explicit queue avoids entirely. > **Remember:** scan every cell; each unvisited land cell you find starts a new island. Flood-fill it so you never count it again. ```knowledge-check { "questions": [ { "id": "dsa-graphs-bfs-dfs-islands-q1", "type": "mcq", "prompt": "Why does mutating grid[r][c] to '0' after visiting it prevent double-counting islands?", "options": [ {"id": "a", "text": "It marks the cell as no longer land, so the outer scan and the flood-fill both skip it on any later visit"}, {"id": "b", "text": "It changes the island's shape"}, {"id": "c", "text": "It has no effect on the count; islands+=1 alone prevents double counting"}, {"id": "d", "text": "It's only needed for BFS, not DFS"} ], "correct": "a", "explanation": "Sinking a visited land cell to '0' acts as a visited marker built into the grid itself. Since the outer loop and the flood-fill both check for '1', a sunk cell is never picked up again by either." } ] } ``` ## Clone Graph [LeetCode 133](https://leetcode.com/problems/clone-graph/), BFS/DFS, Deep copy You must build a completely new graph with new node objects, while preserving the same connections. The trick is avoiding infinite loops on cycles: keep a map from original node to cloned node so you never clone the same node twice. **Approach:** BFS or DFS from the given start node. Use a hash map `old -> new`. Whenever you meet a neighbor you haven't cloned yet, create its clone and enqueue it; either way, append the clone to the current node's clone's neighbor list. ```python class Node: def __init__(self, val=0, neighbors=None): self.val = val self.neighbors = neighbors if neighbors is not None else [] def cloneGraph(node: 'Node') -> 'Node': if not node: return None old_to_new = {node: Node(node.val)} queue = deque([node]) while queue: cur = queue.popleft() for neighbor in cur.neighbors: if neighbor not in old_to_new: old_to_new[neighbor] = Node(neighbor.val) queue.append(neighbor) old_to_new[cur].neighbors.append(old_to_new[neighbor]) return old_to_new[node] ``` ```javascript + class Node { constructor(val = 0, neighbors = null) { this.val = val; this.neighbors = neighbors !== null ? neighbors : []; } } function cloneGraph(node) { if (!node) { return null; } const oldToNew = new Map([[node, new Node(node.val)]]); const queue = [node]; while (queue.length > 0) { const cur = queue.shift(); for (const neighbor of cur.neighbors) { if (!oldToNew.has(neighbor)) { oldToNew.set(neighbor, new Node(neighbor.val)); queue.push(neighbor); } oldToNew.get(cur).neighbors.push(oldToNew.get(neighbor)); } } return oldToNew.get(node); } ``` ```java + import java.util.ArrayDeque; import java.util.ArrayList; import java.util.Deque; import java.util.HashMap; import java.util.List; import java.util.Map; public class Main { public static void main(String[] args) { Node a = new Node(1); Node b = new Node(2); a.neighbors.add(b); b.neighbors.add(a); Node clonedA = cloneGraph(a); System.out.println("Cloned root val: " + clonedA.val + ", neighbor count: " + clonedA.neighbors.size()); } static Node cloneGraph(Node node) { if (node == null) { return null; } Map oldToNew = new HashMap<>(); oldToNew.put(node, new Node(node.val)); Deque queue = new ArrayDeque<>(); queue.add(node); while (!queue.isEmpty()) { Node cur = queue.poll(); for (Node neighbor : cur.neighbors) { if (!oldToNew.containsKey(neighbor)) { oldToNew.put(neighbor, new Node(neighbor.val)); queue.add(neighbor); } oldToNew.get(cur).neighbors.add(oldToNew.get(neighbor)); } } return oldToNew.get(node); } } class Node { int val; List neighbors = new ArrayList<>(); Node(int val) { this.val = val; } } ``` **Complexity:** Time O(V + E), space O(V) for the map and queue. **Common mistakes:** Cloning a neighbor's value instead of wiring up the actual clone object. Not handling the single-node-with-no-neighbors edge case. Re-cloning a node already in the map; always check the map before creating a new `Node`. > **Remember:** a map from old node to new node is what stops a cycle from cloning the same node twice, or looping forever. ```knowledge-check { "questions": [ { "id": "dsa-graphs-bfs-dfs-clone-q1", "type": "mcq", "prompt": "What role does the old-to-new hash map play in Clone Graph?", "options": [ {"id": "a", "text": "It prevents re-cloning the same node twice and avoids infinite loops on cyclic graphs"}, {"id": "b", "text": "It stores the final answer directly"}, {"id": "c", "text": "It sorts nodes by value before cloning"}, {"id": "d", "text": "It's only needed for graphs with more than 100 nodes"} ], "correct": "a", "explanation": "Without the map, a cycle (A points to B, B points back to A) would cause the clone process to keep creating new clones of the same nodes forever. Checking the map before cloning ensures each original node is cloned exactly once." } ] } ``` ## Rotting Oranges [LeetCode 994](https://leetcode.com/problems/rotting-oranges/), BFS, Multi-source BFS Every rotten orange rots its fresh neighbors at the same time, one minute at a time. That is BFS starting from multiple sources at once: seed the queue with every initially-rotten orange, then expand level by level, where each level equals exactly one minute. **Approach:** Push all rotten cells into the queue first (minute 0). Track the `fresh` count. BFS level by level; each level that rots at least one orange increments the minute counter. If `fresh > 0` after the BFS runs out, return -1. ```python def orangesRotting(grid: list[list[int]]) -> int: rows, cols = len(grid), len(grid[0]) queue = deque() fresh = 0 for r in range(rows): for c in range(cols): if grid[r][c] == 2: queue.append((r, c)) elif grid[r][c] == 1: fresh += 1 minutes = 0 directions = [(1, 0), (-1, 0), (0, 1), (0, -1)] while queue and fresh > 0: minutes += 1 for _ in range(len(queue)): # process one full level = one minute r, c = queue.popleft() for dr, dc in directions: nr, nc = r + dr, c + dc if 0 <= nr < rows and 0 <= nc < cols and grid[nr][nc] == 1: grid[nr][nc] = 2 fresh -= 1 queue.append((nr, nc)) return minutes if fresh == 0 else -1 ``` ```javascript + function orangesRotting(grid) { const rows = grid.length; const cols = grid[0].length; const queue = []; let fresh = 0; for (let r = 0; r < rows; r++) { for (let c = 0; c < cols; c++) { if (grid[r][c] === 2) { queue.push([r, c]); } else if (grid[r][c] === 1) { fresh += 1; } } } let minutes = 0; const directions = [[1, 0], [-1, 0], [0, 1], [0, -1]]; while (queue.length > 0 && fresh > 0) { minutes += 1; const levelSize = queue.length; // process one full level = one minute for (let i = 0; i < levelSize; i++) { const [r, c] = queue.shift(); for (const [dr, dc] of directions) { const nr = r + dr; const nc = c + dc; if (nr >= 0 && nr < rows && nc >= 0 && nc < cols && grid[nr][nc] === 1) { grid[nr][nc] = 2; fresh -= 1; queue.push([nr, nc]); } } } } return fresh === 0 ? minutes : -1; } ``` ```java + import java.util.ArrayDeque; import java.util.Deque; public class Main { public static void main(String[] args) { int[][] grid = { {2, 1, 1}, {1, 1, 0}, {0, 1, 1} }; System.out.println(orangesRotting(grid)); } static int orangesRotting(int[][] grid) { int rows = grid.length; int cols = grid[0].length; Deque queue = new ArrayDeque<>(); int fresh = 0; for (int r = 0; r < rows; r++) { for (int c = 0; c < cols; c++) { if (grid[r][c] == 2) { queue.add(new int[]{r, c}); } else if (grid[r][c] == 1) { fresh += 1; } } } int minutes = 0; int[][] directions = {{1, 0}, {-1, 0}, {0, 1}, {0, -1}}; while (!queue.isEmpty() && fresh > 0) { minutes += 1; int levelSize = queue.size(); // process one full level = one minute for (int i = 0; i < levelSize; i++) { int[] cell = queue.poll(); int r = cell[0]; int c = cell[1]; for (int[] dir : directions) { int nr = r + dir[0]; int nc = c + dir[1]; if (nr >= 0 && nr < rows && nc >= 0 && nc < cols && grid[nr][nc] == 1) { grid[nr][nc] = 2; fresh -= 1; queue.add(new int[]{nr, nc}); } } } } return fresh == 0 ? minutes : -1; } } ``` **Complexity:** Time O(rows × cols), space O(rows × cols) for the queue. **Common mistakes:** Incrementing `minutes` even on a final level where nothing new rotted. The level-batching pattern above handles this correctly; verify it against the "no fresh oranges at all" edge case, which should return 0. Forgetting multi-source seeding and instead running BFS from just one rotten cell. > **Remember:** seed the queue with every rotten orange at once. One BFS level equals exactly one minute passing. ```knowledge-check { "questions": [ { "id": "dsa-graphs-bfs-dfs-rotting-oranges-q1", "type": "mcq", "prompt": "Why does Rotting Oranges start BFS by pushing ALL initially-rotten cells into the queue at once, instead of one at a time?", "options": [ {"id": "a", "text": "All rotten oranges rot their neighbors simultaneously each minute, so BFS needs every rotten cell as a starting source"}, {"id": "b", "text": "Pushing one at a time would give a wrong final count but the same minute total"}, {"id": "c", "text": "It's only a minor optimization with no effect on correctness"}, {"id": "d", "text": "BFS requires exactly one starting node by definition"} ], "correct": "a", "explanation": "The problem's real-world rule is that every rotten orange spreads at the same time each minute. Seeding all of them at once and processing one full BFS level per minute directly models that simultaneous spread; seeding one at a time would compute the wrong timeline entirely." } ] } ``` ## Walls and Gates [LeetCode 286](https://leetcode.com/problems/walls-and-gates/), BFS, Fill distances Same multi-source BFS pattern as Rotting Oranges, but instead of counting minutes, you write the BFS depth directly into each empty room as its distance to the nearest gate. **Approach:** Seed the queue with every gate (value `0`). BFS outward; whenever you reach an empty room (`INF`), set its distance to `current_distance + 1` and enqueue it. ```python INF = 2147483647 def wallsAndGates(rooms: list[list[int]]) -> None: if not rooms: return rows, cols = len(rooms), len(rooms[0]) queue = deque() for r in range(rows): for c in range(cols): if rooms[r][c] == 0: queue.append((r, c)) directions = [(1, 0), (-1, 0), (0, 1), (0, -1)] while queue: r, c = queue.popleft() for dr, dc in directions: nr, nc = r + dr, c + dc if 0 <= nr < rows and 0 <= nc < cols and rooms[nr][nc] == INF: rooms[nr][nc] = rooms[r][c] + 1 queue.append((nr, nc)) ``` ```javascript + const INF = 2147483647; function wallsAndGates(rooms) { if (rooms.length === 0) { return; } const rows = rooms.length; const cols = rooms[0].length; const queue = []; for (let r = 0; r < rows; r++) { for (let c = 0; c < cols; c++) { if (rooms[r][c] === 0) { queue.push([r, c]); } } } const directions = [[1, 0], [-1, 0], [0, 1], [0, -1]]; while (queue.length > 0) { const [r, c] = queue.shift(); for (const [dr, dc] of directions) { const nr = r + dr; const nc = c + dc; if (nr >= 0 && nr < rows && nc >= 0 && nc < cols && rooms[nr][nc] === INF) { rooms[nr][nc] = rooms[r][c] + 1; queue.push([nr, nc]); } } } } ``` ```java + import java.util.ArrayDeque; import java.util.Arrays; import java.util.Deque; public class Main { static final int INF = Integer.MAX_VALUE; public static void main(String[] args) { int[][] rooms = { {INF, -1, 0, INF}, {INF, INF, INF, -1}, {INF, -1, INF, -1}, {0, -1, INF, INF} }; wallsAndGates(rooms); for (int[] row : rooms) { System.out.println(Arrays.toString(row)); } } static void wallsAndGates(int[][] rooms) { if (rooms.length == 0) { return; } int rows = rooms.length; int cols = rooms[0].length; Deque queue = new ArrayDeque<>(); for (int r = 0; r < rows; r++) { for (int c = 0; c < cols; c++) { if (rooms[r][c] == 0) { queue.add(new int[]{r, c}); } } } int[][] directions = {{1, 0}, {-1, 0}, {0, 1}, {0, -1}}; while (!queue.isEmpty()) { int[] cell = queue.poll(); int r = cell[0]; int c = cell[1]; for (int[] dir : directions) { int nr = r + dir[0]; int nc = c + dir[1]; if (nr >= 0 && nr < rows && nc >= 0 && nc < cols && rooms[nr][nc] == INF) { rooms[nr][nc] = rooms[r][c] + 1; queue.add(new int[]{nr, nc}); } } } } } ``` **Complexity:** Time O(rows × cols), space O(rows × cols). **Common mistakes:** Running BFS separately from every gate instead of seeding all gates into one shared queue. That still gives the correct answer, but it costs O(gates × cells) instead of O(cells); mention the multi-source optimization explicitly, since interviewers look for it. Walls (`-1`) should simply be skipped, not treated as an error case. > **Remember:** seed every gate into one shared queue, one BFS. Don't run a separate BFS per gate. ```knowledge-check { "questions": [ { "id": "dsa-graphs-bfs-dfs-walls-gates-q1", "type": "mcq", "prompt": "What is the benefit of seeding all gates into one shared BFS queue at once, rather than running a separate BFS from each gate?", "options": [ {"id": "a", "text": "It reduces the total cost from O(gates × cells) to O(cells)"}, {"id": "b", "text": "It's required for the algorithm to produce a correct answer at all"}, {"id": "c", "text": "It reduces the space used by the grid itself"}, {"id": "d", "text": "Running per-gate BFS produces a different, wrong distance value"} ], "correct": "a", "explanation": "A separate BFS per gate would each visit up to every cell, multiplying cost by the number of gates. A single multi-source BFS visits each cell once total, since the first time a room is reached is guaranteed to be via its nearest gate." } ] } ``` 3a:T9331,Before you can get dressed, you put on socks before shoes. Before a build system compiles your project, it compiles the files you depend on first. Topological sort answers exactly this question in code: "in what order must these tasks run, given their dependencies?" It only makes sense for graphs with no cycles, so cycle detection and topological sort are really two names for the same idea. ## What makes an order possible at all A **DAG** (Directed Acyclic Graph) is a directed graph with no cycles: you can never start at a node, follow edges, and arrive back where you started. That property is exactly what makes a valid ordering possible. If task A must come before task B (an edge A→B), a cycle A→B→A would make "before" meaningless, since A would need to come before B and after B at the same time. No valid order could exist. **Topological order**: a line-up of nodes such that for every directed edge `u → v`, `u` appears before `v` in the line. A DAG can have more than one valid topological order, or exactly one if it happens to be a strict chain. ```python # Example: 5 depends on 2 and 0; 4 depends on 0 and 1; 3 depends on 1 # edges: 5->2, 5->0, 4->0, 4->1, 2->3, 3->1 # Valid orders include: [5, 4, 2, 3, 1, 0] and [4, 5, 2, 3, 1, 0] ``` ```javascript + // Example: 5 depends on 2 and 0; 4 depends on 0 and 1; 3 depends on 1 // edges: 5->2, 5->0, 4->0, 4->1, 2->3, 3->1 // Valid orders include: [5, 4, 2, 3, 1, 0] and [4, 5, 2, 3, 1, 0] ``` ```java + public class Main { public static void main(String[] args) { // Example: 5 depends on 2 and 0; 4 depends on 0 and 1; 3 depends on 1 // edges: 5->2, 5->0, 4->0, 4->1, 2->3, 3->1 // Valid orders include: [5, 4, 2, 3, 1, 0] and [4, 5, 2, 3, 1, 0] } } ``` **Key fact:** a graph has a valid topological order **if and only if it is a DAG**. So "can this be topologically sorted?" and "does this graph have a cycle?" are the same question asked two ways, which is why cycle detection and topological sort share one algorithm. > **Remember:** a topological order exists only if the graph has no cycles. Asking "is it a DAG?" and "can it be sorted?" are the same question. ```knowledge-check { "questions": [ { "id": "dsa-graphs-topo-dag-q1", "type": "mcq", "prompt": "Why can a graph with a cycle never have a valid topological order?", "options": [ {"id": "a", "text": "A cycle would require a node to come both before and after another node in the same ordering, which is a contradiction"}, {"id": "b", "text": "Cycles just make computing the order slower, not impossible"}, {"id": "c", "text": "Topological order only applies to trees, not general graphs"}, {"id": "d", "text": "A cycle can be broken by picking any starting node"} ], "correct": "a", "explanation": "If A must come before B (A->B) and the graph also has B->A, then B must come before A too. No linear ordering can satisfy both at once, so a cycle makes a valid topological order impossible." } ] } ``` ## Kahn's algorithm: peel off nodes with nothing left owed to them Kahn's algorithm repeatedly removes nodes with **in-degree 0**, meaning no remaining dependencies point at them. That's the whole idea: a node with in-degree 0 can safely run right now, since nothing is still waiting to happen before it. ```python from collections import deque, defaultdict def kahn_topo_sort(num_nodes: int, edges: list[tuple[int, int]]) -> list[int]: graph = defaultdict(list) in_degree = [0] * num_nodes for u, v in edges: # u must come before v graph[u].append(v) in_degree[v] += 1 queue = deque(n for n in range(num_nodes) if in_degree[n] == 0) order = [] while queue: node = queue.popleft() order.append(node) for neighbor in graph[node]: in_degree[neighbor] -= 1 if in_degree[neighbor] == 0: queue.append(neighbor) if len(order) != num_nodes: return [] # cycle detected — not all nodes could be processed return order ``` ```javascript + function kahnTopoSort(numNodes, edges) { const graph = new Map(); const inDegree = new Array(numNodes).fill(0); for (const [u, v] of edges) { // u must come before v if (!graph.has(u)) graph.set(u, []); graph.get(u).push(v); inDegree[v] += 1; } const queue = []; for (let n = 0; n < numNodes; n++) { if (inDegree[n] === 0) queue.push(n); } const order = []; while (queue.length > 0) { const node = queue.shift(); order.push(node); for (const neighbor of graph.get(node) || []) { inDegree[neighbor] -= 1; if (inDegree[neighbor] === 0) queue.push(neighbor); } } if (order.length !== numNodes) return []; // cycle detected — not all nodes could be processed return order; } ``` ```java + import java.util.*; public class Main { public static void main(String[] args) { int numNodes = 6; int[][] edges = {{5, 2}, {5, 0}, {4, 0}, {4, 1}, {2, 3}, {3, 1}}; System.out.println(kahnTopoSort(numNodes, edges)); } static List kahnTopoSort(int numNodes, int[][] edges) { Map> graph = new HashMap<>(); int[] inDegree = new int[numNodes]; for (int[] edge : edges) { // u must come before v int u = edge[0], v = edge[1]; graph.computeIfAbsent(u, k -> new ArrayList<>()).add(v); inDegree[v]++; } Deque queue = new ArrayDeque<>(); for (int n = 0; n < numNodes; n++) { if (inDegree[n] == 0) queue.add(n); } List order = new ArrayList<>(); while (!queue.isEmpty()) { int node = queue.poll(); order.add(node); for (int neighbor : graph.getOrDefault(node, Collections.emptyList())) { inDegree[neighbor]--; if (inDegree[neighbor] == 0) queue.add(neighbor); } } if (order.size() != numNodes) return new ArrayList<>(); // cycle detected return order; } } ``` **Complexity:** Time O(V + E), space O(V + E). **Why it doubles as cycle detection:** if the graph has a cycle, the nodes inside that cycle never reach in-degree 0, since each one depends on another node that's also stuck in the cycle. So `order` ends up shorter than `num_nodes`. That length check IS the cycle check; no separate logic needed. > **Remember:** repeatedly peel off nodes with in-degree 0. If the final order is shorter than the node count, a cycle ate the rest. ```knowledge-check { "questions": [ { "id": "dsa-graphs-topo-kahn-q1", "type": "mcq", "prompt": "In Kahn's algorithm, why does a cycle in the graph cause the output order to be shorter than the total node count?", "options": [ {"id": "a", "text": "Every node in the cycle depends on another node also stuck in the cycle, so none of them ever reaches in-degree 0"}, {"id": "b", "text": "Kahn's algorithm crashes on cyclic graphs before finishing"}, {"id": "c", "text": "Cycles cause duplicate nodes to be added to the queue"}, {"id": "d", "text": "The queue becomes empty immediately if any cycle exists"} ], "correct": "a", "explanation": "A node only enters the queue once its in-degree hits 0. Inside a cycle, every node has at least one incoming edge from another cycle member that never gets processed, so their in-degree never drops to 0, and they're never added to the order." } ] } ``` ## The DFS alternative Run DFS from every unvisited node, and when a node's DFS call finishes, meaning every one of its descendants is fully processed, push that node onto a stack. Reverse the stack at the end. ```python def dfs_topo_sort(num_nodes: int, edges: list[tuple[int, int]]) -> list[int]: graph = defaultdict(list) for u, v in edges: graph[u].append(v) visited = set() stack = [] def dfs(node): visited.add(node) for neighbor in graph[node]: if neighbor not in visited: dfs(neighbor) stack.append(node) # postorder: node goes on stack after all descendants for node in range(num_nodes): if node not in visited: dfs(node) return stack[::-1] ``` ```javascript + function dfsTopoSort(numNodes, edges) { const graph = new Map(); for (const [u, v] of edges) { if (!graph.has(u)) graph.set(u, []); graph.get(u).push(v); } const visited = new Set(); const stack = []; function dfs(node) { visited.add(node); for (const neighbor of graph.get(node) || []) { if (!visited.has(neighbor)) dfs(neighbor); } stack.push(node); // postorder: node goes on stack after all descendants } for (let node = 0; node < numNodes; node++) { if (!visited.has(node)) dfs(node); } return stack.reverse(); } ``` ```java + import java.util.*; public class Main { public static void main(String[] args) { int numNodes = 6; int[][] edges = {{5, 2}, {5, 0}, {4, 0}, {4, 1}, {2, 3}, {3, 1}}; System.out.println(dfsTopoSort(numNodes, edges)); } static List dfsTopoSort(int numNodes, int[][] edges) { Map> graph = new HashMap<>(); for (int[] edge : edges) { graph.computeIfAbsent(edge[0], k -> new ArrayList<>()).add(edge[1]); } Set visited = new HashSet<>(); Deque stack = new ArrayDeque<>(); for (int node = 0; node < numNodes; node++) { if (!visited.contains(node)) { dfs(node, graph, visited, stack); } } return new ArrayList<>(stack); // ArrayDeque.push() + iteration gives postorder reversed } static void dfs(int node, Map> graph, Set visited, Deque stack) { visited.add(node); for (int neighbor : graph.getOrDefault(node, Collections.emptyList())) { if (!visited.contains(neighbor)) dfs(neighbor, graph, visited, stack); } stack.push(node); // postorder: node goes on stack after all descendants } } ``` **Why postorder + reverse works:** a node is only pushed after everything it depends on downstream has already been pushed. Reversing puts dependencies before the things that depend on them. This variant needs a separate 3-color cycle check, covered next, because a plain visited set alone can't tell "currently on this DFS path" apart from "already fully processed." **Trade-off:** Kahn's is iterative, so it carries no recursion-depth risk, and it detects cycles for free via the length check. DFS-based is often shorter to write when you already have DFS cycle detection in place, and it fits naturally when the problem is phrased as "process a node only after its dependents," as in course-scheduling frameworks. > **Remember:** DFS-based topo sort pushes a node onto a stack only after all its descendants are done, then reverses. That reversal is the whole trick. ```knowledge-check { "questions": [ { "id": "dsa-graphs-topo-dfs-q1", "type": "mcq", "prompt": "In the DFS-based topological sort, why must the final stack be reversed before returning it as the order?", "options": [ {"id": "a", "text": "A node is pushed only after all its descendants are already pushed, so the stack has dependents before their dependencies until reversed"}, {"id": "b", "text": "Reversing fixes a bug in the DFS traversal itself"}, {"id": "c", "text": "It's an arbitrary style choice with no effect on correctness"}, {"id": "d", "text": "It only matters when the graph has a cycle"} ], "correct": "a", "explanation": "Since a node's descendants finish (and get pushed) before the node itself, the stack builds up with 'later' nodes at the bottom and 'earlier' nodes at the top. Reversing puts dependencies before the things that depend on them, the correct topological order." } ] } ``` ## Detecting a cycle correctly For an **undirected** graph, a plain visited set is enough. If you reach an already-visited neighbor that isn't your immediate parent, that's a cycle. For a **directed** graph, the interview-relevant case (Course Schedule and friends), you need three states, not two, because a node can be "visited" from a completed branch without being part of any cycle: ```python WHITE, GRAY, BLACK = 0, 1, 2 # unvisited, in-progress (on current DFS path), done def has_cycle_directed(num_nodes: int, edges: list[tuple[int, int]]) -> bool: graph = defaultdict(list) for u, v in edges: graph[u].append(v) color = [WHITE] * num_nodes def dfs(node): color[node] = GRAY for neighbor in graph[node]: if color[neighbor] == GRAY: return True # back edge -> cycle if color[neighbor] == WHITE and dfs(neighbor): return True color[node] = BLACK return False return any(color[n] == WHITE and dfs(n) for n in range(num_nodes)) ``` ```javascript + const WHITE = 0, GRAY = 1, BLACK = 2; // unvisited, in-progress (on current DFS path), done function hasCycleDirected(numNodes, edges) { const graph = new Map(); for (const [u, v] of edges) { if (!graph.has(u)) graph.set(u, []); graph.get(u).push(v); } const color = new Array(numNodes).fill(WHITE); function dfs(node) { color[node] = GRAY; for (const neighbor of graph.get(node) || []) { if (color[neighbor] === GRAY) return true; // back edge -> cycle if (color[neighbor] === WHITE && dfs(neighbor)) return true; } color[node] = BLACK; return false; } for (let n = 0; n < numNodes; n++) { if (color[n] === WHITE && dfs(n)) return true; } return false; } ``` ```java + import java.util.*; public class Main { static final int WHITE = 0, GRAY = 1, BLACK = 2; // unvisited, in-progress, done public static void main(String[] args) { int numNodes = 4; int[][] edges = {{0, 1}, {1, 2}, {2, 0}, {2, 3}}; System.out.println(hasCycleDirected(numNodes, edges)); } static boolean hasCycleDirected(int numNodes, int[][] edges) { Map> graph = new HashMap<>(); for (int[] edge : edges) { graph.computeIfAbsent(edge[0], k -> new ArrayList<>()).add(edge[1]); } int[] color = new int[numNodes]; // defaults to WHITE (0) for (int n = 0; n < numNodes; n++) { if (color[n] == WHITE && dfs(n, graph, color)) return true; } return false; } static boolean dfs(int node, Map> graph, int[] color) { color[node] = GRAY; for (int neighbor : graph.getOrDefault(node, Collections.emptyList())) { if (color[neighbor] == GRAY) return true; // back edge -> cycle if (color[neighbor] == WHITE && dfs(neighbor, graph, color)) return true; } color[node] = BLACK; return false; } } ``` **Pitfall:** using a single visited set (two states) on a directed graph gives false positives. Two different branches can both reach the same node without a cycle existing at all, since directed edges don't imply "coming back." The GRAY state, tracking the current recursion path specifically, is what correctly identifies a true back edge. > **Remember:** directed-graph cycle detection needs three states (white/gray/black), not two. GRAY means "on my current path right now," which is the only thing a true cycle can hit. ```knowledge-check { "questions": [ { "id": "dsa-graphs-topo-cycle-detect-q1", "type": "mcq", "prompt": "Why does a plain 2-state visited set give false positives for cycle detection on a directed graph?", "options": [ {"id": "a", "text": "Two separate branches can both legitimately reach the same node without any cycle existing, since directed edges don't imply coming back"}, {"id": "b", "text": "A 2-state set only works on trees, never on graphs"}, {"id": "c", "text": "It's actually fine; 3 states are only needed for undirected graphs"}, {"id": "d", "text": "2-state visited sets can't be implemented with DFS"} ], "correct": "a", "explanation": "A node reached from two unrelated branches would look 'already visited' under a 2-state scheme even with no cycle. The 3rd state (GRAY, meaning 'on the current DFS path') distinguishes that harmless case from a true back edge, which only happens when you re-reach a node still on your own current path." } ] } ``` ## Course Schedule [LeetCode 207](https://leetcode.com/problems/course-schedule/), Topological sort, Detect cycle "Can you finish all courses?" is exactly "is this prerequisite graph a DAG?" Build the graph, run Kahn's algorithm, and check whether every course got processed. **Approach:** Build the adjacency list and in-degree array from the prerequisites, then run Kahn's algorithm; compare the processed count to `numCourses`. ```python def canFinish(numCourses: int, prerequisites: list[list[int]]) -> bool: graph = defaultdict(list) in_degree = [0] * numCourses for course, prereq in prerequisites: graph[prereq].append(course) in_degree[course] += 1 queue = deque(c for c in range(numCourses) if in_degree[c] == 0) processed = 0 while queue: node = queue.popleft() processed += 1 for neighbor in graph[node]: in_degree[neighbor] -= 1 if in_degree[neighbor] == 0: queue.append(neighbor) return processed == numCourses ``` ```javascript + function canFinish(numCourses, prerequisites) { const graph = new Map(); const inDegree = new Array(numCourses).fill(0); for (const [course, prereq] of prerequisites) { if (!graph.has(prereq)) graph.set(prereq, []); graph.get(prereq).push(course); inDegree[course] += 1; } const queue = []; for (let c = 0; c < numCourses; c++) { if (inDegree[c] === 0) queue.push(c); } let processed = 0; while (queue.length > 0) { const node = queue.shift(); processed += 1; for (const neighbor of graph.get(node) || []) { inDegree[neighbor] -= 1; if (inDegree[neighbor] === 0) queue.push(neighbor); } } return processed === numCourses; } ``` ```java + import java.util.*; public class Main { public static void main(String[] args) { int numCourses = 2; int[][] prerequisites = {{1, 0}}; System.out.println(canFinish(numCourses, prerequisites)); } static boolean canFinish(int numCourses, int[][] prerequisites) { Map> graph = new HashMap<>(); int[] inDegree = new int[numCourses]; for (int[] p : prerequisites) { int course = p[0], prereq = p[1]; graph.computeIfAbsent(prereq, k -> new ArrayList<>()).add(course); inDegree[course]++; } Deque queue = new ArrayDeque<>(); for (int c = 0; c < numCourses; c++) { if (inDegree[c] == 0) queue.add(c); } int processed = 0; while (!queue.isEmpty()) { int node = queue.poll(); processed++; for (int neighbor : graph.getOrDefault(node, Collections.emptyList())) { inDegree[neighbor]--; if (inDegree[neighbor] == 0) queue.add(neighbor); } } return processed == numCourses; } } ``` **Complexity:** Time O(V + E), space O(V + E). **Common mistakes:** Flipping the edge direction; it runs prereq to course, not course to prereq. Forgetting that courses with zero prerequisites and zero dependents still count toward `processed`. > **Remember:** this is topological sort wearing a boolean costume. Just check whether Kahn's algorithm processed every course. ```knowledge-check { "questions": [ { "id": "dsa-graphs-topo-course-schedule-q1", "type": "mcq", "prompt": "In Course Schedule, what does it mean if the number of courses processed by Kahn's algorithm is less than numCourses?", "options": [ {"id": "a", "text": "There is a cycle in the prerequisite graph, so not all courses can be completed"}, {"id": "b", "text": "The input contains a course with no prerequisites"}, {"id": "c", "text": "The graph has more edges than nodes"}, {"id": "d", "text": "It always means the input was malformed"} ], "correct": "a", "explanation": "Courses stuck in a prerequisite cycle never reach in-degree 0, so Kahn's algorithm never processes them. A processed count below numCourses is exactly the signal that a cycle exists somewhere in the prerequisites." } ] } ``` ## Course Schedule II [LeetCode 210](https://leetcode.com/problems/course-schedule-ii/), Topological sort, Return order Identical to Course Schedule I, but instead of a true/false answer, you return the actual valid order (or an empty list if it's impossible). **Approach:** Reuse Kahn's algorithm verbatim, but collect the order instead of only counting it. ```python def findOrder(numCourses: int, prerequisites: list[list[int]]) -> list[int]: graph = defaultdict(list) in_degree = [0] * numCourses for course, prereq in prerequisites: graph[prereq].append(course) in_degree[course] += 1 queue = deque(c for c in range(numCourses) if in_degree[c] == 0) order = [] while queue: node = queue.popleft() order.append(node) for neighbor in graph[node]: in_degree[neighbor] -= 1 if in_degree[neighbor] == 0: queue.append(neighbor) return order if len(order) == numCourses else [] ``` ```javascript + function findOrder(numCourses, prerequisites) { const graph = new Map(); const inDegree = new Array(numCourses).fill(0); for (const [course, prereq] of prerequisites) { if (!graph.has(prereq)) graph.set(prereq, []); graph.get(prereq).push(course); inDegree[course] += 1; } const queue = []; for (let c = 0; c < numCourses; c++) { if (inDegree[c] === 0) queue.push(c); } const order = []; while (queue.length > 0) { const node = queue.shift(); order.push(node); for (const neighbor of graph.get(node) || []) { inDegree[neighbor] -= 1; if (inDegree[neighbor] === 0) queue.push(neighbor); } } return order.length === numCourses ? order : []; } ``` ```java + import java.util.*; public class Main { public static void main(String[] args) { int numCourses = 4; int[][] prerequisites = {{1, 0}, {2, 0}, {3, 1}, {3, 2}}; System.out.println(findOrder(numCourses, prerequisites)); } static List findOrder(int numCourses, int[][] prerequisites) { Map> graph = new HashMap<>(); int[] inDegree = new int[numCourses]; for (int[] p : prerequisites) { int course = p[0], prereq = p[1]; graph.computeIfAbsent(prereq, k -> new ArrayList<>()).add(course); inDegree[course]++; } Deque queue = new ArrayDeque<>(); for (int c = 0; c < numCourses; c++) { if (inDegree[c] == 0) queue.add(c); } List order = new ArrayList<>(); while (!queue.isEmpty()) { int node = queue.poll(); order.add(node); for (int neighbor : graph.getOrDefault(node, Collections.emptyList())) { inDegree[neighbor]--; if (inDegree[neighbor] == 0) queue.add(neighbor); } } return order.size() == numCourses ? order : new ArrayList<>(); } } ``` **Complexity:** Time O(V + E), space O(V + E). **Common mistakes:** Returning a partial order instead of an empty list when a cycle exists. Always check the length before returning. > **Remember:** same algorithm as Course Schedule I, just return the collected order instead of a boolean. ```knowledge-check { "questions": [ { "id": "dsa-graphs-topo-course-schedule-ii-q1", "type": "mcq", "prompt": "In Course Schedule II, what should findOrder return if a cycle makes it impossible to complete all courses?", "options": [ {"id": "a", "text": "An empty list, not the partial order that was collected before the cycle blocked further progress"}, {"id": "b", "text": "The partial order collected so far"}, {"id": "c", "text": "A list containing only the courses involved in the cycle"}, {"id": "d", "text": "The value -1"} ], "correct": "a", "explanation": "A partial order isn't a valid answer since it doesn't cover every course. The problem expects an empty list specifically when the full ordering is impossible, which the length check against numCourses catches." } ] } ``` ## Alien Dictionary [LeetCode 269](https://leetcode.com/problems/alien-dictionary/), Topological sort, Hard You're given a list of words already sorted according to some unknown alien alphabet. Comparing adjacent words reveals relative character ordering: the first character where two consecutive words differ tells you "this letter comes before that letter." Build a graph of those constraints and topologically sort the alphabet's letters. **Approach:** For each pair of adjacent words, find the first index where the characters differ; that gives one directed edge `word1[i] -> word2[i]`. Special case: if `word1` is longer than `word2` but `word2` is exactly its prefix, such as `"abc"` before `"ab"`, the order is invalid and you return `""`. Then run Kahn's algorithm over the 26 letters. ```python def alienOrder(words: list[str]) -> str: graph = defaultdict(set) in_degree = {c: 0 for word in words for c in word} for w1, w2 in zip(words, words[1:]): min_len = min(len(w1), len(w2)) if len(w1) > len(w2) and w1[:min_len] == w2[:min_len]: return "" # invalid: longer word can't be a prefix of the next for c1, c2 in zip(w1, w2): if c1 != c2: if c2 not in graph[c1]: graph[c1].add(c2) in_degree[c2] += 1 break # only the first differing pair gives a constraint queue = deque(c for c in in_degree if in_degree[c] == 0) order = [] while queue: c = queue.popleft() order.append(c) for neighbor in graph[c]: in_degree[neighbor] -= 1 if in_degree[neighbor] == 0: queue.append(neighbor) return "".join(order) if len(order) == len(in_degree) else "" ``` ```javascript + function alienOrder(words) { const graph = new Map(); const inDegree = new Map(); for (const word of words) { for (const c of word) { if (!inDegree.has(c)) inDegree.set(c, 0); } } for (let i = 0; i < words.length - 1; i++) { const w1 = words[i], w2 = words[i + 1]; const minLen = Math.min(w1.length, w2.length); if (w1.length > w2.length && w1.slice(0, minLen) === w2.slice(0, minLen)) { return ""; // invalid: longer word can't be a prefix of the next } for (let j = 0; j < minLen; j++) { const c1 = w1[j], c2 = w2[j]; if (c1 !== c2) { if (!graph.has(c1)) graph.set(c1, new Set()); if (!graph.get(c1).has(c2)) { graph.get(c1).add(c2); inDegree.set(c2, inDegree.get(c2) + 1); } break; // only the first differing pair gives a constraint } } } const queue = [...inDegree.keys()].filter((c) => inDegree.get(c) === 0); const order = []; while (queue.length > 0) { const c = queue.shift(); order.push(c); for (const neighbor of graph.get(c) || []) { inDegree.set(neighbor, inDegree.get(neighbor) - 1); if (inDegree.get(neighbor) === 0) queue.push(neighbor); } } return order.length === inDegree.size ? order.join("") : ""; } ``` ```java + import java.util.*; public class Main { public static void main(String[] args) { String[] words = {"wrt", "wrf", "er", "ett", "rftt"}; System.out.println(alienOrder(words)); } static String alienOrder(String[] words) { Map> graph = new HashMap<>(); Map inDegree = new HashMap<>(); for (String word : words) { for (char c : word.toCharArray()) { inDegree.putIfAbsent(c, 0); } } for (int i = 0; i < words.length - 1; i++) { String w1 = words[i], w2 = words[i + 1]; int minLen = Math.min(w1.length(), w2.length()); if (w1.length() > w2.length() && w1.substring(0, minLen).equals(w2.substring(0, minLen))) { return ""; // invalid: longer word can't be a prefix of the next } for (int j = 0; j < minLen; j++) { char c1 = w1.charAt(j), c2 = w2.charAt(j); if (c1 != c2) { Set neighbors = graph.computeIfAbsent(c1, k -> new HashSet<>()); if (!neighbors.contains(c2)) { neighbors.add(c2); inDegree.put(c2, inDegree.get(c2) + 1); } break; // only the first differing pair gives a constraint } } } Deque queue = new ArrayDeque<>(); for (Map.Entry entry : inDegree.entrySet()) { if (entry.getValue() == 0) queue.add(entry.getKey()); } StringBuilder order = new StringBuilder(); while (!queue.isEmpty()) { char c = queue.poll(); order.append(c); for (char neighbor : graph.getOrDefault(c, Collections.emptySet())) { inDegree.put(neighbor, inDegree.get(neighbor) - 1); if (inDegree.get(neighbor) == 0) queue.add(neighbor); } } return order.length() == inDegree.size() ? order.toString() : ""; } } ``` **Complexity:** Time O(C), where C is the total character count across all words: each adjacent-pair comparison is bounded by word length, and the topological sort itself is O(26) for nodes and edges. Space is O(1) in practice, since there are at most 26 letters. **Common mistakes:** Not handling the "prefix but longer" invalid case. Adding duplicate edges when the same letter pair appears across multiple word comparisons; the "already in graph" guard prevents inflating in-degree counts. Continuing the inner loop past the first differing character, since later differences carry no information once the first one is found. > **Remember:** compare only adjacent words, take only the FIRST differing character per pair, and watch for the "longer word is a prefix of the shorter one" invalid case. ```knowledge-check { "questions": [ { "id": "dsa-graphs-topo-alien-dictionary-q1", "type": "mcq", "prompt": "In Alien Dictionary, why do you stop at the FIRST differing character between two adjacent words instead of comparing every differing pair?", "options": [ {"id": "a", "text": "Only the first difference gives a valid ordering constraint; any later differences are meaningless once the words have already diverged"}, {"id": "b", "text": "Comparing more than one pair would make the algorithm too slow"}, {"id": "c", "text": "Later characters are guaranteed to be equal anyway"}, {"id": "d", "text": "It doesn't matter; comparing all differing pairs gives the same result"} ], "correct": "a", "explanation": "Once two words diverge at some character, that single difference already tells you the ordering constraint between those two letters. Any characters after that point say nothing reliable about the whole alphabet's order, since the words have already been distinguished." } ] } ``` ## Longest Increasing Path in a Matrix [LeetCode 329](https://leetcode.com/problems/longest-increasing-path-in-a-matrix/), DFS + Memoization Treat each cell as a graph node with a directed edge to any 4-directional neighbor holding a strictly greater value. Since values strictly increase along any path, this graph is automatically acyclic, no separate cycle check needed. Find the longest path in this implicit DAG with DFS plus memoization; it's topological-DAG-style DP even though you never build an explicit adjacency list. **Approach:** DFS from each cell, caching "longest increasing path starting here" so overlapping subproblems are never recomputed. ```python def longestIncreasingPath(matrix: list[list[int]]) -> int: if not matrix: return 0 rows, cols = len(matrix), len(matrix[0]) memo = {} def dfs(r, c): if (r, c) in memo: return memo[(r, c)] best = 1 for dr, dc in ((1, 0), (-1, 0), (0, 1), (0, -1)): nr, nc = r + dr, c + dc if 0 <= nr < rows and 0 <= nc < cols and matrix[nr][nc] > matrix[r][c]: best = max(best, 1 + dfs(nr, nc)) memo[(r, c)] = best return best return max(dfs(r, c) for r in range(rows) for c in range(cols)) ``` ```javascript + function longestIncreasingPath(matrix) { if (!matrix || matrix.length === 0) return 0; const rows = matrix.length, cols = matrix[0].length; const memo = new Map(); const directions = [[1, 0], [-1, 0], [0, 1], [0, -1]]; function dfs(r, c) { const key = `${r},${c}`; if (memo.has(key)) return memo.get(key); let best = 1; for (const [dr, dc] of directions) { const nr = r + dr, nc = c + dc; if (nr >= 0 && nr < rows && nc >= 0 && nc < cols && matrix[nr][nc] > matrix[r][c]) { best = Math.max(best, 1 + dfs(nr, nc)); } } memo.set(key, best); return best; } let result = 0; for (let r = 0; r < rows; r++) { for (let c = 0; c < cols; c++) { result = Math.max(result, dfs(r, c)); } } return result; } ``` ```java + public class Main { static int rows, cols; static int[][] memo; static int[][] grid; static final int[][] DIRECTIONS = {{1, 0}, {-1, 0}, {0, 1}, {0, -1}}; public static void main(String[] args) { int[][] matrix = {{9, 9, 4}, {6, 6, 8}, {2, 1, 1}}; System.out.println(longestIncreasingPath(matrix)); } static int longestIncreasingPath(int[][] matrix) { if (matrix == null || matrix.length == 0) return 0; grid = matrix; rows = matrix.length; cols = matrix[0].length; memo = new int[rows][cols]; int result = 0; for (int r = 0; r < rows; r++) { for (int c = 0; c < cols; c++) { result = Math.max(result, dfs(r, c)); } } return result; } static int dfs(int r, int c) { if (memo[r][c] != 0) return memo[r][c]; int best = 1; for (int[] d : DIRECTIONS) { int nr = r + d[0], nc = c + d[1]; if (nr >= 0 && nr < rows && nc >= 0 && nc < cols && grid[nr][nc] > grid[r][c]) { best = Math.max(best, 1 + dfs(nr, nc)); } } memo[r][c] = best; return best; } } ``` **Complexity:** Time O(rows × cols), since memoization computes each cell's answer exactly once. Space O(rows × cols) for the memo and recursion stack. **Common mistakes:** Trying to solve this with a visited set instead of memoization. A visited set assumes you never revisit a cell in any path, but here you legitimately want to revisit cells from different starting points. "Longest path starting at (r, c)," cached, is the correct DP framing. > **Remember:** strictly increasing values make the implicit graph automatically acyclic. Cache "best path starting here" instead of using a visited set. ```knowledge-check { "questions": [ { "id": "dsa-graphs-topo-lip-q1", "type": "mcq", "prompt": "Why is a plain visited set the wrong tool for Longest Increasing Path in a Matrix, even though it's a graph traversal problem?", "options": [ {"id": "a", "text": "You legitimately need to revisit the same cell from different starting points, which a visited set would incorrectly block"}, {"id": "b", "text": "Visited sets only work on undirected graphs"}, {"id": "c", "text": "The matrix might contain negative numbers"}, {"id": "d", "text": "A visited set would make the algorithm run faster than necessary"} ], "correct": "a", "explanation": "Each cell's longest increasing path is computed independently for every starting cell that can reach it. A visited set, once a cell is marked, would wrongly prevent it from being explored again as part of a different starting path. Memoization caches the per-cell answer instead, which is safe to reuse across different starts." } ] } ``` 3b:T7d84,Picture a party where you keep introducing people. Every time you introduce two strangers, their two friend circles merge into one. At any moment, you might ask "are these two people in the same friend circle now?" Union-Find (Disjoint Set Union, or DSU) answers exactly that question, and merges groups, both in near-constant time. It replaces slower BFS/DFS connectivity checks, and it's the difference between a working solution and a timeout on problems where connections arrive one at a time, like Number of Islands II. ## Find: walking up to the group's leader, with a shortcut `find(x)` walks up parent pointers from `x` until it reaches the root of `x`'s tree, a node that is its own parent. That root acts as the "name" of the whole group. Without any optimization, this walk can take O(n) steps on a long, chain-like tree. Path compression fixes that: while walking up to find the root, rewire every node you pass through to point directly at the root. The next `find` call through any of those nodes is then instant. ```python def find(self, x: int) -> int: if self.parent[x] != x: self.parent[x] = self.find(self.parent[x]) # path compression return self.parent[x] ``` ```javascript + function find(x) { if (this.parent[x] !== x) { this.parent[x] = find.call(this, this.parent[x]); // path compression } return this.parent[x]; } ``` ```java + public class Main { public static void main(String[] args) { DSU dsu = new DSU(new int[]{0, 0, 1, 3}); System.out.println(dsu.find(3)); } } class DSU { int[] parent; DSU(int[] parent) { this.parent = parent; } int find(int x) { if (parent[x] != x) { parent[x] = find(parent[x]); // path compression } return parent[x]; } } ``` This looks like a simple recursive one-liner, but it does real work: the recursive call returns the root, and the assignment flattens `x`'s pointer to point straight at that root, permanently shortening the path for every future call that passes through `x`. > **Remember:** find() walks up to the root. Path compression rewires every node it passes through to point directly at that root, so the next lookup is instant. ```knowledge-check { "questions": [ { "id": "dsa-union-find-find-q1", "type": "mcq", "prompt": "What does path compression actually do inside find(x)?", "options": [ {"id": "a", "text": "It rewires every node visited on the way up so it points directly at the root, speeding up future lookups"}, {"id": "b", "text": "It deletes nodes that are no longer needed"}, {"id": "c", "text": "It sorts the parent array"}, {"id": "d", "text": "It merges two separate groups into one"} ], "correct": "a", "explanation": "As find() recurses up to the root and returns, the assignment `self.parent[x] = self.find(...)` overwrites x's parent pointer with the root directly, flattening the path for x and every node the recursion passed through." } ] } ``` ## Union by rank: keep the merged tree shallow `union(x, y)` merges the two groups containing `x` and `y` by attaching one tree's root under the other's. Attaching them arbitrarily can, over many merges, build a tall, unbalanced tree. Union by rank (or by size) always attaches the shorter tree under the taller one's root, keeping the whole structure shallow. ```python def union(self, x: int, y: int) -> None: root_x, root_y = self.find(x), self.find(y) if root_x == root_y: return # already connected if self.rank[root_x] < self.rank[root_y]: root_x, root_y = root_y, root_x self.parent[root_y] = root_x if self.rank[root_x] == self.rank[root_y]: self.rank[root_x] += 1 ``` ```javascript + function union(x, y) { let rootX = find.call(this, x); let rootY = find.call(this, y); if (rootX === rootY) { return; // already connected } if (this.rank[rootX] < this.rank[rootY]) { [rootX, rootY] = [rootY, rootX]; } this.parent[rootY] = rootX; if (this.rank[rootX] === this.rank[rootY]) { this.rank[rootX]++; } } ``` ```java + public class Main { public static void main(String[] args) { DSU dsu = new DSU(4); dsu.union(0, 1); dsu.union(2, 3); System.out.println(dsu.find(1) == dsu.find(0)); } } class DSU { int[] parent; int[] rank; DSU(int n) { parent = new int[n]; rank = new int[n]; for (int i = 0; i < n; i++) parent[i] = i; } int find(int x) { if (parent[x] != x) { parent[x] = find(parent[x]); } return parent[x]; } void union(int x, int y) { int rootX = find(x); int rootY = find(y); if (rootX == rootY) { return; // already connected } if (rank[rootX] < rank[rootY]) { int tmp = rootX; rootX = rootY; rootY = tmp; } parent[rootY] = rootX; if (rank[rootX] == rank[rootY]) { rank[rootX]++; } } } ``` Combined, path compression and union by rank give an amortized time of O(α(n)) per operation, where α is the inverse Ackermann function. For any `n` you could realistically encounter, α(n) is at most 4, which is why this is described as "nearly O(1)." > **Remember:** always attach the shorter tree under the taller one's root. Combined with path compression, this makes every operation nearly O(1). ```knowledge-check { "questions": [ { "id": "dsa-union-find-union-rank-q1", "type": "mcq", "prompt": "Why does union by rank attach the shorter tree under the taller tree's root, rather than the other way around?", "options": [ {"id": "a", "text": "It keeps the overall tree shallow, since the taller tree's height doesn't grow when a shorter tree is added underneath it"}, {"id": "b", "text": "It's required to make find() return the correct root"}, {"id": "c", "text": "It reduces memory usage"}, {"id": "d", "text": "It has no real effect; the choice is arbitrary"} ], "correct": "a", "explanation": "If you always attach a shorter tree under a taller one, the taller tree's height stays the same. Attaching the taller tree under the shorter one instead would increase the overall height, degrading future find() calls." } ] } ``` ## Using union-find to catch a cycle as you build a graph DSU gives a clean way to detect a cycle while building a graph one edge at a time: before adding an edge `(u, v)`, check whether `find(u) == find(v)`. If they're already in the same group, this edge would create a cycle, so either skip it, or, if you add it anyway, you've just confirmed a cycle exists. This is exactly how Kruskal's minimum-spanning-tree algorithm decides which edges to keep, and it's the core trick behind Graph Valid Tree below. ```python def has_cycle_on_add(self, u: int, v: int) -> bool: if self.find(u) == self.find(v): return True # adding this edge would close a cycle self.union(u, v) return False ``` ```javascript + function hasCycleOnAdd(u, v) { if (find.call(this, u) === find.call(this, v)) { return true; // adding this edge would close a cycle } union.call(this, u, v); return false; } ``` ```java + public class Main { public static void main(String[] args) { DSU dsu = new DSU(4); System.out.println(dsu.hasCycleOnAdd(0, 1)); System.out.println(dsu.hasCycleOnAdd(1, 0)); } } class DSU { int[] parent; int[] rank; DSU(int n) { parent = new int[n]; rank = new int[n]; for (int i = 0; i < n; i++) parent[i] = i; } int find(int x) { if (parent[x] != x) { parent[x] = find(parent[x]); } return parent[x]; } void union(int x, int y) { int rootX = find(x); int rootY = find(y); if (rootX == rootY) return; if (rank[rootX] < rank[rootY]) { int tmp = rootX; rootX = rootY; rootY = tmp; } parent[rootY] = rootX; if (rank[rootX] == rank[rootY]) { rank[rootX]++; } } boolean hasCycleOnAdd(int u, int v) { if (find(u) == find(v)) { return true; // adding this edge would close a cycle } union(u, v); return false; } } ``` > **Remember:** if find(u) equals find(v) before you union them, adding that edge would close a cycle. ```knowledge-check { "questions": [ { "id": "dsa-union-find-cycle-q1", "type": "mcq", "prompt": "How does union-find detect that adding an edge (u, v) would create a cycle?", "options": [ {"id": "a", "text": "If find(u) already equals find(v), both nodes are already in the same group, so the new edge would close a loop"}, {"id": "b", "text": "It counts the total number of edges added so far"}, {"id": "c", "text": "It runs a full BFS after every edge to check for cycles"}, {"id": "d", "text": "It checks whether u and v have the same rank"} ], "correct": "a", "explanation": "Two nodes already sharing the same root means a path already connects them. Adding a direct edge between two already-connected nodes creates a second path between them, which is exactly what a cycle is." } ] } ``` ## Number of Connected Components in an Undirected Graph [LeetCode 323 · Number of Connected Components](https://leetcode.com/problems/number-of-connected-components-in-an-undirected-graph/) · DSU Start with `n` components, since every node begins isolated. Each edge that connects two *different* components reduces the component count by exactly one; an edge between two nodes already in the same component changes nothing. **Approach:** Initialize DSU with `n` singleton sets. Union across every edge; decrement a running count directly whenever a union actually merges two different roots. ```python class DSU: def __init__(self, n: int) -> None: self.parent = list(range(n)) self.rank = [0] * n self.count = n # number of distinct components def find(self, x: int) -> int: if self.parent[x] != x: self.parent[x] = self.find(self.parent[x]) return self.parent[x] def union(self, x: int, y: int) -> None: root_x, root_y = self.find(x), self.find(y) if root_x == root_y: return if self.rank[root_x] < self.rank[root_y]: root_x, root_y = root_y, root_x self.parent[root_y] = root_x if self.rank[root_x] == self.rank[root_y]: self.rank[root_x] += 1 self.count -= 1 def count_components(n: int, edges: list[list[int]]) -> int: dsu = DSU(n) for u, v in edges: dsu.union(u, v) return dsu.count ``` ```javascript + class DSU { constructor(n) { this.parent = Array.from({ length: n }, (_, i) => i); this.rank = new Array(n).fill(0); this.count = n; // number of distinct components } find(x) { if (this.parent[x] !== x) { this.parent[x] = this.find(this.parent[x]); } return this.parent[x]; } union(x, y) { let rootX = this.find(x); let rootY = this.find(y); if (rootX === rootY) return; if (this.rank[rootX] < this.rank[rootY]) { [rootX, rootY] = [rootY, rootX]; } this.parent[rootY] = rootX; if (this.rank[rootX] === this.rank[rootY]) { this.rank[rootX]++; } this.count--; } } function countComponents(n, edges) { const dsu = new DSU(n); for (const [u, v] of edges) { dsu.union(u, v); } return dsu.count; } ``` ```java + public class Main { public static void main(String[] args) { int[][] edges = {{0, 1}, {1, 2}, {3, 4}}; System.out.println(countComponents(5, edges)); } static int countComponents(int n, int[][] edges) { DSU dsu = new DSU(n); for (int[] edge : edges) { dsu.union(edge[0], edge[1]); } return dsu.count; } } class DSU { int[] parent; int[] rank; int count; DSU(int n) { parent = new int[n]; rank = new int[n]; for (int i = 0; i < n; i++) parent[i] = i; count = n; // number of distinct components } int find(int x) { if (parent[x] != x) { parent[x] = find(parent[x]); } return parent[x]; } void union(int x, int y) { int rootX = find(x); int rootY = find(y); if (rootX == rootY) return; if (rank[rootX] < rank[rootY]) { int tmp = rootX; rootX = rootY; rootY = tmp; } parent[rootY] = rootX; if (rank[rootX] == rank[rootY]) { rank[rootX]++; } count--; } } ``` **Complexity:** O(n + E · α(n)) time, O(n) space. This `DSU` class is the reusable template for all four problems in this lesson. **Common mistakes:** Recomputing the component count with a separate pass calling `find(i)` on every node, instead of tracking it incrementally inside `union`. Forgetting path compression, which degrades `find` to O(n) on adversarial inputs, such as a chain graph. > **Remember:** start every node as its own component, then decrement the count by exactly one on every union that actually merges two different roots. ```knowledge-check { "questions": [ { "id": "dsa-union-find-connected-components-q1", "type": "mcq", "prompt": "Why does the component count only decrease when union merges two DIFFERENT roots, not on every union call?", "options": [ {"id": "a", "text": "If both nodes already share a root, they're already counted as one component, so merging them again changes nothing"}, {"id": "b", "text": "The count should decrease on every union call regardless"}, {"id": "c", "text": "It only matters when rank is equal between the two roots"}, {"id": "d", "text": "Because union always fails when roots are equal"} ], "correct": "a", "explanation": "An edge between two nodes already in the same component doesn't reduce the number of distinct components, since they were never counted separately in the first place. Only a union that bridges two previously separate groups actually reduces the count by one." } ] } ``` ## Longest Consecutive Sequence [LeetCode 128 · Longest Consecutive Sequence](https://leetcode.com/problems/longest-consecutive-sequence/) · DSU Values that are consecutive integers (`x` and `x+1`) belong in the same "run." Union every value with `value + 1` whenever that neighbor is present in the array; the answer is then the size of the largest resulting component. (A hash-set expand-from-start approach is O(n) and usually the preferred interview answer, but DSU is worth knowing since it's this lesson's topic, and the same "union adjacent related values" idea shows up elsewhere.) **Approach:** Map each value to an index. Union `value` with `value + 1` whenever both are present. Track component sizes in the DSU so "largest run" is a direct lookup. ```python def longest_consecutive(nums: list[int]) -> int: if not nums: return 0 unique_nums = list(set(nums)) index_of = {num: i for i, num in enumerate(unique_nums)} n = len(unique_nums) parent = list(range(n)) size = [1] * n def find(x: int) -> int: if parent[x] != x: parent[x] = find(parent[x]) return parent[x] def union(x: int, y: int) -> None: rx, ry = find(x), find(y) if rx == ry: return if size[rx] < size[ry]: rx, ry = ry, rx parent[ry] = rx size[rx] += size[ry] for num in unique_nums: if num + 1 in index_of: union(index_of[num], index_of[num + 1]) return max(size[find(i)] for i in range(n)) ``` ```javascript + function longestConsecutive(nums) { if (nums.length === 0) return 0; const uniqueNums = Array.from(new Set(nums)); const indexOf = new Map(uniqueNums.map((num, i) => [num, i])); const n = uniqueNums.length; const parent = Array.from({ length: n }, (_, i) => i); const size = new Array(n).fill(1); function find(x) { if (parent[x] !== x) { parent[x] = find(parent[x]); } return parent[x]; } function union(x, y) { let rx = find(x); let ry = find(y); if (rx === ry) return; if (size[rx] < size[ry]) { [rx, ry] = [ry, rx]; } parent[ry] = rx; size[rx] += size[ry]; } for (const num of uniqueNums) { if (indexOf.has(num + 1)) { union(indexOf.get(num), indexOf.get(num + 1)); } } let longest = 0; for (let i = 0; i < n; i++) { longest = Math.max(longest, size[find(i)]); } return longest; } ``` ```java + import java.util.HashMap; import java.util.HashSet; import java.util.Map; import java.util.Set; public class Main { public static void main(String[] args) { int[] nums = {100, 4, 200, 1, 3, 2}; System.out.println(longestConsecutive(nums)); } static int longestConsecutive(int[] nums) { if (nums.length == 0) return 0; Set uniqueSet = new HashSet<>(); for (int num : nums) uniqueSet.add(num); Integer[] uniqueNums = uniqueSet.toArray(new Integer[0]); int n = uniqueNums.length; Map indexOf = new HashMap<>(); for (int i = 0; i < n; i++) indexOf.put(uniqueNums[i], i); int[] parent = new int[n]; int[] size = new int[n]; for (int i = 0; i < n; i++) { parent[i] = i; size[i] = 1; } for (int num : uniqueNums) { if (indexOf.containsKey(num + 1)) { union(parent, size, indexOf.get(num), indexOf.get(num + 1)); } } int longest = 0; for (int i = 0; i < n; i++) { longest = Math.max(longest, size[find(parent, i)]); } return longest; } static int find(int[] parent, int x) { if (parent[x] != x) { parent[x] = find(parent, parent[x]); } return parent[x]; } static void union(int[] parent, int[] size, int x, int y) { int rx = find(parent, x); int ry = find(parent, y); if (rx == ry) return; if (size[rx] < size[ry]) { int tmp = rx; rx = ry; ry = tmp; } parent[ry] = rx; size[rx] += size[ry]; } } ``` **Complexity:** O(n · α(n)) time, O(n) space. The pure hash-set approach (expand upward only from numbers that have no `num - 1` predecessor) reaches plain O(n) without any DSU overhead. Mention both, and lead with whichever fits the interviewer's follow-up. **Common mistakes:** Unioning by raw value instead of by index, since the DSU arrays are indexed 0..n-1, not by arbitrary integer value. Forgetting to dedupe the input first, which wastes work reprocessing duplicate values. > **Remember:** union each value with value+1 when both exist; the biggest resulting group size is the longest consecutive run. ```knowledge-check { "questions": [ { "id": "dsa-union-find-consecutive-sequence-q1", "type": "mcq", "prompt": "In the DSU solution to Longest Consecutive Sequence, what determines whether two values get unioned?", "options": [ {"id": "a", "text": "Whether both value and value + 1 are present in the input array"}, {"id": "b", "text": "Whether the two values are equal"}, {"id": "c", "text": "Whether both values are even"}, {"id": "d", "text": "The order the values appear in the original array"} ], "correct": "a", "explanation": "The whole approach models 'being in the same consecutive run' as being in the same DSU group. That only happens correctly if you union a value with its immediate successor whenever both exist in the set." } ] } ``` ## Graph Valid Tree [LeetCode 261 · Graph Valid Tree](https://leetcode.com/problems/graph-valid-tree/) · DSU A graph with `n` nodes is a valid tree only if it has exactly `n - 1` edges AND is fully connected, meaning no cycles and no separate pieces. DSU checks both conditions in one pass: if any edge connects two nodes already in the same component, that's a cycle, and the graph is immediately invalid. **Approach:** A quick edge-count check first (`len(edges) != n - 1` fails immediately, saving wasted DSU work). Then union each edge, failing fast the moment a cycle is detected. ```python def valid_tree(n: int, edges: list[list[int]]) -> bool: if len(edges) != n - 1: return False # too many edges (cycle) or too few (disconnected) parent = list(range(n)) def find(x: int) -> int: if parent[x] != x: parent[x] = find(parent[x]) return parent[x] for u, v in edges: root_u, root_v = find(u), find(v) if root_u == root_v: return False # cycle detected parent[root_v] = root_u return True ``` ```javascript + function validTree(n, edges) { if (edges.length !== n - 1) { return false; // too many edges (cycle) or too few (disconnected) } const parent = Array.from({ length: n }, (_, i) => i); function find(x) { if (parent[x] !== x) { parent[x] = find(parent[x]); } return parent[x]; } for (const [u, v] of edges) { const rootU = find(u); const rootV = find(v); if (rootU === rootV) { return false; // cycle detected } parent[rootV] = rootU; } return true; } ``` ```java + public class Main { public static void main(String[] args) { int[][] edges = {{0, 1}, {0, 2}, {0, 3}, {1, 4}}; System.out.println(validTree(5, edges)); } static boolean validTree(int n, int[][] edges) { if (edges.length != n - 1) { return false; // too many edges (cycle) or too few (disconnected) } int[] parent = new int[n]; for (int i = 0; i < n; i++) parent[i] = i; for (int[] edge : edges) { int rootU = find(parent, edge[0]); int rootV = find(parent, edge[1]); if (rootU == rootV) { return false; // cycle detected } parent[rootV] = rootU; } return true; } static int find(int[] parent, int x) { if (parent[x] != x) { parent[x] = find(parent, parent[x]); } return parent[x]; } } ``` **Complexity:** O(n · α(n)) time, O(n) space. **Common mistakes:** Skipping the `len(edges) != n - 1` pre-check and relying purely on cycle detection: a graph can be cycle-free but still disconnected (a forest of separate trees), and the edge-count check is what rules that out cheaply. Forgetting that a valid tree also requires full connectivity, not just the absence of cycles. > **Remember:** a valid tree needs exactly n-1 edges AND no cycle. The edge count alone doesn't guarantee connectivity, and no-cycle alone doesn't either; you need both checks. ```knowledge-check { "questions": [ { "id": "dsa-union-find-valid-tree-q1", "type": "mcq", "prompt": "Why isn't checking 'no cycle exists' alone enough to confirm a graph is a valid tree?", "options": [ {"id": "a", "text": "A graph can be acyclic but still disconnected, forming a forest of separate trees instead of one tree"}, {"id": "b", "text": "Cycle detection is unreliable in undirected graphs"}, {"id": "c", "text": "A tree is defined only by its edge count, not by cycles at all"}, {"id": "d", "text": "It actually is enough; the edge-count check is unnecessary"} ], "correct": "a", "explanation": "Two separate acyclic pieces (a forest) have no cycle anywhere, but they aren't one connected tree. The n - 1 edge-count check, combined with the no-cycle check, together rule out both 'too many edges' (a cycle) and 'too few edges' (a disconnected forest)." } ] } ``` ## Number of Islands II [LeetCode 305 · Number of Islands II](https://leetcode.com/problems/number-of-islands-ii/) · DSU · Hard Land cells are added one at a time, and after each addition you need the current island count. Recomputing with BFS/DFS after every single addition costs O(n) per query. DSU processes each addition in near-O(1), which is the entire reason DSU exists for *dynamic* (incremental) connectivity problems, as opposed to static ones where BFS/DFS is simpler. **Approach:** Maintain a DSU over the grid's flattened cell indices, plus a `land` set tracking which cells are filled. On each new land cell, increment the island count by 1 (a brand-new component), then union with any of its 4 already-land neighbors, decrementing the count once per successful merge. ```python def num_islands2(m: int, n: int, positions: list[list[int]]) -> list[int]: parent = {} rank = {} land = set() result = [] count = 0 def find(x: int) -> int: if parent[x] != x: parent[x] = find(parent[x]) return parent[x] def union(x: int, y: int) -> bool: rx, ry = find(x), find(y) if rx == ry: return False if rank[rx] < rank[ry]: rx, ry = ry, rx parent[ry] = rx if rank[rx] == rank[ry]: rank[rx] += 1 return True for r, c in positions: idx = r * n + c if idx in land: result.append(count) # duplicate addition, no change continue land.add(idx) parent[idx] = idx rank[idx] = 0 count += 1 for dr, dc in ((1, 0), (-1, 0), (0, 1), (0, -1)): nr, nc = r + dr, c + dc n_idx = nr * n + nc if 0 <= nr < m and 0 <= nc < n and n_idx in land: if union(idx, n_idx): count -= 1 result.append(count) return result ``` ```javascript + function numIslands2(m, n, positions) { const parent = new Map(); const rank = new Map(); const land = new Set(); const result = []; let count = 0; function find(x) { if (parent.get(x) !== x) { parent.set(x, find(parent.get(x))); } return parent.get(x); } function union(x, y) { let rx = find(x); let ry = find(y); if (rx === ry) return false; if (rank.get(rx) < rank.get(ry)) { [rx, ry] = [ry, rx]; } parent.set(ry, rx); if (rank.get(rx) === rank.get(ry)) { rank.set(rx, rank.get(rx) + 1); } return true; } for (const [r, c] of positions) { const idx = r * n + c; if (land.has(idx)) { result.push(count); // duplicate addition, no change continue; } land.add(idx); parent.set(idx, idx); rank.set(idx, 0); count++; for (const [dr, dc] of [[1, 0], [-1, 0], [0, 1], [0, -1]]) { const nr = r + dr; const nc = c + dc; const nIdx = nr * n + nc; if (nr >= 0 && nr < m && nc >= 0 && nc < n && land.has(nIdx)) { if (union(idx, nIdx)) { count--; } } } result.push(count); } return result; } ``` ```java + import java.util.ArrayList; import java.util.HashMap; import java.util.HashSet; import java.util.List; import java.util.Map; import java.util.Set; public class Main { public static void main(String[] args) { int[][] positions = {{0, 0}, {0, 1}, {1, 2}, {2, 1}}; System.out.println(numIslands2(3, 3, positions)); } static Map parent = new HashMap<>(); static Map rank = new HashMap<>(); static Set land = new HashSet<>(); static List numIslands2(int m, int n, int[][] positions) { List result = new ArrayList<>(); int count = 0; int[][] dirs = {{1, 0}, {-1, 0}, {0, 1}, {0, -1}}; for (int[] pos : positions) { int r = pos[0], c = pos[1]; int idx = r * n + c; if (land.contains(idx)) { result.add(count); // duplicate addition, no change continue; } land.add(idx); parent.put(idx, idx); rank.put(idx, 0); count++; for (int[] dir : dirs) { int nr = r + dir[0], nc = c + dir[1]; int nIdx = nr * n + nc; if (nr >= 0 && nr < m && nc >= 0 && nc < n && land.contains(nIdx)) { if (union(idx, nIdx)) { count--; } } } result.add(count); } return result; } static int find(int x) { if (parent.get(x) != x) { parent.put(x, find(parent.get(x))); } return parent.get(x); } static boolean union(int x, int y) { int rx = find(x); int ry = find(y); if (rx == ry) return false; if (rank.get(rx) < rank.get(ry)) { int tmp = rx; rx = ry; ry = tmp; } parent.put(ry, rx); if (rank.get(rx).equals(rank.get(ry))) { rank.put(rx, rank.get(rx) + 1); } return true; } } ``` **Complexity:** O(k · α(k)) time for `k` position updates, O(k) space (only land cells get DSU entries, via a dict-based sparse DSU, not a full `m*n` array). **Common mistakes:** Allocating a dense `parent` array of size `m*n` when a dict keyed by only the cells actually visited is simpler and avoids wasted memory on large sparse grids. Forgetting to handle duplicate positions in the input, since the same cell can appear twice and must not be double-counted as a new island. Not decrementing `count` on every successful union; each merge reduces the island count by exactly one, and a single new cell can merge with up to 4 neighbors at once. > **Remember:** each new land cell starts as its own island (+1), then merges with any land neighbors (-1 per merge). A sparse dict-based DSU avoids allocating the whole grid upfront. ```knowledge-check { "questions": [ { "id": "dsa-union-find-islands-ii-q1", "type": "mcq", "prompt": "Why is union-find a better fit than re-running BFS/DFS after every new land cell in Number of Islands II?", "options": [ {"id": "a", "text": "Connectivity is being queried incrementally between additions, and DSU processes each addition in near-constant time instead of O(n) per query"}, {"id": "b", "text": "BFS/DFS cannot correctly count islands on a grid at all"}, {"id": "c", "text": "DSU uses less memory than BFS/DFS in every case"}, {"id": "d", "text": "The problem requires a sorted order of results, which only DSU can produce"} ], "correct": "a", "explanation": "Re-running BFS/DFS from scratch after every single addition costs O(n) each time, O(n*k) total for k additions. DSU updates the existing structure incrementally, near O(1) amortized per addition, which is exactly the situation DSU is built for." } ] } ``` The four problems in this lesson split along one axis: is the graph built once (Number of Connected Components, Graph Valid Tree), or does it grow incrementally (Longest Consecutive Sequence's value-by-value unions, Number of Islands II's cell-by-cell additions)? For the one-time case, BFS/DFS is usually just as good as DSU, and sometimes simpler to write. DSU earns its place specifically when connectivity needs to be checked *between* additions, not only once at the very end. 3c:T4692,Picture splitting a big food bill among five friends who keep re-adding the same subtotals by hand, again and again, every time someone asks "wait, how much do I owe?" That's wasted work: the subtotal for the first three people never changes, so write it down once and reuse it. Dynamic programming (DP) is that idea turned into a technique: solve small pieces of a problem once, save the answers, and build the big answer out of the pieces you already solved. It trips up more candidates than any other topic, not because the code is hard, but because finding the right "piece" to save is hard. Get that right and the code almost writes itself. ## Recursion vs memoization vs tabulation **Plain recursion** re-solves the same subproblem again and again whenever subproblems overlap. That repeated work is what makes a naive recursive solution slow, often exponentially slow. ```python def fib_naive(n): if n <= 1: return n return fib_naive(n - 1) + fib_naive(n - 2) # fib_naive(5) recomputes fib_naive(3) twice, fib_naive(2) three times, etc. # Time: O(2^n) ``` ```javascript + function fibNaive(n) { if (n <= 1) return n; return fibNaive(n - 1) + fibNaive(n - 2); } // fibNaive(5) recomputes fibNaive(3) twice, fibNaive(2) three times, etc. // Time: O(2^n) ``` ```java + public class Main { public static void main(String[] args) { System.out.println(fibNaive(10)); } static int fibNaive(int n) { if (n <= 1) return n; return fibNaive(n - 1) + fibNaive(n - 2); } // fibNaive(5) recomputes fibNaive(3) twice, fibNaive(2) three times, etc. // Time: O(2^n) } ``` **Memoization** (top-down DP) keeps the same recursive calls, but writes each answer down in a cache the first time it's computed. The next time the same question comes up, read the cache instead of recomputing. ```python def fib_memo(n, cache={}): if n <= 1: return n if n in cache: return cache[n] cache[n] = fib_memo(n - 1, cache) + fib_memo(n - 2, cache) return cache[n] # Time: O(n), Space: O(n) for cache + O(n) recursion stack ``` ```javascript + const fibMemoCache = new Map(); function fibMemo(n) { if (n <= 1) return n; if (fibMemoCache.has(n)) return fibMemoCache.get(n); const result = fibMemo(n - 1) + fibMemo(n - 2); fibMemoCache.set(n, result); return result; } // Time: O(n), Space: O(n) for cache + O(n) recursion stack ``` ```java + import java.util.*; public class Main { static final Map cache = new HashMap<>(); public static void main(String[] args) { System.out.println(fibMemo(30)); } static int fibMemo(int n) { if (n <= 1) return n; if (cache.containsKey(n)) return cache.get(n); int result = fibMemo(n - 1) + fibMemo(n - 2); cache.put(n, result); return result; } } ``` **Tabulation** (bottom-up DP) drops recursion entirely. Instead of starting at the top and working down, you start at the smallest answers and build up, filling a table step by step, the way you'd fill in a spreadsheet row by row. ```python def fib_tab(n): if n <= 1: return n dp = [0] * (n + 1) dp[1] = 1 for i in range(2, n + 1): dp[i] = dp[i - 1] + dp[i - 2] return dp[n] # Time: O(n), Space: O(n), no recursion stack risk ``` ```javascript + function fibTab(n) { if (n <= 1) return n; const dp = new Array(n + 1).fill(0); dp[1] = 1; for (let i = 2; i <= n; i++) { dp[i] = dp[i - 1] + dp[i - 2]; } return dp[n]; } ``` ```java + public class Main { public static void main(String[] args) { System.out.println(fibTab(10)); } static int fibTab(int n) { if (n <= 1) return n; int[] dp = new int[n + 1]; dp[1] = 1; for (int i = 2; i <= n; i++) { dp[i] = dp[i - 1] + dp[i - 2]; } return dp[n]; } } ``` | | Recursion | Memoization | Tabulation | |---|---|---|---| | Structure | Top-down, natural to write | Top-down, with a cache | Bottom-up, a loop | | Time when subproblems overlap | Exponential | Proportional to number of states | Proportional to number of states | | Risk of crashing on deep input | High (deep recursion) | High | None | | Best one to write first | Yes, to find the recurrence | Add a cache once recursion is correct | Convert once base cases and the rule are locked | | Can you shrink the memory used? | Not really | Cache grows with the state space | Often shrinks to a couple of variables | **How to use this in an interview:** write the plain recursive version first, even just in your head, to nail down the rule connecting a value to smaller ones. Add a cache to show you understand why the naive version was slow. Then offer the loop version, and shrinking the memory, as the polish. Walking through that progression out loud is itself what shows an interviewer you understand DP, not just that you memorized a template. > **Remember:** recursion re-solves, memoization remembers while going down, tabulation builds while going up. Same answer, three different amounts of wasted work. ```knowledge-check { "questions": [ { "id": "dsa-dp-basics-recursion-memo-tab-q1", "type": "mcq", "prompt": "Why is plain recursive Fibonacci exponential time, while the memoized version is linear time?", "options": [ {"id": "a", "text": "Plain recursion recomputes the same subproblem many times; memoization caches each subproblem's answer so it's computed only once"}, {"id": "b", "text": "Memoization uses a different, faster addition operator"}, {"id": "c", "text": "Plain recursion is only slow in Python, not in other languages"}, {"id": "d", "text": "Tabulation and memoization always produce different answers"} ], "correct": "a", "explanation": "Without a cache, fib(5) re-derives fib(3) and fib(2) from scratch every time they're needed. A cache means each distinct subproblem is solved exactly once." } ] } ``` ## State definition The "state" is the smallest set of facts that fully answers "what's the best outcome from here?" Getting this wrong is the single most common way candidates get stuck on DP. Ask yourself: **what changes between one recursive call and the next, and what do I actually need to know to answer the question at this point?** - Climbing Stairs: the state is the current step `i`. `dp[i]` means "number of ways to reach step `i`." - House Robber: the state is the current house index `i`. `dp[i]` means "max money you can rob from houses `0` through `i`." - Problems comparing two strings (later in this course): the state is a pair `(i, j)`, your position in *each* string. A useful test: if two different state definitions give different answers for what should be the same subproblem, the state is incomplete. You're missing a piece of information, often a yes/no flag like "have I already used my one free skip?" > **Remember:** the state is the exact question you'd have to text a friend to get back the right number. If the question is incomplete, the answer will be too. ```knowledge-check { "questions": [ { "id": "dsa-dp-basics-state-q1", "type": "mcq", "prompt": "What's the sign that a DP state definition is missing information?", "options": [ {"id": "a", "text": "Two different paths that should reach the same subproblem give different answers under that state"}, {"id": "b", "text": "The code runs slower than expected"}, {"id": "c", "text": "The base case is set to zero"}, {"id": "d", "text": "The array has more than one dimension"} ], "correct": "a", "explanation": "If a state definition were complete, every path that lands on the 'same' state should get the same answer. A mismatch means an extra fact (like a used/unused flag) needs to be part of the state." } ] } ``` ## Base cases and transitions Every DP recurrence has exactly two parts: 1. **Base case(s):** the smallest subproblems, answered directly with no recursion needed (for example, `dp[0] = 1`, `dp[1] = 1`). 2. **Transition:** the rule for building `dp[i]` out of smaller, already-solved states (for example, `dp[i] = dp[i-1] + dp[i-2]`). Get the base case wrong, and every value built on top of it is wrong too, even if the transition rule is perfect. Always check your base cases against the smallest one or two real examples by hand before you write any code. > **Remember:** a wrong base case poisons the whole table. Check it by hand first, on paper, before typing anything. ```knowledge-check { "questions": [ { "id": "dsa-dp-basics-base-transition-q1", "type": "mcq", "prompt": "Why does a wrong base case matter more in DP than a small bug elsewhere in the recurrence?", "options": [ {"id": "a", "text": "Every later value in the table is built on top of the base case, so an error there propagates through the whole table"}, {"id": "b", "text": "Base cases are checked separately by the compiler"}, {"id": "c", "text": "It only matters for problems with two-dimensional tables"}, {"id": "d", "text": "A wrong base case only affects the final answer, not any intermediate ones"} ], "correct": "a", "explanation": "dp[i] depends on dp[i-1] and dp[i-2], which depend on the base cases. A wrong dp[0] or dp[1] corrupts every downstream value." } ] } ``` ### Climbing Stairs [LeetCode 70](https://leetcode.com/problems/climbing-stairs/), DP, Basic **Intuition:** To reach step `n`, your last move was either a 1-step from `n-1` or a 2-step from `n-2`. So the number of ways to reach `n` is the sum of the ways to reach those two prior steps. This is the Fibonacci recurrence in disguise. **Approach:** `dp[i] = dp[i-1] + dp[i-2]`, with `dp[0] = 1` (one way to stand at the start: do nothing) and `dp[1] = 1`. ```python def climbStairs(n: int) -> int: if n <= 1: return 1 prev2, prev1 = 1, 1 # dp[0], dp[1] for i in range(2, n + 1): prev2, prev1 = prev1, prev2 + prev1 return prev1 ``` ```javascript + function climbStairs(n) { if (n <= 1) return 1; let prev2 = 1, prev1 = 1; // dp[0], dp[1] for (let i = 2; i <= n; i++) { [prev2, prev1] = [prev1, prev2 + prev1]; } return prev1; } ``` ```java + public class Main { public static void main(String[] args) { System.out.println(climbStairs(5)); } static int climbStairs(int n) { if (n <= 1) return 1; int prev2 = 1, prev1 = 1; // dp[0], dp[1] for (int i = 2; i <= n; i++) { int next = prev2 + prev1; prev2 = prev1; prev1 = next; } return prev1; } } ``` **Worked example:** for `n = 5`, the ways build up as `1, 1, 2, 3, 5, 8`, so `dp[5] = 8`. **Complexity:** Time O(n), space O(1). This is a memory shrink in action: since `dp[i]` only needs the two previous values, there's no need to keep the whole array. **Common mistakes:** getting the base case off by one; `dp[0]` should be 1, not 0, since there's exactly one way to be at the ground with zero steps taken (do nothing). Using plain unmemoized recursion here gives O(2^n) for no reason. > **Remember:** Climbing Stairs is Fibonacci with a costume on. Spot the "last move was one of two options" shape and the recurrence follows. ### Min Cost Climbing Stairs [LeetCode 746](https://leetcode.com/problems/min-cost-climbing-stairs/), DP, Basic **Intuition:** You can start from step 0 or step 1 for free, and every step you land on costs `cost[i]` to leave. Minimize the total cost of getting past the top. `dp[i]` = minimum cost to reach step `i`. **Approach:** `dp[i] = min(dp[i-1] + cost[i-1], dp[i-2] + cost[i-2])`. Reaching step `i` means paying to leave whichever of the two prior steps you came from. ```python def minCostClimbingStairs(cost: list[int]) -> int: n = len(cost) prev2, prev1 = 0, 0 # dp[0] = 0, dp[1] = 0 (both are free starting points) for i in range(2, n + 1): prev2, prev1 = prev1, min(prev1 + cost[i - 1], prev2 + cost[i - 2]) return prev1 ``` ```javascript + function minCostClimbingStairs(cost) { const n = cost.length; let prev2 = 0, prev1 = 0; // dp[0] = 0, dp[1] = 0 (both free starting points) for (let i = 2; i <= n; i++) { [prev2, prev1] = [prev1, Math.min(prev1 + cost[i - 1], prev2 + cost[i - 2])]; } return prev1; } ``` ```java + public class Main { public static void main(String[] args) { int[] cost = {10, 15, 20}; System.out.println(minCostClimbingStairs(cost)); } static int minCostClimbingStairs(int[] cost) { int n = cost.length; int prev2 = 0, prev1 = 0; // dp[0] = 0, dp[1] = 0 (both free starting points) for (int i = 2; i <= n; i++) { int next = Math.min(prev1 + cost[i - 1], prev2 + cost[i - 2]); prev2 = prev1; prev1 = next; } return prev1; } } ``` **Complexity:** Time O(n), space O(1). **Common mistakes:** mixing up "cost to reach step i" with "cost of step i." The cost is paid when you leave a step, not when you land on it, and that shifts the indices in the transition. Also, forgetting the top is one step past the last index, `n`, not `len(cost) - 1`. > **Remember:** the cost is a toll you pay leaving a step, not an entry fee. That one detail decides which index goes where in the formula. ### House Robber [LeetCode 198](https://leetcode.com/problems/house-robber/), DP, State selection **Intuition:** At each house, you either rob it (and skip the previous one, since two adjacent houses can't both be robbed) or skip it. `dp[i]` = the most money you can rob from the first `i` houses. **Approach:** `dp[i] = max(dp[i-1], dp[i-2] + nums[i])`. Either skip house `i` and carry forward `dp[i-1]`, or rob it: `nums[i]` plus the best result from two houses back, since the one right before it is now off-limits. ```python def rob(nums: list[int]) -> int: prev2, prev1 = 0, 0 # dp[-1] = 0 (no houses), dp[0] before loop starts for num in nums: prev2, prev1 = prev1, max(prev1, prev2 + num) return prev1 ``` ```javascript + function rob(nums) { let prev2 = 0, prev1 = 0; // dp[-1] = 0 (no houses), dp[0] before loop starts for (const num of nums) { [prev2, prev1] = [prev1, Math.max(prev1, prev2 + num)]; } return prev1; } ``` ```java + public class Main { public static void main(String[] args) { int[] nums = {2, 7, 9, 3, 1}; System.out.println(rob(nums)); } static int rob(int[] nums) { int prev2 = 0, prev1 = 0; // dp[-1] = 0 (no houses), dp[0] before loop starts for (int num : nums) { int next = Math.max(prev1, prev2 + num); prev2 = prev1; prev1 = next; } return prev1; } } ``` **Complexity:** Time O(n), space O(1). **Common mistakes:** trying to track *which* houses were robbed instead of just the best total. The problem only asks for the amount, so the state is simpler than it looks at first. Also, confusing this with a greedy "always take the bigger neighbor" rule, which is wrong: DP correctly looks ahead through the recurrence, greedy doesn't. > **Remember:** at every house you make one binary choice, rob it or skip it, and `dp[i]` remembers the best answer so far either way. ### House Robber II [LeetCode 213](https://leetcode.com/problems/house-robber-ii/), DP, Circular array **Intuition:** The houses sit in a circle, so house 0 and house `n-1` are now neighbors too, and you can't rob both. Split into two cases: rob from every house except the last, or rob from every house except the first. The answer is the better of the two, each solved with plain House Robber. **Approach:** Run the House Robber I logic twice, once on `nums[0:n-1]` and once on `nums[1:n]`, and take the max. Handle `n == 1` as its own case, since a single house has no circle conflict at all. ```python def rob_ii(nums: list[int]) -> int: if len(nums) == 1: return nums[0] def rob_linear(houses): prev2, prev1 = 0, 0 for num in houses: prev2, prev1 = prev1, max(prev1, prev2 + num) return prev1 return max(rob_linear(nums[:-1]), rob_linear(nums[1:])) ``` ```javascript + function robII(nums) { if (nums.length === 1) return nums[0]; function robLinear(houses) { let prev2 = 0, prev1 = 0; for (const num of houses) { [prev2, prev1] = [prev1, Math.max(prev1, prev2 + num)]; } return prev1; } return Math.max(robLinear(nums.slice(0, -1)), robLinear(nums.slice(1))); } ``` ```java + import java.util.*; public class Main { public static void main(String[] args) { int[] nums = {2, 3, 2}; System.out.println(robII(nums)); } static int robII(int[] nums) { if (nums.length == 1) return nums[0]; return Math.max( robLinear(Arrays.copyOfRange(nums, 0, nums.length - 1)), robLinear(Arrays.copyOfRange(nums, 1, nums.length)) ); } static int robLinear(int[] houses) { int prev2 = 0, prev1 = 0; for (int num : houses) { int next = Math.max(prev1, prev2 + num); prev2 = prev1; prev1 = next; } return prev1; } } ``` **Complexity:** Time O(n) across two linear passes, space O(n) for the slices, or O(1) extra if you pass index ranges instead of slicing. **Common mistakes:** forgetting the `n == 1` case. Slicing `nums[:-1]` and `nums[1:]` both produce empty lists when `n == 1`, which silently returns 0 instead of `nums[0]`. Also, trying to solve the circular case directly in one pass instead of breaking it into two linear subproblems; that reduction to plain House Robber is the entire trick. > **Remember:** a circle is just two lines in disguise. Solve "exclude the last house" and "exclude the first house" separately and take the better one. 3d:T55c4,Think of comparing two shopping lists to find the items they share, or figuring out the fewest edits to turn one sentence into another. Both need you to track a position in *two* things at once, not just one. The Dynamic Programming Basics lesson used a single moving index, `dp[i]`. Here the state grows to two dimensions: two strings, two positions in the same array, or one sequence plus an extra flag like "have I used my one free skip yet." This is where a lot of candidates' DP falls apart. Get comfortable with two-dimensional state and you've covered the pattern behind most "hard" DP interview questions. ## 2D DP state When a problem compares or combines **two sequences**, or tracks one sequence plus something extra (like "how many items used so far" or "have I done X yet"), the state usually needs two indices: `dp[i][j]`. ```python # Generic 2D DP table shape dp = [[0] * (n + 1) for _ in range(m + 1)] ``` The extra row and column, the `+1` in each dimension, conventionally stands for the **empty prefix**: `dp[0][j]` and `dp[i][0]` are base cases meaning "zero characters or items considered from this side." This convention saves you from special-casing empty inputs everywhere inside the main loop. **How to recognize 2D DP:** if comparing or combining two sequences means you need to know where you are in *both* of them, you need two indices. If it's really one sequence but you're also tracking an extra constraint, like a budget, a mode, or a used/unused flag, that constraint becomes the second dimension. > **Remember:** two strings, two positions. One string plus an extra fact you must remember, one position plus one flag. Either way, that's your second dimension. ```knowledge-check { "questions": [ { "id": "dsa-dp-intermediate-2d-state-q1", "type": "mcq", "prompt": "What usually signals that a DP problem needs a 2D table, dp[i][j], instead of a 1D one?", "options": [ {"id": "a", "text": "The problem compares or combines two sequences, or tracks one sequence plus an extra condition like a used/unused flag"}, {"id": "b", "text": "The input array has more than 100 elements"}, {"id": "c", "text": "The problem asks for a yes/no answer instead of a number"}, {"id": "d", "text": "The code uses recursion instead of a loop"} ], "correct": "a", "explanation": "A second index appears whenever the answer depends on positions in two separate sequences, or on one position plus one more piece of tracked information." } ] } ``` ## String DP String DP problems compare or transform two strings character by character. The state is `dp[i][j]` = "the answer considering the first `i` characters of string A and the first `j` characters of string B." The transition almost always branches on whether `A[i-1] == B[j-1]`. ```python # Skeleton shared by LCS, Edit Distance, and most string-pair DP: for i in range(1, m + 1): for j in range(1, n + 1): if A[i - 1] == B[j - 1]: dp[i][j] = ... # characters match — extend some prior state else: dp[i][j] = ... # characters differ — combine other subproblems ``` Space is often shrinkable from O(m×n) down to O(min(m,n)), because row `i` usually only depends on row `i-1`. > **Remember:** string DP is a grid where row `i` and column `j` mean "first `i` characters of A, first `j` characters of B." The character comparison at that cell decides the transition. ```knowledge-check { "questions": [ { "id": "dsa-dp-intermediate-string-dp-q1", "type": "mcq", "prompt": "In a two-string DP like Edit Distance or LCS, what does dp[i][j] usually represent?", "options": [ {"id": "a", "text": "The answer for the first i characters of one string compared against the first j characters of the other"}, {"id": "b", "text": "The total length of both strings combined"}, {"id": "c", "text": "The number of times character i appears in string j"}, {"id": "d", "text": "A boolean for whether the two full strings are identical"} ], "correct": "a", "explanation": "The two indices track a prefix length in each string independently, which is exactly why the table has two dimensions." } ] } ``` ## State machines Some DP problems, like stock trading or string parsing with modes, model the process as a **finite state machine**: `dp[i][state]` tracks the best value at step `i` while in a given state, and transitions move between states. ```python # Example shape: dp[i][0] = best value at step i in "state 0" # dp[i][1] = best value at step i in "state 1" # Buy/sell stock is the canonical example: def maxProfit_stateMachine(prices: list[int]) -> int: hold, not_hold = float('-inf'), 0 # state 0: holding a share, state 1: not for price in prices: hold, not_hold = max(hold, not_hold - price), max(not_hold, hold + price) return not_hold ``` ```javascript + function maxProfitStateMachine(prices) { let hold = -Infinity, notHold = 0; // state 0: holding a share, state 1: not for (const price of prices) { [hold, notHold] = [Math.max(hold, notHold - price), Math.max(notHold, hold + price)]; } return notHold; } ``` ```java + public class Main { public static void main(String[] args) { int[] prices = {7, 1, 5, 3, 6, 4}; System.out.println(maxProfitStateMachine(prices)); } static int maxProfitStateMachine(int[] prices) { int hold = Integer.MIN_VALUE, notHold = 0; // state 0: holding a share, state 1: not for (int price : prices) { int newHold = Math.max(hold, notHold - price); int newNotHold = Math.max(notHold, hold + price); hold = newHold; notHold = newNotHold; } return notHold; } } ``` The key skill is drawing the state diagram first, on paper: what states exist, what moves between them are legal, what each move costs or earns, before writing any code. It's the same discipline as pinning down `dp[i]` correctly, just with an extra "which mode am I in" dimension. > **Remember:** draw the states and the arrows between them on paper before coding. Code the diagram, don't invent it in the loop. ```knowledge-check { "questions": [ { "id": "dsa-dp-intermediate-state-machine-q1", "type": "mcq", "prompt": "In the buy/sell stock state-machine DP, what do the two tracked states represent?", "options": [ {"id": "a", "text": "Currently holding a share, and currently not holding a share"}, {"id": "b", "text": "The stock price is rising, and the stock price is falling"}, {"id": "c", "text": "The first half of the prices array, and the second half"}, {"id": "d", "text": "Buying is allowed, and buying is forbidden"} ], "correct": "a", "explanation": "hold tracks the best profit if you currently own a share; notHold tracks the best profit if you don't. Each day's prices update both possibilities." } ] } ``` ### Longest Common Subsequence [LeetCode 1143](https://leetcode.com/problems/longest-common-subsequence/), DP, 2D **Intuition:** A subsequence keeps the relative order of characters but can skip some. `dp[i][j]` = length of the longest common subsequence (LCS) of `text1[:i]` and `text2[:j]`. If the current characters match, they extend the LCS found without them; if not, take the better of skipping a character from either string. **Approach:** `dp[i][j] = dp[i-1][j-1] + 1` if `text1[i-1] == text2[j-1]`, else `max(dp[i-1][j], dp[i][j-1])`. ```python def longestCommonSubsequence(text1: str, text2: str) -> int: m, n = len(text1), len(text2) dp = [[0] * (n + 1) for _ in range(m + 1)] for i in range(1, m + 1): for j in range(1, n + 1): if text1[i - 1] == text2[j - 1]: dp[i][j] = dp[i - 1][j - 1] + 1 else: dp[i][j] = max(dp[i - 1][j], dp[i][j - 1]) return dp[m][n] ``` ```javascript + function longestCommonSubsequence(text1, text2) { const m = text1.length, n = text2.length; const dp = Array.from({ length: m + 1 }, () => new Array(n + 1).fill(0)); for (let i = 1; i <= m; i++) { for (let j = 1; j <= n; j++) { if (text1[i - 1] === text2[j - 1]) { dp[i][j] = dp[i - 1][j - 1] + 1; } else { dp[i][j] = Math.max(dp[i - 1][j], dp[i][j - 1]); } } } return dp[m][n]; } ``` ```java + public class Main { public static void main(String[] args) { System.out.println(longestCommonSubsequence("abcde", "ace")); } static int longestCommonSubsequence(String text1, String text2) { int m = text1.length(), n = text2.length(); int[][] dp = new int[m + 1][n + 1]; for (int i = 1; i <= m; i++) { for (int j = 1; j <= n; j++) { if (text1.charAt(i - 1) == text2.charAt(j - 1)) { dp[i][j] = dp[i - 1][j - 1] + 1; } else { dp[i][j] = Math.max(dp[i - 1][j], dp[i][j - 1]); } } } return dp[m][n]; } } ``` **Worked example:** `"abcde"` and `"ace"` share the subsequence `"ace"` (skip `b` and `d`), so the answer is 3. **Complexity:** Time O(m·n), space O(m·n), shrinkable to O(min(m,n)) since row `i` only needs row `i-1`. **Common mistakes:** confusing "subsequence" with "substring." LCS allows gaps, so `dp[i][j]` isn't restricted to characters at `i-1, j-1` being part of one contiguous run. Also, off-by-one indexing between the 1-indexed `dp` table and 0-indexed strings: it's `text1[i-1]`, not `text1[i]`. > **Remember:** LCS skips freely; substring problems don't. Mixing those two up is the most common LCS bug. ### Edit Distance [LeetCode 72](https://leetcode.com/problems/edit-distance/), DP, 2D, Hard **Intuition:** You want the fewest operations (insert, delete, replace) to turn `word1` into `word2`. `dp[i][j]` = edit distance between `word1[:i]` and `word2[:j]`. If characters match, no operation is needed at this position; if not, take the best of the three possible operations plus 1. **Approach:** `dp[i][j] = dp[i-1][j-1]` if characters match, else `1 + min(dp[i-1][j-1], dp[i-1][j], dp[i][j-1])` (replace, delete, insert respectively). ```python def minDistance(word1: str, word2: str) -> int: m, n = len(word1), len(word2) dp = [[0] * (n + 1) for _ in range(m + 1)] for i in range(m + 1): dp[i][0] = i # delete all i characters of word1 for j in range(n + 1): dp[0][j] = j # insert all j characters of word2 for i in range(1, m + 1): for j in range(1, n + 1): if word1[i - 1] == word2[j - 1]: dp[i][j] = dp[i - 1][j - 1] else: dp[i][j] = 1 + min( dp[i - 1][j - 1], # replace dp[i - 1][j], # delete from word1 dp[i][j - 1], # insert into word1 ) return dp[m][n] ``` ```javascript + function minDistance(word1, word2) { const m = word1.length, n = word2.length; const dp = Array.from({ length: m + 1 }, () => new Array(n + 1).fill(0)); for (let i = 0; i <= m; i++) dp[i][0] = i; // delete all i characters of word1 for (let j = 0; j <= n; j++) dp[0][j] = j; // insert all j characters of word2 for (let i = 1; i <= m; i++) { for (let j = 1; j <= n; j++) { if (word1[i - 1] === word2[j - 1]) { dp[i][j] = dp[i - 1][j - 1]; } else { dp[i][j] = 1 + Math.min( dp[i - 1][j - 1], // replace dp[i - 1][j], // delete from word1 dp[i][j - 1] // insert into word1 ); } } } return dp[m][n]; } ``` ```java + public class Main { public static void main(String[] args) { System.out.println(minDistance("horse", "ros")); } static int minDistance(String word1, String word2) { int m = word1.length(), n = word2.length(); int[][] dp = new int[m + 1][n + 1]; for (int i = 0; i <= m; i++) dp[i][0] = i; // delete all i characters of word1 for (int j = 0; j <= n; j++) dp[0][j] = j; // insert all j characters of word2 for (int i = 1; i <= m; i++) { for (int j = 1; j <= n; j++) { if (word1.charAt(i - 1) == word2.charAt(j - 1)) { dp[i][j] = dp[i - 1][j - 1]; } else { dp[i][j] = 1 + Math.min( dp[i - 1][j - 1], // replace Math.min(dp[i - 1][j], dp[i][j - 1]) // delete, insert ); } } } return dp[m][n]; } } ``` **Complexity:** Time O(m·n), space O(m·n), shrinkable to O(min(m,n)). **Common mistakes:** forgetting the base-case row and column, `dp[i][0] = i` and `dp[0][j] = j`. Without these, comparing against an empty string gives wrong results. Also, mixing up which operation goes with which neighbor cell: delete is `dp[i-1][j]`, insert is `dp[i][j-1]`, replace is `dp[i-1][j-1]`. Draw a small table by hand once to lock this in. > **Remember:** three neighbors, three operations. `dp[i-1][j]` deletes, `dp[i][j-1]` inserts, `dp[i-1][j-1]` replaces. ### Longest Increasing Subsequence [LeetCode 300](https://leetcode.com/problems/longest-increasing-subsequence/), DP, Binary search optimization **Intuition:** `dp[i]` = length of the longest increasing subsequence ending exactly at index `i`. The O(n²) version checks every earlier smaller element. The O(n log n) version instead keeps an array `tails`, where `tails[k]` is the smallest possible tail value of an increasing subsequence of length `k+1`, updated with binary search. **Approach (O(n²), derive this one first):** `dp[i] = 1 + max(dp[j] for j < i if nums[j] < nums[i])`, defaulting to 1. ```python def lengthOfLIS_On2(nums: list[int]) -> int: n = len(nums) dp = [1] * n for i in range(n): for j in range(i): if nums[j] < nums[i]: dp[i] = max(dp[i], dp[j] + 1) return max(dp) ``` ```javascript + function lengthOfLISOn2(nums) { const n = nums.length; const dp = new Array(n).fill(1); for (let i = 0; i < n; i++) { for (let j = 0; j < i; j++) { if (nums[j] < nums[i]) { dp[i] = Math.max(dp[i], dp[j] + 1); } } } return Math.max(...dp); } ``` ```java + public class Main { public static void main(String[] args) { int[] nums = {10, 9, 2, 5, 3, 7, 101, 18}; System.out.println(lengthOfLISOn2(nums)); } static int lengthOfLISOn2(int[] nums) { int n = nums.length; int[] dp = new int[n]; java.util.Arrays.fill(dp, 1); for (int i = 0; i < n; i++) { for (int j = 0; j < i; j++) { if (nums[j] < nums[i]) { dp[i] = Math.max(dp[i], dp[j] + 1); } } } int best = 0; for (int v : dp) best = Math.max(best, v); return best; } } ``` **Approach (O(n log n), the interview follow-up):** ```python import bisect def lengthOfLIS(nums: list[int]) -> int: tails = [] for num in nums: pos = bisect.bisect_left(tails, num) if pos == len(tails): tails.append(num) else: tails[pos] = num return len(tails) ``` ```javascript + function lengthOfLIS(nums) { const tails = []; for (const num of nums) { let lo = 0, hi = tails.length; while (lo < hi) { // binary search: first index where tails[idx] >= num const mid = (lo + hi) >> 1; if (tails[mid] < num) lo = mid + 1; else hi = mid; } if (lo === tails.length) tails.push(num); else tails[lo] = num; } return tails.length; } ``` ```java + import java.util.*; public class Main { public static void main(String[] args) { int[] nums = {10, 9, 2, 5, 3, 7, 101, 18}; System.out.println(lengthOfLIS(nums)); } static int lengthOfLIS(int[] nums) { int[] tails = new int[nums.length]; int size = 0; for (int num : nums) { int pos = Arrays.binarySearch(tails, 0, size, num); if (pos < 0) pos = -(pos + 1); // insertion point, mirrors bisect_left tails[pos] = num; if (pos == size) size++; } return size; } } ``` **Complexity:** O(n²) DP: time O(n²), space O(n). Binary-search version: time O(n log n), space O(n). **Common mistakes:** thinking `tails` is an actual LIS at the end. It isn't: it only tracks the smallest possible tail for each length, so its length equals the LIS length, but its contents aren't a real subsequence. Also, using `bisect_right` instead of `bisect_left`, which would wrongly allow non-strict increases for the "strictly increasing" version of this problem. > **Remember:** `tails` is a scoreboard of best-possible endings, not a real subsequence. Only its length matters for the answer. ### Word Break [LeetCode 139](https://leetcode.com/problems/word-break/), DP, String **Intuition:** `dp[i]` = can `s[:i]` be split into dictionary words? `dp[i]` is true if some earlier split point `j` has `dp[j]` true and `s[j:i]` is itself a dictionary word. **Approach:** `dp[0] = True` (an empty prefix is trivially splittable). For each `i`, check every `j < i`: if `dp[j]` and `s[j:i]` is in the word set, set `dp[i] = True`. ```python def wordBreak(s: str, wordDict: list[str]) -> bool: word_set = set(wordDict) n = len(s) dp = [False] * (n + 1) dp[0] = True for i in range(1, n + 1): for j in range(i): if dp[j] and s[j:i] in word_set: dp[i] = True break # no need to check other j once found return dp[n] ``` ```javascript + function wordBreak(s, wordDict) { const wordSet = new Set(wordDict); const n = s.length; const dp = new Array(n + 1).fill(false); dp[0] = true; for (let i = 1; i <= n; i++) { for (let j = 0; j < i; j++) { if (dp[j] && wordSet.has(s.slice(j, i))) { dp[i] = true; break; // no need to check other j once found } } } return dp[n]; } ``` ```java + import java.util.*; public class Main { public static void main(String[] args) { List wordDict = Arrays.asList("leet", "code"); System.out.println(wordBreak("leetcode", wordDict)); } static boolean wordBreak(String s, List wordDict) { Set wordSet = new HashSet<>(wordDict); int n = s.length(); boolean[] dp = new boolean[n + 1]; dp[0] = true; for (int i = 1; i <= n; i++) { for (int j = 0; j < i; j++) { if (dp[j] && wordSet.contains(s.substring(j, i))) { dp[i] = true; break; // no need to check other j once found } } } return dp[n]; } } ``` **Complexity:** Time O(n²) for the double loop, plus O(k) per substring slice and lookup where k is the average word length, so effectively O(n²·k) worst case; a `set` keeps membership checks O(1) on average. Space O(n) for `dp`, plus O(total dictionary characters) for `word_set`. **Common mistakes:** treating this as needing to list every possible split, which is a different, more expensive problem (Word Break II); this variant only needs a yes/no answer. Also, forgetting the `dp[0] = True` base case, which anchors every later true value. Not breaking early once `dp[i]` is set is harmless for correctness but wastes time on large inputs. > **Remember:** `dp[i]` asks one question: is there ANY earlier valid split point `j` where the rest of the string is a dictionary word? One yes is enough. ## Recovering the answer, not just its value LCS and Edit Distance above both compute a number: a length or a cost. Getting the actual subsequence, or the actual sequence of edits, takes one more step: walk backward from `dp[m][n]`, and at each cell figure out which transition produced it. In LCS, if `text1[i-1] == text2[j-1]`, that character belongs to the answer and you step diagonally to `dp[i-1][j-1]`. Otherwise you step toward whichever neighbor, `dp[i-1][j]` or `dp[i][j-1]`, matches the current cell's value. The same backward walk applied to the Edit Distance table recovers the actual sequence of inserts, deletes, and replacements. Interviewers often ask for this as a follow-up once the length-or-cost version works, so trace it through by hand once rather than meeting it cold in an interview. > **Remember:** the table gives you a number. Walking it backward, cell by cell, gives you the actual sequence of choices behind that number. ```knowledge-check { "questions": [ { "id": "dsa-dp-intermediate-recover-answer-q1", "type": "mcq", "prompt": "After computing dp[m][n] for LCS, how do you recover the actual common subsequence, not just its length?", "options": [ {"id": "a", "text": "Walk backward from dp[m][n], stepping diagonally when characters match and toward whichever neighbor matches the current value otherwise"}, {"id": "b", "text": "Re-run the algorithm forward with a different starting cell"}, {"id": "c", "text": "The table already stores the subsequence directly in dp[0][0]"}, {"id": "d", "text": "It's impossible to recover the subsequence, only its length is computable"} ], "correct": "a", "explanation": "Backtracking through the table by re-deriving which transition produced each cell's value reconstructs the actual sequence of matches and skips." } ] } ``` 3e:T5fa9,Think about a search box that supports `*` for "anything" and `?` for "any one character," the way old file explorers let you type `report*.pdf` to find every report. Making that actually work under the hood is dynamic programming (DP), and it's one of the places senior interviews specifically probe, because a wrong transition often *looks* right and only fails on tricky inputs. This lesson pushes DP past the "fill a 1D table" problems from earlier lessons into 2D string-matching DP, where the transition itself is the hard part. Interviewers use these problems to check whether you actually understand the state you're building, rather than having memorized a template. ## Recognizing a 2-string matching DP Regex matching, wildcard matching, and edit distance all share one shape: two strings (or a string and a pattern) being compared position by position. Once you can spot that shape, the setup is always the same three steps. 1. Define `dp[i][j]` as the answer for the first `i` characters of string `s` and the first `j` characters of the other string `t`. 2. Build a table sized `(len(s)+1) x (len(t)+1)`. Row 0 and column 0 stand for the empty prefix, which kills most off-by-one bugs before they start. 3. Fill row by row, and each cell's answer depends only on `(i-1, j)`, `(i, j-1)`, and `(i-1, j-1)`, the cells directly above, to the left, and diagonally above-left. Reach for this shape whenever you see: two sequences being compared, transformed, or aligned (edit distance, longest common subsequence, interleaving strings); or `*` / `?` wildcard-style matching against a pattern. > **Remember:** two strings being compared, one table with an extra empty-prefix row and column. That setup is the same for edit distance, wildcard matching, and regex matching. ```knowledge-check { "questions": [ { "id": "dsa-dp-hard-recognize-q1", "type": "mcq", "prompt": "What's the shared setup across edit distance, wildcard matching, and regex matching?", "options": [ {"id": "a", "text": "A dp[i][j] table sized (len(s)+1) x (len(t)+1), where row 0 and column 0 represent empty prefixes"}, {"id": "b", "text": "All three use a min-heap to track the best partial match"}, {"id": "c", "text": "All three can be solved without ever comparing individual characters"}, {"id": "d", "text": "None of them need a base case"} ], "correct": "a", "explanation": "Every 2-string comparison DP uses the same table shape: two indices, and an extra row/column so the empty prefix has a defined answer." } ] } ``` ## State reduction State reduction means shrinking `dp[i][j][k]...` down to the smallest set of indices that fully describes a subproblem. Every DP problem starts with too much information in your head: position in the string, position in the pattern, whether you're mid-star, how many stars used so far. The real skill is proving most of that is unnecessary. For string matching problems, the state is almost always `(i, j)`: "does `s[:i]` match `p[:j]`?" You don't need to track *how* it matched, only *whether* it did, because what happens next only depends on that yes/no plus the remaining suffixes. That's the reduction: from "the full matching history" down to "one bit per `(i, j)` pair." ```python # Bad instinct: track the whole match path # dp[i][j] = list of ways s[:i] matched p[:j] -> exponential blowup # Correct: track only whether a match is possible # dp[i][j] = bool -> O(m*n) states ``` Rule of thumb: if two different "histories" lead to the same future behavior, they belong in the same state. If your DP table has an extra dimension, ask whether that dimension actually changes what happens next. > **Remember:** don't track how you got here, only whether you're in a valid state now. If the future doesn't care about the history, the state shouldn't either. ```knowledge-check { "questions": [ { "id": "dsa-dp-hard-state-reduction-q1", "type": "mcq", "prompt": "Why is dp[i][j] = boolean enough for string matching, instead of tracking the full history of how the match happened?", "options": [ {"id": "a", "text": "Because what happens next from (i, j) only depends on whether a match is possible there, not on how it became possible"}, {"id": "b", "text": "Because booleans use less memory than integers"}, {"id": "c", "text": "Because Python doesn't support storing lists inside a DP table"}, {"id": "d", "text": "Tracking history is required; boolean-only DP is a common bug"} ], "correct": "a", "explanation": "If two different match histories lead to the same future behavior, they belong in the same state. The future from (i, j) is identical regardless of the specific path taken to reach it." } ] } ``` ## Space optimization Once you have a correct `dp[i][j]` table, look at the transition. If `dp[i][j]` only ever reads from row `i-1` (and maybe row `i`), you don't need the full 2D table: two 1D rows (`prev`, `curr`) are enough, or even one row updated carefully in place. ```python # 2D table: O(m*n) space dp = [[False] * (n + 1) for _ in range(m + 1)] # Rolling array: O(n) space — only keep the previous row prev = [False] * (n + 1) curr = [False] * (n + 1) for i in range(1, m + 1): curr[0] = False # reset base case for this row for j in range(1, n + 1): curr[j] = ... # transition using prev[j], prev[j-1], curr[j-1] prev, curr = curr, prev ``` This matters in interviews for two reasons. It shows you understand the *dependency structure* of your own recurrence, not just that you wrote one down. And it's a real production concern: a 10,000 x 10,000 DP table is 100 million cells; a rolling array is 10,000 cells. **Pitfall:** when you roll the array, any base-case reset (`dp[i][0]`) has to happen explicitly inside the loop, since you're reusing the same memory. Forgetting this is the number one bug in rolling-array code. > **Remember:** if a cell only ever reads the row above it, you don't need the whole table, just that one row. Mention the shrink out loud even if you don't have time to code it. ```knowledge-check { "questions": [ { "id": "dsa-dp-hard-space-opt-q1", "type": "mcq", "prompt": "What's the most common bug when converting a 2D DP table into a rolling two-row version?", "options": [ {"id": "a", "text": "Forgetting to explicitly reset the base-case cell (like curr[0]) inside the loop, since the memory is now reused instead of being fresh each row"}, {"id": "b", "text": "Rolling arrays always change the final answer"}, {"id": "c", "text": "Rolling arrays can only be used with strings, not with numbers"}, {"id": "d", "text": "The time complexity increases when you roll the array"} ], "correct": "a", "explanation": "In the full 2D table, dp[i][0] starts as its own fresh cell every row. In a rolling array, that memory is reused, so the base case has to be reset by hand each iteration." } ] } ``` ## Complex transitions The wildcard and regex family have "look-behind" transitions. `p[j-1] == '*'` involves more than comparing one pair of characters: it branches into "match zero of the preceding element" versus "match one more of the current string," and both branches have to be OR'd together. This is the part candidates get wrong under pressure: they handle the plain character-match case fine, then panic on `*` and either miss a branch or mix up `i` and `j`. The reliable process: say the recurrence out loud in plain English first ("if the pattern character is `*`, either the string character is unused entirely, since `*` matched zero times, or the string character is consumed and we stay on the same pattern position, since `*` can match more"), then transcribe it directly into code. Don't try to write the branch logic without saying it out loud first. > **Remember:** never code a `*` transition cold. Say the two branches in plain English first, then translate the sentence into code. ```knowledge-check { "questions": [ { "id": "dsa-dp-hard-transitions-q1", "type": "mcq", "prompt": "Why do candidates most often get the `*` transition wrong under interview pressure?", "options": [ {"id": "a", "text": "They handle the simple character-match case fine but skip stating the two `*` branches in plain English first, so they miss one branch or swap i and j"}, {"id": "b", "text": "The `*` character isn't allowed in regular expressions"}, {"id": "c", "text": "Python doesn't support the `*` operator in string matching"}, {"id": "d", "text": "The `*` transition never actually needs two branches"} ], "correct": "a", "explanation": "The `*` case has two valid outcomes (match zero, or consume one more) that must be OR'd together. Skipping the plain-English statement of both branches is what causes the slip." } ] } ``` ### Regular Expression Matching [LeetCode 10 · Regular Expression Matching](https://leetcode.com/problems/regular-expression-matching/) · DP · Hard **Intuition:** `.` matches any single character; `*` matches zero or more of the *preceding* element (not the literal character before `*`, but that pattern unit). Because `*` looks back one pattern character, `dp[i][j]` has to consider `p[j-2]` whenever `p[j-1] == '*'`. **Approach:** Build `dp[i][j]` = "does `s[:i]` match `p[:j]`?" Base case: an empty pattern only matches an empty string, but patterns like `a*`, `a*b*` can also match an empty string, so `dp[0][j]` needs its own rule. For each cell, branch on whether the current pattern character is `*`. ```python def is_match(s: str, p: str) -> bool: m, n = len(s), len(p) dp = [[False] * (n + 1) for _ in range(m + 1)] dp[0][0] = True # empty string vs patterns like a*, a*b*c* etc. for j in range(1, n + 1): if p[j - 1] == '*': dp[0][j] = dp[0][j - 2] for i in range(1, m + 1): for j in range(1, n + 1): if p[j - 1] == '.' or p[j - 1] == s[i - 1]: dp[i][j] = dp[i - 1][j - 1] elif p[j - 1] == '*': # zero occurrences of p[j-2] dp[i][j] = dp[i][j - 2] # one more occurrence of p[j-2], if it can match s[i-1] prev_char = p[j - 2] if prev_char == '.' or prev_char == s[i - 1]: dp[i][j] = dp[i][j] or dp[i - 1][j] else: dp[i][j] = False return dp[m][n] ``` ```javascript + function isMatch(s, p) { const m = s.length, n = p.length; const dp = Array.from({ length: m + 1 }, () => new Array(n + 1).fill(false)); dp[0][0] = true; // empty string vs patterns like a*, a*b*c* etc. for (let j = 1; j <= n; j++) { if (p[j - 1] === '*') { dp[0][j] = dp[0][j - 2]; } } for (let i = 1; i <= m; i++) { for (let j = 1; j <= n; j++) { if (p[j - 1] === '.' || p[j - 1] === s[i - 1]) { dp[i][j] = dp[i - 1][j - 1]; } else if (p[j - 1] === '*') { // zero occurrences of p[j-2] dp[i][j] = dp[i][j - 2]; // one more occurrence of p[j-2], if it can match s[i-1] const prevChar = p[j - 2]; if (prevChar === '.' || prevChar === s[i - 1]) { dp[i][j] = dp[i][j] || dp[i - 1][j]; } } else { dp[i][j] = false; } } } return dp[m][n]; } ``` ```java + public class Main { public static boolean isMatch(String s, String p) { int m = s.length(), n = p.length(); boolean[][] dp = new boolean[m + 1][n + 1]; dp[0][0] = true; // empty string vs patterns like a*, a*b*c* etc. for (int j = 1; j <= n; j++) { if (p.charAt(j - 1) == '*') { dp[0][j] = dp[0][j - 2]; } } for (int i = 1; i <= m; i++) { for (int j = 1; j <= n; j++) { char pc = p.charAt(j - 1); if (pc == '.' || pc == s.charAt(i - 1)) { dp[i][j] = dp[i - 1][j - 1]; } else if (pc == '*') { // zero occurrences of p[j-2] dp[i][j] = dp[i][j - 2]; // one more occurrence of p[j-2], if it can match s[i-1] char prevChar = p.charAt(j - 2); if (prevChar == '.' || prevChar == s.charAt(i - 1)) { dp[i][j] = dp[i][j] || dp[i - 1][j]; } } else { dp[i][j] = false; } } } return dp[m][n]; } public static void main(String[] args) { System.out.println(isMatch("aa", "a*")); System.out.println(isMatch("mississippi", "mis*is*p*.")); } } ``` **Complexity:** O(m*n) time, O(m*n) space (rollable to O(n), see Space optimization above). **Common mistakes:** forgetting the `dp[0][j]` base case for patterns that can match an empty string; indexing `p[j-2]` when `j < 2` (safe here because a valid regex never starts with `*`, but always double-check input assumptions in an interview); confusing "zero occurrences" (`dp[i][j-2]`) with "one occurrence" (`dp[i-1][j]`), when both actually need to be considered together. > **Remember:** `*` in regex looks backward at the pattern character before it. Both "use it zero times" and "use it one more time" have to be checked. ### Wildcard Matching [LeetCode 44 · Wildcard Matching](https://leetcode.com/problems/wildcard-matching/) · DP · Hard **Intuition:** `?` matches exactly one character, `*` matches any sequence, including empty, of characters. This is simpler than regex, because `*` doesn't look back at a preceding element here: it's a free-standing wildcard. **Approach:** `dp[i][j]` = "does `s[:i]` match `p[:j]`?" When `p[j-1] == '*'`, it can either match zero characters of `s` (`dp[i][j-1]`) or consume one more character of `s` and stay matched against the same `*` (`dp[i-1][j]`). This is the O(m*n) time, O(n) space version. ```python def is_match(s: str, p: str) -> bool: m, n = len(s), len(p) # prev = dp[i-1][*], curr = dp[i][*] prev = [False] * (n + 1) prev[0] = True for j in range(1, n + 1): prev[j] = prev[j - 1] and p[j - 1] == '*' for i in range(1, m + 1): curr = [False] * (n + 1) curr[0] = False # non-empty s can't match empty p for j in range(1, n + 1): if p[j - 1] == '*': curr[j] = curr[j - 1] or prev[j] elif p[j - 1] == '?' or p[j - 1] == s[i - 1]: curr[j] = prev[j - 1] else: curr[j] = False prev = curr return prev[n] ``` ```javascript + function isMatch(s, p) { const m = s.length, n = p.length; // prev = dp[i-1][*], curr = dp[i][*] let prev = new Array(n + 1).fill(false); prev[0] = true; for (let j = 1; j <= n; j++) { prev[j] = prev[j - 1] && p[j - 1] === '*'; } for (let i = 1; i <= m; i++) { const curr = new Array(n + 1).fill(false); curr[0] = false; // non-empty s can't match empty p for (let j = 1; j <= n; j++) { if (p[j - 1] === '*') { curr[j] = curr[j - 1] || prev[j]; } else if (p[j - 1] === '?' || p[j - 1] === s[i - 1]) { curr[j] = prev[j - 1]; } else { curr[j] = false; } } prev = curr; } return prev[n]; } ``` ```java + public class Main { public static boolean isMatch(String s, String p) { int m = s.length(), n = p.length(); // prev = dp[i-1][*], curr = dp[i][*] boolean[] prev = new boolean[n + 1]; prev[0] = true; for (int j = 1; j <= n; j++) { prev[j] = prev[j - 1] && p.charAt(j - 1) == '*'; } for (int i = 1; i <= m; i++) { boolean[] curr = new boolean[n + 1]; curr[0] = false; // non-empty s can't match empty p for (int j = 1; j <= n; j++) { char pc = p.charAt(j - 1); if (pc == '*') { curr[j] = curr[j - 1] || prev[j]; } else if (pc == '?' || pc == s.charAt(i - 1)) { curr[j] = prev[j - 1]; } else { curr[j] = false; } } prev = curr; } return prev[n]; } public static void main(String[] args) { System.out.println(isMatch("adceb", "*a*b")); System.out.println(isMatch("acdcb", "a*c?b")); } } ``` **Complexity:** O(m*n) time, O(n) space. **Common mistakes:** mixing up this `*`'s "zero or more characters" meaning with regex's "zero or more of the preceding element" from the problem above. They look similar, but the transition differs, since wildcard's `*` never looks back. Also, forgetting to reset `curr[0] = False` each row when rolling the array; and assuming consecutive `*` characters need special handling, when the DP already collapses them to the same matching power as one `*`, with no pre-processing needed. > **Remember:** wildcard's `*` never looks back at a specific character, it's just "any sequence." That's the one difference from regex's `*` to keep straight. ### Minimum Path Sum [LeetCode 64 · Minimum Path Sum](https://leetcode.com/problems/minimum-path-sum/) · DP · 2D **Intuition:** Only two moves are allowed, right or down, so the minimum cost to reach `(i, j)` is that cell's own cost plus the cheaper of "coming from above" or "coming from the left." **Approach:** In-place DP directly on the input grid skips extra space entirely. It's the state-reduction idea applied aggressively: you don't even need a separate table, because each cell's dependency (`up`, `left`) is already computed and won't be needed again. ```python def min_path_sum(grid: list[list[int]]) -> int: m, n = len(grid), len(grid[0]) for i in range(m): for j in range(n): if i == 0 and j == 0: continue elif i == 0: grid[i][j] += grid[i][j - 1] elif j == 0: grid[i][j] += grid[i - 1][j] else: grid[i][j] += min(grid[i - 1][j], grid[i][j - 1]) return grid[m - 1][n - 1] ``` ```javascript + function minPathSum(grid) { const m = grid.length, n = grid[0].length; for (let i = 0; i < m; i++) { for (let j = 0; j < n; j++) { if (i === 0 && j === 0) { continue; } else if (i === 0) { grid[i][j] += grid[i][j - 1]; } else if (j === 0) { grid[i][j] += grid[i - 1][j]; } else { grid[i][j] += Math.min(grid[i - 1][j], grid[i][j - 1]); } } } return grid[m - 1][n - 1]; } ``` ```java + public class Main { public static int minPathSum(int[][] grid) { int m = grid.length, n = grid[0].length; for (int i = 0; i < m; i++) { for (int j = 0; j < n; j++) { if (i == 0 && j == 0) { continue; } else if (i == 0) { grid[i][j] += grid[i][j - 1]; } else if (j == 0) { grid[i][j] += grid[i - 1][j]; } else { grid[i][j] += Math.min(grid[i - 1][j], grid[i][j - 1]); } } } return grid[m - 1][n - 1]; } public static void main(String[] args) { int[][] grid = { {1, 3, 1}, {1, 5, 1}, {4, 2, 1} }; System.out.println(minPathSum(grid)); } } ``` **Complexity:** O(m*n) time, O(1) extra space (mutates the input in place, so mention that trade-off out loud in an interview, since it isn't always acceptable). **Common mistakes:** forgetting the first row/column special cases; they only have one possible direction of approach, not two. Also, mutating the grid when the interviewer expects the input preserved: ask first, or copy the grid if unsure. > **Remember:** the first row and column only have one way in. Everywhere else, take the cheaper of "from above" or "from the left." ### Longest Palindromic Substring [LeetCode 5 · Longest Palindromic Substring](https://leetcode.com/problems/longest-palindromic-substring/) · DP **Intuition:** A substring `s[i:j]` is a palindrome if `s[i] == s[j-1]` and the inner substring `s[i+1:j-1]` is also a palindrome. That's a valid DP, but the expand-around-center technique gets the same O(n²) time with O(1) space, and it's the version to lead with in an interview. **Approach (expand around center):** Every palindrome has a center, either a single character (odd length) or a gap between two characters (even length). Try all `2n - 1` centers and expand outward while characters keep matching. ```python def longest_palindrome(s: str) -> str: if not s: return "" def expand(left: int, right: int) -> tuple[int, int]: while left >= 0 and right < len(s) and s[left] == s[right]: left -= 1 right += 1 # left/right have overstepped by one on the last failed check return left + 1, right - 1 start, end = 0, 0 for center in range(len(s)): l1, r1 = expand(center, center) # odd length l2, r2 = expand(center, center + 1) # even length if r1 - l1 > end - start: start, end = l1, r1 if r2 - l2 > end - start: start, end = l2, r2 return s[start:end + 1] ``` ```javascript + function longestPalindrome(s) { if (!s) return ""; const expand = (left, right) => { while (left >= 0 && right < s.length && s[left] === s[right]) { left -= 1; right += 1; } // left/right have overstepped by one on the last failed check return [left + 1, right - 1]; }; let [start, end] = [0, 0]; for (let center = 0; center < s.length; center++) { const [l1, r1] = expand(center, center); // odd length const [l2, r2] = expand(center, center + 1); // even length if (r1 - l1 > end - start) [start, end] = [l1, r1]; if (r2 - l2 > end - start) [start, end] = [l2, r2]; } return s.slice(start, end + 1); } ``` ```java + public class Main { public static String longestPalindrome(String s) { if (s == null || s.isEmpty()) return ""; int[] best = {0, 0}; for (int center = 0; center < s.length(); center++) { int[] odd = expand(s, center, center); // odd length int[] even = expand(s, center, center + 1); // even length if (odd[1] - odd[0] > best[1] - best[0]) best = odd; if (even[1] - even[0] > best[1] - best[0]) best = even; } return s.substring(best[0], best[1] + 1); } private static int[] expand(String s, int left, int right) { while (left >= 0 && right < s.length() && s.charAt(left) == s.charAt(right)) { left -= 1; right += 1; } // left/right have overstepped by one on the last failed check return new int[] { left + 1, right - 1 }; } public static void main(String[] args) { System.out.println(longestPalindrome("babad")); } } ``` **Complexity:** O(n²) time, O(1) space. The classic DP table version is O(n²) time and O(n²) space, worth knowing both so you can explain the trade-off if asked. **Common mistakes:** forgetting the even-length center case (a gap, not a character), which silently misses palindromes like `"abba"`. Also, an off-by-one in the return of `expand`: the loop exits one step past the actual palindrome boundary, so you must correct by 1 in each direction. > **Remember:** every palindrome has a center, either on a character or in the gap between two. Check both kinds of center at every position. The two `*` semantics in this lesson are easy to blur together once you've seen both: regex's `*` looks back at the preceding pattern element, wildcard's `*` is free-standing and never looks back. If you catch yourself writing the same transition for both problems, stop and re-derive it from the plain-English description first. 3f:T4bd5,Picture trying on every combination of shirt and pants in your closet, but the moment you notice a shirt clashes with a color of pants, you skip trying it with any other pants and move straight to the next shirt. That's backtracking: explore a choice, and the moment it stops making sense, undo it and try the next one instead of blindly finishing a doomed combination. It's how you list every valid configuration of something (subsets, permutations, combinations) without brute-forcing every possibility blindly. It's one of the highest-frequency interview patterns, because the code shape stays nearly identical across problems, and interviewers use small twists, like duplicates, reusing an item, or a fixed length, to check whether you actually understand the recursion tree or just memorized one template. ## Choice, constraints, goal framework Every backtracking problem breaks down into three questions: 1. **Choice**: at this point in the recursion, what options can I pick from next? 2. **Constraints**: which of those options are actually valid given what I've already picked? 3. **Goal**: when do I have a complete, valid answer worth recording? ```python def backtrack(path, choices): if is_goal(path): # goal check record(path) return for choice in choices: # choice enumeration if not is_valid(choice, path): # constraint check continue path.append(choice) backtrack(path, next_choices(choices, choice)) path.pop() # undo — this is the "back" in backtracking ``` The `path.pop()` right after the recursive call is the entire idea in one line: try a choice, explore everything downstream of it, then undo it so the next sibling choice starts from a clean slate. Forgetting that undo is the single most common backtracking bug, and it silently corrupts every branch that comes after it. > **Remember:** every backtracking loop asks the same three questions: what can I pick, is it valid, am I done? And it always undoes a choice before trying the next one. ```knowledge-check { "questions": [ { "id": "dsa-backtracking-framework-q1", "type": "mcq", "prompt": "What does the path.pop() line right after the recursive call actually do in a backtracking template?", "options": [ {"id": "a", "text": "Undoes the current choice so the next sibling option starts from a clean slate, instead of carrying over a choice that's no longer active"}, {"id": "b", "text": "Removes the goal check from the recursion"}, {"id": "c", "text": "Sorts the path so far"}, {"id": "d", "text": "Stops the recursion permanently"} ], "correct": "a", "explanation": "Without the undo, every sibling branch after the first would still see the earlier choice sitting in path, corrupting every result after it." } ] } ``` ## Pruning optimization Backtracking without pruning is just exhaustive search with extra bookkeeping. Pruning means noticing that a partial path can *never* lead to a valid goal, and abandoning it right away instead of recursing all the way down to find that out later. ```python # Without pruning: recurse fully, check validity only at leaves — wasteful # With pruning: check validity at every step, bail out early def backtrack(path, remaining_sum, candidates, start): if remaining_sum < 0: # prune: overshot, no point continuing return if remaining_sum == 0: record(path) return for i in range(start, len(candidates)): if candidates[i] > remaining_sum: # prune: sorted array, rest are bigger too break path.append(candidates[i]) backtrack(path, remaining_sum - candidates[i], candidates, i) path.pop() ``` Sorting the input first often makes pruning possible where it otherwise wouldn't be, like the `break` above: once one candidate is too large, every candidate after it is too, since the array is sorted. That turns a correctness check, skipping invalid branches, into a real performance win. > **Remember:** don't wait until a leaf to discover a branch was hopeless. Check as early as possible and bail out before wasting more recursion on it. ```knowledge-check { "questions": [ { "id": "dsa-backtracking-pruning-q1", "type": "mcq", "prompt": "Why does sorting the candidates array first help pruning in problems like Combination Sum?", "options": [ {"id": "a", "text": "Once one candidate is too large for the remaining sum, every candidate after it (since they're sorted) is too large as well, so the loop can break early"}, {"id": "b", "text": "Sorting makes the recursion depth shallower"}, {"id": "c", "text": "Sorting removes the need for a goal check"}, {"id": "d", "text": "Sorting is only needed for permutation problems, not for combinations"} ], "correct": "a", "explanation": "With a sorted array, the moment a candidate exceeds the remaining budget, every later candidate does too, so the loop can break instead of continuing to check each one." } ] } ``` ## Combination vs permutation This distinction decides where your loop starts each recursive call, and it's the detail interviewers watch closely. - **Combinations / subsets** (order doesn't matter): each recursive call starts its loop from `start` (or `start + 1`), never revisiting earlier indices. `[1,2]` and `[2,1]` count as the same combination, so you never generate both. - **Permutations** (order matters): each recursive call loops over *all* indices not yet used, tracked with a `used` set or by swapping. `[1,2]` and `[2,1]` are different permutations, so both must be generated. ```python # Combinations: loop starts at `start`, moves forward only for i in range(start, len(nums)): ... backtrack(i + 1) # next call starts after i # Permutations: loop scans everything, skip what's used for i in range(len(nums)): if used[i]: continue ... backtrack() # next call scans from 0 again ``` Mixing these up is the classic bug. A `start` index used for a permutation problem silently produces only results in sorted order; a full scan used for a combination problem produces duplicates. > **Remember:** combinations move the starting point forward and never look back. Permutations scan everything every time and just skip what's already used. ```knowledge-check { "questions": [ { "id": "dsa-backtracking-combo-vs-perm-q1", "type": "mcq", "prompt": "What bug happens if you use a `start` index (the combination pattern) inside a permutation problem?", "options": [ {"id": "a", "text": "It silently produces only one ordering per set of elements instead of all n! orderings"}, {"id": "b", "text": "It crashes with an index out of range error"}, {"id": "c", "text": "It produces every permutation, just in a different order than expected"}, {"id": "d", "text": "Nothing changes; start-based and used-based loops are interchangeable"} ], "correct": "a", "explanation": "A start index only ever moves forward, so it can never revisit an earlier index to place it in a different position, which is exactly what generating distinct orderings requires." } ] } ``` ### Subsets [LeetCode 78 · Subsets](https://leetcode.com/problems/subsets/) · Backtracking · Generate all subsets **Intuition:** Every element is either "in" or "out" of a given subset. Backtracking naturally lists all of them by recording the current path at every recursive call, not just at the leaves, since every prefix is itself a valid subset. **Approach:** Standard combination-style loop starting at `start`, recording `path` at every node of the recursion tree, not only at the base case. ```python def subsets(nums: list[int]) -> list[list[int]]: result = [] path = [] def backtrack(start: int) -> None: result.append(path[:]) # every node is a valid subset for i in range(start, len(nums)): path.append(nums[i]) backtrack(i + 1) path.pop() backtrack(0) return result ``` ```javascript + function subsets(nums) { const result = []; const path = []; function backtrack(start) { result.push([...path]); // every node is a valid subset for (let i = start; i < nums.length; i++) { path.push(nums[i]); backtrack(i + 1); path.pop(); } } backtrack(0); return result; } ``` ```java + import java.util.*; public class Main { public static List> subsets(int[] nums) { List> result = new ArrayList<>(); Deque path = new ArrayDeque<>(); backtrack(nums, 0, path, result); return result; } private static void backtrack(int[] nums, int start, Deque path, List> result) { result.add(new ArrayList<>(path)); // every node is a valid subset for (int i = start; i < nums.length; i++) { path.addLast(nums[i]); backtrack(nums, i + 1, path, result); path.removeLast(); } } public static void main(String[] args) { System.out.println(subsets(new int[] {1, 2, 3})); } } ``` **Complexity:** O(n * 2^n) time (2^n subsets, O(n) to copy each), O(n) recursion depth excluding the output. **Common mistakes:** appending `path` directly instead of `path[:]`, which stores a reference that later gets mutated and corrupts every subset already recorded; forgetting that every recursive call, not only the leaves, produces a valid answer here. > **Remember:** Subsets records an answer at every single node, not just at the leaves, because every prefix is already a valid subset. ### Subsets II [LeetCode 90 · Subsets II](https://leetcode.com/problems/subsets-ii/) · Backtracking · Handle duplicates **Intuition:** The input may have duplicate values. Sort first, then at each recursion level, skip a candidate if it's equal to the previous candidate *at that same level*, not globally. That previous one already covered every subset this one would produce. **Approach:** Sort `nums`. In the loop, skip `nums[i]` when `i > start and nums[i] == nums[i-1]`. ```python def subsets_with_dup(nums: list[int]) -> list[list[int]]: nums.sort() result = [] path = [] def backtrack(start: int) -> None: result.append(path[:]) for i in range(start, len(nums)): if i > start and nums[i] == nums[i - 1]: continue # skip duplicate at this recursion level path.append(nums[i]) backtrack(i + 1) path.pop() backtrack(0) return result ``` ```javascript + function subsetsWithDup(nums) { nums = [...nums].sort((a, b) => a - b); const result = []; const path = []; function backtrack(start) { result.push([...path]); for (let i = start; i < nums.length; i++) { if (i > start && nums[i] === nums[i - 1]) continue; // skip duplicate at this level path.push(nums[i]); backtrack(i + 1); path.pop(); } } backtrack(0); return result; } ``` ```java + import java.util.*; public class Main { public static List> subsetsWithDup(int[] nums) { Arrays.sort(nums); List> result = new ArrayList<>(); Deque path = new ArrayDeque<>(); backtrack(nums, 0, path, result); return result; } private static void backtrack(int[] nums, int start, Deque path, List> result) { result.add(new ArrayList<>(path)); for (int i = start; i < nums.length; i++) { if (i > start && nums[i] == nums[i - 1]) continue; // skip duplicate at this level path.addLast(nums[i]); backtrack(nums, i + 1, path, result); path.removeLast(); } } public static void main(String[] args) { System.out.println(subsetsWithDup(new int[] {1, 2, 2})); } } ``` **Complexity:** O(n * 2^n) time worst case, O(n) recursion depth. **Common mistakes:** skipping duplicates with a global `seen` set instead of the `i > start` same-level check. A global set wrongly blocks valid subsets that reuse a value at a *different* branch of the tree. Also, forgetting to sort first, which the same-level dedup depends on completely. > **Remember:** skip a duplicate only if it's a repeat at the SAME level as the one right before it, not a repeat anywhere in the whole array. ### Combination Sum [LeetCode 39 · Combination Sum](https://leetcode.com/problems/combination-sum/) · Backtracking · Unbounded knapsack **Intuition:** The same number can be reused as many times as needed, so the recursive call passes `i` (not `i + 1`), to allow re-picking the current candidate. **Approach:** Sort candidates for pruning. Track the `remaining` target, subtract as you go, prune when `remaining < 0`, record when `remaining == 0`. ```python def combination_sum(candidates: list[int], target: int) -> list[list[int]]: candidates.sort() result = [] path = [] def backtrack(start: int, remaining: int) -> None: if remaining == 0: result.append(path[:]) return for i in range(start, len(candidates)): if candidates[i] > remaining: break # sorted, so nothing further can work either path.append(candidates[i]) backtrack(i, remaining - candidates[i]) # i, not i+1: reuse allowed path.pop() backtrack(0, target) return result ``` ```javascript + function combinationSum(candidates, target) { candidates = [...candidates].sort((a, b) => a - b); const result = []; const path = []; function backtrack(start, remaining) { if (remaining === 0) { result.push([...path]); return; } for (let i = start; i < candidates.length; i++) { if (candidates[i] > remaining) break; // sorted, so nothing further can work either path.push(candidates[i]); backtrack(i, remaining - candidates[i]); // i, not i+1: reuse allowed path.pop(); } } backtrack(0, target); return result; } ``` ```java + import java.util.*; public class Main { public static List> combinationSum(int[] candidates, int target) { Arrays.sort(candidates); List> result = new ArrayList<>(); Deque path = new ArrayDeque<>(); backtrack(candidates, target, 0, path, result); return result; } private static void backtrack(int[] candidates, int remaining, int start, Deque path, List> result) { if (remaining == 0) { result.add(new ArrayList<>(path)); return; } for (int i = start; i < candidates.length; i++) { if (candidates[i] > remaining) break; // sorted, so nothing further can work either path.addLast(candidates[i]); backtrack(candidates, remaining - candidates[i], i, path, result); // i, not i+1: reuse allowed path.removeLast(); } } public static void main(String[] args) { System.out.println(combinationSum(new int[] {2, 3, 6, 7}, 7)); } } ``` **Complexity:** O(n^(target/min_candidate)) time worst case (exponential, bounded by the target), O(target / min_candidate) recursion depth. **Common mistakes:** passing `i + 1` instead of `i`, the classic bug that silently turns "unbounded reuse" into "each number used at most once," which is actually a different problem (Combination Sum II). Also, forgetting to sort before relying on `break` as a pruning strategy. > **Remember:** passing `i` instead of `i + 1` into the recursive call is what allows reusing the same number. That single character is the whole difference from "use once." ### Permutations [LeetCode 46 · Permutations](https://leetcode.com/problems/permutations/) · Backtracking · Generate permutations **Intuition:** Unlike combinations, order matters here, and every index can appear in every position, so the loop scans the full array each time, skipping only what's already placed in the current path. **Approach:** Track a `used` boolean array (or set) instead of a `start` index, since permutations don't have an "already passed this index" idea; they have "already placed this value." ```python def permute(nums: list[int]) -> list[list[int]]: result = [] path = [] used = [False] * len(nums) def backtrack() -> None: if len(path) == len(nums): result.append(path[:]) return for i in range(len(nums)): if used[i]: continue used[i] = True path.append(nums[i]) backtrack() path.pop() used[i] = False backtrack() return result ``` ```javascript + function permute(nums) { const result = []; const path = []; const used = new Array(nums.length).fill(false); function backtrack() { if (path.length === nums.length) { result.push([...path]); return; } for (let i = 0; i < nums.length; i++) { if (used[i]) continue; used[i] = true; path.push(nums[i]); backtrack(); path.pop(); used[i] = false; } } backtrack(); return result; } ``` ```java + import java.util.*; public class Main { public static List> permute(int[] nums) { List> result = new ArrayList<>(); Deque path = new ArrayDeque<>(); boolean[] used = new boolean[nums.length]; backtrack(nums, used, path, result); return result; } private static void backtrack(int[] nums, boolean[] used, Deque path, List> result) { if (path.size() == nums.length) { result.add(new ArrayList<>(path)); return; } for (int i = 0; i < nums.length; i++) { if (used[i]) continue; used[i] = true; path.addLast(nums[i]); backtrack(nums, used, path, result); path.removeLast(); used[i] = false; } } public static void main(String[] args) { System.out.println(permute(new int[] {1, 2, 3})); } } ``` **Complexity:** O(n * n!) time (n! permutations, O(n) to copy each), O(n) space for `used` plus recursion depth. **Common mistakes:** using a `start` index like a combination problem, which produces only 1 ordering instead of n!. Also, forgetting to reset `used[i] = False` on backtrack, which corrupts sibling branches. > **Remember:** permutations need a `used` set, not a `start` index, because any leftover value can go in any leftover position. Notice where each problem records its answer follows directly from its own goal condition: Subsets records at every node because every prefix is valid, Combination Sum records only when `remaining == 0`, and Permutations records only once `path` reaches full length. Get the goal condition right, and the recording point falls out for free. 40:T6cdb,Think about seating guests at a wedding: each guest has a few people they can't sit next to, and every seat you fill changes which seats are still safe for everyone else. That's a constraint satisfaction problem, and it's the Backtracking lesson's template applied to problems where checking "is this choice valid" is itself the hard part. N-Queens needs fast conflict detection across three directions at once, Sudoku-style validation shows up in "design a checker" interviews, and IP address restoration tests whether you can bound a search with domain-specific rules instead of generic pruning. These are the backtracking problems that separate "knows the template" from "can adapt it." ## Constraint satisfaction A constraint satisfaction problem (CSP) is a backtracking problem where "is this choice valid" depends on relationships between *multiple* previous choices, not just the most recent one. N-Queens is the classic example: placing a queen at `(row, col)` is invalid if any previously placed queen shares its column, or either diagonal. The trick to making CSP backtracking fast is keeping validity-check information updated as you go, instead of re-scanning the whole board on every placement. A naive N-Queens checks every previously placed queen: O(n) per placement, O(n²) per row. A good one keeps three sets, columns, `row - col` diagonals, and `row + col` diagonals, for O(1) conflict checks. ```python cols = set() diag1 = set() # row - col is constant along a "/" diagonal diag2 = set() # row + col is constant along a "\" diagonal def is_safe(row: int, col: int) -> bool: return col not in cols and (row - col) not in diag1 and (row + col) not in diag2 ``` ```javascript + const cols = new Set(); const diag1 = new Set(); // row - col is constant along a "/" diagonal const diag2 = new Set(); // row + col is constant along a "\" diagonal function isSafe(row, col) { return !cols.has(col) && !diag1.has(row - col) && !diag2.has(row + col); } ``` ```java + import java.util.*; public class Main { static Set cols = new HashSet<>(); static Set diag1 = new HashSet<>(); // row - col is constant along a "/" diagonal static Set diag2 = new HashSet<>(); // row + col is constant along a "\" diagonal public static boolean isSafe(int row, int col) { return !cols.contains(col) && !diag1.contains(row - col) && !diag2.contains(row + col); } public static void main(String[] args) { System.out.println(isSafe(0, 0)); cols.add(0); diag1.add(0 - 0); diag2.add(0 + 0); System.out.println(isSafe(1, 1)); // false: same diagonal as (0,0) } } ``` Why `row - col` and `row + col`: every cell on the same "/" diagonal shares the same `row - col` value; every cell on the same "\" diagonal shares the same `row + col` value. That one fact turns an O(n) check into O(1). Know it cold; it shows up in every N-Queens variant. > **Remember:** a constraint satisfaction problem checks validity against everything placed so far, not just the last move. Precompute what you can into sets so each check stays O(1). ```knowledge-check { "questions": [ { "id": "dsa-backtracking-adv-csp-q1", "type": "mcq", "prompt": "Why do row - col and row + col make useful set keys for N-Queens diagonal checks?", "options": [ {"id": "a", "text": "Every cell on the same \"/\" diagonal shares the same row - col value, and every cell on the same \"\\\" diagonal shares the same row + col value"}, {"id": "b", "text": "They're the only way to represent a 2D coordinate as a single number"}, {"id": "c", "text": "row - col and row + col are always equal to each other"}, {"id": "d", "text": "They only work when the board is exactly 8x8"} ], "correct": "a", "explanation": "Each diagonal is a line where one of those two expressions stays constant, so tracking them in a set gives an O(1) conflict check instead of scanning every placed queen." } ] } ``` ## N-Queens pattern The pattern: place one queen per row, which rules out row conflicts by construction, so you never need to check rows at all, try every column in that row, and recurse to the next row only if the placement is safe. Backtrack (remove the queen, unmark the sets) once a branch is exhausted. ```python def solve(row: int) -> None: if row == n: record_solution() return for col in range(n): if not is_safe(row, col): continue place(row, col) solve(row + 1) remove(row, col) ``` This "one choice per slot" framing is worth generalizing: whenever a problem has a natural "one choice per slot, slots don't depend on each other's identity" structure, iterate over slots in the outer loop and choices in the inner loop. It collapses a 2D search space (which row, which column) into a 1D one (which column, since the row is implied by recursion depth). > **Remember:** placing one item per row (or per slot) for free rules out a whole category of conflicts before you even start checking. ```knowledge-check { "questions": [ { "id": "dsa-backtracking-adv-nqueens-q1", "type": "mcq", "prompt": "Why does the \"one queen per row\" placement strategy eliminate row conflicts entirely?", "options": [ {"id": "a", "text": "Since exactly one queen is placed per row by construction, two queens can never share a row, so no row check is ever needed"}, {"id": "b", "text": "Because rows are checked first before columns"}, {"id": "c", "text": "Because the board is always square"}, {"id": "d", "text": "It doesn't; row conflicts still need to be checked separately"} ], "correct": "a", "explanation": "The recursion advances row by row and places exactly one queen per row, so by the structure of the algorithm itself, no two queens ever land on the same row." } ] } ``` ## Sudoku solving Sudoku is N-Queens's constraint-satisfaction cousin with more rules: each number must be unique in its row, column, *and* 3x3 box. The backtracking shape is identical, try a value, recurse, undo, but the validity check now needs three conditions at once instead of one. ```python def is_valid(board, row: int, col: int, num: str) -> bool: for i in range(9): if board[row][i] == num or board[i][col] == num: return False box_row, box_col = 3 * (row // 3), 3 * (col // 3) for r in range(box_row, box_row + 3): for c in range(box_col, box_col + 3): if board[r][c] == num: return False return True def solve_sudoku(board: list[list[str]]) -> bool: for row in range(9): for col in range(9): if board[row][col] != '.': continue for num in '123456789': if is_valid(board, row, col, num): board[row][col] = num if solve_sudoku(board): return True board[row][col] = '.' # undo return False # no valid number for this cell — dead end return True # every cell filled ``` ```javascript + function isValid(board, row, col, num) { for (let i = 0; i < 9; i++) { if (board[row][i] === num || board[i][col] === num) return false; } const boxRow = 3 * Math.floor(row / 3); const boxCol = 3 * Math.floor(col / 3); for (let r = boxRow; r < boxRow + 3; r++) { for (let c = boxCol; c < boxCol + 3; c++) { if (board[r][c] === num) return false; } } return true; } function solveSudoku(board) { for (let row = 0; row < 9; row++) { for (let col = 0; col < 9; col++) { if (board[row][col] !== '.') continue; for (const num of '123456789') { if (isValid(board, row, col, num)) { board[row][col] = num; if (solveSudoku(board)) return true; board[row][col] = '.'; // undo } } return false; // no valid number for this cell — dead end } } return true; // every cell filled } ``` ```java + public class Main { public static boolean isValid(char[][] board, int row, int col, char num) { for (int i = 0; i < 9; i++) { if (board[row][i] == num || board[i][col] == num) return false; } int boxRow = 3 * (row / 3); int boxCol = 3 * (col / 3); for (int r = boxRow; r < boxRow + 3; r++) { for (int c = boxCol; c < boxCol + 3; c++) { if (board[r][c] == num) return false; } } return true; } public static boolean solveSudoku(char[][] board) { for (int row = 0; row < 9; row++) { for (int col = 0; col < 9; col++) { if (board[row][col] != '.') continue; for (char num = '1'; num <= '9'; num++) { if (isValid(board, row, col, num)) { board[row][col] = num; if (solveSudoku(board)) return true; board[row][col] = '.'; // undo } } return false; // no valid number for this cell — dead end } } return true; // every cell filled } public static void main(String[] args) { char[][] board = { {'5','3','.','.','7','.','.','.','.'}, {'6','.','.','1','9','5','.','.','.'}, {'.','9','8','.','.','.','.','6','.'}, {'8','.','.','.','6','.','.','.','3'}, {'4','.','.','8','.','3','.','.','1'}, {'7','.','.','.','2','.','.','.','6'}, {'.','6','.','.','.','.','2','8','.'}, {'.','.','.','4','1','9','.','.','5'}, {'.','.','.','.','8','.','.','7','9'} }; System.out.println(solveSudoku(board)); } } ``` The same lesson as N-Queens applies here: precomputing row/column/box "used number" sets instead of scanning turns each validity check into a true O(1) set lookup, instead of scanning 27 cells with fixed but wasteful constants. It's worth mentioning in an interview even if you don't have time to fully build it, since it shows you know exactly where the slow part would be. > **Remember:** Sudoku is the same "try, recurse, undo" shape as N-Queens, just with three simultaneous constraints (row, column, box) instead of one. ```knowledge-check { "questions": [ { "id": "dsa-backtracking-adv-sudoku-q1", "type": "mcq", "prompt": "What makes Sudoku's validity check harder than N-Queens', even though the backtracking shape is identical?", "options": [ {"id": "a", "text": "Sudoku needs three simultaneous checks (row, column, and 3x3 box), while N-Queens only needs column and two diagonals"}, {"id": "b", "text": "Sudoku doesn't use recursion at all"}, {"id": "c", "text": "Sudoku has no undo step"}, {"id": "d", "text": "Sudoku boards are always smaller than chessboards"} ], "correct": "a", "explanation": "Both problems try a value, recurse, and undo on failure. The difference is purely in how many conditions the validity check has to verify at once." } ] } ``` ### N-Queens [LeetCode 51 · N-Queens](https://leetcode.com/problems/n-queens/) · Backtracking · Hard **Intuition:** Place queens row by row; a row can never conflict with itself, so the only checks needed are column and both diagonals against previously placed queens. **Approach:** Track `cols`, `diag1` (`row - col`), `diag2` (`row + col`) as sets for O(1) conflict checks. Recurse row by row; when `row == n`, convert the current column choices into the board string format and record. ```python def solve_n_queens(n: int) -> list[list[str]]: result = [] col_positions = [0] * n # col_positions[row] = column of the queen in that row cols, diag1, diag2 = set(), set(), set() def backtrack(row: int) -> None: if row == n: board = [] for r in range(n): line = ['.'] * n line[col_positions[r]] = 'Q' board.append(''.join(line)) result.append(board) return for col in range(n): if col in cols or (row - col) in diag1 or (row + col) in diag2: continue cols.add(col); diag1.add(row - col); diag2.add(row + col) col_positions[row] = col backtrack(row + 1) cols.remove(col); diag1.remove(row - col); diag2.remove(row + col) backtrack(0) return result ``` ```javascript + function solveNQueens(n) { const result = []; const colPositions = new Array(n).fill(0); // colPositions[row] = column of the queen in that row const cols = new Set(), diag1 = new Set(), diag2 = new Set(); function backtrack(row) { if (row === n) { const board = []; for (let r = 0; r < n; r++) { const line = new Array(n).fill('.'); line[colPositions[r]] = 'Q'; board.push(line.join('')); } result.push(board); return; } for (let col = 0; col < n; col++) { if (cols.has(col) || diag1.has(row - col) || diag2.has(row + col)) continue; cols.add(col); diag1.add(row - col); diag2.add(row + col); colPositions[row] = col; backtrack(row + 1); cols.delete(col); diag1.delete(row - col); diag2.delete(row + col); } } backtrack(0); return result; } ``` ```java + import java.util.*; public class Main { public static List> solveNQueens(int n) { List> result = new ArrayList<>(); int[] colPositions = new int[n]; // colPositions[row] = column of the queen in that row Set cols = new HashSet<>(), diag1 = new HashSet<>(), diag2 = new HashSet<>(); backtrack(0, n, colPositions, cols, diag1, diag2, result); return result; } private static void backtrack(int row, int n, int[] colPositions, Set cols, Set diag1, Set diag2, List> result) { if (row == n) { List board = new ArrayList<>(); for (int r = 0; r < n; r++) { char[] line = new char[n]; Arrays.fill(line, '.'); line[colPositions[r]] = 'Q'; board.add(new String(line)); } result.add(board); return; } for (int col = 0; col < n; col++) { if (cols.contains(col) || diag1.contains(row - col) || diag2.contains(row + col)) continue; cols.add(col); diag1.add(row - col); diag2.add(row + col); colPositions[row] = col; backtrack(row + 1, n, colPositions, cols, diag1, diag2, result); cols.remove(col); diag1.remove(row - col); diag2.remove(row + col); } } public static void main(String[] args) { System.out.println(solveNQueens(4)); } } ``` **Complexity:** O(n!) time worst case, roughly, since each row has fewer valid choices than the last thanks to pruning. O(n) space for the sets and recursion depth, excluding the output. **Common mistakes:** using `row + col` and `row - col` backwards, or checking only one diagonal. Also, rebuilding the board string on every recursive call instead of only at `row == n`. And forgetting to remove from all three sets on backtrack, since a partial undo corrupts every sibling branch after the first. > **Remember:** track columns and both diagonals as sets, place one queen per row, and undo all three sets when you backtrack, not just one. ### N-Queens II [LeetCode 52 · N-Queens II](https://leetcode.com/problems/n-queens-ii/) · Backtracking · Count solutions **Intuition:** The exact same search as N-Queens I, but you only need a count, not the actual board layouts. Drop the board-reconstruction step entirely and just increment a counter at `row == n`. **Approach:** Same three-set conflict tracking; the recursion returns or accumulates an integer instead of appending to a results list. ```python def total_n_queens(n: int) -> int: cols, diag1, diag2 = set(), set(), set() def backtrack(row: int) -> int: if row == n: return 1 count = 0 for col in range(n): if col in cols or (row - col) in diag1 or (row + col) in diag2: continue cols.add(col); diag1.add(row - col); diag2.add(row + col) count += backtrack(row + 1) cols.remove(col); diag1.remove(row - col); diag2.remove(row + col) return count return backtrack(0) ``` ```javascript + function totalNQueens(n) { const cols = new Set(), diag1 = new Set(), diag2 = new Set(); function backtrack(row) { if (row === n) return 1; let count = 0; for (let col = 0; col < n; col++) { if (cols.has(col) || diag1.has(row - col) || diag2.has(row + col)) continue; cols.add(col); diag1.add(row - col); diag2.add(row + col); count += backtrack(row + 1); cols.delete(col); diag1.delete(row - col); diag2.delete(row + col); } return count; } return backtrack(0); } ``` ```java + import java.util.*; public class Main { public static int totalNQueens(int n) { Set cols = new HashSet<>(), diag1 = new HashSet<>(), diag2 = new HashSet<>(); return backtrack(0, n, cols, diag1, diag2); } private static int backtrack(int row, int n, Set cols, Set diag1, Set diag2) { if (row == n) return 1; int count = 0; for (int col = 0; col < n; col++) { if (cols.contains(col) || diag1.contains(row - col) || diag2.contains(row + col)) continue; cols.add(col); diag1.add(row - col); diag2.add(row + col); count += backtrack(row + 1, n, cols, diag1, diag2); cols.remove(col); diag1.remove(row - col); diag2.remove(row + col); } return count; } public static void main(String[] args) { System.out.println(totalNQueens(4)); } } ``` **Complexity:** Same as N-Queens I minus the O(n²) board-building cost per solution: O(n!) time worst case, O(n) space. **Common mistakes:** building the full board anyway out of habit, wasting work when only a count is needed. Noticing "I don't need the reconstruction step at all" is itself an interview signal worth stating out loud. > **Remember:** if the problem only asks "how many," don't build the thing you'd need to answer "which ones." ### Letter Combinations of a Phone Number [LeetCode 17 · Letter Combinations of a Phone Number](https://leetcode.com/problems/letter-combinations-of-a-phone-number/) · Backtracking **Intuition:** Each digit maps to a fixed set of letters, like an old T9 keypad. The output is the Cartesian product of every digit's letter set, and backtracking naturally lists a Cartesian product by looping over one dimension's options per recursion level. **Approach:** Recurse by digit index; at each level, loop over that digit's mapped letters, append, recurse to the next digit, undo. ```python def letter_combinations(digits: str) -> list[str]: if not digits: return [] mapping = { '2': 'abc', '3': 'def', '4': 'ghi', '5': 'jkl', '6': 'mno', '7': 'pqrs', '8': 'tuv', '9': 'wxyz', } result = [] path = [] def backtrack(index: int) -> None: if index == len(digits): result.append(''.join(path)) return for letter in mapping[digits[index]]: path.append(letter) backtrack(index + 1) path.pop() backtrack(0) return result ``` ```javascript + function letterCombinations(digits) { if (!digits) return []; const mapping = { '2': 'abc', '3': 'def', '4': 'ghi', '5': 'jkl', '6': 'mno', '7': 'pqrs', '8': 'tuv', '9': 'wxyz', }; const result = []; const path = []; function backtrack(index) { if (index === digits.length) { result.push(path.join('')); return; } for (const letter of mapping[digits[index]]) { path.push(letter); backtrack(index + 1); path.pop(); } } backtrack(0); return result; } ``` ```java + import java.util.*; public class Main { public static List letterCombinations(String digits) { List result = new ArrayList<>(); if (digits == null || digits.isEmpty()) return result; Map mapping = new HashMap<>(); mapping.put('2', "abc"); mapping.put('3', "def"); mapping.put('4', "ghi"); mapping.put('5', "jkl"); mapping.put('6', "mno"); mapping.put('7', "pqrs"); mapping.put('8', "tuv"); mapping.put('9', "wxyz"); backtrack(digits, 0, new StringBuilder(), mapping, result); return result; } private static void backtrack(String digits, int index, StringBuilder path, Map mapping, List result) { if (index == digits.length()) { result.add(path.toString()); return; } String letters = mapping.get(digits.charAt(index)); for (char letter : letters.toCharArray()) { path.append(letter); backtrack(digits, index + 1, path, mapping, result); path.deleteCharAt(path.length() - 1); } } public static void main(String[] args) { System.out.println(letterCombinations("23")); } } ``` **Complexity:** O(4^n * n) time worst case (digits 7 and 9 map to 4 letters, n is `len(digits)`), O(n) recursion depth. **Common mistakes:** trying to solve this iteratively with nested loops for a variable number of digits. It works but is far messier than recursion, since the digit count isn't fixed. Also, forgetting the `if not digits: return []` edge case, since the expected answer is an empty list, not `[""]`. > **Remember:** each digit contributes its own loop level. The whole output is the Cartesian product of all the digits' letter sets. ### Restore IP Addresses [LeetCode 93 · Restore IP Addresses](https://leetcode.com/problems/restore-ip-addresses/) · Backtracking · Validation **Intuition:** A valid IP address is 4 segments, each 1-3 digits, each in `[0, 255]`, with no leading zeros except the segment `"0"` itself. This is a partitioning problem: decide where to cut the string into 4 valid pieces. **Approach:** Recurse on (remaining string, segments placed so far). At each step, try consuming 1, 2, or 3 characters as the next segment, validate, recurse. Prune early: if the remaining length can't possibly fill the remaining segments, since each segment is at most 3 characters, bail out. ```python def restore_ip_addresses(s: str) -> list[str]: result = [] path = [] def is_valid_segment(seg: str) -> bool: if len(seg) > 1 and seg[0] == '0': # no leading zeros return False return 0 <= int(seg) <= 255 def backtrack(start: int) -> None: if len(path) == 4: if start == len(s): result.append('.'.join(path)) return remaining_segments = 4 - len(path) remaining_chars = len(s) - start # prune: not enough or too many characters left for remaining segments if not (remaining_segments <= remaining_chars <= remaining_segments * 3): return for length in range(1, 4): if start + length > len(s): break segment = s[start:start + length] if not is_valid_segment(segment): continue path.append(segment) backtrack(start + length) path.pop() backtrack(0) return result ``` ```javascript + function restoreIpAddresses(s) { const result = []; const path = []; function isValidSegment(seg) { if (seg.length > 1 && seg[0] === '0') return false; // no leading zeros return Number(seg) >= 0 && Number(seg) <= 255; } function backtrack(start) { if (path.length === 4) { if (start === s.length) result.push(path.join('.')); return; } const remainingSegments = 4 - path.length; const remainingChars = s.length - start; // prune: not enough or too many characters left for remaining segments if (remainingChars < remainingSegments || remainingChars > remainingSegments * 3) return; for (let length = 1; length <= 3; length++) { if (start + length > s.length) break; const segment = s.slice(start, start + length); if (!isValidSegment(segment)) continue; path.push(segment); backtrack(start + length); path.pop(); } } backtrack(0); return result; } ``` ```java + import java.util.*; public class Main { public static List restoreIpAddresses(String s) { List result = new ArrayList<>(); backtrack(s, 0, new ArrayDeque<>(), result); return result; } private static boolean isValidSegment(String seg) { if (seg.length() > 1 && seg.charAt(0) == '0') return false; // no leading zeros int value = Integer.parseInt(seg); return value >= 0 && value <= 255; } private static void backtrack(String s, int start, Deque path, List result) { if (path.size() == 4) { if (start == s.length()) result.add(String.join(".", path)); return; } int remainingSegments = 4 - path.size(); int remainingChars = s.length() - start; // prune: not enough or too many characters left for remaining segments if (remainingChars < remainingSegments || remainingChars > remainingSegments * 3) return; for (int length = 1; length <= 3; length++) { if (start + length > s.length()) break; String segment = s.substring(start, start + length); if (!isValidSegment(segment)) continue; path.addLast(segment); backtrack(s, start + length, path, result); path.removeLast(); } } public static void main(String[] args) { System.out.println(restoreIpAddresses("25525511135")); } } ``` **Complexity:** O(3^4) = O(1) effectively, since the search space is bounded by 4 segments times 3 possible lengths each, independent of input size beyond that small constant. O(1) extra space beyond output. **Common mistakes:** forgetting the leading-zero rule (`"01"` is invalid even though `1 <= 255`). Also, skipping the remaining-length pruning, which wastes time exploring segment lengths that could never reach exactly 4 segments by the end of the string. And an off-by-one when slicing `s[start:start+length]`. > **Remember:** four segments, each 1-3 characters, no leading zeros, each value 0-255. The pruning check before the loop keeps the search tiny. N-Queens, Sudoku, and Restore IP Addresses look unrelated at first glance, but they're the same backtracking template wearing different validity checks: precomputed sets for N-Queens, three simultaneous scans for Sudoku, segment-length arithmetic for IP addresses. Once you see the validity check as a swappable piece, adapting the template to a new constraint satisfaction problem is mostly a matter of asking what "invalid" means here, and how cheaply you can detect it. 41:T4b2c,Picture paying for a snack with the fewest coins possible: you probably grab the biggest coin that still fits, then the next biggest, and so on, without ever going back to reconsider an earlier coin. That's a greedy algorithm: make the locally best choice at every step and never look back. No recursion tree, no backtracking, no undo. That makes greedy algorithms fast, usually O(n log n) or better, but the entire interview is about *proving* the greedy choice is actually safe. For every problem where greedy works, there's a near-identical variant where it silently gives a wrong answer. ## Greedy choice property A problem has the greedy choice property if a locally best choice at every step leads to a globally best solution, and, critically, making that choice never rules out reaching the true best answer. This needs to be proven, not assumed. The standard way to convince yourself, and an interviewer, is an exchange argument: take a best solution that didn't make the greedy choice, show you can swap it in without making the solution worse, and that proves the greedy choice was at least as good. Example: Jump Game II (minimum jumps to reach the end). The greedy rule, at each step jump to whichever reachable position stretches your *reach* the furthest, rather than the position closest to the end, works because reach is transitive: whatever the furthest-reaching position can eventually access, every other reachable position can access too, or less. You lose nothing by maximizing reach at every step. ```python # Greedy choice property check, informally: # 1. State the greedy rule in one sentence. # 2. Ask: does an optimal solution exist that makes a DIFFERENT choice here # and still does at least as well? If yes, greedy is wrong. # 3. If no such solution exists, the greedy choice is safe. ``` ```javascript + // Greedy choice property check, informally: // 1. State the greedy rule in one sentence. // 2. Ask: does an optimal solution exist that makes a DIFFERENT choice here // and still does at least as well? If yes, greedy is wrong. // 3. If no such solution exists, the greedy choice is safe. ``` ```java + public class Main { public static void main(String[] args) { // Greedy choice property check, informally: // 1. State the greedy rule in one sentence. // 2. Ask: does an optimal solution exist that makes a DIFFERENT choice here // and still does at least as well? If yes, greedy is wrong. // 3. If no such solution exists, the greedy choice is safe. } } ``` > **Remember:** a greedy choice is only safe if you can prove no better solution ever needs to undo it. If you can't state that proof in a sentence, don't trust the greedy rule yet. ```knowledge-check { "questions": [ { "id": "dsa-greedy-choice-property-q1", "type": "mcq", "prompt": "What does an exchange argument actually prove about a greedy choice?", "options": [ {"id": "a", "text": "That any optimal solution can be modified to include the greedy choice without becoming worse, so the greedy choice is at least as good"}, {"id": "b", "text": "That the greedy solution always runs faster than any other algorithm"}, {"id": "c", "text": "That the problem has no optimal solution"}, {"id": "d", "text": "That greedy always finds every possible valid answer, not just one"} ], "correct": "a", "explanation": "An exchange argument takes a hypothetical optimal solution that skipped the greedy choice and shows swapping it in doesn't hurt, which proves the greedy choice never rules out reaching the optimum." } ] } ``` ## Local vs global optimum Greedy's failure mode is a locally attractive choice that quietly closes off a better path later. Classic counterexample: coin change with denominations `[1, 3, 4]` and target `6`. Greedy picks the largest coin that's `<=` the remaining amount every time: `4 + 1 + 1 = 3` coins. The true best answer is `3 + 3 = 2` coins. Greedy's "take the biggest coin now" was locally sensible but globally wrong. This is exactly why coin change in general needs DP, not greedy; greedy only works for specific denomination sets, like US currency. The interview skill is recognizing *which* category a new problem falls into before committing to an approach. If you can't build a proof or a clean exchange argument in under a minute, that's your signal to fall back to DP or search instead of forcing greedy. > **Remember:** a choice that looks best right now can quietly block the actual best path later. Coins `[1,3,4]`, target 6, is the go-to counterexample to test any new greedy idea against. ```knowledge-check { "questions": [ { "id": "dsa-greedy-local-global-q1", "type": "mcq", "prompt": "With coins [1, 3, 4] and target 6, why does the greedy \"always take the biggest coin\" strategy fail?", "options": [ {"id": "a", "text": "It gives 4 + 1 + 1 = 3 coins, but the optimal answer is 3 + 3 = 2 coins; the locally biggest coin blocks the globally best combination"}, {"id": "b", "text": "It fails because 4 is not a valid coin denomination"}, {"id": "c", "text": "It doesn't fail; greedy always finds the optimal answer for coin change"}, {"id": "d", "text": "It fails only when the target amount is odd"} ], "correct": "a", "explanation": "Taking the 4-coin first locally looks efficient, but it leaves only 1s to fill the remaining 2, giving 3 coins total instead of the true optimum of 2 (3+3)." } ] } ``` ## When greedy fails Signs a problem is not greedy-safe: - The "obviously best" local choice depends on information you don't have yet (later constraints change what "best" even means). - A counterexample is easy to build by hand; always try 2-3 small cases before committing to greedy. - The problem asks for a count of *all* ways, or needs backtracking over choices: greedy produces one answer, not an exploration of alternatives. If you can't rule these out quickly, say so out loud in the interview and default to DP. Proposing greedy and then getting handed the counterexample mid-interview is a worse outcome than never proposing it at all. > **Remember:** if you can build a counterexample in under a minute, greedy is wrong for this problem. Test small cases before you commit. ```knowledge-check { "questions": [ { "id": "dsa-greedy-when-fails-q1", "type": "mcq", "prompt": "Which of these is a reliable warning sign that a problem is NOT safe for a greedy approach?", "options": [ {"id": "a", "text": "A small counterexample is easy to construct by hand within a minute or two"}, {"id": "b", "text": "The input array is already sorted"}, {"id": "c", "text": "The problem only has one test case"}, {"id": "d", "text": "The array contains only positive integers"} ], "correct": "a", "explanation": "If you can quickly build a small case where the locally best choice leads to a worse overall result, that's direct proof the greedy-choice property doesn't hold here." } ] } ``` ### Jump Game [LeetCode 55 · Jump Game](https://leetcode.com/problems/jump-game/) · Greedy · Forward traversal **Intuition:** Track the furthest index reachable so far. If you ever reach an index beyond that furthest-reachable point before updating it, you're stuck. Otherwise, by the time you reach the last index, it was always within reach. **Approach:** Single forward pass; maintain `max_reach`. At each index `i`, if `i > max_reach` the current index is unreachable, so fail immediately. Otherwise update `max_reach = max(max_reach, i + nums[i])`. ```python def can_jump(nums: list[int]) -> bool: max_reach = 0 for i, num in enumerate(nums): if i > max_reach: return False # can't even reach this index max_reach = max(max_reach, i + num) if max_reach >= len(nums) - 1: return True return True ``` ```javascript + function canJump(nums) { let maxReach = 0; for (let i = 0; i < nums.length; i++) { if (i > maxReach) { return false; // can't even reach this index } maxReach = Math.max(maxReach, i + nums[i]); if (maxReach >= nums.length - 1) { return true; } } return true; } ``` ```java + public class Main { public static void main(String[] args) { int[] nums = {2, 3, 1, 1, 4}; System.out.println(canJump(nums)); } static boolean canJump(int[] nums) { int maxReach = 0; for (int i = 0; i < nums.length; i++) { if (i > maxReach) { return false; // can't even reach this index } maxReach = Math.max(maxReach, i + nums[i]); if (maxReach >= nums.length - 1) { return true; } } return true; } } ``` **Complexity:** O(n) time, O(1) space. **Common mistakes:** checking `max_reach >= len(nums) - 1` only after the loop instead of inside it. That's still correct but misses an early-exit optimization. Also, using DP with O(n²) reachability checks when the greedy one-pass version is strictly simpler and faster. > **Remember:** track the furthest reach seen so far. If the index you're standing on is ever past that reach, you were never going to make it. ### Jump Game II [LeetCode 45 · Jump Game II](https://leetcode.com/problems/jump-game-ii/) · Greedy · Minimum jumps **Intuition:** Think in "levels," like BFS on an implicit graph. `current_end` marks the boundary of the current jump's reach; `farthest` tracks the best reach achievable from any position within the current level. When you hit `current_end`, you're forced to take another jump: increment the counter and advance the boundary to `farthest`. **Approach:** This is the "maximize reach at every step" greedy choice from earlier in this lesson, formalized into a BFS-level counter. ```python def jump(nums: list[int]) -> int: jumps = 0 current_end = 0 farthest = 0 for i in range(len(nums) - 1): # don't need to jump from the last index farthest = max(farthest, i + nums[i]) if i == current_end: jumps += 1 current_end = farthest return jumps ``` ```javascript + function jump(nums) { let jumps = 0; let currentEnd = 0; let farthest = 0; for (let i = 0; i < nums.length - 1; i++) { // don't need to jump from the last index farthest = Math.max(farthest, i + nums[i]); if (i === currentEnd) { jumps++; currentEnd = farthest; } } return jumps; } ``` ```java + public class Main { public static void main(String[] args) { int[] nums = {2, 3, 1, 1, 4}; System.out.println(jump(nums)); } static int jump(int[] nums) { int jumps = 0; int currentEnd = 0; int farthest = 0; for (int i = 0; i < nums.length - 1; i++) { // don't need to jump from the last index farthest = Math.max(farthest, i + nums[i]); if (i == currentEnd) { jumps++; currentEnd = farthest; } } return jumps; } } ``` **Complexity:** O(n) time, O(1) space. **Common mistakes:** confusing this with Jump Game I. This problem counts *minimum jumps*, not reachability, and the greedy rule here, maximize reach, advance the boundary only when forced, is different from a plain reachability scan. Also, looping through the entire array including the last index, an off-by-one, since you never need to jump *from* the destination. > **Remember:** advance the jump counter only when you're forced to, when you've hit the boundary of what the current jump could reach. ### Meeting Rooms II [LeetCode 253 · Meeting Rooms II](https://leetcode.com/problems/meeting-rooms-ii/) · Greedy · Min heap **Intuition:** The number of rooms needed at any instant equals the number of meetings currently overlapping. Sort meetings by start time, then use a min-heap of end times to track which room frees up soonest. If the earliest-ending meeting has already finished by the time the next meeting starts, reuse that room instead of allocating a new one. **Approach:** Sort by start. Keep a min-heap of currently occupied rooms' end times. For each meeting, pop and reuse if the heap's smallest end time is `<=` the new meeting's start; otherwise push a new end time (a new room). The heap's final size is the answer. ```python import heapq def min_meeting_rooms(intervals: list[list[int]]) -> int: if not intervals: return 0 intervals.sort(key=lambda pair: pair[0]) heap = [] # min-heap of end times of currently occupied rooms for start, end in intervals: if heap and heap[0] <= start: heapq.heappop(heap) # reuse the room that just freed up heapq.heappush(heap, end) return len(heap) ``` ```javascript + class MinHeap { constructor() { this.data = []; } get size() { return this.data.length; } peek() { return this.data[0]; } push(value) { this.data.push(value); let i = this.data.length - 1; while (i > 0) { const parent = (i - 1) >> 1; if (this.data[parent] <= this.data[i]) break; [this.data[parent], this.data[i]] = [this.data[i], this.data[parent]]; i = parent; } } pop() { const top = this.data[0]; const last = this.data.pop(); if (this.data.length > 0) { this.data[0] = last; let i = 0; while (true) { const left = 2 * i + 1; const right = 2 * i + 2; let smallest = i; if (left < this.data.length && this.data[left] < this.data[smallest]) smallest = left; if (right < this.data.length && this.data[right] < this.data[smallest]) smallest = right; if (smallest === i) break; [this.data[i], this.data[smallest]] = [this.data[smallest], this.data[i]]; i = smallest; } } return top; } } function minMeetingRooms(intervals) { if (intervals.length === 0) return 0; intervals.sort((a, b) => a[0] - b[0]); const heap = new MinHeap(); // min-heap of end times of currently occupied rooms for (const [start, end] of intervals) { if (heap.size > 0 && heap.peek() <= start) { heap.pop(); // reuse the room that just freed up } heap.push(end); } return heap.size; } ``` ```java + import java.util.Arrays; import java.util.PriorityQueue; public class Main { public static void main(String[] args) { int[][] intervals = {{0, 30}, {5, 10}, {15, 20}}; System.out.println(minMeetingRooms(intervals)); } static int minMeetingRooms(int[][] intervals) { if (intervals.length == 0) return 0; Arrays.sort(intervals, (a, b) -> a[0] - b[0]); PriorityQueue heap = new PriorityQueue<>(); // min-heap of end times of currently occupied rooms for (int[] interval : intervals) { int start = interval[0], end = interval[1]; if (!heap.isEmpty() && heap.peek() <= start) { heap.poll(); // reuse the room that just freed up } heap.offer(end); } return heap.size(); } } ``` **Complexity:** O(n log n) time (sort plus n heap operations), O(n) space for the heap. **Common mistakes:** forgetting to sort by start time first, since the greedy reuse logic assumes meetings arrive in chronological order. Also, using `<` instead of `<=` when comparing an end time to a start time: a meeting ending exactly when another starts can share a room, assuming the problem's convention allows it, so confirm that with the interviewer. > **Remember:** the heap's smallest end time tells you the soonest a room frees up. Reuse it if that room is free by the time the next meeting starts. ### Task Scheduler [LeetCode 621 · Task Scheduler](https://leetcode.com/problems/task-scheduler/) · Greedy · Formula **Intuition:** The bottleneck is the most frequent task, since it needs `n` idle slots between each repetition. Build the schedule around the max-frequency task(s): `(max_freq - 1)` full cooldown blocks of size `(n + 1)`, plus however many tasks tie for the max frequency in the final block. Anything beyond that fills the idle slots for free. **Approach:** Compute frequency counts, find `max_freq` and how many tasks are tied at `max_freq`. The formula: `max(len(tasks), (max_freq - 1) * (n + 1) + count_of_max_freq_tasks)`. ```python from collections import Counter def least_interval(tasks: list[str], n: int) -> int: counts = Counter(tasks) max_freq = max(counts.values()) num_max = sum(1 for count in counts.values() if count == max_freq) # (max_freq - 1) full blocks of size (n + 1), plus the final partial block formula = (max_freq - 1) * (n + 1) + num_max return max(len(tasks), formula) ``` ```javascript + function leastInterval(tasks, n) { const counts = new Map(); for (const task of tasks) { counts.set(task, (counts.get(task) || 0) + 1); } const maxFreq = Math.max(...counts.values()); let numMax = 0; for (const count of counts.values()) { if (count === maxFreq) numMax++; } // (maxFreq - 1) full blocks of size (n + 1), plus the final partial block const formula = (maxFreq - 1) * (n + 1) + numMax; return Math.max(tasks.length, formula); } ``` ```java + import java.util.HashMap; import java.util.Map; public class Main { public static void main(String[] args) { char[] tasks = {'A', 'A', 'A', 'B', 'B', 'B'}; System.out.println(leastInterval(tasks, 2)); } static int leastInterval(char[] tasks, int n) { Map counts = new HashMap<>(); for (char task : tasks) { counts.merge(task, 1, Integer::sum); } int maxFreq = 0; for (int count : counts.values()) { maxFreq = Math.max(maxFreq, count); } int numMax = 0; for (int count : counts.values()) { if (count == maxFreq) numMax++; } // (maxFreq - 1) full blocks of size (n + 1), plus the final partial block int formula = (maxFreq - 1) * (n + 1) + numMax; return Math.max(tasks.length, formula); } } ``` **Complexity:** O(k) time where `k` is the number of tasks (counting) plus O(26) for the frequency scan, effectively O(k). O(1) space (bounded by 26 uppercase letters). **Common mistakes:** forgetting `max(len(tasks), formula)`. When there are enough distinct tasks to fill every idle slot, the formula alone can undercount and give a value smaller than the task count itself. Also, miscounting `num_max`: you must count *all* tasks tied at the max frequency, not just one of them. > **Remember:** the most frequent task sets the pace. Everything else either fills its forced idle slots or, if there's enough variety, doesn't need idle slots at all. 42:T561c,Think of a shared calendar app trying to figure out how many meeting rooms a company needs, or a delivery app merging overlapping time slots for a driver. Interval problems, merging, inserting, scheduling, show up constantly because real systems deal in time ranges: calendar bookings, resource allocation, CPU scheduling. The whole category collapses to one insight: sort first, then a single linear pass. This lesson covers the sort-key decision and applies it across four problems. ## Sorting intervals by start or end Almost every interval problem begins with a sort, and **which field you sort by is the single most important decision**. Get it wrong and no amount of clever logic afterward fixes it. - **Sort by start time** when merging overlaps or inserting a new interval. You need to process intervals in the order they begin to correctly detect chains of overlap. - **Sort by end time** when doing interval scheduling or selection (maximize non-overlapping intervals, minimum "arrows" to cover ranges). Greedily picking the interval that finishes earliest leaves the most room for future choices. ```python intervals = [[1, 3], [2, 6], [8, 10], [15, 18]] by_start = sorted(intervals, key=lambda x: x[0]) by_end = sorted(intervals, key=lambda x: x[1]) ``` ```javascript + const intervals = [[1, 3], [2, 6], [8, 10], [15, 18]]; const byStart = [...intervals].sort((a, b) => a[0] - b[0]); const byEnd = [...intervals].sort((a, b) => a[1] - b[1]); ``` ```java + import java.util.*; public class Main { public static void main(String[] args) { List intervals = new ArrayList<>(List.of( new int[]{1, 3}, new int[]{2, 6}, new int[]{8, 10}, new int[]{15, 18} )); List byStart = new ArrayList<>(intervals); byStart.sort((a, b) -> Integer.compare(a[0], b[0])); List byEnd = new ArrayList<>(intervals); byEnd.sort((a, b) -> Integer.compare(a[1], b[1])); for (int[] interval : byStart) { System.out.println(Arrays.toString(interval)); } for (int[] interval : byEnd) { System.out.println(Arrays.toString(interval)); } } } ``` Why this matters so much: the correctness of the whole single-pass algorithm that follows depends on the sort setting up the right invariant. For example, once you've sorted by start and moved past an interval, you know nothing later can start before it did. > **Remember:** merging and inserting sort by start. Scheduling and selection sort by end. Pick the wrong one and the bug hides in code that still looks reasonable. ```knowledge-check { "questions": [ { "id": "dsa-intervals-sort-key-q1", "type": "mcq", "prompt": "When should you sort intervals by end time instead of start time?", "options": [ {"id": "a", "text": "When solving a scheduling/selection problem, like maximizing non-overlapping intervals, where greedily picking the earliest-finishing option leaves the most room for future choices"}, {"id": "b", "text": "Always; sorting by end time works for every interval problem"}, {"id": "c", "text": "Only when the intervals are already sorted by start time"}, {"id": "d", "text": "Never; merging and scheduling both require sorting by start time"} ], "correct": "a", "explanation": "Scheduling/selection problems want to fit as many non-overlapping intervals as possible, and picking the earliest-ending option first is what leaves maximum room for everything after it." } ] } ``` ## Merging overlapping intervals Once sorted by start, merging is a single linear pass: keep a "current merged interval," and for each next interval, either fold it in if it overlaps, or close out the current one and start a new one. ```python def merge_intervals(intervals: list[list[int]]) -> list[list[int]]: if not intervals: return [] intervals.sort(key=lambda x: x[0]) merged = [intervals[0]] for start, end in intervals[1:]: last_end = merged[-1][1] if start <= last_end: # overlaps (or touches) the last merged interval merged[-1][1] = max(last_end, end) else: merged.append([start, end]) return merged ``` ```javascript + function mergeIntervals(intervals) { if (intervals.length === 0) return []; const sorted = [...intervals].sort((a, b) => a[0] - b[0]); const merged = [sorted[0]]; for (let i = 1; i < sorted.length; i++) { const [start, end] = sorted[i]; const lastEnd = merged[merged.length - 1][1]; if (start <= lastEnd) { // overlaps (or touches) the last merged interval merged[merged.length - 1][1] = Math.max(lastEnd, end); } else { merged.push([start, end]); } } return merged; } ``` ```java + import java.util.*; public class Main { public static void main(String[] args) { int[][] intervals = {{1, 3}, {2, 6}, {8, 10}, {15, 18}}; for (int[] interval : mergeIntervals(intervals)) { System.out.println(Arrays.toString(interval)); } } static List mergeIntervals(int[][] intervals) { if (intervals.length == 0) return new ArrayList<>(); int[][] sorted = intervals.clone(); Arrays.sort(sorted, (a, b) -> Integer.compare(a[0], b[0])); List merged = new ArrayList<>(); merged.add(sorted[0]); for (int i = 1; i < sorted.length; i++) { int start = sorted[i][0]; int end = sorted[i][1]; int[] last = merged.get(merged.size() - 1); if (start <= last[1]) { // overlaps (or touches) the last merged interval last[1] = Math.max(last[1], end); } else { merged.add(new int[]{start, end}); } } return merged; } } ``` The overlap check that trips people up: `start <= last_end`, not `start < last_end`. Intervals `[1, 3]` and `[3, 5]` count as overlapping (touching) in most problem statements, and merge into `[1, 5]`. Always check the problem statement for whether touching endpoints count as overlapping. > **Remember:** once sorted by start, one pass is enough. The only question at each step is whether the new interval touches or overlaps the one you're currently building. ```knowledge-check { "questions": [ { "id": "dsa-intervals-merging-q1", "type": "mcq", "prompt": "In the merge-overlapping-intervals sweep, what does `start <= last_end` (rather than strict `<`) usually mean for the problem's convention?", "options": [ {"id": "a", "text": "Touching intervals, like [1,3] and [3,5], count as overlapping and should be merged into one interval"}, {"id": "b", "text": "The intervals must never touch, or the algorithm is broken"}, {"id": "c", "text": "It only matters when intervals contain negative numbers"}, {"id": "d", "text": "It has no effect on the result either way"} ], "correct": "a", "explanation": "Using <= instead of < treats an interval that starts exactly where the previous one ends as overlapping, which is the usual convention for 'merge intervals' style problems." } ] } ``` ## Scheduling problems Scheduling and selection problems ask "how many intervals can you fit without overlap," or the flip side, "how many do you need to remove." The greedy strategy: **sort by end time, then greedily keep any interval whose start is at least the end of the last kept interval.** ```python def max_non_overlapping(intervals: list[list[int]]) -> int: if not intervals: return 0 intervals.sort(key=lambda x: x[1]) # sort by END time count = 1 last_end = intervals[0][1] for start, end in intervals[1:]: if start >= last_end: count += 1 last_end = end return count ``` ```javascript + function maxNonOverlapping(intervals) { if (intervals.length === 0) return 0; const sorted = [...intervals].sort((a, b) => a[1] - b[1]); // sort by END time let count = 1; let lastEnd = sorted[0][1]; for (let i = 1; i < sorted.length; i++) { const [start, end] = sorted[i]; if (start >= lastEnd) { count++; lastEnd = end; } } return count; } ``` ```java + import java.util.*; public class Main { public static void main(String[] args) { int[][] intervals = {{1, 2}, {2, 3}, {3, 4}, {1, 3}}; System.out.println(maxNonOverlapping(intervals)); } static int maxNonOverlapping(int[][] intervals) { if (intervals.length == 0) return 0; int[][] sorted = intervals.clone(); Arrays.sort(sorted, (a, b) -> Integer.compare(a[1], b[1])); // sort by END time int count = 1; int lastEnd = sorted[0][1]; for (int i = 1; i < sorted.length; i++) { int start = sorted[i][0]; int end = sorted[i][1]; if (start >= lastEnd) { count++; lastEnd = end; } } return count; } } ``` Why "sort by end, pick the earliest-ending" is optimal: the interval that finishes earliest leaves the most remaining room for future intervals. This is a classic exchange-argument greedy proof: any optimal solution can be rearranged to include the earliest-ending interval without becoming worse, and it's worth stating that justification out loud in an interview. > **Remember:** the interval that ends soonest leaves the most room behind it. That's why scheduling problems sort by end, not by start. ```knowledge-check { "questions": [ { "id": "dsa-intervals-scheduling-q1", "type": "mcq", "prompt": "Why does greedily picking the earliest-ending interval work for maximizing the count of non-overlapping intervals?", "options": [ {"id": "a", "text": "The earliest-ending interval leaves the most remaining room for future intervals, so any optimal solution can be rearranged to include it without getting worse"}, {"id": "b", "text": "It works because intervals are always the same length"}, {"id": "c", "text": "It works only when there are fewer than 10 intervals"}, {"id": "d", "text": "It's actually incorrect; the correct approach requires dynamic programming"} ], "correct": "a", "explanation": "This is the exchange-argument proof: swapping in the earliest-ending interval for whatever an optimal solution chose instead never makes the solution worse, so greedy is safe here." } ] } ``` ## Merge Intervals [LeetCode 56](https://leetcode.com/problems/merge-intervals/) — Intervals **Intuition:** Direct application of the merging pattern above: sort by start, sweep once, fold overlapping intervals together. **Approach:** Sort by start time. Keep a result list; compare each interval's start against the last merged interval's end. ```python def merge(intervals: list[list[int]]) -> list[list[int]]: intervals.sort(key=lambda x: x[0]) merged = [] for interval in intervals: if not merged or interval[0] > merged[-1][1]: merged.append(interval) else: merged[-1][1] = max(merged[-1][1], interval[1]) return merged ``` ```javascript + function merge(intervals) { const sorted = [...intervals].sort((a, b) => a[0] - b[0]); const merged = []; for (const interval of sorted) { if (merged.length === 0 || interval[0] > merged[merged.length - 1][1]) { merged.push(interval); } else { merged[merged.length - 1][1] = Math.max(merged[merged.length - 1][1], interval[1]); } } return merged; } ``` ```java + import java.util.*; public class Main { public static void main(String[] args) { int[][] intervals = {{1, 3}, {2, 6}, {8, 10}, {15, 18}}; int[][] result = merge(intervals); for (int[] interval : result) { System.out.println(Arrays.toString(interval)); } } static int[][] merge(int[][] intervals) { int[][] sorted = intervals.clone(); Arrays.sort(sorted, (a, b) -> Integer.compare(a[0], b[0])); List merged = new ArrayList<>(); for (int[] interval : sorted) { if (merged.isEmpty() || interval[0] > merged.get(merged.size() - 1)[1]) { merged.add(interval); } else { int[] last = merged.get(merged.size() - 1); last[1] = Math.max(last[1], interval[1]); } } return merged.toArray(new int[0][]); } } ``` **Complexity:** Time O(n log n) for the sort (the pass itself is O(n)), space O(n) for the output. **Common mistakes:** using `>=` instead of `>` for the "no overlap" branch, an off-by-one on the touching-endpoints rule; verify against the problem's stated examples. Also, mutating the input list's inner lists when the interviewer expects the original untouched: build fresh `[start, end]` pairs if that matters. > **Remember:** Merge Intervals is the concept section's algorithm applied directly, with no extra wrinkle. ## Insert Interval [LeetCode 57](https://leetcode.com/problems/insert-interval/) — Intervals **Intuition:** The input is already sorted and non-overlapping; you're inserting one new interval and merging only where it collides. Three phases: intervals entirely before the new one (copy as-is), intervals overlapping the new one (merge into it), intervals entirely after (copy as-is). **Approach:** Walk the list once. Append intervals that end before the new interval starts. Merge all intervals that overlap the new interval, expanding its bounds. Append the merged interval, then append everything remaining. ```python def insert(intervals: list[list[int]], newInterval: list[int]) -> list[list[int]]: result = [] i, n = 0, len(intervals) new_start, new_end = newInterval while i < n and intervals[i][1] < new_start: result.append(intervals[i]) i += 1 while i < n and intervals[i][0] <= new_end: new_start = min(new_start, intervals[i][0]) new_end = max(new_end, intervals[i][1]) i += 1 result.append([new_start, new_end]) while i < n: result.append(intervals[i]) i += 1 return result ``` ```javascript + function insert(intervals, newInterval) { const result = []; let i = 0; const n = intervals.length; let [newStart, newEnd] = newInterval; while (i < n && intervals[i][1] < newStart) { result.push(intervals[i]); i++; } while (i < n && intervals[i][0] <= newEnd) { newStart = Math.min(newStart, intervals[i][0]); newEnd = Math.max(newEnd, intervals[i][1]); i++; } result.push([newStart, newEnd]); while (i < n) { result.push(intervals[i]); i++; } return result; } ``` ```java + import java.util.*; public class Main { public static void main(String[] args) { int[][] intervals = {{1, 3}, {6, 9}}; int[] newInterval = {2, 5}; for (int[] interval : insert(intervals, newInterval)) { System.out.println(Arrays.toString(interval)); } } static int[][] insert(int[][] intervals, int[] newInterval) { List result = new ArrayList<>(); int i = 0; int n = intervals.length; int newStart = newInterval[0]; int newEnd = newInterval[1]; while (i < n && intervals[i][1] < newStart) { result.add(intervals[i]); i++; } while (i < n && intervals[i][0] <= newEnd) { newStart = Math.min(newStart, intervals[i][0]); newEnd = Math.max(newEnd, intervals[i][1]); i++; } result.add(new int[]{newStart, newEnd}); while (i < n) { result.add(intervals[i]); i++; } return result.toArray(new int[0][]); } } ``` **Complexity:** Time O(n): no sort needed since the input is already sorted. Space O(n) for the output. **Common mistakes:** sorting the input unnecessarily. It's guaranteed pre-sorted, so sorting wastes O(n log n) work and can hide a bug in the merge logic. Also, using `<` instead of `<=` in the overlap-detection loop, which misses touching intervals that should merge. > **Remember:** the input is already sorted, so don't sort it again. Just walk it once: before, overlapping, after. ## Meeting Rooms [LeetCode 252](https://leetcode.com/problems/meeting-rooms/) — Intervals **Intuition:** Can one person attend all meetings? That's the same question as: do any two intervals overlap? Sort by start time; if any interval starts before the previous one ends, there's a conflict. **Approach:** Sort by start. Single pass comparing each interval's start against the previous interval's end. ```python def canAttendMeetings(intervals: list[list[int]]) -> bool: intervals.sort(key=lambda x: x[0]) for i in range(1, len(intervals)): if intervals[i][0] < intervals[i - 1][1]: return False return True ``` ```javascript + function canAttendMeetings(intervals) { const sorted = [...intervals].sort((a, b) => a[0] - b[0]); for (let i = 1; i < sorted.length; i++) { if (sorted[i][0] < sorted[i - 1][1]) { return false; } } return true; } ``` ```java + import java.util.*; public class Main { public static void main(String[] args) { int[][] intervals = {{0, 30}, {5, 10}, {15, 20}}; System.out.println(canAttendMeetings(intervals)); } static boolean canAttendMeetings(int[][] intervals) { int[][] sorted = intervals.clone(); Arrays.sort(sorted, (a, b) -> Integer.compare(a[0], b[0])); for (int i = 1; i < sorted.length; i++) { if (sorted[i][0] < sorted[i - 1][1]) { return false; } } return true; } } ``` **Complexity:** Time O(n log n), space O(1) extra (ignoring sort space). **Common mistakes:** confusing this with Meeting Rooms II below, and building a heap when a simple sorted pass is enough. This variant only asks a yes/no question, not "how many rooms." Meeting Rooms II (the natural follow-up, LeetCode 253, referenced constantly in interviews even where it's paywalled) asks for the *minimum number of rooms* needed, which requires tracking how many meetings are active at once. The Greedy Algorithms lesson's Meeting Rooms II walkthrough covers this in full: sort by start, track occupied rooms' end times in a min-heap, and reuse a room the moment its meeting has ended. > **Remember:** "can one person attend everything" is just "do any two intervals overlap." Sort by start and check neighbors. ## Minimum Number of Arrows to Burst Balloons [LeetCode 452](https://leetcode.com/problems/minimum-number-of-arrows-to-burst-balloons/) — Intervals **Intuition:** An arrow shot at position x bursts every balloon whose interval contains x. Minimizing arrows means maximizing how many balloons one arrow can burst at once, which is the same "sort by end time, greedily group overlapping intervals" scheduling pattern from earlier in this lesson, just phrased as balloons instead of meetings. **Approach:** Sort by end coordinate. Shoot an arrow at the end of the first, earliest-ending, balloon's range; any later balloon whose start is `<=` that arrow position is burst by the same arrow. When a balloon starts after the current arrow position, you need a new arrow. ```python def findMinArrowShots(points: list[list[int]]) -> int: if not points: return 0 points.sort(key=lambda x: x[1]) arrows = 1 arrow_pos = points[0][1] for start, end in points[1:]: if start > arrow_pos: arrows += 1 arrow_pos = end return arrows ``` ```javascript + function findMinArrowShots(points) { if (points.length === 0) return 0; const sorted = [...points].sort((a, b) => a[1] - b[1]); let arrows = 1; let arrowPos = sorted[0][1]; for (let i = 1; i < sorted.length; i++) { const [start, end] = sorted[i]; if (start > arrowPos) { arrows++; arrowPos = end; } } return arrows; } ``` ```java + import java.util.*; public class Main { public static void main(String[] args) { int[][] points = {{10, 16}, {2, 8}, {1, 6}, {7, 12}}; System.out.println(findMinArrowShots(points)); } static int findMinArrowShots(int[][] points) { if (points.length == 0) return 0; int[][] sorted = points.clone(); Arrays.sort(sorted, (a, b) -> Integer.compare(a[1], b[1])); int arrows = 1; int arrowPos = sorted[0][1]; for (int i = 1; i < sorted.length; i++) { int start = sorted[i][0]; int end = sorted[i][1]; if (start > arrowPos) { arrows++; arrowPos = end; } } return arrows; } } ``` **Complexity:** Time O(n log n) for the sort, space O(1) extra. **Common mistakes:** sorting by start instead of end, exactly the "wrong sort key" trap the concept section warns about, which produces a wrong greedy result here. Also, using `>=` instead of `>` in the new-arrow check: touching balloons, like `[1,2]` and `[2,3]`, can share one arrow at position 2, so verify against the problem's boundary convention. > **Remember:** minimizing arrows and maximizing non-overlapping meetings are the same problem wearing different names, sort by end and greedily group. Four problems, one recurring choice: sort by start or sort by end. Get that call right and each algorithm above becomes a few lines of linear-pass bookkeeping. Get it wrong and the bug hides in code that passes small examples and fails on edge cases, so when a new interval problem shows up, decide the sort key before writing anything else. 43:T407b,Think of a row of light switches, each either on or off. A lot of clever tricks in computing come from realizing you can flip, check, or compare those switches directly instead of doing math on the number they represent. That's bit manipulation: working with the actual 1s and 0s under a number, rather than the number as a whole. Bit manipulation problems test whether you understand what's really happening under a language's integer abstraction. They come up because a handful of XOR/AND/OR tricks turn O(n) extra-space problems into O(1) space ones, and interviewers use them as a quick signal for how deep your computer science fundamentals go. ## Bitwise operations The core operators, and what they mean bit by bit: ```python a & b # AND: 1 only where both bits are 1 — used for masking / checking a bit a | b # OR: 1 where either bit is 1 — used for setting a bit a ^ b # XOR: 1 where bits differ — used for toggling / finding differences ~a # NOT: flips every bit — in Python, ~a == -a - 1 (two's complement) a << k # left shift: multiply by 2^k a >> k # right shift: divide by 2^k (floor, arithmetic shift for negative ints in Python) ``` ```javascript + const a = 0b1100, b = 0b1010, k = 2; a & b; // AND: 1 only where both bits are 1 — used for masking / checking a bit a | b; // OR: 1 where either bit is 1 — used for setting a bit a ^ b; // XOR: 1 where bits differ — used for toggling / finding differences ~a; // NOT: flips every bit — in JS, ~a === -a - 1 (two's complement) a << k; // left shift: multiply by 2^k a >> k; // right shift: divide by 2^k (floor, arithmetic shift; JS also has >>> for unsigned) ``` ```java + public class Main { public static void main(String[] args) { int a = 0b1100, b = 0b1010, k = 2; System.out.println("a & b = " + (a & b)); // AND: 1 only where both bits are 1 System.out.println("a | b = " + (a | b)); // OR: 1 where either bit is 1 System.out.println("a ^ b = " + (a ^ b)); // XOR: 1 where bits differ System.out.println("~a = " + (~a)); // NOT: flips every bit, ~a == -a - 1 System.out.println("a << k = " + (a << k)); // left shift: multiply by 2^k System.out.println("a >> k = " + (a >> k)); // right shift: divide by 2^k (arithmetic) } } ``` Useful bit-twiddling idioms worth having memorized: ```python n & (n - 1) # clears the lowest set bit — used to count set bits, check power of 2 n & (-n) # isolates the lowest set bit n | (1 << k) # sets bit k n & ~(1 << k) # clears bit k n ^ (1 << k) # toggles bit k (n >> k) & 1 # reads bit k ``` ```javascript + const n = 12, k = 2; n & (n - 1); // clears the lowest set bit — used to count set bits, check power of 2 n & (-n); // isolates the lowest set bit n | (1 << k); // sets bit k n & ~(1 << k); // clears bit k n ^ (1 << k); // toggles bit k (n >> k) & 1; // reads bit k ``` ```java + public class Main { public static void main(String[] args) { int n = 12, k = 2; System.out.println("n & (n - 1) = " + (n & (n - 1))); // clears the lowest set bit System.out.println("n & (-n) = " + (n & (-n))); // isolates the lowest set bit System.out.println("n | (1 << k) = " + (n | (1 << k))); // sets bit k System.out.println("n & ~(1 << k) = " + (n & ~(1 << k))); // clears bit k System.out.println("n ^ (1 << k) = " + (n ^ (1 << k))); // toggles bit k System.out.println("(n >> k) & 1 = " + ((n >> k) & 1)); // reads bit k } } ``` `n & (n - 1) == 0` (for `n > 0`) is the fastest power-of-2 check: a power of 2 has exactly one set bit, and subtracting 1 flips every bit below it, so ANDing the two together always gives zero. > **Remember:** AND masks, OR sets, XOR toggles, and `n & (n-1)` clears the lowest set bit. These six lines cover most bit-manipulation interview questions. ```knowledge-check { "questions": [ { "id": "dsa-bits-operations-q1", "type": "mcq", "prompt": "Why does n & (n - 1) equal zero exactly when n is a power of two (for n > 0)?", "options": [ {"id": "a", "text": "A power of two has exactly one set bit; subtracting 1 flips every bit below it, so ANDing the two leaves no bits in common"}, {"id": "b", "text": "Because subtraction always produces zero when ANDed with the original number"}, {"id": "c", "text": "Because powers of two are always even"}, {"id": "d", "text": "It only works for n less than 16"} ], "correct": "a", "explanation": "For a power of two like 8 (1000), n-1 is 0111. ANDing 1000 with 0111 gives 0000, since there's no overlap in set bits. Any number with more than one set bit won't have that property." } ] } ``` ## Two's complement Negative integers are represented as two's complement in essentially every language with fixed-width integers: to negate `n`, flip every bit and add 1 (`~n + 1 == -n`). That's why `~a == -a - 1` in Python even though Python integers are conceptually unbounded; Python still models bitwise NOT as if it were operating on an infinite two's-complement representation. Python has a quirk worth knowing for interviews: unlike Java or C++, Python integers have no fixed bit width, so operations like `n >> 1` on a negative number keep sign-extending forever, and there's no native 32-bit overflow wraparound. Problems like Reverse Bits and Sum of Two Integers explicitly need you to *simulate* fixed-width behavior with masking: ```python MASK32 = 0xFFFFFFFF # mask to simulate a 32-bit unsigned register def to_signed_32(n: int) -> int: n &= MASK32 # if the sign bit (bit 31) is set, interpret as negative return n if n < 0x80000000 else n - 0x100000000 ``` ```javascript + function toSigned32(n) { n = n >>> 0; // mask down to a 32-bit unsigned value first // if the sign bit (bit 31) is set, interpret as negative return n < 0x80000000 ? n : n - 0x100000000; } ``` ```java + public class Main { public static void main(String[] args) { System.out.println(toSigned32(4294967295L)); // -1 System.out.println(toSigned32(5L)); // 5 } static final long MASK32 = 0xFFFFFFFFL; // mask to simulate a 32-bit unsigned register static int toSigned32(long n) { n &= MASK32; // if the sign bit (bit 31) is set, interpret as negative return (int) (n < 0x80000000L ? n : n - 0x100000000L); } } ``` > **Remember:** Python integers never overflow on their own. If a problem needs 32-bit behavior, you have to fake it yourself with a mask. ```knowledge-check { "questions": [ { "id": "dsa-bits-twos-complement-q1", "type": "mcq", "prompt": "Why do problems like Reverse Bits need explicit 32-bit masking in Python, even though the algorithm itself works fine without it?", "options": [ {"id": "a", "text": "Python integers are unbounded and never wrap around at 32 bits on their own, so fixed-width behavior has to be simulated with a mask"}, {"id": "b", "text": "Python doesn't support the bitwise NOT operator"}, {"id": "c", "text": "Masking makes the algorithm run in less time"}, {"id": "d", "text": "Reverse Bits doesn't actually need masking in any language"} ], "correct": "a", "explanation": "Unlike Java or C++, Python has no fixed integer width, so simulating a 32-bit register (for sign interpretation or overflow behavior) requires an explicit mask like 0xFFFFFFFF." } ] } ``` ## Common patterns **XOR self-cancellation** (`a ^ a == 0`, `a ^ 0 == a`, and XOR is commutative and associative): XOR-ing an array where every element appears twice except one leaves only the unpaired element, because every pair cancels to 0. That's the entire trick behind Single Number. **Counting set bits**: `n & (n - 1)` repeatedly clears the lowest set bit. Loop until `n == 0`, counting iterations. This runs in O(popcount) time rather than O(32) for checking every bit position, which matters when `n` is sparse. **Missing number via XOR**: XOR-ing `0..n` together with every element of an `n`-length array (which is missing exactly one value from `0..n`) cancels every present value, leaving the missing one behind. This avoids the overflow risk of a sum-based approach (`n*(n+1)/2 - sum(nums)`), which matters in fixed-width-integer languages even though it's a non-issue in Python. > **Remember:** XOR cancels pairs to zero and leaves singles untouched. That one fact solves Single Number and Missing Number both. ```knowledge-check { "questions": [ { "id": "dsa-bits-common-patterns-q1", "type": "mcq", "prompt": "What XOR property makes it possible to find the one element that appears once, when every other element appears exactly twice?", "options": [ {"id": "a", "text": "a ^ a = 0 and a ^ 0 = a, so XOR-ing the whole array cancels every paired value to 0 and leaves only the unpaired one"}, {"id": "b", "text": "XOR sorts the array as a side effect"}, {"id": "c", "text": "XOR always returns the largest value in the array"}, {"id": "d", "text": "XOR only works correctly on sorted arrays"} ], "correct": "a", "explanation": "Since XOR is commutative and associative, order doesn't matter: every pair cancels to 0 regardless of position, leaving only the unpaired element in the running result." } ] } ``` ### Number of 1 Bits [LeetCode 191 · Number of 1 Bits](https://leetcode.com/problems/number-of-1-bits/) · Bit · Hamming weight **Intuition:** Count set bits by repeatedly clearing the lowest one with `n & (n - 1)` until `n` becomes 0. The number of clears equals the number of set bits. **Approach:** Loop while `n != 0`; each iteration does `n &= n - 1` and increments a counter. ```python def hamming_weight(n: int) -> int: count = 0 while n: n &= n - 1 # clears the lowest set bit count += 1 return count ``` ```javascript + function hammingWeight(n) { let count = 0; while (n !== 0) { n &= n - 1; // clears the lowest set bit count++; } return count; } ``` ```java + public class Main { public static void main(String[] args) { System.out.println(hammingWeight(0b1011)); } static int hammingWeight(int n) { int count = 0; while (n != 0) { n &= n - 1; // clears the lowest set bit count++; } return count; } } ``` **Complexity:** O(k) time where `k` is the number of set bits, not 32, better than a naive O(32) bit-by-bit scan on sparse inputs. O(1) space. **Common mistakes:** using `n >>= 1` combined with `n & 1` in a fixed 32-iteration loop. That's correct but strictly worse than the `n & (n-1)` trick when bits are sparse. Also, forgetting Python has no fixed width, so a naive right-shift loop on a value treated as "signed 32-bit" needs masking to behave correctly. > **Remember:** each `n & (n-1)` removes exactly one set bit. Count the removals, not the bit positions. ### Reverse Bits [LeetCode 190 · Reverse Bits](https://leetcode.com/problems/reverse-bits/) · Bit · Bit swapping **Intuition:** Build the result bit by bit: take the lowest bit of the input, place it as the highest bit of the output (shifted into position), then shift the input right and repeat for all 32 positions. **Approach:** Loop 32 times; each iteration extracts `n`'s lowest bit, shifts it into the correct position of `result`, then shifts `n` right by one. ```python def reverse_bits(n: int) -> int: result = 0 for i in range(32): bit = (n >> i) & 1 result |= bit << (31 - i) return result ``` ```javascript + function reverseBits(n) { let result = 0; for (let i = 0; i < 32; i++) { const bit = (n >>> i) & 1; result = (result | (bit << (31 - i))) >>> 0; } return result; } ``` ```java + public class Main { public static void main(String[] args) { System.out.println(reverseBits(0b00000010100101000001111010011100)); } static int reverseBits(int n) { int result = 0; for (int i = 0; i < 32; i++) { int bit = (n >>> i) & 1; result |= bit << (31 - i); } return result; } } ``` **Complexity:** O(32) = O(1) time (fixed width), O(1) space. **Common mistakes:** forgetting the loop must run exactly 32 times regardless of how many leading zero bits `n` has, since this is a fixed-width problem, not a variable-length one. Also, an off-by-one in the shift amount: it's `31 - i`, not `32 - i`. > **Remember:** the loop always runs exactly 32 times. Leading zeros in the input don't shorten it. ### Single Number [LeetCode 136 · Single Number](https://leetcode.com/problems/single-number/) · Bit · XOR trick **Intuition:** Every element except one appears exactly twice. XOR-ing the whole array cancels every paired element to 0, leaving only the unpaired one, since XOR is commutative and associative, so the order pairs cancel in doesn't matter. **Approach:** Single pass, XOR-accumulate into a running result. ```python def single_number(nums: list[int]) -> int: result = 0 for num in nums: result ^= num return result ``` ```javascript + function singleNumber(nums) { let result = 0; for (const num of nums) { result ^= num; } return result; } ``` ```java + public class Main { public static void main(String[] args) { int[] nums = {4, 1, 2, 1, 2}; System.out.println(singleNumber(nums)); } static int singleNumber(int[] nums) { int result = 0; for (int num : nums) { result ^= num; } return result; } } ``` **Complexity:** O(n) time, O(1) space. Strictly better than a hash-set approach (O(n) space), which is the "obvious" first instinct. **Common mistakes:** reaching for a `Counter`/hash-set solution first without noticing the O(1)-space XOR trick applies whenever "every element appears twice except one" is the setup. Also, trying to force the XOR trick onto a variant where elements appear *three* times except one (LeetCode 137), which needs a different bit-counting technique since XOR alone doesn't work there. > **Remember:** "everything appears twice except one" is the exact trigger phrase for the XOR trick. Don't reach for a hash set first. ### Missing Number [LeetCode 268 · Missing Number](https://leetcode.com/problems/missing-number/) · Bit · XOR **Intuition:** An array of length `n` contains distinct values from `0` to `n`, missing exactly one. XOR every array value together with every value from `0` to `n` inclusive: every present number cancels with its own index/value pairing, leaving only the missing number. **Approach:** Initialize `result = n` (accounts for the index-`n` term that has no matching array index), then XOR in `i ^ nums[i]` for each index. ```python def missing_number(nums: list[int]) -> int: result = len(nums) # pre-seed with n, since indices only go 0..n-1 for i, num in enumerate(nums): result ^= i ^ num return result ``` ```javascript + function missingNumber(nums) { let result = nums.length; // pre-seed with n, since indices only go 0..n-1 for (let i = 0; i < nums.length; i++) { result ^= i ^ nums[i]; } return result; } ``` ```java + public class Main { public static void main(String[] args) { int[] nums = {3, 0, 1}; System.out.println(missingNumber(nums)); } static int missingNumber(int[] nums) { int result = nums.length; // pre-seed with n, since indices only go 0..n-1 for (int i = 0; i < nums.length; i++) { result ^= i ^ nums[i]; } return result; } } ``` **Complexity:** O(n) time, O(1) space. **Common mistakes:** using the arithmetic sum formula (`n*(n+1)//2 - sum(nums)`), which is fine in Python but worth contrasting with XOR: in fixed-width-integer languages, the sum formula risks overflow for large `n`, while XOR never does, which is why XOR is the "safer general" answer even though both are O(n)/O(1) in Python. Also, miscounting the range: you must XOR indices `0..n-1` plus values, seeded with `n`, not `0..n`. > **Remember:** seed the running XOR with `n` before the loop, since index `n` itself never appears as an array position. 44:T65a9,Think of a security guard checking IDs at a locked door: they don't need to check every single fact about you, just the one or two that actually prove who you are. Math and geometry interview problems work the same way; a handful of number-theory facts and careful index arithmetic solve almost everything. They test something different from graph or DP fluency, and they show up often as "easy-looking but easy to get subtly wrong" questions. This lesson covers primes, GCD/LCM, matrix rotation, and fast exponentiation. ## Prime numbers A prime number is only divisible by 1 and itself. The naive check tests divisors up to `n`, but you only need to check up to `sqrt(n)`. Here's why: if `n = a * b` with both `a` and `b` greater than `sqrt(n)`, then `a * b > n`, which is a contradiction, so at least one factor must be at or below `sqrt(n)`. ```python def is_prime(n: int) -> bool: if n < 2: return False if n in (2, 3): return True if n % 2 == 0: return False i = 3 while i * i <= n: if n % i == 0: return False i += 2 return True ``` ```javascript + function isPrime(n) { if (n < 2) return false; if (n === 2 || n === 3) return true; if (n % 2 === 0) return false; for (let i = 3; i * i <= n; i += 2) { if (n % i === 0) return false; } return true; } ``` ```java + public class Main { public static void main(String[] args) { System.out.println(isPrime(97)); } static boolean isPrime(int n) { if (n < 2) return false; if (n == 2 || n == 3) return true; if (n % 2 == 0) return false; for (int i = 3; (long) i * i <= n; i += 2) { if (n % i == 0) return false; } return true; } } ``` **Complexity:** O(sqrt(n)) per check. For checking primality of *many* numbers up to some bound N, the Sieve of Eratosthenes further down this lesson beats calling `is_prime` N separate times. > **Remember:** you only ever need to test divisors up to `sqrt(n)`. Past that point, any factor would have to pair with one smaller than `sqrt(n)`, which you'd have already found. ```knowledge-check { "questions": [ { "id": "dsa-math-primes-q1", "type": "mcq", "prompt": "Why does a primality check only need to test divisors up to sqrt(n), instead of all the way up to n?", "options": [ {"id": "a", "text": "If n = a * b with both a and b greater than sqrt(n), then a * b would exceed n, which is a contradiction, so at least one factor must be at or below sqrt(n)"}, {"id": "b", "text": "Because all prime numbers are less than their own square root"}, {"id": "c", "text": "Because division is undefined for numbers larger than sqrt(n)"}, {"id": "d", "text": "It's just a performance shortcut with no mathematical justification"} ], "correct": "a", "explanation": "Any factor pair of a composite n must have one factor at or below sqrt(n) and one at or above it, so checking only up to sqrt(n) is guaranteed to catch a factor if one exists." } ] } ``` ## GCD and LCM **GCD** (greatest common divisor) comes from the **Euclidean algorithm**: `gcd(a, b) = gcd(b, a % b)`, stopping when `b == 0`. ```python def gcd(a: int, b: int) -> int: while b: a, b = b, a % b return a ``` ```javascript + function gcd(a, b) { while (b) { [a, b] = [b, a % b]; } return a; } ``` ```java + public class Main { public static void main(String[] args) { System.out.println(gcd(48, 18)); } static int gcd(int a, int b) { while (b != 0) { int temp = b; b = a % b; a = temp; } return a; } } ``` **LCM** (least common multiple) follows directly from GCD: `lcm(a, b) = a * b / gcd(a, b)`. ```python def lcm(a: int, b: int) -> int: return a * b // gcd(a, b) ``` ```javascript + function gcd(a, b) { while (b) { [a, b] = [b, a % b]; } return a; } function lcm(a, b) { return (a * b) / gcd(a, b); } ``` ```java + public class Main { public static void main(String[] args) { System.out.println(lcm(4, 6)); } static int gcd(int a, int b) { while (b != 0) { int temp = b; b = a % b; a = temp; } return a; } static int lcm(int a, int b) { return (a * b) / gcd(a, b); } } ``` **Complexity:** GCD runs in O(log(min(a, b))): each step roughly halves the smaller number in the worst case (numbers adjacent in the Fibonacci sequence are the slow case, still logarithmic). Python's standard library has `math.gcd` and `math.lcm` directly. Mention the built-in, but be ready to derive it from scratch, since implementing Euclid's algorithm is a common ask. **Pitfall:** compute `a * b // gcd(a, b)` as written, in that order. If you're worried about overflow in a fixed-width-integer language, order of operations matters; this isn't a Python concern, but interviewers sometimes probe it anyway. > **Remember:** `gcd(a, b) = gcd(b, a % b)`, stop at `b == 0`. LCM is just `a * b / gcd(a, b)` on top of that. ```knowledge-check { "questions": [ { "id": "dsa-math-gcd-lcm-q1", "type": "mcq", "prompt": "What's the core recurrence behind the Euclidean algorithm for GCD?", "options": [ {"id": "a", "text": "gcd(a, b) = gcd(b, a % b), stopping once b reaches 0"}, {"id": "b", "text": "gcd(a, b) = a * b, always"}, {"id": "c", "text": "gcd(a, b) requires factoring both numbers into primes first"}, {"id": "d", "text": "gcd(a, b) = a - b, repeated until they're equal"} ], "correct": "a", "explanation": "Repeatedly replacing (a, b) with (b, a % b) shrinks the pair each step and converges to the greatest common divisor once b becomes 0." } ] } ``` ## Matrix rotation Rotating an `n x n` matrix 90 degrees clockwise **in place** (O(1) extra space) takes two steps: **transpose**, then **reverse each row**. ```python def rotate_90_clockwise(matrix: list[list[int]]) -> None: n = len(matrix) # 1. transpose: swap matrix[i][j] with matrix[j][i] for i in range(n): for j in range(i + 1, n): matrix[i][j], matrix[j][i] = matrix[j][i], matrix[i][j] # 2. reverse each row for row in matrix: row.reverse() ``` ```javascript + function rotate90Clockwise(matrix) { const n = matrix.length; // 1. transpose: swap matrix[i][j] with matrix[j][i] for (let i = 0; i < n; i++) { for (let j = i + 1; j < n; j++) { [matrix[i][j], matrix[j][i]] = [matrix[j][i], matrix[i][j]]; } } // 2. reverse each row for (const row of matrix) { row.reverse(); } } ``` ```java + public class Main { public static void main(String[] args) { int[][] matrix = { {1, 2, 3}, {4, 5, 6}, {7, 8, 9} }; rotate90Clockwise(matrix); for (int[] row : matrix) { System.out.println(java.util.Arrays.toString(row)); } } static void rotate90Clockwise(int[][] matrix) { int n = matrix.length; // 1. transpose: swap matrix[i][j] with matrix[j][i] for (int i = 0; i < n; i++) { for (int j = i + 1; j < n; j++) { int temp = matrix[i][j]; matrix[i][j] = matrix[j][i]; matrix[j][i] = temp; } } // 2. reverse each row for (int[] row : matrix) { int left = 0, right = row.length - 1; while (left < right) { int temp = row[left]; row[left] = row[right]; row[right] = temp; left++; right--; } } } } ``` Why transpose plus reverse rows equals a 90 degree clockwise turn: transposing flips the matrix across its main diagonal, turning rows into columns. Reversing each row then flips left-right, and the two combined equal a clockwise quarter turn. Trace a 3x3 example by hand once; it's much easier to verify visually than to reason about in the abstract. The alternative **4-way (layer-by-layer) swap** rotates the outer ring, then the next ring inward, cycling four cells at a time (`top -> right -> bottom -> left -> top`). Both approaches hit O(1) extra space. Transpose-plus-reverse is shorter to write correctly under pressure, so default to it unless the interviewer specifically wants the layer-cycling version. > **Remember:** transpose flips across the diagonal, reversing each row flips left-right. Do both, in that order, and you've rotated 90 degrees clockwise in place. ```knowledge-check { "questions": [ { "id": "dsa-math-matrix-rotation-q1", "type": "mcq", "prompt": "What two steps rotate an n x n matrix 90 degrees clockwise in place?", "options": [ {"id": "a", "text": "Transpose the matrix (swap across the main diagonal), then reverse each row"}, {"id": "b", "text": "Reverse each row, then reverse each column"}, {"id": "c", "text": "Sort each row in ascending order, then transpose"}, {"id": "d", "text": "Allocate a brand-new matrix and copy every value into its rotated position"} ], "correct": "a", "explanation": "Transposing turns rows into columns; reversing each row afterward completes the clockwise quarter turn, and both steps together use only O(1) extra space." } ] } ``` ### Rotate Image [LeetCode 48](https://leetcode.com/problems/rotate-image/) — Matrix **Intuition:** A direct application of the transpose-plus-reverse-rows technique above. This problem *is* that technique, asked standalone. **Approach:** Transpose in place, then reverse each row in place. ```python def rotate(matrix: list[list[int]]) -> None: n = len(matrix) for i in range(n): for j in range(i + 1, n): matrix[i][j], matrix[j][i] = matrix[j][i], matrix[i][j] for row in matrix: row.reverse() ``` ```javascript + function rotate(matrix) { const n = matrix.length; for (let i = 0; i < n; i++) { for (let j = i + 1; j < n; j++) { [matrix[i][j], matrix[j][i]] = [matrix[j][i], matrix[i][j]]; } } for (const row of matrix) { row.reverse(); } } ``` ```java + public class Main { public static void main(String[] args) { int[][] matrix = { {1, 2, 3}, {4, 5, 6}, {7, 8, 9} }; rotate(matrix); for (int[] row : matrix) { System.out.println(java.util.Arrays.toString(row)); } } static void rotate(int[][] matrix) { int n = matrix.length; for (int i = 0; i < n; i++) { for (int j = i + 1; j < n; j++) { int temp = matrix[i][j]; matrix[i][j] = matrix[j][i]; matrix[j][i] = temp; } } for (int[] row : matrix) { int left = 0, right = row.length - 1; while (left < right) { int temp = row[left]; row[left] = row[right]; row[right] = temp; left++; right--; } } } } ``` **Complexity:** Time O(n²), space O(1); the whole point of this problem is the in-place constraint. **Common mistakes:** transposing the full `n x n` range instead of only the upper triangle (`j in range(i+1, n)`), which transposes twice and undoes the operation. Also, allocating a new matrix and copying rotated values in, which works but violates the "in place" requirement the problem is explicitly testing. > **Remember:** only swap the upper triangle when transposing. Swapping the whole matrix undoes itself. ### Spiral Matrix [LeetCode 54](https://leetcode.com/problems/spiral-matrix/) — Matrix **Intuition:** Walk the matrix in a shrinking rectangular spiral: right across the top row, down the right column, left across the bottom row, up the left column, then shrink the boundary and repeat. **Approach:** Maintain four boundaries (`top`, `bottom`, `left`, `right`). Traverse each side in order, then move the corresponding boundary inward. Stop when the boundaries cross. ```python def spiralOrder(matrix: list[list[int]]) -> list[int]: if not matrix: return [] result = [] top, bottom = 0, len(matrix) - 1 left, right = 0, len(matrix[0]) - 1 while top <= bottom and left <= right: for col in range(left, right + 1): result.append(matrix[top][col]) top += 1 for row in range(top, bottom + 1): result.append(matrix[row][right]) right -= 1 if top <= bottom: for col in range(right, left - 1, -1): result.append(matrix[bottom][col]) bottom -= 1 if left <= right: for row in range(bottom, top - 1, -1): result.append(matrix[row][left]) left -= 1 return result ``` ```javascript + function spiralOrder(matrix) { if (matrix.length === 0) return []; const result = []; let top = 0, bottom = matrix.length - 1; let left = 0, right = matrix[0].length - 1; while (top <= bottom && left <= right) { for (let col = left; col <= right; col++) { result.push(matrix[top][col]); } top++; for (let row = top; row <= bottom; row++) { result.push(matrix[row][right]); } right--; if (top <= bottom) { for (let col = right; col >= left; col--) { result.push(matrix[bottom][col]); } bottom--; } if (left <= right) { for (let row = bottom; row >= top; row--) { result.push(matrix[row][left]); } left++; } } return result; } ``` ```java + import java.util.*; public class Main { public static void main(String[] args) { int[][] matrix = { {1, 2, 3}, {4, 5, 6}, {7, 8, 9} }; System.out.println(spiralOrder(matrix)); } static List spiralOrder(int[][] matrix) { List result = new ArrayList<>(); if (matrix.length == 0) return result; int top = 0, bottom = matrix.length - 1; int left = 0, right = matrix[0].length - 1; while (top <= bottom && left <= right) { for (int col = left; col <= right; col++) { result.add(matrix[top][col]); } top++; for (int row = top; row <= bottom; row++) { result.add(matrix[row][right]); } right--; if (top <= bottom) { for (int col = right; col >= left; col--) { result.add(matrix[bottom][col]); } bottom--; } if (left <= right) { for (int row = bottom; row >= top; row--) { result.add(matrix[row][left]); } left++; } } return result; } } ``` **Complexity:** Time O(rows x cols), since every cell is visited exactly once. Space O(1) extra (excluding the output list). **Common mistakes:** leaving out the `if top <= bottom` / `if left <= right` guards before the bottom-row and left-column traversals. Without them, a single-row or single-column matrix gets its edge cells double-counted. Also, an off-by-one on boundary updates: `top += 1` happens after finishing the top row, not before. > **Remember:** four shrinking boundaries, four directions. The two guard checks before the last two sides are what stop a thin matrix from double-counting cells. ### Count Primes [LeetCode 204](https://leetcode.com/problems/count-primes/) — Math **Intuition:** Counting primes below `n` one by one with `is_prime` is O(n sqrt(n)), too slow for large n. The **Sieve of Eratosthenes** flips the approach: instead of testing each number for primality, start with everything marked "possibly prime" and cross out multiples of each prime as you find one, in O(n log log n) total. **Approach:** Build a boolean array of size `n`, all `True` initially. Starting from 2, for every number still marked prime, cross out all its multiples. Count the remaining `True` entries. ```python def countPrimes(n: int) -> int: if n < 3: return 0 is_prime_arr = [True] * n is_prime_arr[0] = is_prime_arr[1] = False for i in range(2, int(n ** 0.5) + 1): if is_prime_arr[i]: for multiple in range(i * i, n, i): # start at i*i: smaller multiples already crossed out is_prime_arr[multiple] = False return sum(is_prime_arr) ``` ```javascript + function countPrimes(n) { if (n < 3) return 0; const isPrimeArr = new Array(n).fill(true); isPrimeArr[0] = isPrimeArr[1] = false; for (let i = 2; i * i <= n; i++) { if (isPrimeArr[i]) { for (let multiple = i * i; multiple < n; multiple += i) { // start at i*i: smaller multiples already crossed out isPrimeArr[multiple] = false; } } } return isPrimeArr.filter(Boolean).length; } ``` ```java + public class Main { public static void main(String[] args) { System.out.println(countPrimes(20)); } static int countPrimes(int n) { if (n < 3) return 0; boolean[] isPrimeArr = new boolean[n]; java.util.Arrays.fill(isPrimeArr, true); isPrimeArr[0] = isPrimeArr[1] = false; for (int i = 2; (long) i * i <= n; i++) { if (isPrimeArr[i]) { for (int multiple = i * i; multiple < n; multiple += i) { // start at i*i: smaller multiples already crossed out isPrimeArr[multiple] = false; } } } int count = 0; for (boolean prime : isPrimeArr) { if (prime) count++; } return count; } } ``` **Complexity:** Time O(n log log n), space O(n). **Common mistakes:** starting the inner crossing-out loop at `2*i` instead of `i*i`. Both are correct, but `i*i` is the standard optimization since smaller multiples of `i` were already crossed out by smaller primes. Also, forgetting the outer loop only needs to run up to `sqrt(n)`: any composite number below n has a factor at or below `sqrt(n)`, so all composites are caught by then. **A closely related task:** you may be asked to return the actual list of primes, not just a count. The sieve barely changes: instead of summing the boolean array, collect the indices where it's still `True`. ```python def sieve_of_eratosthenes(n: int) -> list[int]: """Return all primes strictly less than n.""" if n < 3: return [] is_prime_arr = [True] * n is_prime_arr[0] = is_prime_arr[1] = False for i in range(2, int(n ** 0.5) + 1): if is_prime_arr[i]: for multiple in range(i * i, n, i): is_prime_arr[multiple] = False return [i for i, prime in enumerate(is_prime_arr) if prime] ``` ```javascript + function sieveOfEratosthenes(n) { // Return all primes strictly less than n. if (n < 3) return []; const isPrimeArr = new Array(n).fill(true); isPrimeArr[0] = isPrimeArr[1] = false; for (let i = 2; i * i <= n; i++) { if (isPrimeArr[i]) { for (let multiple = i * i; multiple < n; multiple += i) { isPrimeArr[multiple] = false; } } } return isPrimeArr.reduce((primes, isPrime, i) => { if (isPrime) primes.push(i); return primes; }, []); } ``` ```java + import java.util.*; public class Main { public static void main(String[] args) { System.out.println(sieveOfEratosthenes(20)); } // Return all primes strictly less than n. static List sieveOfEratosthenes(int n) { if (n < 3) return new ArrayList<>(); boolean[] isPrimeArr = new boolean[n]; Arrays.fill(isPrimeArr, true); isPrimeArr[0] = isPrimeArr[1] = false; for (int i = 2; (long) i * i <= n; i++) { if (isPrimeArr[i]) { for (int multiple = i * i; multiple < n; multiple += i) { isPrimeArr[multiple] = false; } } } List primes = new ArrayList<>(); for (int i = 0; i < n; i++) { if (isPrimeArr[i]) primes.add(i); } return primes; } } ``` > **Remember:** don't test each number for primality one at a time. Cross out multiples of every prime you find, and everything left standing is prime. ### Pow(x, n) [LeetCode 50](https://leetcode.com/problems/powx-n/) — Math — Binary exponentiation **Intuition:** Computing `x^n` by multiplying `x` by itself `n` times is O(n). **Binary (fast) exponentiation** uses `x^n = (x^(n//2))^2`, times an extra `x` if `n` is odd, to halve the problem size at every step, giving O(log n). **Approach:** Repeatedly square the base and halve the exponent, either recursively or iteratively. Handle negative exponents by inverting at the start (`x^-n = 1 / x^n`). ```python def myPow(x: float, n: int) -> float: if n < 0: x = 1 / x n = -n result = 1 while n > 0: if n % 2 == 1: result *= x x *= x n //= 2 return result ``` ```javascript + function myPow(x, n) { if (n < 0) { x = 1 / x; n = -n; } let result = 1; while (n > 0) { if (n % 2 === 1) { result *= x; } x *= x; n = Math.floor(n / 2); } return result; } ``` ```java + public class Main { public static void main(String[] args) { System.out.println(myPow(2.0, 10)); } static double myPow(double x, int n) { long exponent = n; if (exponent < 0) { x = 1 / x; exponent = -exponent; } double result = 1; while (exponent > 0) { if (exponent % 2 == 1) { result *= x; } x *= x; exponent /= 2; } return result; } } ``` **Complexity:** Time O(log n), space O(1) for the iterative version; the recursive version is O(log n) time but O(log n) space for the call stack. **Common mistakes:** the naive O(n) repeated-multiplication approach is correct but too slow, so always mention the fast-exponentiation follow-up even if you start with the naive version. Also, mishandling `n = 0` (any `x^0 = 1`, including `0^0` by this problem's convention) or negative `n` (invert `x` and negate `n` *before* the loop, not after). Floating-point precision drift on very large `n` is acceptable for LeetCode's tolerance, but worth naming as a real-world caveat. > **Remember:** squaring the base and halving the exponent turns O(n) multiplications into O(log n). The same trick powers matrix exponentiation and modular exponentiation elsewhere in computing. ### Reverse Integer [LeetCode 7 · Reverse Integer](https://leetcode.com/problems/reverse-integer/) — Math — Overflow handling **Intuition:** Reverse the digits of a 32-bit signed integer, returning `0` if the result would overflow `[-2^31, 2^31 - 1]`. It's the same shape of problem as `Pow(x, n)`'s overflow question above: the naive version works fine, and the interview is really about handling overflow and edge cases correctly. **Approach 1: string conversion.** Works, but relies on string allocation, and only catches overflow *after the fact*, since Python integers are unbounded. Most interviewers push you toward the math approach next. ```python def reverse_v1(x: int) -> int: sign = -1 if x < 0 else 1 rev = int(str(abs(x))[::-1]) * sign return rev if -(2**31) <= rev <= 2**31 - 1 else 0 ``` **Approach 2: digit extraction with an overflow check before it happens.** This is the answer interviewers are actually looking for. ```python def reverse(x: int) -> int: INT_MIN, INT_MAX = -(2**31), 2**31 - 1 result = 0 sign = -1 if x < 0 else 1 x = abs(x) while x != 0: digit = x % 10 x //= 10 # check BEFORE updating result — after would already have overflowed if result > INT_MAX // 10 or (result == INT_MAX // 10 and digit > 7): return 0 result = result * 10 + digit return sign * result ``` **Why check before, not after:** in a language with fixed-width integers (Java, C++), `result * 10 + digit` overflows *during* the computation. By the time you could check the result, it's already wrong: undefined behavior in C++, silent wraparound in Java. Checking `result > INT_MAX // 10` beforehand, since that condition means the next multiply would overflow, avoids ever computing the bad value. **Why `digit > 7` specifically:** `2^31 - 1 = 2147483647`, and its last digit is `7`. If `result == INT_MAX // 10` exactly, the only digit that keeps the result in bounds is 7 or less; anything higher overflows. **Complexity:** Time O(log10 x), one iteration per digit. Space O(1). **Common mistakes:** treating this as a Python-only problem and skipping the overflow check, since Python integers never overflow on their own. State the portability point out loud: a Python-only solution could reverse first and clamp after, and it would still pass this problem's tests. But that wouldn't hold up in Java or C++, where the multiply-add itself overflows before you get a chance to check anything. Approach 2's before-the-fact check is the one that translates directly to a fixed-width-integer language, and that's usually what the interviewer is actually testing. > **Remember:** check for overflow before the operation that would cause it, not after. In a fixed-width language, "after" is already too late. 45:T6e65,Think of building a sentence by gluing words together one at a time versus writing every word on a sticky note first and then reading them off in one go. The second way is faster, and it's exactly the difference between slow and fast string code. String problems mix two skills you've already built, sliding windows and frequency counting, with the specifics of building strings efficiently and matching patterns inside them. This lesson closes out the strings arc with harder sliding-window variants, an anagram-detection pattern you'll reuse constantly, and a classic string-matching algorithm. ## String building In Python, strings are immutable. Every `s += char` creates a brand-new string, which makes naive concatenation in a loop **O(n²)** overall, since each of the n appends copies the whole string built so far. ```python # O(n^2) - avoid in a loop result = "" for ch in "abcdef": result += ch # O(n) - build a list, join once parts = [] for ch in "abcdef": parts.append(ch) result = "".join(parts) ``` ```javascript + // O(n^2) - avoid in a loop let result = ""; for (const ch of "abcdef") { result += ch; } // O(n) - build an array, join once const parts = []; for (const ch of "abcdef") { parts.push(ch); } result = parts.join(""); ``` ```java + public class Main { public static void main(String[] args) { // O(n^2) - avoid in a loop: String is immutable, += allocates a new String each time String result = ""; for (char ch : "abcdef".toCharArray()) { result += ch; } // O(n) - build with StringBuilder, convert once StringBuilder parts = new StringBuilder(); for (char ch : "abcdef".toCharArray()) { parts.append(ch); } result = parts.toString(); System.out.println(result); } } ``` `"".join(list_of_strings)` is the idiomatic O(n) pattern: it computes the final length once and allocates a single buffer, instead of reallocating on every append. This matters specifically when a problem asks you to build a result string inside a loop that could run thousands of times. > **Remember:** collect pieces in a list, then join once at the end. Never `+=` a string inside a loop that could run many times. ```knowledge-check { "questions": [ { "id": "dsa-strings-building-q1", "type": "mcq", "prompt": "Why is repeatedly doing result += ch inside a loop O(n²) in Python, while collecting pieces in a list and joining once is O(n)?", "options": [ {"id": "a", "text": "Strings are immutable, so every += allocates a brand-new string and copies everything built so far; join() allocates one buffer at the end instead"}, {"id": "b", "text": "Python lists are always faster than strings regardless of the operation"}, {"id": "c", "text": "The += operator is disabled for strings longer than 100 characters"}, {"id": "d", "text": "join() runs on a separate CPU thread"} ], "correct": "a", "explanation": "Each += on an immutable string copies the entire string-so-far into a new object. Over n appends, that's O(1 + 2 + ... + n) = O(n^2) total copying, versus one O(n) allocation for join()." } ] } ``` ## Pattern matching "Does string A appear inside string B" shows up disguised in many forms: substring search, anagram windows, repeated patterns. The naive approach checks every starting position in B against A character by character: **O(n·m)** where n = len(B), m = len(A). Two techniques improve on this: 1. **Sliding window with frequency counts.** When you're looking for anagrams or permutations of A within B, rather than an exact substring match, keep a frequency map of A and compare it against a same-size window's frequency map as it slides. This skips re-scanning m characters at every position. 2. **Rabin-Karp (rolling hash).** When you need exact substring matches, hash A once, then compute B's window hashes incrementally, an O(1) update per shift, instead of rehashing the whole window each time. Covered later in this lesson. > **Remember:** "does A's pattern appear anywhere in B" is either a sliding frequency-map comparison (for anagrams) or a rolling hash (for exact substrings). Both beat rescanning from scratch at every position. ```knowledge-check { "questions": [ { "id": "dsa-strings-pattern-matching-q1", "type": "mcq", "prompt": "When looking for every window in B that's an anagram of A, why is comparing frequency maps better than comparing sorted substrings at every position?", "options": [ {"id": "a", "text": "A sliding frequency map can be updated incrementally in O(1) per shift, instead of re-sorting or rebuilding a full comparison at every position"}, {"id": "b", "text": "Frequency maps only work on lowercase letters"}, {"id": "c", "text": "Sorting substrings is always O(1)"}, {"id": "d", "text": "There's no difference in performance between the two approaches"} ], "correct": "a", "explanation": "As the window slides by one, only two characters change: one leaves, one enters. Updating counts for just those two is far cheaper than re-deriving the whole window's signature from scratch." } ] } ``` ## Anagram detection Two strings are anagrams if they contain exactly the same characters with the same multiplicities. The standard check: compare a `Counter` (or a fixed-size frequency array) of both strings. ```python from collections import Counter def is_anagram(s: str, t: str) -> bool: return Counter(s) == Counter(t) ``` ```javascript + function isAnagram(s, t) { const count = (str) => { const map = new Map(); for (const ch of str) { map.set(ch, (map.get(ch) || 0) + 1); } return map; }; const sCount = count(s); const tCount = count(t); if (sCount.size !== tCount.size) return false; for (const [ch, freq] of sCount) { if (tCount.get(ch) !== freq) return false; } return true; } ``` ```java + import java.util.*; public class Main { public static void main(String[] args) { System.out.println(isAnagram("listen", "silent")); } static boolean isAnagram(String s, String t) { if (s.length() != t.length()) return false; Map counts = new HashMap<>(); for (char ch : s.toCharArray()) { counts.merge(ch, 1, Integer::sum); } for (char ch : t.toCharArray()) { counts.merge(ch, -1, Integer::sum); } for (int freq : counts.values()) { if (freq != 0) return false; } return true; } } ``` For **sliding-window anagram search** (find every window of B that's an anagram of A), keep a running frequency count for the current window and compare it to A's frequency count incrementally instead of rebuilding it every shift: ```python def find_anagram_windows(s: str, p: str) -> list[int]: if len(p) > len(s): return [] p_count = Counter(p) window_count = Counter(s[:len(p)]) result = [] if window_count == p_count: result.append(0) for i in range(len(p), len(s)): left_char = s[i - len(p)] window_count[s[i]] += 1 window_count[left_char] -= 1 if window_count[left_char] == 0: del window_count[left_char] if window_count == p_count: result.append(i - len(p) + 1) return result ``` ```javascript + function findAnagramWindows(s, p) { if (p.length > s.length) return []; const countOf = (str) => { const map = new Map(); for (const ch of str) { map.set(ch, (map.get(ch) || 0) + 1); } return map; }; const mapsEqual = (a, b) => { if (a.size !== b.size) return false; for (const [key, val] of a) { if (b.get(key) !== val) return false; } return true; }; const pCount = countOf(p); const windowCount = countOf(s.slice(0, p.length)); const result = []; if (mapsEqual(windowCount, pCount)) { result.push(0); } for (let i = p.length; i < s.length; i++) { const leftChar = s[i - p.length]; windowCount.set(s[i], (windowCount.get(s[i]) || 0) + 1); windowCount.set(leftChar, windowCount.get(leftChar) - 1); if (windowCount.get(leftChar) === 0) { windowCount.delete(leftChar); } if (mapsEqual(windowCount, pCount)) { result.push(i - p.length + 1); } } return result; } ``` ```java + import java.util.*; public class Main { public static void main(String[] args) { System.out.println(findAnagramWindows("cbaebabacd", "abc")); } static List findAnagramWindows(String s, String p) { List result = new ArrayList<>(); if (p.length() > s.length()) return result; Map pCount = new HashMap<>(); for (char ch : p.toCharArray()) { pCount.merge(ch, 1, Integer::sum); } Map windowCount = new HashMap<>(); for (int i = 0; i < p.length(); i++) { windowCount.merge(s.charAt(i), 1, Integer::sum); } if (windowCount.equals(pCount)) { result.add(0); } for (int i = p.length(); i < s.length(); i++) { char leftChar = s.charAt(i - p.length()); windowCount.merge(s.charAt(i), 1, Integer::sum); windowCount.merge(leftChar, -1, Integer::sum); if (windowCount.get(leftChar) == 0) { windowCount.remove(leftChar); } if (windowCount.equals(pCount)) { result.add(i - p.length() + 1); } } return result; } } ``` **Complexity:** O(n) amortized if you avoid the O(26) `Counter == Counter` comparison per step. One optimization: track a running `matches` integer instead of comparing full Counters (see Find All Anagrams below for the fully optimized version). The version above is O(n · 26) worst case, still effectively linear since the alphabet is bounded. > **Remember:** two strings are anagrams exactly when their character counts match. Sliding that count window, instead of rebuilding it, is what makes the search fast. ```knowledge-check { "questions": [ { "id": "dsa-strings-anagram-detection-q1", "type": "mcq", "prompt": "What's the standard check for whether two strings are anagrams of each other?", "options": [ {"id": "a", "text": "Compare a character frequency count (like a Counter) of both strings; they're anagrams if the counts match exactly"}, {"id": "b", "text": "Compare the strings' lengths only"}, {"id": "c", "text": "Check whether the first characters of both strings match"}, {"id": "d", "text": "Reverse one string and check if it equals the other"} ], "correct": "a", "explanation": "Anagrams contain exactly the same characters with the same multiplicities, which is precisely what comparing two frequency counts verifies." } ] } ``` ### Longest Substring with At Least K Repeating Characters [LeetCode 395](https://leetcode.com/problems/longest-substring-with-at-least-k-repeating-characters/) — String **Intuition:** Any character appearing fewer than `k` times anywhere in the current substring can never be part of a valid answer: it disqualifies every substring that contains it. So find such a "bad" character, split the string at every occurrence of it, and recurse on each piece. This is divide-and-conquer, not sliding window, since the set of distinct characters and their positions don't slide cleanly here. **Approach:** Count character frequencies in the current substring. If every frequency is at least k, the whole substring is valid, so return its length. Otherwise, split on the first character with frequency below k and recurse on each side, taking the max. ```python def longestSubstring(s: str, k: int) -> int: if len(s) < k: return 0 counts = Counter(s) for ch, freq in counts.items(): if freq < k: return max(longestSubstring(part, k) for part in s.split(ch)) return len(s) # every character meets the threshold ``` ```javascript + function longestSubstring(s, k) { if (s.length < k) return 0; const counts = new Map(); for (const ch of s) { counts.set(ch, (counts.get(ch) || 0) + 1); } for (const [ch, freq] of counts) { if (freq < k) { return Math.max(...s.split(ch).map((part) => longestSubstring(part, k))); } } return s.length; // every character meets the threshold } ``` ```java + import java.util.*; import java.util.regex.Pattern; public class Main { public static void main(String[] args) { System.out.println(longestSubstring("aaabb", 3)); } static int longestSubstring(String s, int k) { if (s.length() < k) return 0; Map counts = new HashMap<>(); for (char ch : s.toCharArray()) { counts.merge(ch, 1, Integer::sum); } for (Map.Entry entry : counts.entrySet()) { if (entry.getValue() < k) { int best = 0; String splitPattern = Pattern.quote(String.valueOf(entry.getKey())); for (String part : s.split(splitPattern)) { best = Math.max(best, longestSubstring(part, k)); } return best; } } return s.length(); // every character meets the threshold } } ``` **Complexity:** Time O(n × 26) in the typical case: each recursion level does O(n) work, and the recursion depth is bounded by the 26-letter alphabet, since each split removes at least one distinct character entirely. Space O(n) for recursion and split copies. **Common mistakes:** trying to force this into a sliding-window shape. The "at least K repeats" condition isn't monotonic in a way that supports a simple expand/contract two-pointer approach, which is why divide-and-conquer is the right tool here. Also, forgetting the base case `len(s) < k`, which would otherwise recurse forever on tiny fragments. > **Remember:** a character below the K-repeat threshold poisons every substring containing it. Split it out and recurse on the two clean halves. ### Find All Anagrams in a String [LeetCode 438](https://leetcode.com/problems/find-all-anagrams-in-a-string/) — String **Intuition:** Exactly the "sliding-window anagram search" pattern from the concept section: find every starting index in `s` where a fixed-size window is an anagram of `p`. **Approach:** A fixed-size window of length `len(p)`. Keep frequency counts and a `matches` counter, how many of the 26 letters currently have equal counts in both windows, to avoid comparing full frequency maps every shift: an O(1) per-step check instead of O(26). ```python def findAnagrams(s: str, p: str) -> list[int]: if len(p) > len(s): return [] p_count = [0] * 26 s_count = [0] * 26 for ch in p: p_count[ord(ch) - ord('a')] += 1 result = [] window_len = len(p) for i in range(len(s)): s_count[ord(s[i]) - ord('a')] += 1 if i >= window_len: left_char = s[i - window_len] s_count[ord(left_char) - ord('a')] -= 1 if i >= window_len - 1 and s_count == p_count: result.append(i - window_len + 1) return result ``` ```javascript + function findAnagrams(s, p) { if (p.length > s.length) return []; const pCount = new Array(26).fill(0); const sCount = new Array(26).fill(0); const aCode = 'a'.charCodeAt(0); for (const ch of p) { pCount[ch.charCodeAt(0) - aCode]++; } const result = []; const windowLen = p.length; for (let i = 0; i < s.length; i++) { sCount[s.charCodeAt(i) - aCode]++; if (i >= windowLen) { const leftChar = s[i - windowLen]; sCount[leftChar.charCodeAt(0) - aCode]--; } if (i >= windowLen - 1 && sCount.every((count, idx) => count === pCount[idx])) { result.push(i - windowLen + 1); } } return result; } ``` ```java + import java.util.*; public class Main { public static void main(String[] args) { System.out.println(findAnagrams("cbaebabacd", "abc")); } static List findAnagrams(String s, String p) { List result = new ArrayList<>(); if (p.length() > s.length()) return result; int[] pCount = new int[26]; int[] sCount = new int[26]; for (char ch : p.toCharArray()) { pCount[ch - 'a']++; } int windowLen = p.length(); for (int i = 0; i < s.length(); i++) { sCount[s.charAt(i) - 'a']++; if (i >= windowLen) { char leftChar = s.charAt(i - windowLen); sCount[leftChar - 'a']--; } if (i >= windowLen - 1 && Arrays.equals(sCount, pCount)) { result.add(i - windowLen + 1); } } return result; } } ``` **Complexity:** Time O(n × 26): the array comparison `s_count == p_count` is O(26), effectively O(1) since the alphabet is bounded, giving overall O(n). Space O(26) = O(1). **Common mistakes:** comparing `Counter` objects every iteration without noticing the alphabet is a bounded constant. Still fine here since 26 is a constant, but worth explicitly noting to the interviewer that this is O(1) per check, not O(n). Also, an off-by-one on when the window becomes "full": `i >= window_len - 1` is the first index at which a complete window exists. > **Remember:** a fixed-size window, two 26-slot count arrays, one array-equality check per shift. That's the whole algorithm. ### Minimum Window Substring [LeetCode 76](https://leetcode.com/problems/minimum-window-substring/) — String — Review **Intuition:** Find the smallest window in `s` containing every character of `t`, with at least their required counts. A classic variable-size sliding window: expand `right` until the window is valid (contains everything needed), then contract `left` as far as possible while it stays valid, recording the best window found. **Approach:** Track required character counts from `t`. Expand `right`, decrementing a "still needed" counter whenever an added character helps satisfy a requirement. Once that counter hits 0 (window is valid), shrink `left` while validity holds, updating the best window at each fully-valid state. ```python def minWindow(s: str, t: str) -> str: if not s or not t: return "" need = Counter(t) missing = len(t) # total characters still needed (with multiplicity) left = 0 best_left, best_len = 0, float('inf') for right, ch in enumerate(s): if need[ch] > 0: missing -= 1 need[ch] -= 1 while missing == 0: if right - left + 1 < best_len: best_left, best_len = left, right - left + 1 need[s[left]] += 1 if need[s[left]] > 0: missing += 1 left += 1 return s[best_left:best_left + best_len] if best_len != float('inf') else "" ``` ```javascript + function minWindow(s, t) { if (!s || !t) return ""; const need = new Map(); for (const ch of t) { need.set(ch, (need.get(ch) || 0) + 1); } let missing = t.length; // total characters still needed (with multiplicity) let left = 0; let bestLeft = 0; let bestLen = Infinity; for (let right = 0; right < s.length; right++) { const ch = s[right]; if ((need.get(ch) || 0) > 0) { missing--; } need.set(ch, (need.get(ch) || 0) - 1); while (missing === 0) { if (right - left + 1 < bestLen) { bestLeft = left; bestLen = right - left + 1; } const leftChar = s[left]; need.set(leftChar, (need.get(leftChar) || 0) + 1); if (need.get(leftChar) > 0) { missing++; } left++; } } return bestLen === Infinity ? "" : s.slice(bestLeft, bestLeft + bestLen); } ``` ```java + import java.util.*; public class Main { public static void main(String[] args) { System.out.println(minWindow("ADOBECODEBANC", "ABC")); } static String minWindow(String s, String t) { if (s.isEmpty() || t.isEmpty()) return ""; Map need = new HashMap<>(); for (char ch : t.toCharArray()) { need.merge(ch, 1, Integer::sum); } int missing = t.length(); // total characters still needed (with multiplicity) int left = 0; int bestLeft = 0; int bestLen = Integer.MAX_VALUE; for (int right = 0; right < s.length(); right++) { char ch = s.charAt(right); if (need.getOrDefault(ch, 0) > 0) { missing--; } need.merge(ch, -1, Integer::sum); while (missing == 0) { if (right - left + 1 < bestLen) { bestLeft = left; bestLen = right - left + 1; } char leftChar = s.charAt(left); need.merge(leftChar, 1, Integer::sum); if (need.get(leftChar) > 0) { missing++; } left++; } } return bestLen == Integer.MAX_VALUE ? "" : s.substring(bestLeft, bestLeft + bestLen); } } ``` **Complexity:** Time O(n + m) where n = len(s), m = len(t): each index enters and leaves the window at most once. Space O(m) for the `need` counter (bounded by the distinct characters in `t`). **Common mistakes:** using `need[ch] > 0` as the sole gate for decrementing `missing` correctly ignores characters not in `t` or already over-satisfied, but it's easy to instead decrement `missing` unconditionally, which breaks when duplicate or extra characters appear in the window. This is a genuinely hard sliding-window problem, worth revisiting the Sliding Window lessons' variable-window material if it doesn't come back quickly. > **Remember:** expand until valid, then shrink while still valid, recording the best window at every fully-valid moment. That expand/shrink rhythm is the whole trick. ### Rabin-Karp Algorithm LeetCode implement: String **Intuition:** To find a pattern `p` inside text `s`, naive matching re-compares up to `m` characters at every one of `n` positions (O(n·m)). Rabin-Karp instead hashes the pattern once, then slides a window across `s`, updating the window's hash in **O(1) per shift** with a rolling hash formula, falling back to a full character comparison only when hashes match, to rule out hash collisions. **Approach:** Compute the pattern's hash and the first window's hash using a polynomial rolling hash (base `B`, modulus `M` to bound the value size). At each shift, remove the leaving character's contribution and add the entering character's contribution in O(1). Compare hashes; on a match, verify with a direct substring comparison to handle the rare hash collision. ```python def rabin_karp(text: str, pattern: str) -> list[int]: n, m = len(text), len(pattern) if m > n or m == 0: return [] BASE = 256 MOD = 10 ** 9 + 7 high_order = pow(BASE, m - 1, MOD) # BASE^(m-1) mod MOD, for removing the leading digit pattern_hash = 0 window_hash = 0 for i in range(m): pattern_hash = (pattern_hash * BASE + ord(pattern[i])) % MOD window_hash = (window_hash * BASE + ord(text[i])) % MOD matches = [] for i in range(n - m + 1): if pattern_hash == window_hash: if text[i:i + m] == pattern: # verify to rule out a hash collision matches.append(i) if i + m < n: window_hash = (window_hash - ord(text[i]) * high_order) % MOD window_hash = (window_hash * BASE + ord(text[i + m])) % MOD window_hash %= MOD return matches ``` ```javascript + function rabinKarp(text, pattern) { const n = text.length; const m = pattern.length; if (m > n || m === 0) return []; const BASE = 256n; const MOD = 1000000007n; let highOrder = 1n; for (let i = 0; i < m - 1; i++) { highOrder = (highOrder * BASE) % MOD; // BASE^(m-1) mod MOD, for removing the leading digit } let patternHash = 0n; let windowHash = 0n; for (let i = 0; i < m; i++) { patternHash = (patternHash * BASE + BigInt(pattern.charCodeAt(i))) % MOD; windowHash = (windowHash * BASE + BigInt(text.charCodeAt(i))) % MOD; } const matches = []; for (let i = 0; i <= n - m; i++) { if (patternHash === windowHash) { if (text.slice(i, i + m) === pattern) { // verify to rule out a hash collision matches.push(i); } } if (i + m < n) { windowHash = (windowHash - BigInt(text.charCodeAt(i)) * highOrder) % MOD; windowHash = (windowHash * BASE + BigInt(text.charCodeAt(i + m))) % MOD; windowHash = ((windowHash % MOD) + MOD) % MOD; } } return matches; } ``` ```java + import java.util.*; public class Main { public static void main(String[] args) { System.out.println(rabinKarp("ababcababcabc", "abc")); } static List rabinKarp(String text, String pattern) { int n = text.length(); int m = pattern.length(); List matches = new ArrayList<>(); if (m > n || m == 0) return matches; final long BASE = 256; final long MOD = 1_000_000_007L; long highOrder = 1; for (int i = 0; i < m - 1; i++) { highOrder = (highOrder * BASE) % MOD; // BASE^(m-1) mod MOD, for removing the leading digit } long patternHash = 0; long windowHash = 0; for (int i = 0; i < m; i++) { patternHash = (patternHash * BASE + pattern.charAt(i)) % MOD; windowHash = (windowHash * BASE + text.charAt(i)) % MOD; } for (int i = 0; i <= n - m; i++) { if (patternHash == windowHash) { if (text.substring(i, i + m).equals(pattern)) { // verify to rule out a hash collision matches.add(i); } } if (i + m < n) { windowHash = (windowHash - text.charAt(i) * highOrder % MOD + MOD) % MOD; windowHash = (windowHash * BASE + text.charAt(i + m)) % MOD; } } return matches; } } ``` **Complexity:** Average time O(n + m): O(1) rolling update per shift, with occasional O(m) verification on hash matches, which is rare if MOD is large relative to collision risk. Worst case O(n·m) if many spurious hash collisions occur, mitigated by a large prime modulus. Space O(1) extra beyond the output. **Common mistakes:** letting the hash grow unbounded without a modulus. That's fine in Python's arbitrary-precision integers, but it defeats the purpose of a fixed-size rolling hash and is wrong in most other languages, worth mentioning if portability comes up. Also, skipping the verification step after a hash match, which risks a false positive on a genuine collision. And getting the rolling-hash update formula's sign wrong when removing the leaving character: you must subtract `leaving_char * BASE^(m-1)` **before** re-multiplying by `BASE`, not after. > **Remember:** hash once, slide the hash in O(1) per step, and always verify a hash match with a real character comparison before trusting it. Notice the shape common to Find All Anagrams, Minimum Window Substring, and Rabin-Karp: each replaces a per-position O(alphabet) or O(pattern-length) recheck with an O(1) incremental update, whether that's a match counter, a "missing" tally, or a rolling hash. That trade, recomputing nothing you can update instead, is the real skill this lesson teaches. 46:Ta244,A fire drill doesn't teach you anything new about where the exits are. It proves you can find them fast, in the dark, without thinking. This lesson is a fire drill for every pattern you've learned in this course: no new data structures, no new algorithms, just rehearsal until pulling out the right tool is automatic. It walks through six mock problems the way you'd actually talk through them in an interview, drills the fastest patterns until they're instant, and ends with two recall sheets you can run through before any interview. ## Talking through a mock problem, start to finish Use this exact shape for every coding problem in an interview, timed or not: 1. **Restate the problem in your own words** (about 30 seconds). This catches misunderstandings while they're still free to fix. 2. **Ask 1-2 clarifying questions.** Input size, duplicates allowed, negative numbers, empty input; whatever the problem statement left ambiguous. 3. **State a brute-force approach and its complexity out loud, before optimizing.** Interviewers reward the reasoning path, not just the final answer. 4. **Code the optimized approach, narrating as you go.** Silence while typing is the single worst signal you can send. 5. **Walk through one example by hand.** 6. **State the final time and space complexity, unprompted.** Pass-bar checklist to hold yourself to: the gap between "read the problem" and "start talking" is under 30 seconds; you keep talking while you code, not silent for five-plus minutes; you state complexity unprompted, correctly; you mention edge cases before or during coding, not only when asked; you notice and fix your own bugs while testing, without needing a hint. The six problems below are worked through this exact way. Read each problem yourself first, think about how you'd talk through it, then compare against the walkthrough. > **Remember:** restate, clarify, brute force out loud, optimize while narrating, walk an example, state complexity unprompted. Same six steps, every problem. ```knowledge-check { "questions": [ { "id": "dsa-mock-rounds-framework-q1", "type": "mcq", "prompt": "What should you do immediately after restating a coding problem, before writing any code?", "options": [ {"id": "a", "text": "Ask 1-2 clarifying questions about input size, duplicates, or edge cases, then state a brute-force approach and its complexity out loud"}, {"id": "b", "text": "Start typing the optimized solution right away to save time"}, {"id": "c", "text": "Ask the interviewer for a hint"}, {"id": "d", "text": "Write all your test cases before discussing any approach"} ], "correct": "a", "explanation": "Clarifying questions catch misunderstandings while they're cheap to fix, and stating the brute force with its complexity shows your reasoning process before you jump to the optimized code." } ] } ``` ### Two Sum and Longest Substring Without Repeating Characters **Two Sum.** Given an array of integers `nums` and an integer `target`, return the indices of the two numbers that add up to `target`. Assume exactly one solution exists, and you may not use the same element twice. ``` Input: nums = [2, 7, 11, 15], target = 9 Output: [0, 1] # nums[0] + nums[1] == 9 ``` Clarifying questions worth asking: can the array be unsorted (yes)? are there duplicate values (yes, `[3, 3]` with `target = 6` must work)? indices or values (indices, any order)? what if no solution exists (out of scope here, but say out loud what you'd do)? ```python def two_sum(nums: list[int], target: int) -> list[int]: seen: dict[int, int] = {} # value -> index for i, n in enumerate(nums): complement = target - n if complement in seen: return [seen[complement], i] seen[n] = i raise ValueError("no two sum solution") if __name__ == "__main__": assert two_sum([2, 7, 11, 15], 9) == [0, 1] assert two_sum([3, 3], 6) == [0, 1] assert sorted(two_sum([3, 2, 4], 6)) == [1, 2] print("ok") ``` Time: O(n), one pass. Space: O(n) for the hash map. Mention the brute force, O(n²)/O(1), then justify the trade up to hashing; interviews reward the reasoning as much as the answer. **Longest Substring Without Repeating Characters.** Given a string `s`, find the length of the longest substring without repeating characters. ``` Input: s = "abcabcbb" -> Output: 3 # "abc" Input: s = "bbbbb" -> Output: 1 # "b" Input: s = "pwwkew" -> Output: 3 # "wke" ``` Clarifying questions: character set (assume any Unicode character, not just lowercase)? empty string (return 0)? substring vs subsequence (substring: must be contiguous)? ```python def length_of_longest_substring(s: str) -> int: last_seen: dict[str, int] = {} start = 0 best = 0 for i, ch in enumerate(s): if ch in last_seen and last_seen[ch] >= start: start = last_seen[ch] + 1 last_seen[ch] = i best = max(best, i - start + 1) return best if __name__ == "__main__": assert length_of_longest_substring("abcabcbb") == 3 assert length_of_longest_substring("bbbbb") == 1 assert length_of_longest_substring("pwwkew") == 3 assert length_of_longest_substring("") == 0 print("ok") ``` Time: O(n) with a sliding window, since each index enters and exits the window once. Space: O(min(n, alphabet size)) for the map. The naive substring-by-substring check is O(n³); name it, then explain why the window collapses it. **How this pair gets scored (out of 5 each):** clarified the problem before coding (duplicates, edge cases, input assumptions); considered edge cases (empty input, no solution, single character); discussed time and space complexity for both the brute force and the optimized version; wrote clean code (meaningful names, no dead code). ### Merge Intervals Given an array of intervals where `intervals[i] = [start_i, end_i]`, merge all overlapping intervals and return an array of the non-overlapping intervals that cover all the intervals in the input. ``` Input: [[1,3],[2,6],[8,10],[15,18]] Output: [[1,6],[8,10],[15,18]] ``` Clarifying questions: is the input sorted (no, sort first)? do touching intervals count as overlapping, like `[1,3]` and `[3,5]` (yes here, treat `end_i >= start_{i+1}` as overlapping)? can intervals be malformed with `start > end` (assume valid, `start <= end`)? ```python def merge_intervals(intervals: list[list[int]]) -> list[list[int]]: if not intervals: return [] intervals.sort(key=lambda iv: iv[0]) merged = [intervals[0]] for start, end in intervals[1:]: last = merged[-1] if start <= last[1]: last[1] = max(last[1], end) else: merged.append([start, end]) return merged if __name__ == "__main__": assert merge_intervals([[1, 3], [2, 6], [8, 10], [15, 18]]) == [[1, 6], [8, 10], [15, 18]] assert merge_intervals([[1, 4], [4, 5]]) == [[1, 5]] assert merge_intervals([]) == [] print("ok") ``` Time: O(n log n) for the sort, then O(n) to sweep. Space: O(n) for the sort and output. The key insight: once sorted, overlap can only happen with the *most recently merged* interval, so one linear pass after sorting is enough; no nested loop needed. **Scoring:** clarified overlap semantics and the sort assumption before coding; handled edge cases (empty input, touching intervals, a single interval); stated time and space complexity unprompted; wrote clean code. ### Number of Islands Given an `m x n` 2D binary grid representing `'1'` (land) and `'0'` (water), return the number of islands. An island is surrounded by water and formed by connecting adjacent lands horizontally or vertically. ``` Input: [["1","1","0","0","0"], ["1","1","0","0","0"], ["0","0","1","0","0"], ["0","0","0","1","1"]] Output: 3 ``` Solve it with BFS first, then again with DFS, and compare the two. Clarifying questions: diagonal adjacency (no, only up/down/left/right)? can the grid be empty (yes, return 0)? can you mutate the input grid (if not, you need a separate `visited` set)? ```python from collections import deque def num_islands_dfs(grid: list[list[str]]) -> int: if not grid: return 0 rows, cols = len(grid), len(grid[0]) def dfs(r: int, c: int) -> None: if r < 0 or r >= rows or c < 0 or c >= cols or grid[r][c] != "1": return grid[r][c] = "0" # mark visited by sinking the island dfs(r + 1, c) dfs(r - 1, c) dfs(r, c + 1) dfs(r, c - 1) count = 0 for r in range(rows): for c in range(cols): if grid[r][c] == "1": count += 1 dfs(r, c) return count def num_islands_bfs(grid: list[list[str]]) -> int: if not grid: return 0 rows, cols = len(grid), len(grid[0]) count = 0 for r in range(rows): for c in range(cols): if grid[r][c] != "1": continue count += 1 queue = deque([(r, c)]) grid[r][c] = "0" while queue: cr, cc = queue.popleft() for nr, nc in ((cr + 1, cc), (cr - 1, cc), (cr, cc + 1), (cr, cc - 1)): if 0 <= nr < rows and 0 <= nc < cols and grid[nr][nc] == "1": grid[nr][nc] = "0" queue.append((nr, nc)) return count if __name__ == "__main__": g1 = [list(r) for r in ["11000", "11000", "00100", "00011"]] g2 = [list(r) for r in ["11000", "11000", "00100", "00011"]] assert num_islands_dfs(g1) == 3 assert num_islands_bfs(g2) == 3 print("ok") ``` **BFS vs DFS out loud:** both are O(rows x cols) time and O(rows x cols) worst-case space. DFS is simpler to write but risks a stack overflow on huge grids, since recursion depth is finite; for production code on unbounded input you'd convert it to an explicit stack. BFS's space is bounded by the frontier size rather than the call stack, at the cost of a little more bookkeeping (the queue). Leading with DFS for speed of writing, then naming BFS as the safer choice for large or unbounded grids, is the strongest answer. Keep this muscle warm with the same BFS/DFS-on-a-graph family: Clone Graph (DFS or BFS with a visited map to avoid infinite recursion on cycles), Pacific Atlantic Water Flow (multi-source BFS/DFS starting from both ocean borders inward), Walls and Gates (multi-source BFS starting from every gate at once). **Scoring:** solved correctly with both BFS and DFS; compared the two approaches' trade-offs (recursion depth risk, space characteristics) unprompted; handled edge cases (empty grid, all water, all land); wrote clean code in both versions. ### Longest Increasing Subsequence Given an integer array `nums`, return the length of the longest strictly increasing subsequence. ``` Input: nums = [10,9,2,5,3,7,101,18] Output: 4 # [2,3,7,101] ``` Solve with both DP (O(n²)) and binary search (O(n log n)), and explain both. Clarifying questions: strictly increasing or non-decreasing (strictly increasing)? subsequence, not subarray, so elements don't need to be contiguous (confirm before coding, since it changes the whole approach)? length only, or the subsequence itself (length only; reconstructing needs parent pointers)? ```python import bisect def length_of_lis_dp(nums: list[int]) -> int: """O(n^2) DP: dp[i] = length of LIS ending at index i.""" if not nums: return 0 dp = [1] * len(nums) for i in range(len(nums)): for j in range(i): if nums[j] < nums[i]: dp[i] = max(dp[i], dp[j] + 1) return max(dp) def length_of_lis_binary_search(nums: list[int]) -> int: """O(n log n): maintain 'tails', tails[k] = smallest possible tail of an increasing subsequence of length k+1. tails stays sorted, so binary search finds the insertion point.""" tails: list[int] = [] for n in nums: pos = bisect.bisect_left(tails, n) if pos == len(tails): tails.append(n) else: tails[pos] = n return len(tails) if __name__ == "__main__": nums = [10, 9, 2, 5, 3, 7, 101, 18] assert length_of_lis_dp(nums) == 4 assert length_of_lis_binary_search(nums) == 4 assert length_of_lis_binary_search([]) == 0 assert length_of_lis_binary_search([7, 7, 7]) == 1 print("ok") ``` **What to explain out loud:** the DP approach answers "longest increasing subsequence ending exactly at `i`," built from every valid `j < i`, O(n²). The binary-search approach reframes the problem: `tails[k]` tracks the smallest tail value achievable for any increasing subsequence of length `k+1`. `tails` is always sorted, since a smaller tail for the same length can only help extend further, which is exactly what makes binary search valid on it. `tails` does *not* hold an actual subsequence, it's a greedy invariant; say that explicitly. Keep this muscle warm with the same DP-over-prefixes-or-amounts family: Word Break (1D DP over string prefixes), Coin Change (1D DP over amounts), Edit Distance (2D DP over two string prefixes, from the Dynamic Programming: Two Dimensions lesson). **Scoring:** correctly implemented the O(n²) DP solution; correctly implemented and explained the O(n log n) binary-search solution, including why `tails` stays sorted; clearly contrasted the two approaches' complexity and trade-offs; handled edge cases (empty array, all-equal elements, strictly decreasing array). ### Merge K Sorted Lists You are given an array of `k` linked lists, each sorted in ascending order. Merge all the lists into one sorted linked list and return it. ``` Input: lists = [[1,4,5],[1,3,4],[2,6]] Output: [1,1,2,3,4,4,5,6] ``` Solve with a min-heap first, targeting O(N log k) where N is the total number of nodes and k is the number of lists. If time remains, implement divide-and-conquer as a second approach and compare. Clarifying questions: can `lists` be empty or contain empty lists (yes to both)? are values unique across lists (no, duplicates allowed)? in-place or a new list (either; reusing existing nodes is the expected style)? ```python import heapq from typing import Optional class ListNode: def __init__(self, val=0, next=None): self.val = val self.next = next def merge_k_lists_heap(lists: list[Optional[ListNode]]) -> Optional[ListNode]: """Push the head of every list into a min-heap. Pop the smallest, attach it to the output, and push its successor. The heap never holds more than k nodes, so each of the N pops/pushes costs O(log k).""" heap: list[tuple[int, int, ListNode]] = [] for i, node in enumerate(lists): if node: # tie-break on i (list index) since ListNode isn't orderable and # heapq needs a total order when values are equal. heapq.heappush(heap, (node.val, i, node)) dummy = ListNode() tail = dummy while heap: val, i, node = heapq.heappop(heap) tail.next = node tail = tail.next if node.next: heapq.heappush(heap, (node.next.val, i, node.next)) return dummy.next def merge_two_lists(a: Optional[ListNode], b: Optional[ListNode]) -> Optional[ListNode]: dummy = ListNode() tail = dummy while a and b: if a.val <= b.val: tail.next, a = a, a.next else: tail.next, b = b, b.next tail = tail.next tail.next = a or b return dummy.next def merge_k_lists_divide_and_conquer(lists: list[Optional[ListNode]]) -> Optional[ListNode]: """Pair up lists and merge two at a time, halving the count each round. Same O(N log k) bound as the heap, without needing a heap at all.""" if not lists: return None lists = list(lists) while len(lists) > 1: merged = [] for i in range(0, len(lists), 2): l1 = lists[i] l2 = lists[i + 1] if i + 1 < len(lists) else None merged.append(merge_two_lists(l1, l2)) lists = merged return lists[0] def build(values: list[int]) -> Optional[ListNode]: dummy = ListNode() tail = dummy for v in values: tail.next = ListNode(v) tail = tail.next return dummy.next def to_list(node: Optional[ListNode]) -> list[int]: out = [] while node: out.append(node.val) node = node.next return out if __name__ == "__main__": lists = [build([1, 4, 5]), build([1, 3, 4]), build([2, 6])] assert to_list(merge_k_lists_heap(lists)) == [1, 1, 2, 3, 4, 4, 5, 6] lists2 = [build([1, 4, 5]), build([1, 3, 4]), build([2, 6])] assert to_list(merge_k_lists_divide_and_conquer(lists2)) == [1, 1, 2, 3, 4, 4, 5, 6] assert merge_k_lists_heap([]) is None assert to_list(merge_k_lists_heap([None, build([1])])) == [1] print("ok") ``` **What to explain out loud:** the naive approach, collect all N values, sort, rebuild, is O(N log N) and throws away the fact that each list is already sorted. Merging lists one at a time is O(N·k), since the accumulated list gets scanned against every remaining list. The heap keeps only the k current heads in memory; every pop and push is O(log k), N total nodes processed, giving O(N log k). Divide-and-conquer reaches the same bound differently: log k rounds, each doing O(N) work total, so O(N log k) again, and it's often preferred in practice because it avoids heap overhead and parallelizes more easily. Keep this muscle warm with the same "running structure over a stream or window" family: Median of Data Stream (two heaps, one max-heap for the lower half and one min-heap for the upper half, rebalanced after every insert), Sliding Window Maximum (a monotonic deque of indices), Top K Frequent Elements (a hash map count, then a min-heap of size k, or bucket sort by frequency). **Scoring:** reached the heap approach and correctly bounded it at O(N log k); implemented divide-and-conquer as the comparison approach and explained why it hits the same bound differently; handled edge cases (empty `lists`, lists containing `None`, duplicate values); wrote clean code (heap tie-breaking, dummy-node pattern). ### Binary Tree Level Order Traversal Given the root of a binary tree, return the level order traversal of its node values, left to right, level by level, as a list of lists. ``` Input: root = [3,9,20,null,null,15,7] Output: [[3],[9,20],[15,7]] ``` Solve with BFS first, then implement a DFS version that produces the same output. Clarifying questions: empty tree (return `[]`)? does node value range matter, negatives or duplicates (no constraint)? left-to-right order within a level, confirmed (yes, that's the definition, say it back before coding)? ```python from collections import deque from typing import Optional class TreeNode: def __init__(self, val=0, left=None, right=None): self.val = val self.left = left self.right = right def level_order_bfs(root: Optional[TreeNode]) -> list[list[int]]: """Queue-based BFS. The 'snapshot the queue length before draining it' trick is what separates levels without needing a sentinel value.""" if not root: return [] result: list[list[int]] = [] queue = deque([root]) while queue: level_size = len(queue) level = [] for _ in range(level_size): node = queue.popleft() level.append(node.val) if node.left: queue.append(node.left) if node.right: queue.append(node.right) result.append(level) return result def level_order_dfs(root: Optional[TreeNode]) -> list[list[int]]: """Pre-order DFS carrying a depth counter. Appends a new level list the first time a given depth is reached, then appends into it on every subsequent visit at that depth.""" result: list[list[int]] = [] def dfs(node: Optional[TreeNode], depth: int) -> None: if not node: return if depth == len(result): result.append([]) result[depth].append(node.val) dfs(node.left, depth + 1) dfs(node.right, depth + 1) dfs(root, 0) return result if __name__ == "__main__": root = TreeNode(3, TreeNode(9), TreeNode(20, TreeNode(15), TreeNode(7))) assert level_order_bfs(root) == [[3], [9, 20], [15, 7]] assert level_order_dfs(root) == [[3], [9, 20], [15, 7]] assert level_order_bfs(None) == [] assert level_order_dfs(None) == [] assert level_order_bfs(TreeNode(1)) == [[1]] print("ok") ``` **What to explain, comparing the two:** BFS is the natural fit; a queue processes nodes in the exact order levels are defined, and "capture `len(queue)` before draining it" is the one piece of mechanics worth having cold. Both are O(n) time and O(n) space (BFS: the queue holds up to the width of the tree; DFS: the recursion stack holds up to the height, and the output list is O(n) either way). DFS is less intuitive here but shows you can adapt a traversal you already have running to also produce level order, without a second data structure. BFS is the default reasonable choice; DFS is preferable mainly if you're already deep in a DFS-based traversal elsewhere and don't want a second pass. Keep this muscle warm with the same traversal family: Validate BST (DFS with a running `(low, high)` bound tightened at every step, not just comparing to immediate children), Lowest Common Ancestor (general tree: DFS returns the node itself when found, or the current node when both children return non-null; BST: exploit ordering, O(h), no full traversal), Invert Binary Tree (swap `left`/`right` at every node, O(n) time). **Scoring:** BFS solution correct and used the level-size-snapshot technique cleanly; DFS solution correct and produced identical output; explained complexity and the real trade-off between the two, not just "both are O(n)"; handled edge cases (empty tree, single node, unbalanced tree). ## Speed round: four patterns in fifteen minutes each Speed comes from recognizing the pattern instantly, not from typing faster. Time yourself: one problem per pattern, fifteen minutes each, cold, with correct edge cases (empty input, single element, no match). If any of these four templates isn't automatic, revisit its full lesson before your next mock round. **Two pointers** (full lesson: Two Pointers) ```python def two_sum_sorted(nums: list[int], target: int) -> list[int]: lo, hi = 0, len(nums) - 1 while lo < hi: s = nums[lo] + nums[hi] if s == target: return [lo, hi] elif s < target: lo += 1 # need a bigger sum else: hi -= 1 # need a smaller sum return [] ``` Use when: a sorted array or string needs a pair or triple matching a sum or comparison condition, or an in-place partition (Dutch flag). **Sliding window** (full lesson: Sliding Window) ```python def longest_substring_no_repeat(s: str) -> int: seen = {} left = 0 best = 0 for right, ch in enumerate(s): if ch in seen and seen[ch] >= left: left = seen[ch] + 1 # shrink window past the duplicate seen[ch] = right best = max(best, right - left + 1) return best ``` Use when: a contiguous subarray or substring is optimizing a size, sum, or count of distinct elements. The window only ever expands right and shrinks left, never resets. **Binary search** (full lesson: Binary Search) ```python def search_rotated(nums: list[int], target: int) -> int: lo, hi = 0, len(nums) - 1 while lo <= hi: mid = (lo + hi) // 2 if nums[mid] == target: return mid if nums[lo] <= nums[mid]: # left half is sorted if nums[lo] <= target < nums[mid]: hi = mid - 1 else: lo = mid + 1 else: # right half is sorted if nums[mid] < target <= nums[hi]: lo = mid + 1 else: hi = mid - 1 return -1 ``` Use when: the search space is sorted, or "sorted with a twist," or you spot the classic tell "minimize the maximum" / "maximize the minimum" over a monotonic condition, which means binary search on the answer, not the array. **BFS/DFS** (full lesson: Graphs: BFS and DFS) ```python from collections import deque def num_islands(grid: list[list[str]]) -> int: if not grid: return 0 rows, cols = len(grid), len(grid[0]) visited = set() count = 0 def bfs(r, c): q = deque([(r, c)]) visited.add((r, c)) while q: cr, cc = q.popleft() for dr, dc in ((1, 0), (-1, 0), (0, 1), (0, -1)): nr, nc = cr + dr, cc + dc if (0 <= nr < rows and 0 <= nc < cols and (nr, nc) not in visited and grid[nr][nc] == "1"): visited.add((nr, nc)) q.append((nr, nc)) for r in range(rows): for c in range(cols): if grid[r][c] == "1" and (r, c) not in visited: bfs(r, c) count += 1 return count ``` Use when: traversing a graph or grid. BFS for shortest path in an unweighted graph or level-order processing; DFS for connectivity, cycle detection, backtracking, or wherever recursion naturally fits, like trees. > **Remember:** the fifteen-minute test isn't about speed for its own sake. If a template takes longer than that cold, the gap is recognition, not typing. ```knowledge-check { "questions": [ { "id": "dsa-mock-rounds-speed-round-q1", "type": "mcq", "prompt": "What does it mean if you can't write one of the four speed-round templates (two pointers, sliding window, binary search, BFS/DFS) from memory within 15 minutes?", "options": [ {"id": "a", "text": "The gap is in pattern recognition or muscle memory, not typing speed, and that specific lesson needs another pass"}, {"id": "b", "text": "That pattern is not actually important for interviews"}, {"id": "c", "text": "You should abandon that pattern and focus only on the other three"}, {"id": "d", "text": "It means the pattern only applies to hard-difficulty problems"} ], "correct": "a", "explanation": "Speed drills exist to expose exactly this: if a template isn't automatic, that's a signal to revisit the full lesson, not a sign the pattern doesn't matter." } ] } ``` ## The clean-solution checklist Apply this checklist to every problem you solve, mock or real: - Meaningful variable names (`left`/`right`, not `i`/`j`, for pointers with semantic meaning; `slow`/`fast` for cycle detection). - No dead code left behind from a discarded approach. - Edge cases handled explicitly, not accidentally working (empty input, single element, all-same values). - The correct final complexity stated in a one-line comment or said out loud. Set a fifteen-minute hard stop per problem, whether you solved it or not. If you solved it under 10 minutes, ask yourself: "was my first approach actually optimal, or did I get lucky with a working-but-suboptimal solution?" and state the real time and space complexity out loud. If it took 10-15 minutes, note what slowed you down: pattern recognition, an edge case, an off-by-one. If you haven't solved it by 15 minutes, stop, look at just the approach, not the code, understand the gap, and move on. > **Remember:** a fifteen-minute hard stop applies whether you solved the problem or not. What you do after the timer is what turns practice into improvement. ```knowledge-check { "questions": [ { "id": "dsa-mock-rounds-checklist-q1", "type": "mcq", "prompt": "If you solve a mock problem in under 10 minutes, what question should you ask yourself before moving on?", "options": [ {"id": "a", "text": "Was my first approach actually optimal, or did I get lucky with a working-but-suboptimal solution, and can I state the real complexity out loud?"}, {"id": "b", "text": "Should I immediately attempt a harder problem to prove I'm ready?"}, {"id": "c", "text": "Nothing; solving quickly means no further reflection is needed"}, {"id": "d", "text": "Whether the interviewer would have given a hint by now"} ], "correct": "a", "explanation": "Solving fast doesn't guarantee the approach was optimal. Explicitly checking complexity and questioning whether you got lucky turns a fast solve into a genuine confidence check." } ] } ``` ## Recall these from memory: graph, topological sort, and heap skeletons Say the shape out loud before writing any code, for each of these: **Graph traversal decision.** ```python # Graph traversal decision: # Ask: does the question say "shortest" / "minimum steps" / "fewest"? # Yes -> BFS with a queue, mark visited at ENQUEUE time # No, asks "does a path exist" / "find all X" / "connected components"? # Yes -> DFS, recursive or explicit stack ``` **Topological sort (Kahn's algorithm).** ```python from collections import deque, defaultdict def kahn_topo_sort(num_nodes, edges): graph = defaultdict(list) in_degree = [0] * num_nodes for u, v in edges: graph[u].append(v) in_degree[v] += 1 queue = deque(n for n in range(num_nodes) if in_degree[n] == 0) order = [] while queue: node = queue.popleft() order.append(node) for nxt in graph[node]: in_degree[nxt] -= 1 if in_degree[nxt] == 0: queue.append(nxt) return order if len(order) == num_nodes else [] # [] means a cycle exists ``` **Heap top-K skeleton.** ```python import heapq def top_k_pattern(items, k, key=lambda x: x): heap = [] for item in items: heapq.heappush(heap, (key(item), item)) if len(heap) > k: heapq.heappop(heap) return [item for _, item in heap] ``` **DP progression**, said out loud before writing code: what's the state (`dp[i]` or `dp[i][j]`)? what's the base case? what's the transition? can the space be compressed? **Common mistakes that repeat across mock rounds:** confusing BFS's "mark visited at enqueue" with DFS's "mark visited at visit," which causes duplicate work or infinite loops on cycles; using a 2-state visited/unvisited cycle check on a directed graph instead of the 3-state (white/gray/black) check that topological sort actually needs; forgetting Python's `heapq` is min-heap only and forgetting to negate back after popping a simulated max-heap value; jumping straight to code without stating the DP state definition first. > **Remember:** graph, topological sort, and heap top-K are the three skeletons worth having so automatic you never have to think about their shape, only their inputs. ```knowledge-check { "questions": [ { "id": "dsa-mock-rounds-recall-skeletons-q1", "type": "mcq", "prompt": "What's the key difference between BFS's and DFS's visited-marking convention that, if confused, causes duplicate work or infinite loops on cycles?", "options": [ {"id": "a", "text": "BFS marks a node visited when it's enqueued; DFS marks a node visited when it's actually visited"}, {"id": "b", "text": "BFS never needs a visited set; only DFS does"}, {"id": "c", "text": "DFS marks nodes visited before the traversal even starts"}, {"id": "d", "text": "There is no difference; both mark visited at the same point"} ], "correct": "a", "explanation": "BFS marks a node visited the moment it's added to the queue, to avoid enqueuing it twice from different neighbors. DFS marks it visited when actually processed. Mixing these conventions up causes bugs." } ] } ``` ## Running your own mock round Structure your own practice the same way a real interview panel would: pick one problem, set a 30-minute timer, and grade yourself against the pass-bar checklist from the top of this lesson. Then run this after-action routine, since it's the most useful part of practicing alone: - **Log every stumble**, pattern gaps and communication misses both, and drill exactly those weaknesses next. Mocks are diagnostic instruments; re-solving what you're already good at feels productive but moves nothing. - **Rate yourself honestly** against the patterns you've covered so far: can you state the trigger cold, code it in under 20 minutes without notes, and explain the complexity trade-offs? Anything that fails even one of those three isn't "done," it's a candidate for re-solving. - **Track two numbers**, not just problem count: time per problem split by phase (recognizing the pattern vs. writing the code vs. debugging edge cases), and which specific pattern keeps reappearing in your stumble log. A pattern that breaks once is bad luck. A pattern that breaks three times is a structural gap. If you blank on the optimal approach mid-round, don't sit in silence. State the brute force, code it if you need to, then optimize out loud. A working O(n²) beats an imaginary O(n) every time; interviewers reward the trajectory from correct to fast, not a silent leap straight to the best answer. > **Remember:** the most useful part of a mock round happens after the timer stops. Log the specific stumble, then drill that exact gap next, not a random new problem. ```knowledge-check { "questions": [ { "id": "dsa-mock-rounds-self-run-q1", "type": "mcq", "prompt": "After running your own mock round, what's the most useful thing to do with the results?", "options": [ {"id": "a", "text": "Log the specific stumbles (pattern gaps or communication misses) and drill exactly those weaknesses next"}, {"id": "b", "text": "Immediately schedule another mock round to stay warm"}, {"id": "c", "text": "Re-solve only the problems you already got right, to build confidence"}, {"id": "d", "text": "Memorize the exact solution to that one problem"} ], "correct": "a", "explanation": "Mocks are diagnostic. Repeating what you're already good at feels productive but changes nothing; logging specific weaknesses and drilling them directly is what actually closes gaps." } ] } ``` ## Which pattern for which clue Use this table to train pattern recognition itself: read the left column as a clue you might see in a fresh problem statement, and answer with the pattern before you've even finished reading the problem. | Clue in the problem | Pattern | Full lesson | |---|---|---| | Need fast lookup, frequency count, "have I seen this before" | Hashing | Arrays and Hashing | | Sorted array or string, find a pair or triple by sum/comparison | Two pointers | Two Pointers | | Contiguous subarray or substring, optimize a size/sum/count | Sliding window | Sliding Window | | Sorted (or "sorted with a twist") search space | Binary search | Binary Search | | "Minimize the maximum" / "maximize the minimum" over a monotonic check | Binary search on the answer | Binary Search | | Matching brackets, "next greater/smaller element" | Stacks | Stacks | | Hierarchy, ancestor/descendant, tree shape questions | Tree traversal | Trees: Basics | | Rebuild a tree from traversal orders, validate a BST | BST properties | Trees: BST and Rebuilding | | Prefix search, autocomplete, "starts with" | Tries | Tries | | "Kth largest/smallest," "top K," running median | Heaps | Heaps and Priority Queues | | Grid or graph connectivity, shortest path in an unweighted graph | BFS/DFS | Graphs: BFS and DFS | | Ordering with dependencies, cycle detection in a directed graph | Topological sort | Graphs: Topological Sort and Cycles | | Grouping or connectivity queries over time, "redundant connection" | Union-Find | Union-Find | | "Count the ways" / "min or max cost," one moving index | 1D DP | Dynamic Programming Basics | | Two sequences compared, or one sequence plus an extra flag | 2D DP | Dynamic Programming: Two Dimensions | | `*` or `?` wildcard, or regex-style pattern matching | Hard string-matching DP | Dynamic Programming: Hard String Matching | | "Generate all subsets/combinations/permutations" | Backtracking | Backtracking | | Board placement with several simultaneous constraints (N-Queens, Sudoku) | Constraint-satisfaction backtracking | Backtracking: Constraint Satisfaction | | A locally safe choice that never needs undoing | Greedy | Greedy Algorithms | | Merge, insert, or schedule time ranges | Intervals | Interval Problems | | "Appears twice except one," popcount, power-of-2 check | Bit manipulation | Bit Manipulation | | Primes, GCD/LCM, in-place matrix rotation, fast exponentiation | Math and geometry | Math and Geometry | | Anagram windows, substring search, efficient string building | Strings | String Manipulation | > **Remember:** the fastest interviewers-are-impressed moment is naming the pattern out loud within the first thirty seconds of reading the problem. This table is what makes that automatic. ```knowledge-check { "questions": [ { "id": "dsa-mock-rounds-pattern-table-q1", "type": "mcq", "prompt": "A problem asks you to find the ordering of course prerequisites and detect if that ordering is impossible. Which pattern does that clue point to?", "options": [ {"id": "a", "text": "Topological sort, since it's about ordering with dependencies and detecting a cycle in a directed graph"}, {"id": "b", "text": "Two pointers, since course lists are usually sorted"}, {"id": "c", "text": "Sliding window, since prerequisites form a contiguous range"}, {"id": "d", "text": "Bit manipulation, since courses are numbered"} ], "correct": "a", "explanation": "\"Ordering with dependencies\" plus \"detect if it's impossible\" is exactly the topological-sort clue: Kahn's algorithm produces the order, and a leftover unprocessed node signals a cycle." } ] } ``` ## Self-check: are you ready Rate yourself honestly, not aspirationally, on each pattern below. Anything that fails its verification isn't done yet; it's a candidate for re-solving before your next real interview. | Pattern | Verify with | |---|---| | Hashing (Two Sum, Anagram, Duplicate) | Solve a medium two-sum or frequency variant in under 15 minutes, cold | | Two Pointers / Sliding Window | Solve a medium substring or subarray problem in under 20 minutes, cold | | Binary Search (basic, rotated, boundaries) | Write the overflow-safe midpoint formula and the rotated-array template from memory | | Stacks (parentheses, monotonic stack, Min Stack) | Explain when a monotonic stack applies without looking anything up | | Trees (traversals, BFS/DFS, BST) | Implement iterative in-order traversal and level-order BFS from memory | | Graphs (BFS/DFS, topological sort) | Explain when to use BFS vs. a weighted shortest-path algorithm without hesitating | | Union-Find | Implement path compression and union by rank from memory | | DP (1D) | Solve House Robber or Climbing Stairs in under 10 minutes | | DP (2D / string matching) | Re-derive the `dp[i][j]` state definition from a blank file, no notes | | Backtracking | Solve N-Queens or Subsets from a blank file; the recursion tree should be obvious immediately | | Greedy | State the exchange-argument proof for one greedy problem you've solved | | Heaps / Priority Queue | Explain why building a heap from an array is O(n), not O(n log n) | | Bit Manipulation | Explain why XOR finds the single unpaired number, and what `n & (n-1)` does | | Math and Geometry | Derive the transpose-plus-reverse-rows matrix rotation on paper | | Strings | Implement the sliding-window anagram check without looking anything up | **Rapid-fire self-test**, answer out loud in one breath: when is a greedy solution valid? (When the problem has the optimal-substructure-plus-no-regret property: a locally optimal choice never gets undone later. If you can't prove that, use DP instead.) What's the time complexity of building a heap from an array? (O(n), not O(n log n), because most nodes are near the bottom and sift down only a short distance; that's amortized analysis, not a naive per-node bound.) When does BFS beat DFS? (Whenever "shortest path" or "fewest steps" in an unweighted graph is the actual question; BFS explores by distance layer, DFS doesn't.) > **Remember:** "I recognize the solution when I read it" is not the same as "I can generate it cold." The second one is what the interview actually tests. ```knowledge-check { "questions": [ { "id": "dsa-mock-rounds-self-check-q1", "type": "mcq", "prompt": "Why is heap construction from an array O(n) instead of O(n log n), even though each insert into an empty heap would be O(log n)?", "options": [ {"id": "a", "text": "Most nodes in a heap are near the bottom of the tree, so they only sift down a short distance; the amortized total across all nodes works out to O(n), not n times O(log n)"}, {"id": "b", "text": "Because heaps don't actually need to maintain their shape during construction"}, {"id": "c", "text": "Because building a heap doesn't require any comparisons"}, {"id": "d", "text": "It's actually O(n log n); O(n) is a common misconception"} ], "correct": "a", "explanation": "Heapify (build-heap) works bottom-up: the bulk of nodes are near the leaves and sift down only a few levels, so the total work sums to a linear amount rather than n log n." } ] } ``` 47:T4d88,Picture a cooking exam. Every candidate gets a different dish to cook, but the judge checks the same five things every time: did you ask what the dish should taste like, did you check how many people you're feeding, did you plan the steps, did you cook them in the right order, and can you explain your choices. The dish changes. The judge's checklist does not. A "system design interview" works the same way. You get 45 minutes to design something like Twitter, Uber, or a payment app on a whiteboard. This kind of interview is often called an HLD interview, short for High-Level Design, because you design the big boxes (services, databases, caches) rather than write real code. The system changes each time. The steps you walk through do not. Most people who struggle here do not fail because they lack knowledge. They fail because they have no steps to follow, so they wander for twenty minutes before saying anything useful. This lesson gives you those steps. The one thing to memorise is the order of the steps. You can work out the details at the whiteboard. > **RESHADE** — **R**equirements, **E**stimation, **S**chema & API, **H**igh-level design, **A**rchitecture deep dive, **D**efend trade-offs, **E**dge cases. ## What the interviewer is actually scoring You are not scored on how many technology names you can list. The interviewer is quietly filling in four boxes on a scorecard. | Row | What it means | How you lose the point | |---|---|---| | **Problem framing** | You turned a vague ask into something you can actually build | You started drawing boxes before asking what the system must do | | **Structured thinking** | You moved through the design in a clear order | You jumped between topics and the interviewer had to steer you back | | **Technical depth** | You can go one level deeper than the box you drew | You said "I'd use a cache" and had nothing more to say when pushed | | **Trade-off reasoning** | You picked an option and said what it costs | You presented your design as if it had no downsides | The last row is what separates a junior answer from a senior one. A junior candidate says "this is the best approach." A senior candidate says something like: "I'm picking option X because we're read-heavy and can live with a one-second delay. If we needed perfect up-to-the-second data, I'd pick option Y and accept the slower response instead." Say your reasoning out loud the whole time. The interviewer cannot give you credit for a good idea they never heard. > **Remember:** a design with no stated cost is not a finished answer. Say what you're choosing, and say what it costs you. ```knowledge-check { "questions": [ { "id": "ip45-hld-01-scoring-q1", "type": "mcq", "prompt": "You propose a read replica (an extra copy of the database used only for reads) to handle more traffic. Which follow-up sentence earns you the trade-off point?", "options": [ {"id":"a","text":"\"Replicas are the standard solution for read-heavy systems.\""}, {"id":"b","text":"\"This adds a small delay before new data reaches the replica, so a user who just posted might not see their own post right away. I'd send that user's next read back to the main database for a few seconds.\""}, {"id":"c","text":"\"We can add more replicas later if needed.\""}, {"id":"d","text":"\"Postgres, MySQL, and MongoDB all support replicas.\""} ], "correct": "b", "explanation": "Trade-off reasoning means naming the cost of your choice and how you'd soften it. Answer (b) names the real downside (a delay before data catches up), who notices it, and the fix. The others are just facts, or they put off the problem." } ] } ``` ## Step 1 — Requirements: turn a vague prompt into a clear spec Give this about five minutes. Do not skip it. If you're still here after eight minutes, move on anyway. Split requirements into two kinds, out loud, on the board. **Functional requirements** are what a user can *do*. Write down three to five actions, no more. For "design Twitter": post a message, follow a person, view a home feed. Say what you're leaving out too: "I'll treat direct messages, search, and ads as out of scope unless you'd like me to cover them." **Non-functional requirements** are the numbers and properties that actually shape the design: | Question to ask | Why it changes the design | |---|---| | How many users, how much traffic? | Decides one database or many, cache or no cache | | Read-heavy or write-heavy? | Read-heavy needs replicas and caching; write-heavy needs splitting the data up and queues | | How fast must it respond? | A 50 millisecond target for the slowest 1% of requests (called "p99 latency") rules out calls to a server on another continent | | Consistency or availability if the network breaks? | Money needs to always be exactly correct; a feed or a like count can be a little stale | | Can we ever lose a record? | A payment record: never. An analytics event: sometimes acceptable | | One region or many? | Serving many regions adds copying data around, routing by location, and legal rules on where data can live | Then say what you are choosing not to build. This is a strength, not a shortcut: "I'll design the posting flow and the feed end to end, and treat uploading photos as an S3-plus-CDN detail I'll come back to if there's time." (S3 is Amazon's storage service for files; a CDN, short for content delivery network, is a set of servers around the world that store a copy of a file close to each reader.) > **Remember:** functional requirements say what a user can do. Non-functional requirements say how well, and those are the numbers that actually shape your design. ```knowledge-check { "questions": [ { "id": "ip45-hld-01-requirements-q1", "type": "mcq", "prompt": "Which of these is a NON-functional requirement?", "options": [ {"id":"a","text":"A user can follow another user"}, {"id":"b","text":"A feed shows the 50 most recent posts"}, {"id":"c","text":"The feed must load in under 200 milliseconds for 10 million daily users"}, {"id":"d","text":"A user can delete their own post"} ], "correct": "c", "explanation": "Functional requirements are what the system does (a, b, d). Non-functional requirements are how well it must do it: speed, scale, staying online, correctness. Non-functional requirements are what actually force your architecture choices." } ] } ``` ## Step 2 — Estimation: get the numbers that shape the design This takes three to five minutes. You are not trying to be exact. You are trying to answer one question: is this a small problem, a medium problem, or a huge one? That answer decides everything else. Picture deciding whether to cook for a family of four or cater a 500-person wedding, before you decide how many stoves you need. The estimate is that same check, done with real numbers. The chain of numbers is always the same shape: ``` DAU → actions per user per day → requests/day → average QPS → peak QPS (×2–3) → bytes per action → storage/day → storage/5yr → bytes × QPS → bandwidth ``` Here DAU means daily active users, the number of people who use the app on a given day. QPS means queries per second, or how many requests hit your servers each second. A worked example, the kind you'd say out loud in about 30 seconds: - 10 million DAU. Each one reads their feed 10 times a day and posts 0.1 times a day (one post every 10 days, on average). - Reads: 100 million a day, divided by 86,400 seconds in a day, is about **1,200 QPS** on average, and about **3,500 QPS** at the busiest moment. - Writes: 1 million a day is about **12 QPS** on average. That's tiny. - The ratio of reads to writes is **100 to 1**. This is a read-heavy system, so caching and extra read copies of the database matter far more than splitting up the writes. - One post is about 300 bytes of text. A million posts a day is about 300 MB a day, or **half a terabyte over five years**. Text easily fits on one strong server. Photos and video are the real storage problem. Notice what those five lines did for you. You now know to spend your design time on the read path, and you have a real reason why. That's the whole point of doing the math. > **Remember:** an estimate that doesn't end in a "so..." sentence earned nothing. The numbers only matter if they point at which part of the design is hard. ```knowledge-check { "questions": [ { "id": "ip45-hld-01-estimation-q1", "type": "mcq", "prompt": "Your estimate shows 100 reads for every 1 write, and only 12 writes per second. What should that tell you about where to spend your design time?", "options": [ {"id":"a","text":"Split the write path across many databases first"}, {"id":"b","text":"Writes are easy for a single database; the real problem is the read path, so focus on caching, extra read copies, and precomputing results"}, {"id":"c","text":"The system needs perfect, always-up-to-date consistency"}, {"id":"d","text":"Use a NoSQL database, because a normal relational database can't handle 12 writes a second"} ], "correct": "b", "explanation": "12 writes a second is nothing; a laptop could handle it. The estimate's job is to point your remaining 30 minutes at the part that's actually hard, which here is serving 3,500 reads a second cheaply." } ] } ``` ## Step 3 — API and data model: the contract before the boxes Give this about five minutes. Two small pieces of work, nothing more. **The API.** Write down three to five endpoints: just the request and the response shape, nothing else. An endpoint is one specific URL a client can call, like "create a post" or "get my feed." Writing these down forces you to decide what the system actually offers, and it surfaces good questions early, like how you page through results, how you avoid double-submits, and who is allowed to call what. ``` POST /v1/tweets {text, media_ids[]} -> {tweet_id, created_at} GET /v1/timeline?cursor= ... -> {tweets[], next_cursor} POST /v1/users/{id}/follow Idempotency-Key: -> 204 ``` Two habits that make you look experienced. First, use **cursor pagination**, never page numbers. A cursor is a bookmark, like a scrap of paper marking your place in a book: it tells the server exactly where you left off, so the next page is always correct even if new posts arrive. A page number, by contrast, drifts and gets slower the further you page. Second, add an **idempotency key** to any write the client might accidentally send twice, such as after a lost network reply. An idempotency key is a unique ID the client generates once per action; the server uses it to recognize a repeat and avoid doing the work twice. **The data model.** List your entities, their key fields, and how they relate. Just as important: write down the **access patterns**, meaning the actual questions your code will ask the database, because those questions decide which storage engine and which indexes you need. ``` User(id PK, handle UNIQUE, name, created_at) Tweet(id PK, author_id FK, text, created_at) index: (author_id, created_at DESC) Follow(follower_id, followee_id) PK(follower_id, followee_id) index: (followee_id) -- "who follows me", for fan-out ``` Say the access pattern out loud next to each index. For example: "the feed query is 'posts by everyone I follow, newest first,' so I need an index in the followee-to-follower direction to look up who to notify when someone posts." Choosing your indexes from the queries you actually wrote is exactly the reasoning a real database review wants to see. > **Remember:** pick every index from a query you actually wrote down. An index that no query needs is just a slower write. ```knowledge-check { "questions": [ { "id": "ip45-hld-01-api-q1", "type": "mcq", "prompt": "Why is cursor pagination (a bookmark like `?cursor=abc123`) preferred over page-number pagination (`?page=500`) for a feed?", "options": [ {"id":"a","text":"Cursors are shorter strings, so requests are smaller"}, {"id":"b","text":"Page numbers force the database to read and throw away every earlier row first, getting slower the deeper you page, and items shift between pages when new rows are added"}, {"id":"c","text":"Page-number pagination cannot be cached"}, {"id":"d","text":"Cursor pagination guarantees perfectly up-to-date data"} ], "correct": "b", "explanation": "Asking for page 500 makes the database walk through 10,000 earlier rows before it can answer, and a new post at the top pushes every row one page later, so users see duplicates or missing items. A cursor jumps straight to the right spot and stays correct even as new rows are added." } ] } ``` ## Step 4 — High-level design: draw the request path Give this about ten minutes. Draw boxes and arrows, and talk through **one request from start to end** as it passes through them. A diagram nobody explains out loud is just decoration. Here is a starting skeleton. Draw it, then delete whatever this particular problem doesn't need. ``` Client → DNS → CDN (static/media) → Load Balancer → API Gateway (auth, rate limit) → Application services ├── Cache (Redis) ├── Primary DB → Read replicas ├── Object store (S3) for blobs └── Message queue → async workers → search index / analytics / notifications ``` Four rules keep this step on track. 1. **Draw only what a requirement demands.** Every box you can't justify is a box you'll be asked to defend, and you won't be able to. 2. **Split synchronous work from asynchronous work.** Synchronous means the user is waiting for it right now; asynchronous means it can happen a moment later, in the background. Anything the response doesn't depend on, like sending notifications, generating thumbnails, or logging analytics, goes behind a queue instead of blocking the reply. 3. **Narrate the write path, then the read path.** For example: "A post request hits the gateway, which checks who the user is and whether they've hit their rate limit. The service saves the post to the main database, announces a 'post created' event, and replies. A separate worker picks up that event later and pushes the new post id into each follower's feed cache." 4. **Keep app servers stateless.** Stateless means a server holds nothing in its own memory between requests; session and cache data lives in Redis (a shared, fast, in-memory data store) instead. That way any server can handle any request, and adding more servers actually works. > **Remember:** draw only what a requirement demands, and anything the user isn't waiting on goes behind a queue. ```knowledge-check { "questions": [ { "id": "ip45-hld-01-hld-q1", "type": "mcq", "prompt": "Which piece of work belongs BEHIND a queue rather than in the path the user is waiting on, when someone posts a tweet?", "options": [ {"id":"a","text":"Checking the tweet's text isn't too long"}, {"id":"b","text":"Saving the tweet so the author sees it on their own profile"}, {"id":"c","text":"Pushing the new tweet into 2 million followers' feed caches"}, {"id":"d","text":"Checking who the caller is"} ], "correct": "c", "explanation": "Anything the user's own response doesn't depend on, especially something whose size depends on someone else's data (like follower count), should happen later, in the background. Updating 2 million feeds can't happen inside a fast reply; the validation, the login check, and the actual save must happen before you reply." } ] } ``` ## Step 5 — Deep dive, bottlenecks, and the trade-off close Give the last fifteen minutes to this step. This is where your level gets decided. Either the interviewer names the deep-dive topic ("how does the feed stay fast for a celebrity with 50 million followers?") or you pick it yourself. If you're picking, pick the box your own estimate showed was under the most pressure. Run every bottleneck (the part of the system that breaks first under load) through the same four questions. | Question | Example answer | |---|---| | Where does it break first? | Updating every follower's feed at post time breaks for celebrity accounts; one tweet means 50 million cache writes | | What's the fix? | A hybrid: update feeds at post time for normal users, but build a celebrity's followers' feeds at read time instead, and merge the two | | What does the fix cost? | Two separate code paths, a "celebrity" threshold you have to tune, and slightly slower reads for people who follow a celebrity | | How do you know it's working? | Feed latency at the 99th percentile, how far behind the update worker is, and the cache hit rate | Then close with three short sentences. 1. **Recap the shape.** "This is read-heavy, so I precomputed feeds in Redis, backed by a database split across several servers." 2. **Name the biggest risk.** "The worker that updates feeds is the piece most likely to fall over during a celebrity spike." 3. **Say what you'd do next with more time.** "I'd design the multi-region setup and the analytics pipeline next." Name failure modes before the interviewer asks about them: a single point of failure (one thing whose crash takes down everything), one database shard getting far more traffic than the others, a wave of requests all hitting an empty cache at once, a queue that grows without limit, and retries with no backoff piling on top of each other. > **Remember:** dive into the box your own estimate proved was under pressure, not the box you feel safest talking about. ```knowledge-check { "questions": [ { "id": "ip45-hld-01-deepdive-q1", "type": "mcq", "prompt": "With 15 minutes left and no direction from the interviewer, which deep dive should you choose?", "options": [ {"id":"a","text":"The part your own back-of-the-envelope estimate showed was under the most pressure"}, {"id":"b","text":"The part you happen to know the most trivia about"}, {"id":"c","text":"The login flow, since every system needs one"}, {"id":"d","text":"A full rewrite of the design using many small services"} ], "correct": "a", "explanation": "The estimate exists to point you at the hard part. Diving there shows your numbers actually drove your design. Diving into your comfort topic instead shows the opposite." } ] } ``` ## Quick recap **The 45-minute budget:** | Minutes | Step | Output on the board | |---|---|---| | 0–5 | Requirements | 3–5 functional bullets, a non-functional table, and an explicit scope cut | | 5–10 | Estimation | QPS, storage, read-to-write ratio, and the one conclusion they point to | | 10–15 | API + data model | 3–5 endpoints, entities with keys, indexes justified by access patterns | | 15–25 | High-level design | Boxes and arrows, one write path and one read path narrated out loud | | 25–40 | Deep dive | Bottleneck, fix, cost, metric, done once or twice | | 40–45 | Close | Recap, biggest risk, what you'd do next | **Five sentences worth learning by heart:** 1. "Before I design anything, what scale are we targeting, and is this read-heavy or write-heavy?" 2. "I'll scope to X and Y, and treat Z as out of scope unless you'd like it covered." 3. "That's 100 reads for every write, so the interesting problem is the read path." 4. "Anything the user's response doesn't depend on goes behind a queue." 5. "I'm choosing X. The cost is Y, and I'd soften it with Z." 48:T34e5,Picture a shopkeeper who, before ordering stock, asks "how many customers a day, roughly?" She doesn't need the exact number. She needs to know if she's stocking a corner shop or a supermarket. Estimation in a system design interview is that same quick check, done with rough numbers in three minutes. Nobody checks your arithmetic. The only question that matters is: is this a one-machine problem, a one-rack-of-machines problem, or a thousand-machine problem? The answer decides everything you draw next. This lesson gives you a set of numbers worth memorising, four shortcuts for doing the maths fast, and three worked examples to pattern-match against. ## The numbers worth memorising Learn these two tables once. They cover almost every estimate you'll ever do at a whiteboard. Picture two friends. One passes a note across the same classroom; the other mails a letter to a friend in another country. The classroom note is like reading from computer memory: almost instant. The international letter is like a network call to a server on another continent: it takes far, far longer. That speed gap is the entire reason system design keeps data close to whoever is asking for it. **Latency, the time one operation takes.** These are rounded on purpose, because round numbers are what you actually need to remember: | Operation | Time | Rule of thumb | |---|---|---| | L1 cache reference (a tiny, ultra-fast memory inside the CPU) | 1 ns | — | | Main memory reference (regular RAM) | 100 ns | RAM is about 100 times slower than L1 | | Read 1 MB from memory | 10 µs | — | | SSD random read (a solid-state drive) | 100 µs | SSD is about 1,000 times slower than RAM | | Read 1 MB from SSD | 200 µs | — | | Round trip within one data center | 500 µs | | | Disk (HDD) seek (an old-style spinning hard drive) | 10 ms | HDD is about 100 times slower than SSD | | Round trip, US East to US West | 70 ms | | | Round trip, US to Europe | 150 ms | Light in fibre-optic cable travels about 200 km per millisecond | Here `ns` means nanosecond (a billionth of a second), `µs` means microsecond (a millionth of a second), and `ms` means millisecond (a thousandth of a second). Three ratios matter more than the exact numbers: **memory is roughly 100 times faster than SSD, SSD is roughly 100 times faster than a spinning disk, and a trip across a continent costs more than 100,000 memory reads.** That last fact is the whole reason you cache data, batch requests together, and avoid chatty calls between services in different regions. **How much one ordinary machine can handle, before you need a second one:** | Resource | Realistic single-machine number | |---|---| | Redis (a fast, in-memory data store) | 100,000 to 1 million operations per second, tens of gigabytes of memory | | PostgreSQL, well-indexed | 5,000 to 10,000 simple queries per second | | Application server, Go or Java, simple JSON | 5,000 to 20,000 requests per second | | Application server, Python or Ruby, one process | 500 to 2,000 requests per second | | Kafka broker (a message-queue server) | 100,000 to 1 million messages per second | | Network interface | 10 gigabits per second, about 1.25 gigabytes per second | Round aggressively. If someone else says "8,000 queries per second on one Postgres node" and you said 10,000, nothing about your design changes. That's the whole point of rounding. > **Remember:** memory beats SSD by about 100 times, SSD beats a spinning disk by about 100 times, and a cross-continent trip costs more than 100,000 memory reads. That's why you cache data close to the user. ```knowledge-check { "questions": [ { "id": "ip45-hld-02-numbers-q1", "type": "mcq", "prompt": "Roughly how much slower is a US-to-Europe round trip (150 milliseconds) than reading from main memory (100 nanoseconds)?", "options": [ {"id":"a","text":"About 1,000 times"}, {"id":"b","text":"About 100,000 times"}, {"id":"c","text":"About 1,500,000 times"}, {"id":"d","text":"About 150 times"} ], "correct": "c", "explanation": "150 milliseconds equals 150,000,000 nanoseconds. Divide that by 100 nanoseconds and you get about 1.5 million. This gap is why one cross-region network call can eat your whole time budget for a request, and why you keep copies of data close to users instead of calling far away every time." } ] } ``` ## Four arithmetic shortcuts These four turn estimation from real maths into something you just remember. **1. Powers of two match common data sizes.** | Power | Value | Name | |---|---|---| | 2^10 | about 1 thousand | KB (kilobyte) | | 2^20 | about 1 million | MB (megabyte) | | 2^30 | about 1 billion | GB (gigabyte) | | 2^40 | about 1 trillion | TB (terabyte) | **2. A day has about 100,000 seconds.** It's really 86,400, but rounding up to 100,000 makes the mental maths easy. So **1 million events a day is about 10 a second**, and **1 billion a day is about 10,000 a second**. Nearly every "how many per second" question you'll ever answer is a version of one of those two. **3. The busiest moment is 2 to 3 times the average.** Real traffic rises and falls through the day, like a shop that's quiet at 3am and busy at 7pm. Design your system to survive the busy peak, but estimate cost using the average. If a big launch or a sale is part of the scenario, use 10 times instead of 2 to 3. **4. Typical sizes let you turn "how many requests" into "how many bytes."** | Thing | Size | |---|---| | UUID (a unique random ID) | 16 bytes | | Timestamp | 8 bytes | | A tweet or short text post | about 300 bytes | | A user record | about 1 KB | | A JSON API response | about 1 to 10 KB | | A thumbnail image | about 50 KB | | A full photo | about 2 MB | | One minute of 1080p video | about 50 MB | One habit that follows from this: **storage for a year is roughly bytes-per-day multiplied by 400** (365 rounded up), and multiply again by 3 if you keep extra copies of the data. > **Remember:** a million events a day is about 10 a second. A billion a day is about 10,000 a second. Multiply by 2 to 3 for the busiest moments of the day. ```knowledge-check { "questions": [ { "id": "ip45-hld-02-shortcuts-q1", "type": "mcq", "prompt": "A service handles 500 million requests a day. Roughly what is its average requests per second, and what should you design for at the busiest moment?", "options": [ {"id":"a","text":"About 500 average, about 1,000 at peak"}, {"id":"b","text":"About 5,000 average, about 10,000 to 15,000 at peak"}, {"id":"c","text":"About 50,000 average, about 150,000 at peak"}, {"id":"d","text":"About 500,000 average, about 1 million at peak"} ], "correct": "b", "explanation": "1 billion a day is about 10,000 a second, so 500 million a day is about 5,000 a second on average. Multiply by 2 to 3 for the busiest moment, giving roughly 10,000 to 15,000 requests per second." } ] } ``` ## The estimation template Run through the same five lines every time, in this order, and say each one out loud. Each line is a chance to earn a point. ``` 1. Users : DAU, and actions per user per day 2. QPS : (DAU × actions) ÷ 100,000 sec → then ×3 for peak 3. Read : Write : the single most design-relevant ratio 4. Storage : bytes per record × records/day × 400 days/yr × years × replication 5. Bandwidth : bytes per response × peak QPS ``` Here DAU means daily active users, and QPS means queries (or requests) per second. Then do the part most people forget: **say the conclusion out loud.** An estimate with no conclusion has earned nothing. Examples of a real conclusion: - "3,500 requests a second at peak is a handful of app servers, not a thousand. I'm not building Google here." - "100 reads for every write, so caching and extra read copies carry this design." - "50 terabytes of video a year means the files live in object storage behind a CDN, and the database only stores information about them." - "One database shard tops out around 10,000 requests a second, so at 40,000 I need at least 4 to 8 shards plus some spare room." There's a fifth conclusion worth practising, because it's the bravest and most senior one to say: **"these numbers are small. A single Postgres database with one backup copy for reads handles this easily, and I'd start there."** Reaching for a big distributed system that the problem doesn't actually need is a real mistake, and interviewers do mark it down. > **Remember:** an estimate that doesn't end in a "so..." sentence wasted everyone's time. Numbers only matter for the decision they point to. ```knowledge-check { "questions": [ { "id": "ip45-hld-02-template-q1", "type": "mcq", "prompt": "Your estimate comes out at 200 requests a second and 40 GB of total data. What is the strongest thing to say next?", "options": [ {"id":"a","text":"\"I'll split the database across 10 machines for safety.\""}, {"id":"b","text":"\"This fits comfortably on one main database with a backup copy for reads and for failover. I'd start simple and note what load would force a change.\""}, {"id":"c","text":"\"I'll add a message queue between every service to decouple them.\""}, {"id":"d","text":"\"Let's assume 100 times more traffic, so the design is future-proof.\""} ], "correct": "b", "explanation": "Matching the design to the actual measured scale, and naming the load at which it would need to change, is the strong answer. Splitting the database early and adding a queue nobody asked for both look like over-building when the numbers don't call for it." } ] } ``` ## Three worked estimates **A. A read-heavy social feed, 10 million daily active users.** ``` Reads : 10M × 10 timeline views = 100M/day → 1,000 QPS avg → 3,000 peak Writes: 10M × 0.1 posts = 1M/day → 10 QPS avg → 30 peak Ratio : 100:1 read-heavy Storage: 1M posts × 300 B = 300 MB/day → ~120 GB/yr text (+ media: 10% of posts × 2 MB = 200 GB/day → 80 TB/yr → object store + CDN) Bandwidth: 5 KB response × 3,000 QPS = 15 MB/s → trivial for text, huge for media ``` **Conclusion:** the text is a small problem. The photos and videos are the real storage and bandwidth problem. Build the read path around a cache, keep the files in object storage behind a CDN, and store only information about each file in the database. **B. Write-heavy metrics collection, 100,000 servers each sending one measurement a second.** ``` Writes: 100k × 1/sec = 100,000 writes/sec sustained Storage: 100k/sec × 50 B × 100k sec/day = 500 GB/day raw → 180 TB/yr ``` **Conclusion:** a normal database table with one row per measurement can't keep up. This calls for a time-series database (one built for exactly this shape of data), which compresses data by column, batches writes together, and shrinks old data over time: full detail for a day, once-a-minute detail for a month, once-an-hour detail for a year. That cuts long-term storage by about 99%. **C. A video platform, 1 million uploads a day, 500 million views a day.** ``` Views : 500M/day = 5,000 QPS avg → 15,000 peak Uploads: 1M/day × 50 MB = 50 TB/day ingest → 18 PB/yr raw Transcoding: 1M videos × 5 renditions = 5M transcode jobs/day → 50/sec sustained Egress : 15,000 concurrent streams × 5 Mbps ≈ 75 Gbps ``` **Conclusion:** 75 gigabits per second cannot come straight from your own servers. The entire design has to be built around a CDN. Converting videos into different quality levels is a queue-and-worker problem, and the database that stores video titles and descriptions is by far the easiest part. Notice the pattern across all three examples: the estimate points straight at one subsystem that's actually hard, and that subsystem becomes your deep dive later in the interview. > **Remember:** every worked estimate should end by pointing at one subsystem. That's the part worth designing carefully. ```knowledge-check { "questions": [ { "id": "ip45-hld-02-worked-q1", "type": "mcq", "prompt": "A metrics system takes in 100,000 measurements a second. Which conclusion follows most directly from that number?", "options": [ {"id":"a","text":"Use a normal relational table with one row per measurement and an index on the timestamp"}, {"id":"b","text":"Buffer and batch the writes into a time-series database, and shrink older data over time to control storage growth"}, {"id":"c","text":"Add extra read copies of the database"}, {"id":"d","text":"Store the measurements in Redis forever"} ], "correct": "b", "explanation": "100,000 sustained writes a second is about 10 times what one relational database can handle, and 180 terabytes a year of raw data is too expensive to keep at full detail. Batching writes into a time-series store and shrinking old data is the standard answer; extra read copies help reads, not this write load." } ] } ``` ## Quick recap ``` Seconds/day ≈ 100,000 1M/day ≈ 10 QPS 1B/day ≈ 10,000 QPS Peak ≈ 2–3× average Storage/yr ≈ bytes/day × 400 × replicas Memory 100 ns · SSD 100 µs · DC round trip 500 µs · cross-continent 150 ms Postgres ≈ 10k QPS/node · Redis ≈ 100k+ ops/sec · app server ≈ 10k req/sec Tweet 300 B · user 1 KB · JSON response 1–10 KB · photo 2 MB · 1080p video 50 MB/min ``` 49:T3859,Every arrow you draw between two boxes on a system design diagram is really a phone call between two computers. Interviewers like to poke at those arrows: how does the client find the right server, how does the server push an update to the browser, why pick one protocol over another. You don't need a networking degree for this. You need to know, for each arrow, which protocol carries it and what that choice costs you. ## From URL to first byte Learn this sequence well enough to explain it out loud. Interviewers ask it directly ("what happens when you type a URL and press enter?"), and it's the foundation for questions about CDNs, load balancers, and secure connections. ``` 1. DNS resolve browser cache → OS cache → resolver → root → TLD → authoritative returns an IP (or a CDN edge IP via geo/latency routing) 2. TCP handshake SYN → SYN-ACK → ACK (1 round trip) 3. TLS handshake TLS 1.3: 1 round trip (1.2 was 2) (0-RTT on resume) 4. HTTP request GET / with headers, cookies 5. Server work LB → app → cache/DB → response 6. Response HTML → browser parses → more requests for CSS/JS/images ``` DNS (Domain Name System) is the phone book of the internet: it turns a name like "mindforge.test" into a numeric address. TCP is the connection-setup handshake computers use before sending data. TLS is the layer that encrypts the connection, so nobody in between can read it. Three facts that pay off in interviews. **DNS is a routing tool, not just a phone book.** Every DNS record has a TTL (time to live), a number of seconds saying how long a client may keep using the old answer before asking again. A short TTL, say 30 to 60 seconds, lets you redirect traffic to a different server quickly if something breaks, at the cost of clients asking DNS more often. DNS can also send users to the nearest region, or shift a small percentage of traffic to a new version gradually. **Setting up a connection is expensive.** It takes roughly two round trips before a single byte of your actual data moves. Picture asking a favour from someone in another country by mail: two letters have to cross the ocean before you've even started the real conversation. Over a connection with a 150 millisecond round trip, that's 300 milliseconds spent on nothing. This is why keeping connections open (called keep-alive), reusing a pool of connections, and letting a CDN handle the connection close to the user all matter so much. **Anycast** is a trick where one IP address is advertised from many physical locations at once, and the network automatically routes each user to whichever location is closest. It's how CDNs and DNS providers work, and it's also how a flood of attack traffic gets spread thin across many sites instead of overwhelming one. > **Remember:** DNS's TTL is a dial you control, not a fixed detail. A short TTL is what lets you redirect traffic away from a dead region within a minute. ```knowledge-check { "questions": [ { "id": "ip45-hld-03-path-q1", "type": "mcq", "prompt": "You want to be able to redirect traffic to a standby region within a minute if the main one fails. What must you set up ahead of time?", "options": [ {"id":"a","text":"A long DNS TTL, so clients cache the address and don't overload the DNS server"}, {"id":"b","text":"A short DNS TTL (30 to 60 seconds), so clients pick up the new address quickly, plus health checks that trigger the switch"}, {"id":"c","text":"HTTP/3, because it reconnects faster"}, {"id":"d","text":"A feature that resumes an old encrypted session"} ], "correct": "b", "explanation": "Clients honour whatever TTL they were given, so a 24-hour TTL means a 24-hour tail of traffic still going to the dead region. A short TTL is the price you pay for fast DNS-based failover; the cost is more frequent DNS lookups." } ] } ``` ## TCP vs UDP, and what QUIC changed TCP and UDP are the two basic ways computers send data to each other over a network. | | TCP | UDP | |---|---|---| | Delivery | Reliable, in order, resends lost data | Fire and forget, may drop or reorder | | Setup | A three-step handshake first | None | | Handling network congestion | Built in | You build it yourself, or go without | | Head-of-line blocking (one lost piece stalling everything behind it) | Yes | No | | Use for | APIs, databases, anything that must be correct | Live video or voice calls, games, DNS, metrics | Ask yourself one question to decide between them: is a late piece of data worth more than a missing one? For a bank transfer, yes: resend it until it arrives, so use TCP. For a video call, no: a video frame that arrives 400 milliseconds late is worse than one that's simply dropped and skipped, so use UDP and hide the gap. **HTTP/3 runs on top of QUIC, and QUIC runs on top of UDP.** QUIC rebuilds reliability, ordering, and congestion handling itself, instead of relying on TCP to do it. That buys two things. First, independent streams: a lost piece of data only stalls its own stream, not the whole connection. Second, connection migration: if your phone switches from Wi-Fi to mobile data mid-call, the connection survives, because it's identified by a connection ID rather than by your IP address. | Version | Key property | |---|---| | HTTP/1.1 | Only one request in flight per connection, so browsers open about 6 connections per site | | HTTP/2 | Many requests share one TCP connection, headers are compressed, but it still suffers TCP's head-of-line blocking | | HTTP/3 | Same sharing, but over QUIC and UDP, so one lost piece of data no longer stalls every other stream; it also connects faster and survives a network switch | > **Remember:** TCP guarantees every byte arrives in order, so one lost piece of data stalls everything behind it. UDP drops that guarantee, which is exactly why live video prefers it. ```knowledge-check { "questions": [ { "id": "ip45-hld-03-tcp-q1", "type": "mcq", "prompt": "HTTP/2 lets many requests share one TCP connection. Which problem does that NOT solve, but HTTP/3 does?", "options": [ {"id":"a","text":"Header size, because HTTP/2 does not compress headers"}, {"id":"b","text":"TCP still delivers bytes strictly in order, so one lost piece of data stalls every shared stream, not just its own"}, {"id":"c","text":"Encryption, because HTTP/2 cannot use TLS"}, {"id":"d","text":"How many times DNS has to be looked up"} ], "correct": "b", "explanation": "HTTP/2 removed the stalling that happened at the application level, but it still runs on TCP, which insists on delivering bytes in order. So one dropped piece of data still blocks every stream sharing that connection. QUIC tracks loss per stream instead, so only the affected stream has to wait." } ] } ``` ## Client-server communication styles The single most common question interviewers ask about protocols is: "how does the client find out something changed?" There are four answers, each more powerful and more expensive than the last. | Style | How it works | Delay | Cost to the server | Use when | |---|---|---|---|---| | **Short polling** | Client asks again every few seconds | Up to that many seconds | Wasteful, since most answers are "nothing changed" | Simple is fine, updates are rare, some staleness is okay | | **Long polling** | The request stays open until there's data or it times out, then the client asks again | Near real-time | One open connection per client | Real-time-ish, without support for WebSockets | | **SSE** (Server-Sent Events) | One long-lived response that the server streams events into; the browser reconnects on its own if it drops | Real-time | One connection per client | **Server to client only**: feeds, notifications, live scores | | **WebSocket** | A regular HTTP request that "upgrades" into a two-way connection | Real-time | One connection per client, and the server has to remember who's connected | **Both directions**: chat, shared editing, multiplayer games, trading | Two consequences interviewers like to push on. **WebSocket and SSE make your servers stateful.** Stateful means the server remembers something between requests, in this case, which client is connected to which machine. That connection is pinned to one specific server, so you need "sticky routing" (always sending that client back to the same server), a shared messaging layer like Redis, NATS, or Kafka to deliver a message to whichever server actually holds the connection, and a careful way of closing connections gradually during a deploy. Saying "just use WebSockets" without mentioning any of that is an incomplete answer. **The number of connections becomes a real capacity number you have to plan for.** One million people connected over WebSockets means one million open connections at once. If one server can comfortably hold 50,000 to 100,000 of them, that's 10 to 20 servers whose only job is holding connections open. If you only need the server pushing to the client, **prefer SSE**. It's plain HTTP, it works through most existing infrastructure without special handling, it reconnects automatically, and it's roughly half the complexity of a WebSocket. > **Remember:** ask which direction the data needs to flow. Server-to-client only means SSE. Both sides talking means WebSocket, and WebSocket makes your servers stateful. ```knowledge-check { "questions": [ { "id": "ip45-hld-03-realtime-q1", "type": "mcq", "prompt": "A dashboard needs live price updates pushed from the server to the browser, and the browser never sends anything back on that same channel. What fits best?", "options": [ {"id":"a","text":"WebSocket, because it's the standard choice for anything real-time"}, {"id":"b","text":"Server-Sent Events: one direction only, plain HTTP, automatic reconnection, and far less to operate"}, {"id":"c","text":"Short polling every 100 milliseconds"}, {"id":"d","text":"A two-way streaming connection from the browser"} ], "correct": "b", "explanation": "SSE is built exactly for server-to-client streams over ordinary HTTP. Choosing WebSocket when you never need the browser to talk back buys you sticky connections and a heavier protocol for no reason." } ] } ``` ## Service-to-service: REST, gRPC, GraphQL, and message queues | | REST/JSON | gRPC/protobuf | GraphQL | Message queue | |---|---|---|---|---| | Shape | A resource with actions on it | A remote call with a typed contract | One endpoint, the client asks for exactly the fields it wants | Publish now, someone else reads it later | | Payload | Plain text, human-readable | Binary, compact and fast | JSON | Anything | | Contract | An optional description (OpenAPI) | A `.proto` file, checked and code-generated | An enforced schema | A loosely-defined event shape | | Streaming | Via SSE or chunked responses | Built in, both directions | Via subscriptions | Built in | | Works in a browser | Natively | Needs an extra proxy layer | Natively | No | | Best for | Public APIs, simple internal calls | High-volume calls between your own services | Many clients that each want different data | Decoupling services, buffering spikes, broadcasting to several listeners | A few rules of thumb that hold up well. **Public or partner-facing calls: use REST.** Anyone can call it with a basic tool like `curl`, caching works the normal HTTP way, and no special toolchain is required. **High-volume calls between your own internal services: use gRPC.** Its binary format and the way it shares connections cut latency and CPU cost, and the generated code keeps two teams' services from drifting out of sync with each other. **Many different clients each needing different data: use GraphQL.** It solves the problem of a client getting too much data or too little in one response. It costs you extra work controlling how expensive a single query can be, makes normal HTTP caching harder, and introduces the "N+1" problem, where fetching a list quietly triggers one extra database query per item; that's fixed with request batching. **The caller doesn't need the answer right now: use a queue, not a direct call.** Chaining calls together multiplies your chance of failure. Five services in a row, each working 99.9% of the time, only work together about 99.5% of the time. > **Remember:** public and simple calls for REST. Internal and high-volume for gRPC. Many different kinds of clients for GraphQL. No need for an answer right now for a queue. ```knowledge-check { "questions": [ { "id": "ip45-hld-03-rpc-q1", "type": "mcq", "prompt": "Two of your own internal services exchange 50,000 structured requests a second. Why is gRPC usually preferred over REST with JSON here?", "options": [ {"id":"a","text":"gRPC responses can be cached by a CDN, but JSON responses cannot"}, {"id":"b","text":"Its compact binary format plus sharing one connection across many requests cuts payload size, CPU spent encoding and decoding, and per-request overhead, and its typed contract is checked before the code even runs"}, {"id":"c","text":"gRPC guarantees a message is delivered exactly once"}, {"id":"d","text":"REST simply cannot be used between backend services"} ], "correct": "b", "explanation": "At high internal volume, the CPU cost of parsing JSON and the size of each payload are real problems, and an untyped contract drifts between teams over time. gRPC fixes both. It gives no delivery guarantee beyond whatever the underlying connection provides, and it's a poor fit for public or browser access." } ] } ``` ## Quick recap | Question | Answer | |---|---| | Client needs updates, server to client only | SSE | | Client and server both need to push | WebSocket, plus sticky routing and a shared messaging layer | | Updates are rare, staleness is fine | Short polling | | Public API | REST/JSON over HTTP | | Internal, high volume, typed | gRPC | | Many client shapes, one round trip | GraphQL, plus depth limits and batching | | Caller doesn't need the result right now | Message queue | | Loss-tolerant, latency-critical media | UDP or WebRTC | | Fast regional failover | Short DNS TTL plus health checks | | Static assets, worldwide audience | CDN at the edge, anycast | 4a:T3ad8,The API is the first real, concrete thing you produce in a design interview, and it's the part most people rush through. Done well, it takes about four minutes and quietly answers half a dozen questions the interviewer would otherwise have to ask you: how do you page through results, how do you handle new versions, what happens if the client sends the same request twice, and who's allowed to call this in the first place. ## Resource modelling and the URL contract REST is just a set of naming habits for URLs, and the whole point of following them is that someone reading your API should be able to guess the next endpoint without being told. ``` GET /v1/users/{id} fetch one GET /v1/users/{id}/tweets?cursor=... a sub-collection POST /v1/tweets create PATCH /v1/tweets/{id} partial update DELETE /v1/tweets/{id} delete POST /v1/tweets/{id}/retweet an action that isn't CRUD ``` A few rules worth saying out loud. **Put nouns in the path, and let the HTTP method carry the verb.** `POST /v1/createTweet` is the classic mistake; the "create" belongs in the method, not the URL. When an action genuinely isn't a simple create, read, update, or delete (retweeting, publishing, cancelling), it's fine to add an action word as a sub-path, like `retweet` above. Just say so, rather than twisting the model to avoid it. **Nest one level deep, then stop.** `/users/{id}/tweets` reads fine. `/users/{id}/tweets/{tid}/comments/{cid}/likes` does not; instead, expose `/comments/{cid}/likes` directly. **HTTP status codes carry real meaning**, so use the right one: `200` means it worked, `201` means something new was created, `202` means it's accepted and being processed in the background, `204` means it worked and there's nothing to return, `400` means the request itself was malformed, `401` means the caller isn't identified, `403` means they are identified but not allowed to do this, `404` means it doesn't exist, `409` means it conflicts with the current state, `422` means the request was well-formed but doesn't make sense, `429` means the caller has been rate-limited (with a `Retry-After` header telling them when to try again), `500` means it's your bug, and `503` means the server is overloaded or degraded. **Errors should have one consistent, machine-readable shape.** For example: `{"error": {"code": "INSUFFICIENT_FUNDS", "message": "...", "request_id": "..."}}`. The `code` is for the client's own logic to react to, the `message` is for a human to read, and the `request_id` is what your support team uses to find the exact request in the logs. **The HTTP method matters more than the URL.** Picture pressing an elevator call button. Pressing it five times doesn't summon five elevators; one press has the same effect as five. Now picture radioing a colleague and saying "add one more passenger" five times: that really does add five passengers. That difference between the two is exactly what these two words describe: - **Safe** means the call doesn't change anything at all. `GET`, `HEAD`, and `OPTIONS` are safe. - **Idempotent** means repeating the call has the same effect as calling it once. `GET`, `PUT`, and `DELETE` are idempotent by convention; `POST` is not. Calling `PUT /users/1 {name:"A"}` twice still leaves one user named A. Calling `POST /tweets` twice creates two separate tweets, which is exactly the problem the idempotency key below is built to solve. > **Remember:** safe means "doesn't change anything." Idempotent means "repeating it changes nothing further." A `POST` is neither, by default. ```knowledge-check { "questions": [ { "id": "ip45-hld-04-rest-q1", "type": "mcq", "prompt": "A client is logged in, but is trying to delete someone else's post. Which status code is correct?", "options": [ {"id":"a","text":"401 Unauthorized"}, {"id":"b","text":"403 Forbidden"}, {"id":"c","text":"400 Bad Request"}, {"id":"d","text":"500 Internal Server Error"} ], "correct": "b", "explanation": "401 means \"I don't know who you are,\" because credentials are missing or invalid. 403 means \"I know exactly who you are, and you may not do this.\" Some APIs deliberately return 404 instead of 403, to avoid revealing that the resource even exists; that's a legitimate design choice worth mentioning." } ] } ``` ## Idempotency: the retry problem This is the single most valuable API topic to know for interviews, because it shows up in every payment, booking, and messaging design. Picture paying at a shop with a card. The machine charges your card, but the receipt printer jams before it prints anything. Nobody knows if the payment went through, so the shopkeeper taps your card again "just in case." Without a safeguard, you've now paid twice. That is exactly the failure at the API level: a client sends a payment request, the server charges the card, and the reply is lost somewhere on the network. The client, seeing no reply, tries again. Without protection, the customer is charged twice. The standard fix is an idempotency key: ``` POST /v1/payments Idempotency-Key: 8f14e45f-ea24-4e0b-b8d1-5a3c7f1e2b90 { "amount_cents": 49900, "currency": "INR", "order_id": "ord_123" } ``` The idempotency key is a random ID the client generates once for this one logical action, and sends along with every attempt at it. Here is what the server does with it. 1. Look up the key in a store built for this purpose (Redis, or a database table), scoped to that particular caller. 2. **If it's not there yet:** insert it marked `in_progress`, guarded by a **unique constraint on the key**. That constraint is what makes this safe when two retries arrive at almost the same moment; only one of them can win the insert. Then do the actual work, save the response and its status, and mark it `completed`. 3. **If it's there and `completed`:** return the exact same response you already saved. Do not repeat the work. 4. **If it's there and still `in_progress`:** return a `409 Conflict` and let the client try again shortly. 5. Let keys expire after 24 to 48 hours, so the store doesn't grow forever. Two details that show real understanding. **The unique constraint is what makes this correct, not the lookup.** "Check if it exists, then insert" without a database constraint is a race: two retries arriving together can both pass the check before either one finishes inserting. **Idempotency is not the same as blocking a second, genuine payment.** If the user truly wants to pay twice, they send a brand new key. The key represents one logical action, generated once by the client, not once per network attempt. Where you can't add a dedicated key, use a **natural idempotency key** already present in the data, such as an `order_id` with a unique constraint on it, or a chat message's client-generated `message_id`. > **Remember:** the UNIQUE constraint is what makes an idempotency key correct, not the lookup before it. A check without a constraint is a race two retries can both win. ```knowledge-check { "questions": [ { "id": "ip45-hld-04-idem-q1", "type": "mcq", "prompt": "Why does a correct idempotency implementation need a UNIQUE database constraint on the key, rather than just checking if it exists before writing?", "options": [ {"id":"a","text":"To make lookups faster"}, {"id":"b","text":"Because two retries arriving at almost the same time can both find no existing record and both proceed. Only the database constraint guarantees exactly one of them wins"}, {"id":"c","text":"Because keys must be stored in sorted order"}, {"id":"d","text":"To let the key expire automatically"} ], "correct": "b", "explanation": "Checking then acting is a classic race condition. The unique constraint turns it into a single atomic step: the loser gets a constraint violation and returns the already-saved result instead of charging the card again." } ] } ``` ## Pagination, filtering, and partial responses Picture a librarian who, every single time you ask for book number 100,000 on a shelf, walks past the first 99,999 books one by one before handing you the right one. That's page-number pagination. A better librarian just remembers exactly where your bookmark was and starts from there. **Never page through a feed using page numbers.** A query like "skip the first 100,000 rows, then give me 20" forces the database to walk through and discard 100,000 rows every single time, and a new row inserted at the top shifts every later page, so users end up seeing duplicates. **Use cursor pagination instead**, where the cursor is a bookmark encoding exactly the sort position of the last row the client saw: ```sql SELECT id, text, created_at FROM tweets WHERE author_id = $1 AND (created_at, id) < ($2, $3) -- the decoded cursor; id breaks ties ORDER BY created_at DESC, id DESC LIMIT 21; -- fetch one extra to know if there's a next page ``` Return `{"items": [...], "next_cursor": "eyJ0IjoiMjAy..."}`. Making the cursor an opaque, encoded string (rather than a plain page number) means you can change the underlying sort order later without breaking any client that's using it. | | Page number | Cursor | |---|---|---| | Cost of a deep page | Grows with how far you page | Stays roughly constant, an index lookup | | Stable when new rows arrive | No | Yes | | Can jump straight to page 500 | Yes | Not really, but rarely needed | | Total count of items | Easy to get | Needs a separate, rough estimate | **Filtering and asking for only some fields** looks like `?status=active&created_after=2026-01-01&fields=id,name`. Only allow filtering and sorting on a fixed list of fields you've approved. An open-ended filter parameter that reaches the database directly is both a security hole (an attacker can inject their own query logic) and a way for one careless client to scan your entire production table. **Rate limiting is part of the API contract, not an afterthought.** Return the caller's budget in response headers, so well-behaved clients can pace themselves: ``` X-RateLimit-Limit: 1000 X-RateLimit-Remaining: 42 X-RateLimit-Reset: 1757145600 Retry-After: 30 (on 429) ``` > **Remember:** a cursor is a bookmark, not a page number. It survives new rows being inserted at the top; a page number does not. ```knowledge-check { "questions": [ { "id": "ip45-hld-04-pagination-q1", "type": "mcq", "prompt": "Why does a cursor for a feed sorted newest-first usually encode both the timestamp and the row's id, instead of just the timestamp?", "options": [ {"id":"a","text":"To make the cursor longer and harder to guess"}, {"id":"b","text":"Because several rows can share the exact same timestamp, and without a tie-breaker the page boundary can skip some rows or repeat them"}, {"id":"c","text":"Because timestamps cannot be indexed"}, {"id":"d","text":"To support jumping to an arbitrary page number"} ], "correct": "b", "explanation": "Cursor pagination needs every row to have a unique position in the ordering. If ten posts share the exact same millisecond, comparing only against the timestamp either drops all ten or returns them twice. Adding the row's own id as a tie-breaker makes the sort order unique." } ] } ``` ## Versioning, compatibility, and the API gateway **Put a version in the URL from day one**, like `/v1/`. It's the simplest option, and it's easy to work with: it shows up in your logs, a load balancer can route on it directly, and it's simple to cache. Putting the version in a header instead is technically purer, but it's much harder to debug. The real skill isn't picking a versioning scheme. It's **avoiding the need for a v2 at all**, by only ever making changes that don't break existing clients: | Safe to ship | Breaks existing clients | |---|---| | Add a new optional field to a response | Remove or rename a field | | Add a new optional request parameter | Make a previously optional parameter required | | Add a new endpoint | Change a field's type or unit | | Add a new possible value to a list, if clients already ignore values they don't recognise | Change what an existing value means | | Loosen a validation rule | Tighten a validation rule | When you truly must break something, run both the old and new versions side by side, announce a date when the old one stops working, add a `Deprecation` header to warn callers, and track which clients are still using the old version so you know exactly who you're about to affect. **The API gateway** is the one place that handles concerns shared by every service, so each service doesn't have to rebuild them itself: ``` Client → Gateway ──▶ auth (verify JWT / API key) ──▶ rate limiting + quotas ──▶ request validation ──▶ routing / versioning ──▶ TLS termination, compression ──▶ logging, tracing headers, metrics ──▶ services ``` Keep business logic out of the gateway. A gateway that starts making decisions about, say, whether an order is valid, turns into one giant service with a single owner and a single point of failure, just wearing a gateway's name. > **Remember:** a change is safe to ship without a new version if an old client can simply ignore it and keep working. Adding something is usually safe. Renaming, removing, or changing the type of something usually is not. ```knowledge-check { "questions": [ { "id": "ip45-hld-04-versioning-q1", "type": "mcq", "prompt": "Which change to an existing endpoint is backward compatible for clients already running in production?", "options": [ {"id":"a","text":"Renaming the response field `userName` to `user_name`"}, {"id":"b","text":"Adding a new optional query parameter that defaults to today's current behaviour"}, {"id":"c","text":"Changing the `amount` field from rupees to paise"}, {"id":"d","text":"Making the previously optional `currency` field required"} ], "correct": "b", "explanation": "Additions that come with a safe default don't break anyone. Renaming a field, silently changing its unit, and making an optional field required all break existing callers. The silent unit change is the most dangerous of the three, because nothing errors out; the numbers are simply wrong." } ] } ``` ## Quick recap ``` □ 3–5 endpoints, nouns + HTTP verbs, /v1/ prefix □ Cursor pagination on every list → {items[], next_cursor} □ Idempotency-Key on every non-idempotent write, backed by a UNIQUE constraint □ Consistent error envelope: {error:{code, message, request_id}} □ Rate-limit headers + 429 + Retry-After □ Auth at the gateway: who calls this, and what scope do they need? □ Whitelisted filter/sort fields — never pass client strings to the query planner ``` 4b:T3bce,"Add a load balancer" is the answer almost everyone reaches for the moment traffic grows, and by itself it earns you nothing. A load balancer is a server that sits in front of your other servers and spreads incoming requests across them. What actually earns points is knowing which layer it works at, which algorithm it uses and why, what happens when one of your servers dies mid-request, and what happens when the load balancer itself dies. ## Vertical vs horizontal, and what makes scaling out possible **Vertical scaling** means buying a bigger machine. It's genuinely the right first move more often than interview prep suggests: there's no distributed-systems complexity to manage, no code changes needed, and a single modern machine can handle a lot. It does have a hard ceiling, and the cost climbs faster than the power once you're near the top of what one machine can do. It also leaves you with exactly one machine to lose. **Horizontal scaling** means adding more machines instead of a bigger one. It has no real ceiling and it survives one machine dying, but it demands one property from your application: it must be **stateless**. An app server is stateless when any one of its copies can answer any incoming request, because none of them is holding on to something the others don't have. In practice that means: - Don't store login sessions in one server's own memory. Put them in Redis (a shared, fast data store), or use a signed token the client itself carries. - Don't keep a private cache of changing shared data on one server. Share it through Redis, or accept, on purpose, that different servers might show slightly different data for a moment. - Don't write files to local disk that matter later. Put them in object storage instead, a service built for storing files. - Don't hardcode "the third server is the one that runs the nightly job." Use a scheduler that picks exactly one runner through leader election, a mechanism covered later in this section. Say this out loud whenever you draw several copies of an app server on your diagram: "these are stateless, session data lives in Redis, so I can add or remove instances freely." That one sentence turns a plain box diagram into a considered design. State never actually disappears. It just moves into fewer places: the database, the cache, and the queue. That's why so much of system design keeps coming back to those three boxes. > **Remember:** any single server instance must be replaceable at any moment. If losing one instance loses data a user needed, that data was stored in the wrong place. ```knowledge-check { "questions": [ { "id": "ip45-hld-05-scaling-q1", "type": "mcq", "prompt": "An app stores logged-in user sessions in each server's own memory. What breaks when you put three of these servers behind a load balancer that rotates requests evenly?", "options": [ {"id":"a","text":"Nothing, because the load balancer copies memory between the servers automatically"}, {"id":"b","text":"Users appear randomly logged out, because a request can land on a server that never saw their original login and so has no session for them"}, {"id":"c","text":"Encrypted connections fail to set up"}, {"id":"d","text":"The database becomes the bottleneck"} ], "correct": "b", "explanation": "Storing sessions in one server's own memory means the servers are no longer interchangeable. The fixes are a shared session store like Redis, a self-contained token like a JWT, or always sending the same user to the same server (sticky sessions). Sticky sessions are the worst of the three: they unbalance the load and lose that user's session entirely if that one server goes down." } ] } ``` ## L4 vs L7, and the algorithms Picture a mail sorter who only glances at the envelope's address, compared with a receptionist who actually opens the letter and reads what it asks for. The sorter is faster, because it reads less. The receptionist can make smarter decisions, because it reads more. Load balancers come in these same two kinds. **Layer 4** load balancing decides where to send traffic based only on the connection itself: the IP address and port. It never looks inside the actual message being sent. It's very fast, it works for any kind of traffic, and once a connection is set up, it sticks to the same server for its entire lifetime. **Layer 7** load balancing ends the connection at the balancer itself, reads the actual HTTP request, and can route based on the URL path, a header, a cookie, or the method used. That's what makes path-based routing possible, like sending `/api/*` to one service and `/static/*` to a CDN, along with routing a small slice of traffic to a new build based on a header, and even rewriting or caching responses. It costs more CPU, and it only works for HTTP-style traffic. | | L4 | L7 | |---|---|---| | Sees | IP address and port only | The full HTTP request | | Balances | Per connection | Per request | | Can route by | Nothing beyond IP and port | Path, header, cookie, method | | Encrypted connections | Passes through, or ends them | Ends them, and can re-encrypt | | Throughput | Very high | Lower, because it has to parse each request | | Typical tools | AWS NLB, IPVS | AWS ALB, nginx, Envoy, HAProxy | **The algorithms, and when each one is the wrong choice:** | Algorithm | What it does | Fails when | |---|---|---| | Round robin | Sends each new request to the next server in turn | Requests cost very different amounts of work, or servers have different capacity | | Weighted round robin | Same idea, but bigger servers get more turns | Same weakness as round robin, just handles unequal hardware better | | **Least connections** | Sends the request to whichever server currently has the fewest in-flight requests | Rarely a bad choice; a safe default when requests cost different amounts | | Least response time | Sends the request to whichever server answered fastest recently | Can overwhelm a server that just came back online empty and looks fast for a moment | | IP hash or consistent hash | The same client, or the same key, always lands on the same server | Traffic can be unevenly spread across clients; needed when you want cache hits to stay on one server, or a session to stick to one machine | | Random two choices | Pick two servers at random, send it to whichever of the two has less load | Nearly as good as least-connections, with much less coordination needed | A complete answer to "which algorithm would you use?" is: "round robin by default, least-connections when requests cost different amounts, and consistent hashing when I need cache locality or a session to stick to one machine." > **Remember:** L4 reads the envelope, L7 reads the letter. Reach for L7 the moment you need to route by path, header, or cookie. ```knowledge-check { "questions": [ { "id": "ip45-hld-05-l4l7-q1", "type": "mcq", "prompt": "You need to send `/api/*` to the API service, `/images/*` to a media service, and 5% of traffic carrying a specific header to a new build. What do you need?", "options": [ {"id":"a","text":"An L4 load balancer, because it's faster"}, {"id":"b","text":"An L7 load balancer, because only it reads the actual HTTP request and can therefore route on path and header"}, {"id":"c","text":"DNS round robin"}, {"id":"d","text":"Consistent hashing on the client's IP address"} ], "correct": "b", "explanation": "An L4 balancer only ever sees the IP address and port, so path-based and header-based rules are simply impossible for it to apply. Routing by the content of a request is exactly the reason to accept L7's extra parsing cost." } ] } ``` ## Health checks, draining, and failing over the balancer itself A load balancer that keeps sending traffic to a server that's already dead is worse than having no load balancer at all. **There are two useful kinds of health check, and they answer different questions.** - **Liveness** asks "is the process still alive?" If it fails, the answer is to restart that process. - **Readiness** asks "can this server actually handle traffic right now?" If it fails, the answer is to stop sending it traffic, without killing it. This is the check a load balancer must use. A server that's still warming up its cache, or one whose database connections are all in use, is alive but not ready. Keep the readiness check **shallow by default**, meaning it should only check the server itself, not everything it depends on. A readiness check that also verifies the database connection means one short database hiccup marks every single app server unhealthy at the exact same moment, taking your entire fleet out of rotation at once. That's a self-inflicted outage. Check deeper dependencies through a separate check that doesn't affect routing. **Passive health checking** works alongside active checks: after a server fails a number of requests or times out repeatedly, take it out of rotation automatically, then let it back in gradually once it recovers. This is sometimes called outlier detection. **Connection draining** matters during a deploy: stop sending *new* requests to a server that's shutting down, but let its requests already in flight finish, up to a timeout. Skip this step and every deploy throws errors at whoever happened to be mid-request. **Who watches the load balancer itself?** Say this before the interviewer has to ask. 1. Run at least two load balancer machines. Either DNS returns both addresses, or they share one address with automatic failover between them. 2. Use your cloud provider's managed load balancer, which is itself already spread across multiple machines and zones. 3. For failing over between entire regions, combine anycast (one address advertised from many sites) with DNS health checks using a short TTL, so DNS itself pulls a dead region out of rotation. > **Remember:** liveness asks "is it alive?" Readiness asks "can it serve traffic right now?" The load balancer should always ask readiness, and readiness should never depend on a shared dependency. ```knowledge-check { "questions": [ { "id": "ip45-hld-05-health-q1", "type": "mcq", "prompt": "Why is it dangerous for an app server's readiness check to also verify its database connection?", "options": [ {"id":"a","text":"It makes the health check slightly slower"}, {"id":"b","text":"A single database hiccup marks every app instance unhealthy at the same moment, so the load balancer removes the entire fleet at once, turning a partial problem into a total outage"}, {"id":"c","text":"Health checks are not allowed to make network calls"}, {"id":"d","text":"It would reveal database credentials"} ], "correct": "b", "explanation": "A readiness check should describe the instance itself, not its dependencies. Putting a shared dependency in it ties every instance's health to the same failure, and removing the whole fleet is far worse than serving slightly degraded responses while the database recovers." } ] } ``` ## Reverse proxy, API gateway, sidecar, service mesh These four ideas overlap, and interviewers like hearing you tell them apart. | Box | Sits | Job | |---|---|---| | **Reverse proxy** (like nginx or Envoy) | In front of your servers | Ends encrypted connections, compresses responses, caches static files, does basic routing, shields slow clients from your app | | **API gateway** (like Kong, or AWS's ALB with Lambda, or Apigee) | At the edge, between the outside world and your system | Everything a reverse proxy does, plus checking who's calling, rate limits, quotas, API keys, versioning, and reshaping requests and responses | | **Sidecar proxy** (like Envoy running next to each service) | Right beside each individual service | Handles encrypted service-to-service calls, retries, timeouts, and tracing for that one service, without the service's own code needing to know | | **Service mesh** (like Istio or Linkerd) | A control layer managing every sidecar | Fleet-wide rules: encryption everywhere, splitting traffic between versions, retry limits, and consistent monitoring | Two directions are worth naming clearly. **North-south** traffic flows between the outside world and your system; that's the gateway's job. **East-west** traffic flows between your own internal services; that's the mesh's job. **Service discovery** is what makes any of this work as servers come and go. Something has to keep track of which servers currently exist. - **Server-side discovery**: clients call one stable load balancer address, and the load balancer itself knows the current list of servers, kept up to date by a tool like Consul, etcd, or Kubernetes. It's simple, at the cost of one extra network hop. - **Client-side discovery**: clients fetch the current list themselves and pick which server to call. It saves that extra hop and can make smarter choices, but every client, in every programming language, needs that same logic built in, which is exactly why sidecars exist: they carry that logic once, outside the application code. One failure mode worth naming for a load balancer itself: it can run out of **bandwidth** just as easily as it can run out of capacity for requests. Streaming 75 gigabits per second of video out cannot pass through a single load balancer; that traffic has to go around it entirely, through a CDN or through direct, signed links to object storage. > **Remember:** a gateway handles traffic between the outside world and your system (north-south). A sidecar mesh handles traffic between your own services (east-west). They solve different problems. ```knowledge-check { "questions": [ { "id": "ip45-hld-05-proxy-q1", "type": "mcq", "prompt": "What does a sidecar proxy running next to each service give you that an edge API gateway does not?", "options": [ {"id":"a","text":"Ending encrypted connections for outside clients"}, {"id":"b","text":"Control over service-to-service calls, like encryption, retries, timeouts, and tracing, without changing application code in every service's own language"}, {"id":"c","text":"Managing API keys for outside developers"}, {"id":"d","text":"Caching static files"} ], "correct": "b", "explanation": "The gateway governs north-south traffic coming in from outside. A sidecar governs east-west traffic between your own internal services, which never passes through the edge at all; that's the exact gap a service mesh fills." } ] } ``` ## Quick recap ``` Scale up first (simple, real ceiling) → scale out when you need HA or exceed one box Scaling out requires statelessness: sessions → Redis/JWT, files → S3, cron → leader election L4 = IP:port, per connection, fast L7 = HTTP-aware, per request, routable Default algorithm: round robin → least connections when request cost varies → consistent hashing for cache locality / affinity Readiness ≠ liveness. Never check shared dependencies in the routing health check. Always: 2+ LBs, connection draining on deploy, outlier ejection on repeated errors North–south = gateway. East–west = mesh/sidecar. Discovery = who's alive right now. ``` 4c:T51ad,Imagine you keep a photocopy of your most-used library book on your desk, so you don't walk to the library every time you need to check a fact. That copy is faster to reach, but now you have two copies of the same information, and if the library updates its book, your desk copy is out of date until you notice. That is exactly what a cache is: a fast copy of data kept close to whoever needs it, with the constant risk of going stale. Caching is the cheapest speed boost you'll ever get in a system, and it's also the most common source of quiet, confusing bugs in production. In interviews it comes up twice: once when you draw Redis on the board, and again a bit later when the interviewer asks "so how does the cache get updated when the data changes?" That second question is the one that tells the interviewer whether you've actually operated a cache, or only drawn one. ## Where caches live A system usually has several caches stacked on top of each other, not just one. Naming which layer you mean is half the battle. | Layer | Example | Typical time before expiry | How it's kept fresh | |---|---|---|---| | Client / browser | `Cache-Control: max-age`, service worker | minutes to days | Filenames that change when content changes | | CDN / edge | CloudFront, Cloudflare, Fastly | minutes to days | A purge request, or filenames that change | | Reverse proxy | nginx / Varnish page cache | seconds to minutes | Time-based expiry, or a purge request | | Application (in-process) | A local map kept inside one server's memory | seconds | Time-based expiry only; each server has its own copy, so there's no single place to clear them all | | Distributed cache | Redis, Memcached | minutes to hours | Deleted directly whenever the real data changes | | Database | Postgres's internal buffer pool | — | Handled automatically by the database itself | | Precomputed result | A feed stored in Redis, a summary table | until recomputed | Recomputed whenever the underlying event happens | Two rules for deciding where to put a cache. **Cache as close to the user as the data's need for freshness allows.** A product photo can sit safely in a browser for a whole year, as long as its filename changes whenever the photo does. A live stock price cannot sit anywhere for more than a second. **An in-process cache, one stored in a single server's own memory, cannot be cleared reliably.** With 20 servers running, you have 20 separate copies, and no single button that clears all of them at once. Only use this kind of cache for data where a short, bounded amount of staleness is genuinely fine, like feature flags or configuration values. > **Remember:** cache close to the user, but only as close as the data's freshness allows. A stock price and a product photo do not need the same expiry time. ```knowledge-check { "questions": [ { "id": "ip45-hld-06-layers-q1", "type": "mcq", "prompt": "Why is a cache stored in each server's own memory a poor fit for data that must update the instant it changes?", "options": [ {"id":"a","text":"In-process caches are too slow"}, {"id":"b","text":"Every server holds its own separate copy, so there is no single place to clear them all; you'd need to reliably tell every server at once, and any server that missed the message keeps serving old data"}, {"id":"c","text":"In-process caches can only store plain text, not structured data"}, {"id":"d","text":"They use up database connections"} ], "correct": "b", "explanation": "Clearing a cache reliably needs one single place in charge of it. A shared Redis gives you that; a separate copy in each server's memory does not. A per-server cache is only safe when a short time-based expiry is an acceptable amount of staleness." } ] } ``` ## The four caching patterns **Cache-aside**, also called lazy loading, is the default choice, the one you should reach for unless you have a specific reason not to. Here, your application code owns the cache directly. ```python def get_user(user_id): key = f"user:{user_id}" cached = redis.get(key) if cached is not None: return json.loads(cached) # hit user = db.query("SELECT * FROM users WHERE id = %s", user_id) # miss if user is not None: redis.setex(key, 300, json.dumps(user)) # populate with a TTL return user def update_user(user_id, changes): db.update("users", user_id, changes) redis.delete(f"user:{user_id}") # invalidate, don't rewrite — see below ``` Only data that's actually been requested gets cached, and if the cache goes down entirely, the system just gets slower instead of breaking outright. The cost is that every miss still has to wait for the database, and there's a small window between saving to the database and deleting the old cache entry where another reader could put the stale value right back in. **Write-through** writes to the cache and the database together, at the same time, as part of the same request. The cache is never out of date, but every single write now pays for both, and you might end up caching data nobody ever reads again. **Write-behind**, also called write-back, writes to the cache, tells the caller it's done, and saves to the database later, in batches. Writes are very fast this way, which is great for things like counters, but if the cache crashes before that batch is saved, that data is gone. Only use this where losing a little data is genuinely acceptable, or where it can be rebuilt from elsewhere. **Refresh-ahead** refreshes popular keys just before their expiry time runs out, so a real user request never has to wait through a cache miss. This works well for a small, predictable set of hot keys, and wastes effort if you guess wrong about which keys are hot. | Pattern | Speed reading | Speed writing | How stale can it get | Risk of losing data | |---|---|---|---|---| | Cache-aside | Fast when found, slow on a miss | Only the database | A small window | None | | Write-through | Always fast | Both database and cache | Never | None | | Write-behind | Always fast | Only the cache | Never, inside the cache | **Yes** | | Refresh-ahead | Always fast | Only the database | Limited and predictable | None | **When you write new data, delete the old cache entry. Do not overwrite it directly.** Here's why: if two writers update the cache at almost the same time, their updates can land in the wrong order, leaving the *older* value stuck in the cache permanently. Deleting the entry instead forces the very next read to go fetch the real, current value from the database. If you need to close even the small gap left by a delete, use a "delayed double delete": delete the cache entry, write to the database, then delete the cache entry again a few hundred milliseconds later. > **Remember:** cache-aside is the default. On a write, delete the cached key instead of overwriting it, so the next read always pulls the true value from the database. ```knowledge-check { "questions": [ { "id": "ip45-hld-06-patterns-q1", "type": "mcq", "prompt": "When updating a row, why is deleting the matching cache key generally safer than overwriting it with the new value directly?", "options": [ {"id":"a","text":"Deleting is a faster operation than overwriting"}, {"id":"b","text":"Two writers updating the cache at nearly the same time can land in the wrong order, leaving the older value stuck in the cache forever; a delete instead forces the next read to fetch the real value from the source of truth"}, {"id":"c","text":"Redis does not allow overwriting an existing key"}, {"id":"d","text":"Deleting always frees up more memory, which is always the better outcome"} ], "correct": "b", "explanation": "Picture writer A reading the old value first, then writer B updating both the database and the cache to a new value, and finally writer A's slightly delayed cache update overwriting it back to the old value. Now the cache disagrees with the database, permanently. Deleting removes that possibility entirely; the worst case is one extra cache miss." } ] } ``` ## Eviction, TTLs, and hit rate Picture a small fridge that's already completely full. New milk arrives, so something has to come out to make room. Do you throw out whatever has sat there longest without being touched, or whatever gets used the least often? That choice is called an eviction policy, and a cache faces the exact same decision whenever it runs out of memory. **Eviction policies decide what gets dropped first when memory runs out:** | Policy | What it drops | Best used for | |---|---|---| | **LRU** (least recently used) | Whatever hasn't been touched in the longest time | General use; this is the usual default | | **LFU** (least frequently used) | Whatever gets touched the fewest times overall | A stable set of hot keys, where you want to survive one big sweep through cold data | | FIFO (first in, first out) | Whatever was added first | Rarely the right choice | | Random | A randomly chosen key | Surprisingly decent, and very cheap to compute | | Time-based only | Only keys that have an expiry set | When some keys must never be evicted, ever | In Redis, you'll usually name `allkeys-lru` or `allkeys-lfu`. LFU's advantage is that one big analytical job sweeping through a million cold keys won't push out your genuinely hot data, because touching something only once never builds up enough frequency to matter. **Expiry times (TTLs, meaning "time to live") do two jobs.** They limit how stale data can get, and they act as a safety net if your code ever forgets to clear a cache entry on a write. Always set one, even on keys you also delete explicitly by hand. A cache entry with no expiry and one missed update becomes a permanently wrong answer. **Add a small random amount to every TTL, called jitter.** If 10,000 keys are all set with the exact same 300-second expiry at the exact same moment, they all expire in the very same second, and every one of those 10,000 requests hits your database at once. Setting the expiry to `300 + random(0, 60)` seconds spreads that load out instead. **Hit rate is the single most important number to watch.** A cache that answers correctly only half the time is barely helping. A hit rate above 95% is where the real speed gain lives. Track hits, misses, evictions, and memory used; a rising number of evictions is an early warning that the data you actually need no longer fits, and your hit rate is about to fall off a cliff. A useful rule of thumb for sizing a cache: roughly 20% of your keys usually account for about 80% of requests, so estimate the size of that hot 20%, not the size of your entire dataset. > **Remember:** LRU throws out what hasn't been touched in a while; LFU throws out what's rarely touched at all. LFU survives a big sweep through cold data; LRU does not. ```knowledge-check { "questions": [ { "id": "ip45-hld-06-eviction-q1", "type": "mcq", "prompt": "A nightly batch job reads through every single user record once. Under which eviction policy is it LEAST likely to push out the hot keys real users depend on?", "options": [ {"id":"a","text":"LRU, because the scanned keys become the most recently touched and push out the hot set"}, {"id":"b","text":"LFU, because each scanned key is only touched once and never builds up enough frequency to displace the genuinely hot keys"}, {"id":"c","text":"FIFO"}, {"id":"d","text":"No eviction policy at all"} ], "correct": "b", "explanation": "This is the classic reason to choose LFU. Under LRU, one sequential sweep through a million cold records marks all of them as \"most recently used\" and pushes out the actual working set, so the next morning starts with a nearly empty, cold cache." } ] } ``` ## The three failure modes: stampede, penetration, avalanche Bringing these up before the interviewer asks is a strong sign that you've actually operated a cache in the real world. **1. Cache stampede, also called a thundering herd.** Picture a shop's doors opening at 9am with 5,000 people waiting outside, and every single one of them rushing through the same one door at once. That's what happens when one popular cache key expires: thousands of requests miss the cache at the same moment and all hit the database for that same row simultaneously. The database can fall over under that load. The usual fixes, in order of preference: - **Request coalescing**, sometimes called single-flight: the very first request that misses takes a short lock, and every other request waits briefly, then rechecks the cache instead of also hitting the database. - **Probabilistic early refresh**: as a key's expiry time gets closer, each reader has a small and rising chance of refreshing it early, so on average exactly one of them ends up doing the work ahead of time. - **Serve stale while refreshing in the background**: hand back the expired value immediately, and quietly refresh it behind the scenes. This is the standard behaviour CDNs use. **2. Cache penetration** happens when requests ask for keys that don't exist in the database at all, often because someone is deliberately probing with random IDs in a loop. Every single one of those requests misses the cache *and* misses the database. The fix is to cache the fact that something doesn't exist, storing something like "no such user" with a short expiry, and optionally put a Bloom filter in front of the cache. A Bloom filter is a small, cheap structure that can quickly and confidently say "this definitely does not exist," which is exactly the question being abused here. **3. Cache avalanche** happens when a large chunk of the cache disappears all at once, either because many keys expire together or because the cache itself restarts, and the full weight of production traffic lands on a cold database with nothing cached to soften it. The fixes are the jitter on TTLs mentioned earlier, warming the cache up before a restarted server is marked ready to receive traffic, keeping a backup or replicated copy of the cache so a restart isn't a total cold start, and putting a circuit breaker (covered in a later lesson) in front of the database, so an overload turns into some errors instead of a complete collapse. > **Remember:** a stampede is everyone rushing one expired key at once. Penetration is repeated requests for keys that never existed. An avalanche is the whole cache disappearing at once. Each one needs its own fix. ```knowledge-check { "questions": [ { "id": "ip45-hld-06-failures-q1", "type": "mcq", "prompt": "An attacker repeatedly requests IDs that don't exist, so every single request misses both the cache and the database. What is this called, and what is the standard fix?", "options": [ {"id":"a","text":"Cache stampede; fix it with a lock so only one request refills the value"}, {"id":"b","text":"Cache penetration; cache the fact that the value doesn't exist with a short expiry, and optionally put a Bloom filter in front of the cache"}, {"id":"c","text":"Cache avalanche; fix it by adding jitter to the expiry times"}, {"id":"d","text":"Cache invalidation; fix it by deleting keys whenever data is written"} ], "correct": "b", "explanation": "Penetration is exactly this miss-then-miss pattern for keys that genuinely don't exist. Caching a \"not found\" result stops the repeated database hits, and a Bloom filter can answer \"definitely not present\" without touching the database at all." } ] } ``` ## CDNs and edge caching Picture ordering a book online. Instead of shipping every single copy from one warehouse on the other side of the world, the seller keeps copies in local warehouses on every continent, so your copy only has to travel 50 kilometres instead of 15,000. A CDN, short for Content Delivery Network, does exactly this for web content: it stores copies of your files on servers physically close to users all around the world. For anything large and mostly unchanging, like images, video, and JavaScript files, a CDN is a core part of the design, not something you bolt on afterward. **Here's how a request flows through one.** DNS, or a technique called anycast, sends the user to the nearest edge location. If that location already has the file cached, it serves it directly in 10 to 30 milliseconds, instead of the 150 milliseconds a round trip to a far-away server would take. If it doesn't have the file yet, it asks a regional layer behind it, which asks your own server if it doesn't have it either, then caches the result on the way back so future requests are fast. That regional layer exists so your own server only has to serve each new file once, not once per edge location around the world. **A CDN can either pull or be pushed to.** A pull CDN fetches a file the first time someone asks for it; simple, and it maintains itself, at the cost of the very first user paying the full delay. A push CDN has files loaded onto it ahead of time by you; useful for large files and launches where you know exactly what's coming. **A handful of HTTP headers control all of this:** ``` Cache-Control: public, max-age=31536000, immutable # hashed asset: app.4f2b9c.js Cache-Control: public, max-age=60, stale-while-revalidate=300 # HTML/API: fresh-ish, never a stampede Cache-Control: private, no-store # per-user or sensitive ETag: "a1b2c3" → client sends If-None-Match → 304 Not Modified (no body) Vary: Accept-Encoding, Accept-Language # each variant is a separate cache entry ``` An ETag is a short fingerprint of a file's content; a client can ask "has this changed since I last saw fingerprint X?" and get back an empty "not modified" reply if it hasn't. **Clearing files at the edge is the hard part, and the answer is almost always to change the filename.** A file named `app.4f2b9c.js`, where that string is a hash of its own content, never needs to be updated once it's cached; it can sit there for a year. Deploying a new build simply produces a new filename. A "please clear this file everywhere" request is possible too, but it's slower, limited in how often you can call it, and takes a moment to reach every location; use it for exceptions, not as your main strategy. Be careful with the `Vary` header: varying the cache based on a header with many possible values, like the raw `User-Agent` string, multiplies the number of separate cache entries needed and can quietly destroy your hit rate. **Beyond plain files**, a CDN can also cache short-lived API responses, run small pieces of code near the user for personalisation, hand out signed, temporary links for private files (so the CDN carries the bytes while your own server only ever approves permission), and shield a small origin server from a very large audience. > **Remember:** a content-hashed filename turns "clear this file everywhere" into "give the new version a new name," which needs no clearing step at all. ```knowledge-check { "questions": [ { "id": "ip45-hld-06-cdn-q1", "type": "mcq", "prompt": "What is the most reliable way to make a JavaScript file cacheable for a year at the CDN, while still being able to ship updates instantly?", "options": [ {"id":"a","text":"Set a one-year expiry and call the purge API on every deploy"}, {"id":"b","text":"Put a hash of the file's content in its filename, and serve it as unchanging: a new build automatically produces a new filename, so there is nothing to clear"}, {"id":"c","text":"Set a 60-second expiry so updates spread quickly"}, {"id":"d","text":"Turn off CDN caching for JavaScript entirely"} ], "correct": "b", "explanation": "A content-hashed filename turns clearing the cache into a naming problem, which is always more reliable than clearing it everywhere on demand. A clear-cache request takes a moment to reach every location and is limited in frequency; a new filename is instant everywhere by design." } ] } ``` ## Quick recap ``` Patterns : cache-aside (default) · write-through (fresh) · write-behind (fast, lossy) · refresh-ahead (hot keys) Rule : on write, DELETE the key — never update it TTL : always set one (safety net) + add jitter (avoid synchronised expiry) Eviction : LRU default · LFU when scans would flush the hot set Failures : stampede (lock / stale-while-revalidate) · penetration (cache NULL / Bloom) · avalanche (jitter + warming + circuit breaker) Metrics : hit rate, eviction rate, memory used, p99 latency CDN : hashed immutable URLs > purge API; stale-while-revalidate for HTML/API; signed URLs for private media; origin shield for small origins ``` 4d:T4cdc,"SQL or NoSQL?" comes up in almost every design interview. The answer that actually scores points is never a personal preference. It's a mapping from what your queries look like to which storage engine handles that shape best. This lesson walks through that mapping, what a database index actually is, why two common storage designs behave so differently, and the transaction guarantees you're already relying on, whether you know it or not. ## Picking a store from the access pattern Start from the questions you'll actually ask the database, not from whichever technology you've heard of. | If the workload is… | Use | Because | |---|---|---| | Related entities, varied queries, rules that span multiple rows | **Relational** (Postgres, MySQL) | Joins, constraints, real transactions, mature tools | | Huge volume, a known key, simple lookups, very high write rate | **Wide-column** (Cassandra, DynamoDB, HBase) | Spreads writes across many machines, tunable correctness, no joins | | Flexible, evolving records fetched as a whole | **Document** (MongoDB, DocumentDB) | Flexible shape, reads nested data without joins | | Short-lived data, counters, leaderboards, sessions, queues | **In-memory** (Redis) | Sub-millisecond speed, useful built-in data structures | | Full-text search, filters, ranking results by relevance | **Search index** (Elasticsearch, OpenSearch) | Built to search text quickly and score results | | Time-stamped measurements at very high write rate | **Time-series** (Timescale, InfluxDB, Prometheus) | Compresses well, shrinks old data automatically, manages retention | | Following relationships (friend of a friend of a friend) | **Graph** (Neo4j) | Follows connections directly, instead of joins that would explode | | Large files that rarely change | **Object store** (S3) plus a small database for details about each file | Cheap, durable, works well with a CDN | | Scanning billions of rows for analytics | **Columnar / warehouse** (BigQuery, ClickHouse, Redshift) | Reads only the columns it needs, compresses very well | Three things worth saying out loud when you make this choice. **"Postgres until proven otherwise."** A well-run Postgres database handles JSON documents, full-text search, location data, and time-series data reasonably well all at once. Running one system you actually know how to operate beats running four you don't. Reaching for Cassandra at 200 requests a second is treated as a mistake, not a strength. **Using more than one kind of database at once is normal, but each one has a real cost.** Every extra store is one more thing to back up, monitor, secure, and keep in sync with the others. Justify each one you add. **When you do use two stores, say clearly which one is the source of truth.** For example: "Postgres holds the real data; Elasticsearch is a search index rebuilt from a stream of Postgres's own changes, and it might lag behind by about a second." **A one-line comparison of three popular wide-column and document stores.** Cassandra has no single leader, spreads writes across many equal machines, and lets you tune correctness per request; it's hard to beat for write-heavy systems spread across regions. DynamoDB is a managed service shaped the same way, but it demands careful choice of the key you partition by. MongoDB has a leader-based design, is pleasant to build with day to day, and needs extra care once your data starts looking more like related tables than standalone documents. > **Remember:** start from the query you need to answer, not from a favourite database. "Postgres until proven otherwise" is a strong, defensible default. ```knowledge-check { "questions": [ { "id": "ip45-hld-07-choice-q1", "type": "mcq", "prompt": "A system needs 100,000 writes a second of sensor readings, always queried as \"readings for device X between time T1 and T2,\" and never joined with anything else. What fits best?", "options": [ {"id":"a","text":"A relational table with an index on device id and timestamp together"}, {"id":"b","text":"A time-series or wide-column store, partitioned by device id and sorted within each partition by timestamp, with compression and shrinking of old data"}, {"id":"c","text":"A graph database"}, {"id":"d","text":"Redis as the only copy of the data"} ], "correct": "b", "explanation": "The query pattern here is a known key plus a time range, exactly what a time-series or wide-column store is built for, and the write rate is about 10 times what a single relational database handles. Partitioning by device and sorting by time, plus shrinking old data over time, is the standard answer." } ] } ``` ## Indexes: what they are and when they hurt Think of a textbook with no index at the back. To find every page that mentions "mitosis," you'd have to read the whole book cover to cover. An index at the back tells you the exact page numbers, so you jump straight there instead. A database index works the same way: it's a separate structure that maps a column's values to where the matching rows actually live, so the database can jump straight to them instead of reading every single row. ```sql -- Without an index: sequential scan of 10M rows SELECT * FROM tweets WHERE author_id = 42 ORDER BY created_at DESC LIMIT 20; -- With this index: an index seek to author 42, then 20 rows read in order CREATE INDEX idx_tweets_author_time ON tweets (author_id, created_at DESC); ``` **When an index covers several columns, the order you list them in matters enormously.** An index on columns `(a, b, c)` speeds up a query that filters on `a` alone, one that filters on `a` and `b` together, and one that filters on all three. This is called a left prefix, meaning it only helps when your query's filter starts matching from the leftmost column onward. It does **not** speed up a query that filters on `b` alone, skipping `a`. A rule worth remembering: put the columns you filter for an exact match first, and put the column you sort or filter by a range on last. **A covering index** stores every column a query needs directly inside the index itself, so the database never has to go fetch the actual row separately. In Postgres this is written with `INCLUDE (...)`. This turns two separate reads into one, and it's often the first thing to try when a specific query is running too slowly. **Indexes are not free. Here is what they cost you:** - Every time you insert, update, or delete a row, every index on that table has to be updated too. A write-heavy table with eight indexes on it is really doing nine writes for every one you asked for. - They take up storage space and memory that the table's own frequently-used pages would otherwise use. - The database's query planner can sometimes choose a worse plan when its internal statistics are out of date. - **Indexing a column with only a few possible values rarely helps.** An index on a true-or-false column usually loses to simply scanning the whole table, because jumping around randomly through an index to fetch half the rows is slower than just reading them in order. **Indexes can silently fail to help in a few common situations**: wrapping the column in a function, like `WHERE lower(email) = ...`, needs a special index built on that exact function; a search pattern starting with a wildcard, like `LIKE '%foo'`, can't use a normal index either; neither can an implicit type conversion, or an `OR` condition spanning two different columns, which is often better rewritten as two queries combined with `UNION`. > **Remember:** a composite index on `(a, b, c)` only helps queries that filter starting from the left: `a` alone, `a` and `b` together, or all three. It cannot help a query that filters on `b` alone. ```knowledge-check { "questions": [ { "id": "ip45-hld-07-index-q1", "type": "mcq", "prompt": "You have an index on the columns `(country, city, created_at)`, in that order. Which query can it NOT speed up?", "options": [ {"id":"a","text":"WHERE country = 'IN'"}, {"id":"b","text":"WHERE country = 'IN' AND city = 'Pune'"}, {"id":"c","text":"WHERE city = 'Pune'"}, {"id":"d","text":"WHERE country = 'IN' AND city = 'Pune' ORDER BY created_at DESC"} ], "correct": "c", "explanation": "A composite index is sorted starting from its first column, so it only helps queries that filter starting from that same leftmost column onward. Filtering on `city` alone skips `country` entirely, so this index gives no useful shortcut; a separate index starting with `city` would be needed instead." } ] } ``` ## B-tree vs LSM-tree: why write-heavy stores are different Picture two libraries handling returned books. Library A puts every returned book straight back onto its exact alphabetical shelf spot right away. That's slower per book, but any book is instantly findable afterward. Library B just drops every return onto a cart by the door, and once the cart is full, carries the whole thing to the shelves in one batch. That's much faster per return, but you might have to check both the cart and the shelf to find a specific book. Library A is how a B-tree works. Library B is how an LSM-tree works. This single difference explains almost everything about how a database behaves under reads versus writes. **A B-tree** is used by Postgres, MySQL's InnoDB engine, and most relational databases. It's a balanced tree of fixed-size pages, and it updates those pages *in place*, directly where they already live. - Reading is predictable: roughly a handful of page reads no matter how big the table gets, and because the lowest level of the tree is kept sorted, scanning a range of values is cheap. - Writing means finding the right page, changing it, and writing it back. That's a **random** write to disk, plus an entry in a separate log kept purely to survive a crash. Over time, pages that keep splitting apart become fragmented. - Best suited to read-heavy or mixed workloads, range queries, and strong correctness on a single machine. **An LSM-tree**, short for log-structured merge-tree, is used by Cassandra, RocksDB, LevelDB, HBase, and ScyllaDB. New writes land first in an in-memory table, get appended to a log on disk for safety, and are periodically flushed out into new, unchangeable, sorted files. A background process called compaction later merges those files back together. - Writing only ever appends data, never rewrites it in place, which is dramatically faster. This is exactly why LSM-based stores dominate write-heavy workloads. - Reading may have to check the in-memory table plus several of those sorted files on disk, a cost called read amplification. This is softened by keeping a Bloom filter per file, a small structure that can quickly say "definitely not in this file," and by the ongoing compaction process merging files together. - The costs: compaction uses real disk and CPU time in the background and can cause sudden slowdowns; a delete is really just a marker called a tombstone, and the space isn't actually freed until the next compaction; and duplicate copies of the same data can pile up temporarily before compaction cleans them up. | | B-tree | LSM-tree | |---|---|---| | How it writes | Random, changes data in place | Only ever appends | | How much it can write | Lower | **Much higher** | | How it reads | One tree | The in-memory table plus several files, helped by Bloom filters | | How predictable a single read is | Very predictable | More variable | | Range scans | Excellent | Good | | Wasted space | Fragmented pages | Duplicate data until compaction runs | | Background work | Occasional cleanup (called vacuum) | **Compaction**, which can cause sudden slowdowns | | Deletes | Changed in place | Marked with a tombstone first | The one sentence worth memorising: **B-trees make reads fast by paying a small cost on every write. LSM-trees make writes fast by paying that cost later, on reads and during background compaction.** > **Remember:** a B-tree write updates data in place immediately. An LSM-tree write just appends, and cleans up later. That's why LSM-trees win on write-heavy workloads. ```knowledge-check { "questions": [ { "id": "ip45-hld-07-lsm-q1", "type": "mcq", "prompt": "Why do LSM-tree storage engines sustain far more writes per second than B-tree engines?", "options": [ {"id":"a","text":"They keep the entire dataset in memory"}, {"id":"b","text":"Writes are buffered in memory and flushed as new, unchangeable, sorted files, avoiding the random in-place page changes a B-tree performs"}, {"id":"c","text":"They don't guarantee data survives a crash"}, {"id":"d","text":"They simply use smaller page sizes"} ], "correct": "b", "explanation": "Writing data in one continuous sweep beats jumping around randomly to update it, even on modern solid-state drives, and never rewriting a page in place skips the read-modify-write cost a B-tree pays. That cost doesn't disappear; it shows up later as extra reading work and background compaction." } ] } ``` ## Transactions: ACID and isolation levels Picture transferring 100 rupees from your account to a friend's. Two things have to happen: your balance drops by 100, and your friend's balance rises by 100. If the system crashes right after the first step but before the second, the money has simply vanished. A transaction is the database's promise that a group of changes like this happen together completely, or not at all. **ACID is the set of guarantees a transaction makes, and you should be able to defend each letter:** - **Atomicity** means every statement in the transaction commits, or none of them do. - **Consistency** here means the transaction moves the database from one valid state to another, respecting whatever rules you've declared, like a column that must never be negative. This is a different "C" from the one in CAP, a topic covered in a later lesson; interviewers like to test whether you know that. - **Isolation** means transactions running at the same time don't see each other's unfinished work, at least to the degree the chosen isolation level actually promises. - **Durability** means once a transaction is confirmed, it survives a crash, thanks to a safety log, forcing data to disk, and often replication too. **Isolation levels decide which problems can still happen. Learn this table well:** | Level | Can you read another transaction's unfinished work? | Can the same read return different values twice? | Can new rows appear in a repeated range query? | Cost | |---|---|---|---|---| | Read Uncommitted | Yes | Yes | Yes | Lowest | | **Read Committed** (Postgres's default) | No | Yes | Yes | Low | | **Repeatable Read** (MySQL's default; called "snapshot" in Postgres) | No | No | Yes, except in Postgres, where it's also prevented | Medium | | **Serializable** | No | No | No | Highest, and can force retries under heavy contention | A few terms defined plainly. A **dirty read** means reading another transaction's work before it's even confirmed. A **non-repeatable read** means reading the same row twice in one transaction and getting two different answers. A **phantom read** means running the same range query twice and seeing new rows appear the second time. A **lost update** means two transactions each read a row, change it, and write it back, and one of those two changes silently disappears. Read Committed, Postgres's own default, does **not** protect you from a lost update. The practical rule most teams follow: use Read Committed everywhere by default, and add explicit locking or an atomic write only in the small number of places where a lost update would actually matter. ```sql -- Lost update, the classic bug: two concurrent runs can both read 10 and both write 9. SELECT seats FROM events WHERE id = 1; -- 10 UPDATE events SET seats = 9 WHERE id = 1; -- Fix 1 — pessimistic: take the row lock, then decide. BEGIN; SELECT seats FROM events WHERE id = 1 FOR UPDATE; UPDATE events SET seats = seats - 1 WHERE id = 1; COMMIT; -- Fix 2 — optimistic: no lock; retry if someone else moved first. UPDATE events SET seats = seats - 1, version = version + 1 WHERE id = 1 AND version = $expected_version AND seats > 0; -- 0 rows affected → someone beat you → re-read and retry -- Fix 3 — atomic and best when it applies: let the database do the arithmetic -- and let a CHECK constraint enforce the invariant. UPDATE events SET seats = seats - 1 WHERE id = 1 AND seats > 0; ``` **Choosing between locking ahead of time (pessimistic) and checking afterward (optimistic) is a real trade-off worth naming.** Locking ahead of time is right when many people are competing for the same thing at once, like booking the very last seat at a popular event. Checking afterward is right when competition is rare, like editing your own profile, because it never holds a lock and so scales better, at the cost of having to retry the occasional guess that turned out wrong. **MVCC** (multi-version concurrency control) is the mechanism behind all of this in Postgres and MySQL. Instead of overwriting a row, a writer creates a new version of it, so readers never have to wait for writers, and writers never have to wait for readers. The cost is that old versions pile up and need periodic cleanup, called vacuuming, and a transaction left running for a long time can hold that cleanup back and let the table bloat. > **Remember:** Read Committed does not prevent a lost update. Two people reading the same row and both writing back is a real bug, and the fix is one single atomic UPDATE statement, not two separate application steps. ```knowledge-check { "questions": [ { "id": "ip45-hld-07-txn-q1", "type": "mcq", "prompt": "Two requests running at the same time each read the seats column (both see 10), then each write `seats = 9`. Which problem is this, and which fix removes it without using any lock?", "options": [ {"id":"a","text":"A dirty read; fix it by raising the isolation level to Read Committed"}, {"id":"b","text":"A lost update; fix it with one atomic statement, such as `UPDATE events SET seats = seats - 1 WHERE id = 1 AND seats > 0`, so the database computes the new value while holding its own row lock"}, {"id":"c","text":"A phantom read; fix it with Serializable isolation"}, {"id":"d","text":"A non-repeatable read; fix it by reading twice"} ], "correct": "b", "explanation": "Reading a value, changing it, and writing it back in separate application steps loses one of the two updates. Folding the arithmetic into the UPDATE statement itself means each statement takes the row's lock and applies its own change to whatever the current value actually is; the extra `seats > 0` check also stops overselling." } ] } ``` ## Quick recap ``` Choose by access pattern, not fashion. Postgres until proven otherwise. Index = seek instead of scan. Composite = LEFT PREFIX only. equality columns first, range/sort column last. Covering index avoids the table read. Index cost = write amplification + memory + planner risk. Low cardinality rarely helps. B-tree : in-place, random writes, great reads → read-heavy, relational LSM-tree: append-only, sequential writes, compaction → write-heavy, Cassandra/Rocks ACID's C ≠ CAP's C. Isolation: Read Committed (default) allows non-repeatable + phantom + LOST UPDATE. Concurrency fixes: atomic UPDATE > optimistic version check > SELECT FOR UPDATE MVCC: readers don't block writers; cost is VACUUM and long-transaction bloat. ``` 4e:T5d8f,Every single database eventually runs out of something: it can't read fast enough, it can't write fast enough, it can't hold any more data, or it can't stay online through a failure. There are exactly two tools for this, and they solve two different problems. Replication, keeping extra copies of the same data, helps with reads and with staying online. Partitioning, splitting the data itself into pieces, helps with writes and with storage. The two are almost always used together. Mixing up which one solves which problem is the most common mistake candidates make in this part of an interview. ## Replication: copies for reads and for survival **The leader-follower design**, also called primary-replica, sends every write to one server called the leader. Other servers, called followers or replicas, copy the leader's own log of changes and can serve reads. ``` ┌──▶ Replica 1 (reads) Writes ──▶ Leader├──▶ Replica 2 (reads) └──▶ Replica 3 (reads, standby for promotion) ``` - Reads scale up as you add more replicas. Writes do not scale at all, since they all still go through the one leader. - It keeps the system available: if the leader dies, you can promote a replica to take its place. - It introduces **replication lag**, the gap in time between the leader confirming a write and a follower actually applying it. Normally this is milliseconds, but it can stretch to seconds under heavy load, or even minutes during a large background job. **Whether the leader waits for a replica before confirming a write is a real dial you control, trading safety for speed:** | | Asynchronous | Synchronous | Semi-synchronous (a quorum) | |---|---|---|---| | Leader waits for | Nothing | Every replica | A chosen number, k, out of n replicas | | Write speed | Fastest | Slowest | In between | | Can data be lost if the leader crashes? | **Yes, possibly** | No | No, as long as at least one of the k survives | | Staying available | Best | One slow replica stalls every write | Keeps working even if n minus k replicas are slow or dead | Semi-synchronous, meaning "wait for at least one replica to confirm it, then reply," is the practical default most systems pick: it bounds how much data you could lose, and it bounds how much extra time each write costs. **Multi-leader replication** lets more than one region accept writes. This removes the extra delay of always writing to one far-away leader, and it keeps working even if regions can't talk to each other. The price is **write conflicts**, cases where two regions each changed the same thing differently and you have to decide which wins. The options are last-write-wins (simple, but it quietly throws away one of the two changes), a merge rule you write yourself, or CRDTs, special data structures designed to always merge cleanly without any conflict at all; these are the right answer for something like collaborative document editing. **Leaderless replication**, used by Dynamo and Cassandra, has the client itself write to several servers and read from several servers, with a bit of counting (called quorum arithmetic, covered in the next lesson on CAP and consistency levels) deciding how fresh the data you read back actually is. **Failover is where the genuinely hard questions live.** Promoting a replica to become the new leader involves detecting the failure without being fooled by a temporary network hiccup, picking whichever replica has the most up-to-date data, redirecting clients to it through DNS, a proxy, or a shared address, and preventing what's called split brain: the old leader coming back online and still accepting writes as if nothing happened. Split brain is prevented through fencing, giving each leadership term a steadily increasing number, and having every write carry that number so storage can reject one that's out of date. > **Remember:** replicas are copies for reading and for surviving a crash. They do nothing for your write rate; that's what partitioning is for. ```knowledge-check { "questions": [ { "id": "ip45-hld-08-replication-q1", "type": "mcq", "prompt": "A user posts a comment and is immediately sent to a page that reads from a replica, but their comment is missing. What is happening, and what is the standard fix?", "options": [ {"id":"a","text":"A cache stampede; add a lock around the read"}, {"id":"b","text":"Replication lag is breaking the \"see your own writes\" guarantee; send that user's reads to the leader, or to a replica known to have caught up, for a short window after they write"}, {"id":"c","text":"A lost update; use a row lock before updating"}, {"id":"d","text":"A phantom read; raise the isolation level to Serializable"} ], "correct": "b", "explanation": "Because replication happens asynchronously, a follower can genuinely be behind for a moment. The fix is to briefly pin that one user's reads to the leader, or to wait until a replica has caught up to the exact point their write happened at." } ] } ``` ## Partitioning: splitting the data itself Picture a library so large that one building can't hold every book, so the city splits its collection into five branch libraries, sorted by street address. Partitioning, also called sharding, does the exact same thing to data: it splits one logical set of data across many machines, so each one holds only a slice. This is what scales **writes** and **storage**, the two things replication alone cannot do. **Vertical partitioning** splits data by column or by feature: the users table lives on one cluster, and analytics events live on another. This is really "split the service into two," and it's often the right first move, because it doesn't require rewriting how your application routes queries. **Horizontal partitioning** splits data by row instead, and the big decision here is choosing the **partition key**, the value that decides which shard a given row lives on. | Strategy | How it works | Good | Bad | |---|---|---|---| | **Range** | Split by ranges, like A through F, or by date | Range queries stay inside one shard | Whatever's newest, like today's date, gets all the writes | | **Hash** | `hash(key) % N` | Spreads data evenly | Range queries have to hit every shard; adding a shard moves almost everything | | **Consistent hashing** | Keys and servers placed on a shared ring, using many points per server | Adding a server only moves about 1 out of N keys | More moving parts; still needs many points per server to stay even | | **Directory / lookup** | A separate service maps each key to its shard | Very flexible, easy to rebalance | That lookup service is now a dependency, and a possible single point of failure | | **Geographic** | Split by region | Good for latency and legal data-location rules | Queries spanning regions become expensive | **Here is exactly why `hash(key) % N` is a trap.** Say you have 4 servers, and a key like `"user:42"` hashes to the number 17. `17 % 4 = 1`, so that key lives on server 1. Now add a 5th server. The key's hash hasn't changed, but `17 % 5 = 2`, so the key suddenly moves to server 2, a server that didn't even just join. Multiply that across every single key whose answer changes between dividing by 4 and dividing by 5, which turns out to be most of them, and you can see why adding just one server to a cache fleet can wipe out almost the entire cache at once. ### Consistent hashing: the ring that fixes the modulo trap Picture a circular clock face instead of a plain numbered list of servers. Consistent hashing places both servers and keys onto that same circle, called a ring, usually numbered from 0 up to a very large number using a hash function like MurmurHash. A key belongs to whichever server you reach first walking clockwise from that key's own position on the ring. ``` hash space: a ring, 0 .. 2^32-1 0 / 2^32 | Server D * . . . . key "session:42" Server A hash -> lands here * * . walk CW . . | . Server C *--+---* Server B | (owns everything clockwise back to Server A) ``` With the ring, adding or removing a server only disturbs a small stretch of it, not the whole thing. - **Adding a server** only takes over the keys that sit between its new spot on the ring and the previous server clockwise from it. Every other key stays exactly where it was. Only about 1 out of every N keys moves, not nearly all of them. - **Removing a server** only hands its keys to the next server clockwise. Every other server's keys are left untouched. **Here's the part people forget: virtual nodes.** If each physical server only gets one single, randomly placed point on the ring, two problems show up. Some servers end up owning a much bigger stretch of the ring than others, purely by chance. And when a server dies, every single one of its keys lands on exactly one neighbour, doubling that neighbour's load overnight. The fix is to give each physical server 100 to 200 separate points on the ring instead of just one, labelled something like `server-A#1`, `server-A#2`, and so on. A key still resolves to "the first point clockwise," but now each physical server owns many small, scattered stretches instead of one big one. Load evens out, and when a server fails, its load spreads across several neighbours instead of dumping onto just one. Using more virtual points per server smooths the distribution further, at the cost of more data to keep track of. A server with twice the memory of its peers can simply be given twice the virtual points, which makes this count a knob for weighting capacity as well as for smoothing load. **Placing replica copies reuses this same ring.** For a replication factor of 3, a key gets stored on the first 3 *distinct physical servers* you reach walking clockwise past its position. This is exactly how Dynamo-style systems, including Cassandra and DynamoDB, decide where to place replicas, with no extra machinery needed. Two mistakes worth naming before you're asked about them: forgetting virtual nodes entirely, which leaves you with uneven load and a large blast radius when one server fails, and confusing "consistent hashing" with "the data itself is always up to date." The name only refers to the hashing staying stable as servers join and leave; it says nothing about how fresh a read is. > **Remember:** plain `hash(key) % N` reshuffles almost every key when a server joins or leaves. A ring with virtual nodes moves only about 1 out of N keys, and spreads a failure's load across many neighbours instead of dumping it on one. ```knowledge-check { "questions": [ { "id": "ip45-hld-08-consistent-hash-q1", "type": "mcq", "prompt": "Why does a hash ring use 100 to 200 virtual points per physical server, instead of just one point per server?", "options": [ {"id": "a", "text": "One point per server gives uneven load and dumps a dead server's entire load onto a single neighbour; many scattered points even out the load and spread a failure across several neighbours"}, {"id": "b", "text": "Virtual nodes make the hash function itself run faster"}, {"id": "c", "text": "Virtual nodes are required for the ring to support more than 4 servers"}, {"id": "d", "text": "Virtual nodes remove the need to choose a replication factor"} ], "correct": "a", "explanation": "With one point per server, where it lands on the ring is pure luck: some servers get a big stretch, some get a small one, and a dead server's entire stretch lands on one neighbour. Many small points spread across each server smooths out both the load and the size of a failure's impact." } ] } ``` **Choosing the partition key is the decision that matters most, and it should pass three tests.** 1. **High cardinality**, meaning enough distinct values to spread the data across many shards. Using `country` as the key is a bad choice, since all of India's data would land on one single shard. Using `user_id` is a good choice. 2. **Even access**, meaning no single value gets a disproportionate share of traffic. A celebrity's own `user_id` breaks this badly, which is exactly why handling a celebrity account is such a recurring design topic. 3. **Query alignment**, meaning your single most common query should be answerable from one shard alone. If you shard tweets by `tweet_id` but almost always query by `author_id`, every read now has to fan out and gather results across every single shard. **Sharding has real costs, and you should say them out loud, since they're exactly why you shouldn't shard before you need to:** - **You lose cross-shard joins.** You either copy data across shards to avoid needing a join, join the data yourself inside your application code, or keep a small reference table copied onto every shard. - **You lose cross-shard transactions**, unless you bring in two-phase commit or a saga, both covered in a later lesson. - **Queries that fan out and gather results from every shard** are only as fast as the single slowest shard, and their worst-case response time is far worse than what a single machine would give you. - **Staying globally unique and correctly ordered needs help.** Use a Snowflake-style ID, combining a timestamp, a machine number, and a counter, or a UUIDv7, instead of a simple auto-incrementing number. - **Rebalancing data across shards is a long, careful process**: write to both the old and new location at once, copy over the existing data in the background, double-check it matches, switch reads over, and only then stop writing to the old location. > **Remember:** a good partition key has many distinct values, spreads traffic evenly, and matches your most common query. Get any one of those wrong, and sharding creates new problems instead of solving the old one. ```knowledge-check { "questions": [ { "id": "ip45-hld-08-partition-q1", "type": "mcq", "prompt": "You shard an orders table by hashing `order_id`, but 90% of queries ask \"all orders for customer X.\" What goes wrong?", "options": [ {"id":"a","text":"Nothing; hash partitioning spreads data evenly, and that's all that matters"}, {"id":"b","text":"Almost every common query has to fan out and gather results across every single shard, so its speed tracks the slowest shard and overall throughput collapses; the key should instead match the dominant query, such as customer id"}, {"id":"c","text":"Orders lose their guarantee of being unique"}, {"id":"d","text":"Replication lag increases"} ], "correct": "b", "explanation": "Spreading data evenly is only half of what a good partition key needs to do. The other half is making sure your most common query can be answered from a single shard. Sharding by customer id keeps one customer's orders together, at the cost of a possible hot shard for one very large customer." } ] } ``` ## Hot spots, celebrities, and skew Picture five identical checkout counters in a supermarket, each meant to serve an equal share of shoppers. Then a celebrity walks in, and every other shopper drifts over to that one counter just to look. One counter is now swamped while the other four sit nearly empty. That's a hot shard: **traffic can be badly uneven even when the keys themselves are spread out evenly.** Every real system has some version of this: a celebrity account, a viral product, a huge sale-day item, or one customer that alone makes up 40% of your database's traffic. **Here is the order of fixes to offer, cheapest first:** 1. **Cache the hot key in front of the shard.** This is usually the cheapest fix, and it's often enough on its own; a single Redis key can absorb a million reads the shard would otherwise have had to serve. 2. **Split the key up, sometimes called salting.** Turn one hot key into ten, like `celebrity_id:0` through `celebrity_id:9`, and spread reads across all ten. Writes now spread out naturally; reads have to merge the ten results back together. 3. **Give the hot case a different path entirely.** The classic example: build each normal user's feed at write time, but build a celebrity's followers' feeds at read time instead, then merge the two approaches. 4. **Give it a dedicated shard, fully isolated.** Move one giant customer onto its own database. This is completely standard practice for multi-tenant systems, and it's easy to justify. 5. **Rate limit or shed load** for the extreme case, so that one troublesome key can't drag down everyone else's experience. **Spotting the problem matters as much as fixing it.** Track metrics per key and per shard, use a small structure called a count-min sketch to spot the busiest keys cheaply, and alert whenever one shard is carrying an unfair share of the load. Saying something like "I'd track requests per shard and their slowest 1%, and alert when one shard is more than twice the median" is a strong, concrete thing to say in an interview. > **Remember:** every real system has a hot key somewhere. The order of fixes is: cache it, split it, give it a separate path, then finally give it its own dedicated shard. ```knowledge-check { "questions": [ { "id": "ip45-hld-08-hotspot-q1", "type": "mcq", "prompt": "One customer on a multi-tenant system generates 40% of all queries and is overwhelming its shard. Which response is most standard?", "options": [ {"id":"a","text":"Re-shard the entire system with more shards"}, {"id":"b","text":"Move that one customer to its own dedicated database, and cache their most-read data, isolating their load from everyone else"}, {"id":"c","text":"Switch from hash-based partitioning to range-based partitioning"}, {"id":"d","text":"Add read replicas of every single shard"} ], "correct": "b", "explanation": "Adding more shards doesn't help here, since that one customer still lands on a single shard regardless of how many shards exist. Giving them their own dedicated database, plus caching, is the standard multi-tenant fix, and it also gives that customer more predictable performance." } ] } ``` ## Denormalisation, derived data, and multi-region Once your data is sharded, you lose the ability to join across shards, so the shape of your schema has to change to cope. **Denormalising on purpose, and being able to explain why, is a legitimate design choice.** Copying an author's display name directly onto each of their posts means rendering a feed needs no join at all, but it also means a name change has to be pushed out everywhere it was copied. Say the trade-off out loud: you're buying faster reads and keeping related data on one shard, at the cost of extra writes and the risk of the copies drifting apart over time. Add a background job that checks for and fixes drift for anything that truly must never drift. **Derived data stores** are the general version of this same idea: the relational database holds the real, authoritative data, and things like search indexes, caches, running totals, and analytics tables are all *derived* from a stream of its changes, either by reading its internal change log directly or through events your application publishes. Two properties make this pattern actually safe to use. - **It must be rebuildable.** If the derived store gets corrupted, or its schema needs to change, you should be able to simply replay the source data and regenerate it. Never let a derived store quietly become the only copy of something important. - **Its lag must be bounded and known.** Saying "the search index can be up to two seconds behind" is a real requirement you should state clearly, monitor, and set an alert on. **Operating in more than one region raises three questions, and interviewers will expect answers to all three.** | Question | Options | |---|---| | Where do writes happen? | One region writes for everyone (simple, but far-away users pay extra delay) · every region can write (fast locally, but creates conflicts) · each region owns its own users' data (splits by geography) | | How does data get copied between regions? | Asynchronously across regions (the normal choice) · synchronously (only for small, critical data, since the delay is severe) | | What happens if regions can't talk to each other? | Fail over to one side, risking split brain · fall back to read-only · accept the two sides drifting apart and reconcile them later | **Where data is legally allowed to live is a real constraint too.** Laws like GDPR can require that data belonging to EU users physically stays within the EU, which forces you to split data by geography no matter what your latency numbers suggest. **Running active in only one region at a time (active-passive) versus active everywhere (active-active)** is a real trade-off. Active-passive is far simpler: one region serves traffic, another sits ready as a standby, and failover is just promoting the standby, though it wastes the standby's capacity while idle. Active-active serves traffic from everywhere at once, giving lower latency, but makes keeping data correct and in sync much harder. State clearly which one you're choosing, and why. > **Remember:** a derived store, like a search index, a cache, or an analytics table, is only safe if you could throw it away and fully rebuild it from the source of truth. If you can't, it has quietly become a second source of truth. ```knowledge-check { "questions": [ { "id": "ip45-hld-08-derived-q1", "type": "mcq", "prompt": "You keep Postgres as the real data and Elasticsearch as a search index fed from a stream of Postgres's own changes. Which property must you preserve?", "options": [ {"id":"a","text":"Elasticsearch must be written to at the exact same time as Postgres, so it never lags behind"}, {"id":"b","text":"The index must be fully rebuildable by replaying Postgres's data from scratch, and its lag must be bounded, monitored, and clearly stated as a requirement"}, {"id":"c","text":"Writes must always go to Elasticsearch first, and Postgres second"}, {"id":"d","text":"Both stores must be split using the exact same partition key"} ], "correct": "b", "explanation": "A derived store is really a cache of the real data. Being rebuildable is what lets you survive a schema change or corruption; a bounded, monitored lag is what turns eventual consistency into a stated requirement, rather than a surprise bug someone discovers later." } ] } ``` ## Quick recap ``` Replication scales READS + availability. Partitioning scales WRITES + storage. Async replication → replication lag → breaks read-your-own-writes fix: read from leader briefly, or wait for a log position Sync/semi-sync → no data loss, higher latency. Semi-sync (k of n) is the sane default. Failover: detect → elect most-current → redirect → FENCE the old leader (epoch numbers) Partition key must be: high cardinality · evenly accessed · aligned with the top query hash % N is a trap → consistent hashing ring + virtual nodes moves only ~1/N of keys Sharding costs: no cross-shard joins/transactions, scatter-gather tails, global IDs (Snowflake/UUIDv7), painful rebalancing Hot key fixes: cache it → salt it → separate path (celebrity) → dedicated shard → shed Derived stores (search, analytics, cache) must be rebuildable from the source of truth Multi-region: where do writes go · how does data replicate · what happens in a partition ``` 4f:T4431,CAP is probably the most repeated, and least understood, idea in system design. People often say "we'll just pick AP" as if it were a simple setting to flip on, then quietly go on to design something that actually needs perfectly up-to-date data everywhere. This lesson makes the theorem precise, adds a second idea called PACELC that describes your system almost all of the time, and gives you the actual list of consistency levels to choose from. ## What CAP actually says Picture two branches of the same bank, in two different cities, whose phone line to each other has just gone dead. A customer walks into Branch A and withdraws the last 500 rupees from a shared account. At the very same moment, someone tries to withdraw from Branch B, which has no way to check with Branch A right now. Branch B has two choices. It can refuse the withdrawal until the phone line comes back, which is safe but turns the customer away. Or it can allow it anyway, risking paying out money that no longer exists. That exact choice is what CAP is about. **The theorem says this:** when a **network partition** happens, meaning two parts of a distributed system can no longer talk to each other, that system must choose between staying **consistent** and staying **available**. It cannot have both at the same time. Let's be precise about each word. - **C, for Consistency**, here specifically means linearizability: every read returns the most recently completed write, as if there were only one single copy of the data anywhere. This is a different meaning from the "C" in ACID, covered in the previous lesson. - **A, for Availability**, means every server that hasn't actually failed still returns a real answer, not an error. - **P, for Partition tolerance**, means the system keeps working even when messages between its own servers get lost or delayed. Here's the important correction most people miss: **P isn't something you get to choose.** Networks partition in real life: cables get cut, network switches reboot, a link between data centers gets overloaded. Any system spread across more than one machine has to deal with partitions sooner or later, so the only real decision is what to do *while* one is happening. - **CP** means refusing to answer rather than risking a stale or wrong answer. Whichever side of the split is in the minority returns errors instead of guessing. Choose this for money, inventory counts, unique constraints, and locks. - **AP** means both sides keep answering, accepting that they might now disagree, and sorting it out once they can talk again. Choose this for feeds, like counts, "who's online" indicators, product catalogues, and DNS. "CA," meaning consistent and available with no partition tolerance at all, isn't a meaningful category for a system spread across multiple machines. A database running on a single machine is trivially "CA" simply because it has no other machine to lose contact with in the first place. Two more points that score well in an interview. **This choice is made per operation, not once for the whole system.** The very same online shop can be CP for "place the order and reduce stock" while being AP for "show the product page and its review count." Saying this out loud is one of the single highest-value sentences in this whole topic. **The choice only actually applies while a partition is happening.** The rest of the time, which is nearly all of the time, you're making a completely different trade-off, which is exactly what PACELC, covered next, describes. > **Remember:** during a partition you pick consistency (refuse rather than risk a wrong answer) or availability (answer anyway, and fix it up later). Networks partition whether you plan for it or not. ```knowledge-check { "questions": [ { "id": "ip45-hld-09-cap-q1", "type": "mcq", "prompt": "Why is \"we'll build a CA system\" not a meaningful answer for a distributed database?", "options": [ {"id":"a","text":"Because consistency and availability are actually the same property"}, {"id":"b","text":"Because partitions are a fact of how networks behave, not something you can opt out of; any system spread across multiple machines must deal with them, so the only real choice is what to do during one: stay consistent (CP) or stay available (AP)"}, {"id":"c","text":"Because CA systems are simply too slow to be practical"}, {"id":"d","text":"Because CAP theory only applies to NoSQL databases"} ], "correct": "b", "explanation": "Partition tolerance isn't a design choice; it's forced on you by physical networks. Only a system running on a single machine escapes this, and it only escapes by not being distributed at all, which comes with its own cost to availability." } ] } ``` ## PACELC: the trade-off you make every day CAP only describes what happens in the rare moment a partition occurs. **PACELC** describes both that rare moment and every single ordinary day: > **If** there is a **P**artition, choose **A**vailability or **C**onsistency. **E**lse, during normal operation, choose **L**atency or **C**onsistency. That second half, the "else," is the part quietly governing your system's response times every single day. Getting perfectly up-to-date data across several replicas requires coordination between them, such as waiting for a quorum of servers to agree, or waiting on the one designated leader, and that coordination always costs time. Accepting slightly less-fresh data buys that time back. | System | How it's classified | What that means | |---|---|---| | Postgres / MySQL with one main server | Consistent during a partition, consistent normally | Chooses correctness both during and outside a partition | | DynamoDB, with its default reads | Available during a partition, fast normally | Chooses speed and availability both during and outside a partition | | DynamoDB, with strongly-consistent reads turned on | Consistent during a partition, consistent normally | You can opt into stronger guarantees per request; this makes the "per operation, not per system" point very concrete | | Cassandra, tunable | Available during a partition, fast normally, by default | Asking for `QUORUM` reads and writes shifts it toward the consistent side | | MongoDB, with majority write concern | Consistent during a partition, consistent normally | Configurable per operation | | DNS | Available during a partition, fast normally | Extremely available, and often quite stale | A strong sentence to use in an interview: **"Even when the network is completely healthy, staying perfectly consistent still costs a round trip of coordination. So I'm only using strong reads for the account balance check, and accepting slightly stale reads for the transaction history."** > **Remember:** CAP only describes the rare moment the network breaks. PACELC's second half describes every normal day: stronger consistency always costs latency. ```knowledge-check { "questions": [ { "id": "ip45-hld-09-pacelc-q1", "type": "mcq", "prompt": "What does the second half of PACELC describe that CAP leaves out entirely?", "options": [ {"id":"a","text":"How the system behaves during a network partition"}, {"id":"b","text":"That even during ordinary, non-partitioned operation there is still a trade-off between speed and consistency, because staying perfectly consistent requires coordination between servers"}, {"id":"c","text":"How data is encrypted while stored on disk"}, {"id":"d","text":"How many replicas a system needs"} ], "correct": "b", "explanation": "CAP only has something to say about the rare, partitioned case. PACELC's real contribution is naming the everyday cost: staying consistent is paid for in extra response time, whether or not the network is actually broken." } ] } ``` ## The consistency ladder Consistency isn't a single switch you flip on or off. It's a ladder of levels, and you should pick the weakest one that still meets your actual requirement, because every rung higher costs you extra time or availability. | Level | What it guarantees | What it costs | Use it for | |---|---|---|---| | **Linearizable (strong)** | Every read sees the latest confirmed write, as if there's only one copy anywhere | Coordination on every single operation; can become unavailable on the smaller side of a partition | Locks, uniqueness checks, account balances, seat allocation | | **Sequential** | Every server sees operations happen in the same order, though not necessarily in real time | High | Systems that replicate a state machine across servers | | **Causal** | Operations that are actually related to each other are seen in that same order by everyone | Moderate; requires tracking cause and effect using something like vector clocks | Comment threads, chat message ordering | | **See your own writes** | A user always sees the effect of their own recent action | Cheap; briefly route that one user's reads to the leader | Posting something, then viewing it right after; editing a profile | | **Never see time go backwards** (monotonic reads) | A user's reads never appear to move backward in time | Cheap; pin that one user's session to one replica | Any view that refreshes or pages through results | | **Eventual** | Replicas will agree, eventually, once writes stop coming in | Cheapest, and stays available the whole time | Like counts, view counts, feeds, catalogues, DNS | The two cheap guarantees in the middle, "see your own writes" and "never see time go backwards," deserve special attention, because they fix the exact symptoms users actually notice from eventual consistency, without paying the full cost of true linearizability. - **See your own writes**: right after posting, read from the leader itself, or from a replica confirmed to have caught up, for the next few seconds. - **Never see time go backwards**: keep a session pinned to one single replica, so a page refresh can never land on a more out-of-date replica and make something that was there a moment ago disappear. Together, these two cover most of what users actually complain about, which is why "eventual consistency, plus these two cheap guarantees" is such a common answer in real production systems. > **Remember:** pick the weakest consistency level that still meets the requirement. Every step stronger costs latency or availability, so don't pay for more than you need. ```knowledge-check { "questions": [ { "id": "ip45-hld-09-ladder-q1", "type": "mcq", "prompt": "Users complain that refreshing a page sometimes makes a comment they just loaded disappear, and then reappear later. Which guarantee fixes this most cheaply?", "options": [ {"id":"a","text":"Making every single read linearizable"}, {"id":"b","text":"Never seeing time go backwards: pin that user's session to one replica, so consecutive reads never move backward through the replication log"}, {"id":"c","text":"The strictest transaction isolation level"}, {"id":"d","text":"Coordinating every write across all replicas before confirming it"} ], "correct": "b", "explanation": "The symptom here is reads bouncing between replicas that are at different points in catching up. Pinning a session to one replica costs almost nothing and removes that time-travel effect entirely, without paying for coordination across the whole system." } ] } ``` ## Quorums and conflict resolution Picture a jury of 5 people. A verdict only counts once at least 3 of them agree; that's a majority. A quorum works the same way for replicas: as long as enough copies of the data agree, you can trust the answer, even if some copies are currently unreachable. **Quorum arithmetic is how leaderless stores, like Dynamo and Cassandra, let you dial consistency up or down for each individual request.** With `N` total replicas, `W` of them required to confirm a write, and `R` of them consulted on a read: > **If `W + R` is greater than `N`, the group of replicas you write to and the group you read from are guaranteed to overlap**, so a read is guaranteed to see the latest confirmed write. | Setting | What happens | |---|---| | N=3, W=3, R=1 | Fast reads, slow writes, and no writes at all can succeed if even one replica is down | | N=3, W=1, R=1 | Fastest possible, but W+R is not greater than N, so this is only **eventually consistent** | | **N=3, W=2, R=2** | The balanced default: overlap is guaranteed, and it tolerates one server being down for both reads and writes | | N=3, W=2, R=1 | Fast reads, but no overlap is guaranteed, so a read might return a stale value | Cassandra exposes exactly this idea as settings called `ONE`, `QUORUM`, and `ALL` on each query, plus a `LOCAL_QUORUM` option that keeps the quorum within one data center, useful across regions. Two mechanisms keep replicas converging back toward agreement over time. **Read repair** happens when a read notices replicas disagree and writes the newest value back to the ones that were behind. **Anti-entropy** is a background process that compares a compact summary (called a Merkle tree) of each range of keys across replicas and syncs up any differences it finds. **Hinted handoff** covers short outages: if a server is briefly down, another server holds onto the writes meant for it and delivers them once it's back. **When two replicas genuinely disagree, something has to decide which value wins:** | Strategy | How it works | Cost | |---|---|---| | **Last-write-wins** | Whichever value has the newest timestamp wins | Simple, but it **silently throws away** the other value, and clocks on different machines aren't perfectly in sync, so "newest" isn't always reliable | | **Vector clocks / version vectors** | Detects that two versions happened at the same time and hands both to the application | Correctly detects the conflict, but someone still has to write the code that merges the two | | **CRDTs** | Special data types, like certain counters, sets, and sequences, that merge cleanly by design | No conflict is even possible, but only certain kinds of data can be expressed this way | | **Application-level merge** | Your own business logic decides, such as combining both versions of a shopping cart | Usually the best outcome for the user, but also the most work to build | The classic example is Amazon's own shopping cart. Last-write-wins would quietly drop an item a user added from their phone if a different update landed after it. Merging the two carts together instead keeps both items; the worst case is a deleted item reappearing, which Amazon decided was a far better trade-off than losing a sale. **One warning about clocks.** The clocks on different machines are not reliably in sync with each other; even with time-syncing services, the drift can be milliseconds, and clocks can occasionally jump forward or backward. Use logical clocks, like Lamport timestamps or vector clocks, to determine which event happened before another. Google's Spanner achieves perfectly consistent transactions across the whole globe only by using GPS and atomic clocks to measure exactly how uncertain its own clock might be, and then deliberately waiting out that uncertainty before confirming each commit. That's a real measure of just how expensive true global consistency actually is. > **Remember:** `W + R > N` guarantees a read overlaps with the latest write. Conflict resolution is as much a product decision as a technical one: last-write-wins quietly deletes data, and that might not be acceptable. ```knowledge-check { "questions": [ { "id": "ip45-hld-09-quorum-q1", "type": "mcq", "prompt": "With N=5 replicas, which (W, R) pair guarantees a read sees the latest confirmed write while still tolerating two servers being down?", "options": [ {"id":"a","text":"W=1, R=1"}, {"id":"b","text":"W=3, R=3, since W+R=6 is greater than 5, so the two groups must overlap, and each group of 3 is still reachable with 2 of 5 servers down"}, {"id":"c","text":"W=5, R=1"}, {"id":"d","text":"W=2, R=2"} ], "correct": "b", "explanation": "Guaranteed overlap needs W+R greater than N: 3+3=6, which is greater than 5. Requiring 3 out of 5 still succeeds even with two servers unavailable, while W=5 needs every single server alive, and W=R=2 gives 4, which is not greater than 5, so there's no overlap guarantee at all." } ] } ``` ## Quick recap ``` CAP: during a PARTITION, choose C or A. P is not optional. "CA" isn't a distributed system. CP = refuse rather than diverge (money, inventory, locks) AP = serve and reconcile (feeds, likes, presence, catalogue) → the choice is PER OPERATION, not per system PACELC: if Partition → A or C; Else → Latency or Consistency (the everyday trade-off) CAP's C = linearizability ≠ ACID's C = constraint validity Ladder (weakest that works wins): eventual < monotonic reads < read-your-own-writes < causal < sequential < linearizable The two cheap session guarantees fix most user-visible symptoms. Quorum: W + R > N ⇒ overlap ⇒ read sees latest. N=3,W=2,R=2 is the default. Repair: read repair · anti-entropy (Merkle trees) · hinted handoff Conflicts: LWW (lossy) · vector clocks (detect) · CRDTs (merge by design) · app merge Clocks: wall-clock ordering across machines is unreliable — use logical clocks. ``` 50:T53fd,The moment you draw a queue on the whiteboard, an interviewer has four follow-up questions ready: what happens if whoever's processing the message crashes halfway through, what happens if the same message gets delivered twice, is the order of messages preserved, and what happens if messages arrive faster than they can be processed. Walk in with all four answers ready, and this becomes one of the strongest parts of your whole design. ## Why a queue, and where the line goes A queue does four genuinely different jobs, and being able to name which one you actually need is what separates "I'd just add a message broker like Kafka" from a design that's actually been thought through. | Job | What it buys you | Example | |---|---|---| | **Decoupling** | The producer doesn't need to know about, or wait on, its consumers | An order service announces "order placed," and separately, email, analytics, and inventory each pick that up | | **Buffering / smoothing out spikes** | Absorbs a sudden rush of traffic so the slower side isn't overwhelmed | 50,000 signups during a flash sale drain into a pool of workers at whatever pace they can handle | | **Moving slow work out of the way** | Keeps slow work off the path a user is waiting on | Converting video, generating a PDF, sending bulk email | | **Retrying safely, without losing anything** | A failed piece of work isn't simply lost | Retrying a failed payment notification with increasing delays | **Here's the line to draw in every design you build: anything the user's response doesn't depend on goes behind a queue.** Creating an order has to save that order and reply right away. Sending the confirmation email, updating a recommendation model, indexing for search, and telling the warehouse can all happen a moment later, in the background. There are real costs here, and you should mention them yourself before you're asked. - **The delay becomes visible to users.** "Your order is placed" shows up instantly, but the confirmation email might arrive 30 seconds later, and an analytics dashboard might lag behind by more. - **Debugging gets harder.** A failure now shows up in a background worker's log, not in the original request's trace, unless you deliberately carry a shared trace ID through both. - **It's another whole system to run**: the message broker itself, how its partitions are managed, watching for messages piling up, and handling messages that keep failing. > **Remember:** if the user's response doesn't depend on it, put it behind a queue. Everything else stays in the request path. ```knowledge-check { "questions": [ { "id": "ip45-hld-10-why-q1", "type": "mcq", "prompt": "Which of these must stay in the request path of creating an order, rather than moving behind a queue?", "options": [ {"id":"a","text":"Sending the order confirmation email"}, {"id":"b","text":"Reserving inventory and saving the order, because the response tells the user whether their order actually succeeded"}, {"id":"c","text":"Updating a recommendation model"}, {"id":"d","text":"Indexing the order for internal search"} ], "correct": "b", "explanation": "Anything the user's own response depends on has to finish before you reply to them. Everything the user only finds out about later, like an email, an analytics update, or search indexing, belongs behind the queue instead." } ] } ``` ## Queue vs log: the distinction that matters Picture a to-do list, where you cross an item off and it's gone for good, compared with a diary, where every entry stays on the page forever and you can flip back and reread any day you like. A to-do list works like a message queue. A diary works like what's called a distributed log. Picking the wrong shape for the job is a common and expensive mistake. **A message queue**, like RabbitMQ, SQS, or ActiveMQ, delivers each message to exactly one consumer, who processes it and confirms it, and the broker then **deletes** it. The broker keeps track of each individual message's state. **A distributed log**, like Kafka, Kinesis, Redpanda, or Pulsar, appends every message to an ordered, **kept** log, split into partitions. Consumers each track their own position, called an offset, and read at their own pace; a message is never deleted just because someone read it. Many separate groups of consumers can all read the very same stream, each independently. | | Queue (RabbitMQ/SQS) | Log (Kafka) | |---|---|---| | What happens after it's read | Deleted | Kept for a set time or size | | How many consumers per message | One, per queue | Many independent groups | | Can you replay old history | No | **Yes**, by resetting your offset | | Ordering | Only within one queue, and lost once several consumers share it | **Strict, within each partition** | | Routing options | Rich: exchanges, topics, headers, priorities | Simple: a topic, split into partitions | | Confirming or retrying one message | Built in, per message | Per offset; one stuck message blocks its whole partition | | How much it can handle | High | **Very high**, thanks to sequential disk writes and batching | | Typical use | Task queues, work that's like a remote call, priority-based routing | Streams of events, database change feeds, analytics, replaying full history | The decision rule is simple: **do you need to replay history, or have several independent consumers each read the same events? Use a log. Do you need per-message routing, priorities, or delayed retries? Use a queue.** In Kafka, partitions are the unit both of how much work can happen in parallel and of ordering itself: messages sharing the same key always go to the same partition and stay strictly ordered there, and each partition is only ever read by one consumer within a given group. So **the number of partitions is the most work you can do in parallel**, and the key you choose is what keeps things belonging to the same entity in order; keying by `user_id`, for instance, keeps one user's own events ordered, even though the topic as a whole is not. > **Remember:** a queue deletes a message once it's read. A log keeps every message, so many independent readers can each replay it at their own pace. Pick a log whenever you need to replay history. ```knowledge-check { "questions": [ { "id": "ip45-hld-10-queuelog-q1", "type": "mcq", "prompt": "You need order events consumed independently by billing, analytics, and search, and you want to rebuild the search index next month by re-reading everything from the start. What fits?", "options": [ {"id":"a","text":"A message queue, with three consumers reading from the same queue"}, {"id":"b","text":"A distributed log, like Kafka: each system runs as its own consumer group with its own offset, and the retained history lets you reset an offset and rebuild"}, {"id":"c","text":"Direct, synchronous calls from the order service to all three services"}, {"id":"d","text":"A shared database table that all three services poll"} ], "correct": "b", "explanation": "Three consumers sharing one queue would split the messages between them instead of each seeing every one, and a queue deletes a message once it's confirmed, so there's nothing left to replay. Keeping the full history and letting each group track its own offset is exactly what a log gives you." } ] } ``` ## Delivery semantics and idempotent consumers There are three possible promises a message system can make, and only two of them are actually achievable. | Promise | How it's done | What can go wrong | |---|---|---| | **At-most-once** | Confirm the message before doing the work | The message is lost if the worker crashes mid-way through | | **At-least-once** | Confirm the message after doing the work | **Duplicates** appear if the confirmation itself gets lost after the work was already done | | **Exactly-once** | Not actually achievable end to end, across separate systems | — | **At-least-once is both the default and the right choice**, because losing work outright is usually worse than accidentally doing it twice. That means handling duplicates isn't an edge case; it's a real design requirement. When Kafka advertises "exactly-once," it means exactly-once *inside Kafka itself*, through transactional writes across its own topics with a producer that avoids sending the same thing twice. The moment your consumer actually charges a card or sends an email, that's an effect happening out in the real world, one that Kafka's own transaction has no power to undo. The honest way to describe this, and the answer interviewers actually want to hear, is: **"at-least-once delivery plus idempotent processing gives you effectively-once behaviour."** **Here's how you actually make a consumer idempotent, meaning safe to run more than once:** ```python def handle(msg): # 1. Natural idempotency — the operation is safe to repeat as-is. # "SET status = 'shipped'" is idempotent; "counter += 1" is not. # 2. Deduplication table — the general mechanism. # The UNIQUE constraint is what makes it race-safe, not the SELECT. try: db.execute( "INSERT INTO processed_messages (message_id, processed_at) VALUES (%s, now())", msg.id, ) except UniqueViolation: return # already handled; ack and move on do_the_work(msg) # 3. Better still: do the work and record the message id in ONE transaction, # so a crash between them cannot leave the dedupe row without the effect. ``` Two more patterns worth knowing by name. **Conditional writes**: a statement like `UPDATE orders SET status='shipped' WHERE id=? AND status='paid'` has the same effect no matter how many times you run it, because it only applies once the row is actually in the expected starting state. **Version or sequence checks**: ignore any incoming event whose version number isn't exactly one greater than the one you already have stored. > **Remember:** duplicates are guaranteed in a distributed system, so design for them. "At-least-once delivery plus an idempotent consumer" is the honest, achievable promise, not "exactly-once." ```knowledge-check { "questions": [ { "id": "ip45-hld-10-delivery-q1", "type": "mcq", "prompt": "Why can no message broker offer true end-to-end exactly-once delivery when the consumer's job is sending an email?", "options": [ {"id":"a","text":"Because email servers themselves are unreliable"}, {"id":"b","text":"Because the consumer can crash right after sending the email but before confirming the message, and no protocol can pull back an email that's already been sent; the achievable goal is at-least-once delivery plus a consumer built to handle duplicates"}, {"id":"c","text":"Because message brokers don't save messages to disk"}, {"id":"d","text":"Because the network can reorder packets"} ], "correct": "b", "explanation": "True exactly-once needs a single atomic commit spanning both the broker and the real-world side effect. Kafka's transactions only cover writes back into Kafka itself, not anything happening outside it, which is exactly why \"effectively-once\" through an idempotent consumer is the honest answer." } ] } ``` ## Ordering, retries, dead letters, and backpressure **Ordering across an entire topic is expensive, and you almost never actually need it. Ordering per entity usually is what you need instead.** Partitioning by the entity's own key, like `user_id`, `account_id`, or `conversation_id`, gives you strict order exactly where it matters, while still letting different entities be processed in parallel. If you genuinely need every single message globally ordered, you're stuck with one partition and one consumer; say that cost out loud when you propose it. Ordering quietly breaks in three common situations: several consumers sharing one queue, a retried message getting pushed behind newer ones that arrived after it, and changing the number of partitions, which changes which partition a given key lands in. **Retries should use exponential backoff with a bit of randomness added, called jitter.** If every failed client retries after exactly the same fixed delay, they all end up retrying together in a wave, called a thundering herd. ``` delay = min(base * 2**attempt, max_delay) * random_between(0.5, 1.5) ``` Always put a cap on the number of attempts. Also tell apart failures that are worth retrying, like a timeout or a temporary overload, from ones that are permanent, like a validation error; retrying a message that's simply malformed forever is pure waste, and it blocks everything behind it in the same partition. **A dead letter queue** is where a message goes after failing too many times. After N attempts, move it there along with its error and how many times it was tried. Nothing is lost, the main flow keeps moving, and a person, or a separate fixed-up consumer, can retry it later. **Always alert on how many messages are sitting in the dead letter queue**; a dead letter queue nobody is watching is a data-loss incident that nobody has noticed yet. **Backpressure is what happens when producers create messages faster than consumers can process them.** The queue keeps growing, memory and disk fill up, and response times climb until something breaks. Your options are: 1. **Scale up the number of consumers**, automatically, based on how deep the queue is or how far behind consumers are. In Kafka, this only helps up to the number of partitions you have. 2. **Put a hard limit on the queue's size**, and reject or pause producers once it's full. Failing immediately and clearly is better than slowly grinding to a halt. 3. **Shed load on purpose**: drop lower-priority messages, or only process a sample of them. 4. **Rate limit the producers themselves.** **The single most important metric here is consumer lag**, meaning how far behind consumers are from the latest message. In Kafka this is the gap between offsets; in SQS it's how old the oldest unprocessed message is. Watch the *trend* in that lag over time, not just its current value: lag that keeps steadily growing means you simply don't have enough consumers, and waiting longer will never fix that on its own. > **Remember:** one bad message can block a whole partition if you keep retrying it forever. Move it to a dead-letter queue after N attempts, and alert on that queue's depth. ```knowledge-check { "questions": [ { "id": "ip45-hld-10-ops-q1", "type": "mcq", "prompt": "One malformed message fails permanently and keeps getting retried forever at the front of a Kafka partition. What is the correct fix?", "options": [ {"id":"a","text":"Increase the retry limit so it eventually succeeds"}, {"id":"b","text":"After N attempts, move it to a dead-letter topic along with its error details, confirm the original message so the partition can keep moving, and alert on how deep the dead-letter topic is getting"}, {"id":"c","text":"Delete the whole partition"}, {"id":"d","text":"Switch the whole system to at-most-once delivery"} ], "correct": "b", "explanation": "A message like this blocks its own partition because messages have to be confirmed in order. Moving it to a dead-letter queue takes it out of the way without losing it, and alerting on that queue's size makes sure someone actually notices and looks at it." } ] } ``` ## Event-driven patterns: pub/sub, outbox, event sourcing, CQRS **Point-to-point versus publish/subscribe.** Point-to-point means one producer, one consumer, one queue, like a personal to-do list. Publish/subscribe, often shortened to pub/sub, means one event has many independent subscribers, like a public announcement everyone can hear. Prefer publishing **facts**, like "order placed," over issuing **commands**, like "send the email." Publishing a fact lets you add a fourth listener later without ever touching the original producer, which is the entire point of decoupling systems in the first place. **The dual-write problem, and the outbox pattern that fixes it, is the single most valuable idea in this whole topic.** Picture writing a cheque, and then, on a separate trip, walking to the post office to mail someone a receipt for it. If you get hit by a bus in between those two trips, the cheque now exists, but nobody was ever told about it. Saving something to a database and then separately publishing an event to a message broker has exactly this same problem: **it isn't one single atomic action**. A crash in between the two can leave the order saved but never announced, or announced without ever actually being saved. ``` Wrong: BEGIN; INSERT order; COMMIT; kafka.publish(event) ← crash here = lost event Right: BEGIN; INSERT INTO orders (...); INSERT INTO outbox (id, topic, payload, created_at); -- same transaction COMMIT; -- a separate relay (CDC on the WAL, or a poller) reads outbox and publishes, -- marking rows sent. At-least-once by construction; consumers dedupe. ``` The reverse of this idea, called the **inbox pattern**, removes duplicates on the receiving side, by recording each processed message's id in the very same transaction as the effect it caused. **Event sourcing** stores the full sequence of events as the actual source of truth, and figures out the current state by replaying them from the start. In exchange, you get a complete audit trail, the ability to look at any point in the past, and the option to build entirely new views from that same history later. The cost is having to handle old event formats as your system evolves, needing periodic snapshots so replaying isn't unbounded, and the fact that a simple question like "what's the current balance" now requires computation instead of a lookup. Use this where the history genuinely *is* the product, like ledgers, audit trails, or collaborative documents, not as a default choice everywhere. **CQRS**, short for command query responsibility segregation, splits the model you write to from one or more separate models you read from, kept in sync through events. It pairs naturally with event sourcing, and with any system whose reads look very different in shape from its writes, such as a normalised write side feeding a denormalised feed for reading. The cost is that the two sides can briefly disagree with each other, and you now maintain two models instead of one. **Change data capture**, often shortened to CDC, reads a database's own internal change log directly, using a tool like Debezium on Postgres's write-ahead log or MySQL's binary log, and publishes each row change as an event. This gives you the outbox pattern's same safety without changing your application code at all, and it's the standard way to feed search indexes, caches, and data warehouses from one authoritative database. > **Remember:** writing to a database and publishing an event are two separate actions, so a crash between them loses one or the other. The outbox pattern writes the event into the same database transaction, so there is nothing to lose. ```knowledge-check { "questions": [ { "id": "ip45-hld-10-outbox-q1", "type": "mcq", "prompt": "A service saves an order to Postgres and then publishes an \"order placed\" event to Kafka. What can go wrong, and what is the standard fix?", "options": [ {"id":"a","text":"Nothing; the two writes simply happen one after the other"}, {"id":"b","text":"The dual-write problem: a crash between the save and the publish loses the event permanently. Fix it with a transactional outbox: insert the event into an outbox table in the very same transaction as the order, then have a separate relay, or change data capture, publish from that table"}, {"id":"c","text":"Kafka might reorder the event; fix it by adding a timestamp"}, {"id":"d","text":"Postgres might roll back after Kafka has already accepted the event; fix it with a longer transaction timeout"} ], "correct": "b", "explanation": "Two separate systems can't be written to atomically without something like a distributed transaction. The outbox pattern turns this into one single local transaction, followed by an at-least-once relay, with consumers built to handle the resulting duplicates." } ] } ``` ## Quick recap ``` Queue jobs: decouple · buffer · async · retry. Rule: response-independent work goes async. Queue (RabbitMQ/SQS) = delete on ack, rich routing, per-message retry Log (Kafka) = retained + replayable, many consumer groups, order PER PARTITION partitions = max parallelism; partition key = ordering unit Delivery: at-most-once (lossy) · at-least-once (DEFAULT, duplicates) · exactly-once (myth) → at-least-once + idempotent consumer = "effectively once" → idempotency via UNIQUE dedupe row, conditional UPDATE, or version check Retries: exponential backoff + JITTER, capped, retryable vs permanent DLQ after N failures + ALERT on depth (a poison message blocks its partition) Backpressure: scale consumers → bound the queue → shed load → rate limit producers Metric: consumer lag, and its TREND Patterns: publish FACTS not commands · transactional OUTBOX (dual-write fix) inbox (consumer dedupe) · CDC (WAL → events) · event sourcing · CQRS ``` 51:T455c,The moment your design has two services with two separate databases, or even just one database split into shards, the simple "begin, then commit" transaction you've relied on your whole career stops working. A flow like "reserve the inventory, charge the card, create the shipment" now stretches across three separate systems, and any one of them can fail after the others have already succeeded. This lesson covers the four honest answers to that problem, and how to pick between them. ## Why you cannot just use a transaction A transaction on a single database gives you atomicity because that one database owns its own log, its own locks, and the single decision of whether to commit or not. Once you spread that same work across separate services, none of that exists anymore. - Service A finishes and confirms its work, then service B fails. Now the system is left in a **half-finished state** a user could actually see. - Service B is slow, and service A is still holding locks while it waits on a network call to B. That creates contention, and a chain of timeouts spreading outward. - Either service can crash in the gap between actually doing the work and recording that it did the work. Say these three principles out loud before proposing any specific mechanism. **The best distributed transaction is the one you never needed in the first place.** If two pieces of data absolutely must change together, that's a strong hint they actually belong in the same service and the same database. Proposing to redraw the service boundary is a legitimate, senior-level answer, not a dodge. **Real business processes are already eventually consistent, and that's fine.** A hotel takes your booking now, charges your card a little later, and cancels the booking if that payment fails. Real workflows already work by compensating for failure afterward, not by being perfectly atomic. Designing it that way is simply matching reality, not settling for less. **Choose your mechanism based on how long the work takes and how long you can afford to hold a lock.** A process that finishes in milliseconds, inside one data center, where atomicity really is non-negotiable, points toward one kind of solution. A workflow spanning several seconds and several services points toward a very different one. > **Remember:** the best distributed transaction is the one you avoid needing. If two pieces of data must always change together, that's a sign they belong in the same database. ```knowledge-check { "questions": [ { "id": "ip45-hld-11-why-q1", "type": "mcq", "prompt": "Two microservices must update their data atomically on every single request, and this is the dominant workflow in the system. What is the strongest first response in a design interview?", "options": [ {"id":"a","text":"Implement two-phase commit between the two services"}, {"id":"b","text":"Question the service boundary itself; data that must change atomically on every request probably belongs together in one service and one database, and a distributed transaction is a fallback, not the goal"}, {"id":"c","text":"Rely on eventual consistency and hope it works out"}, {"id":"d","text":"Put both databases behind a single shared connection pool"} ], "correct": "b", "explanation": "A hard atomicity requirement across a service boundary is a strong sign that boundary is in the wrong place. Proposing to move it, before reaching for two-phase commit or sagas, is the stronger move; those mechanisms are for when splitting the data really is unavoidable." } ] } ``` ## Two-phase commit (2PC) Picture a wedding officiant asking three witnesses, one after another, "do you agree this marriage should happen?" Each witness who says yes has made a binding promise; once everyone has agreed, none of them can take it back. Only after all three say yes does the officiant announce "married." If the officiant collapses right after hearing the last yes but before making the announcement, all three witnesses are stuck: they've each promised, but nobody has told them whether it's actually final. Two-phase commit works exactly like that officiant, steering every participant toward one single shared decision. ``` Phase 1 — PREPARE Coordinator → all participants: "can you commit?" Each participant does the work, writes it durably, takes locks, replies YES or NO A YES is a PROMISE: it must be able to commit later, no matter what Phase 2 — COMMIT / ABORT All YES → coordinator writes "commit" to its own log → tells everyone to commit Any NO → coordinator tells everyone to abort ``` This genuinely gives you real atomicity. Here's what it costs you in return. **The coordinator becomes a single point of failure at the exact worst possible moment.** If it crashes after everyone voted yes, but before telling anyone the final decision, every single participant is now **stuck**, still holding its locks, unable to decide on its own what to do. This is exactly why two-phase commit is often called a blocking protocol. **Locks are held across network round trips**, so under real contention, throughput collapses, and one slow participant can stall every other one. **Availability multiplies downward.** The whole transaction needs every single participant to be up and reachable at once. Support for it is also uneven; most modern databases and message brokers simply don't implement the standard needed for it at all. Use two-phase commit for a small number of participants, inside a single data center, where atomicity truly is non-negotiable and the volume is modest, such as some financial systems or inside certain distributed databases themselves. Do not use it for anything long-running, anything a user is actively waiting on, or anything crossing organizational boundaries. **Three-phase commit** adds an extra step before committing, to make the protocol non-blocking in some failure cases. It's rarely used in practice, because it adds an extra network round trip and can still get stuck during a genuine network partition. Modern systems that need this kind of guarantee instead reach for a **consensus protocol**, like Raft or Paxos, covered in the next lesson, which is built from the ground up to survive failures. Google's Spanner, for instance, actually runs two-phase commit *on top of* groups running Paxos, so no single coordinator's failure can ever block anything. > **Remember:** in 2PC, a YES vote is a promise, not a suggestion. If the coordinator dies right after collecting the votes, every participant is stuck holding its lock until the coordinator comes back. ```knowledge-check { "questions": [ { "id": "ip45-hld-11-2pc-q1", "type": "mcq", "prompt": "In two-phase commit, the coordinator crashes after every participant has voted YES, but before it sends out the final decision. What happens?", "options": [ {"id":"a","text":"Participants time out and abort on their own, so the system stays safe"}, {"id":"b","text":"Participants are stuck holding their locks; they've already promised they can commit and are not allowed to abort on their own, so they must wait for the coordinator to come back"}, {"id":"c","text":"The transaction commits automatically once a timeout passes"}, {"id":"d","text":"Each participant asks the original client what to do"} ], "correct": "b", "explanation": "A YES vote is a binding promise, so aborting on its own could leave one participant disagreeing with another that already committed. This blocked, lock-holding window is two-phase commit's defining weakness, and exactly why production systems tend to prefer sagas or a consensus-backed commit instead." } ] } ``` ## Sagas: compensating transactions Picture booking a flight, then a hotel, then a rental car, all as one trip. If the car booking fails at the end, there's no magic "undo the whole trip" button. You cancel the hotel and refund the flight yourself, one step at a time, in reverse order. A saga replaces one single atomic transaction with exactly this idea: a **sequence of separate local transactions**, each paired with its own **compensating action** that undoes its effect in spirit, if not literally. There's no global lock and no global rollback here, just a forward path and a backward path. ``` T1 reserve inventory C1 release inventory T2 charge payment C2 refund payment T3 create shipment C3 cancel shipment Failure at T3 → run C2, then C1, in reverse order. ``` **There are two ways to coordinate the steps of a saga:** | | Choreography | Orchestration | |---|---|---| | How it works | Each service listens for events and emits the next one itself | One central coordinator calls each step in turn and decides what happens next | | Coupling between services | Loose | Individual services stay simple; the coordinator alone knows the full flow | | Can you see the whole workflow anywhere | No, it doesn't exist as one readable thing | Yes, it's one clear, readable state machine | | Debugging it | Hard once you're past 3 or 4 steps; you piece it together from scattered logs | Easy; just query the coordinator's own current state | | Best suited for | 2 to 3 steps | 4 or more steps, or anything with complicated compensation logic | For anything beyond the simplest case, **orchestration**, using a durable workflow engine like Temporal, AWS Step Functions, or even your own state-machine table, is the stronger answer. Saying "I'd model this as an explicit state machine with the state saved for every single order" is a strong, concrete thing to say in an interview. **Here's what building a saga actually demands of you.** **Compensations undo the meaning of an action, not the action itself.** You can't literally un-send an email, but you can send an apology. You can't literally un-charge a card, but you can issue a refund, and the customer's statement will show both entries. **Some steps simply cannot be compensated at all.** Order those steps last if you can, or define a **pivot point**: everything before it can still be undone, but everything after it must be retried until it eventually succeeds, since there's no going back once you pass it. **Every single step, and every compensating action, must itself be safe to repeat**, because retries are guaranteed to happen sooner or later. **The in-between states are real and visible to others.** Money can already be captured while the shipment is still pending. Give those in-between moments explicit names, like "payment pending" or "paid, waiting on stock," rather than pretending the whole operation happens instantly. **You lose isolation entirely.** Some other part of the system can read this half-finished state while it's in progress. The usual countermeasures are a status flag that other operations respect, like `status = 'processing'`, keeping a separate reserved balance apart from the truly available balance, or re-checking everything again right before the final commit step. > **Remember:** a saga has no rollback. If a later step fails, you run compensating actions for the earlier steps in reverse order; a refund, not an undo. ```knowledge-check { "questions": [ { "id": "ip45-hld-11-saga-q1", "type": "mcq", "prompt": "In a saga, payment succeeds, but creating the shipment fails permanently afterward. What happens?", "options": [ {"id":"a","text":"The database automatically rolls back the payment transaction"}, {"id":"b","text":"A compensating action runs: issue a refund and release the reserved inventory, because there is no global rollback, only explicit, deliberate undo steps"}, {"id":"c","text":"The coordinator blocks and waits until shipment recovers on its own"}, {"id":"d","text":"The saga simply retries creating the shipment forever"} ], "correct": "b", "explanation": "The earlier local transactions have already fully committed and are already visible elsewhere. The only way back is a forward-moving compensation, like a refund that shows up as its own separate entry, run in the reverse order of the original steps. Retrying forever is only the right call once you're past a pivot point where compensating is no longer even possible." } ] } ``` ## Idempotency, exactly-once effects, and reconciliation Distributed systems retry things constantly. That means **every effect visible outside the system must be safe to attempt more than once.** This is the practical guarantee that actually replaces true atomicity here. The mechanisms for this, from weakest to strongest: 1. **Operations that are naturally safe to repeat.** Setting `status='shipped'` directly is safe to repeat; incrementing a counter with something like `status = next(status)` is not. Setting an absolute value beats adding or subtracting a delta. 2. **Conditional writes.** A statement like `UPDATE orders SET status='paid' WHERE id=? AND status='pending'` has no effect if run a second time, and the number of rows it actually changed tells you whether this particular attempt was the one that won. 3. **Idempotency keys backed by a unique constraint**, covered in the earlier API lesson: the general-purpose mechanism for answering "have I already done this?" 4. **A ledger, instead of a single mutable value.** For anything involving money, never store just a single, changeable balance column. Store immutable rows recording every individual change instead, and calculate the balance by adding them up: ```sql CREATE TABLE ledger_entries ( id uuid PRIMARY KEY, account_id uuid NOT NULL, amount_paise bigint NOT NULL, -- signed; debits negative, credits positive txn_id uuid NOT NULL, -- the transfer this entry belongs to created_at timestamptz NOT NULL DEFAULT now(), UNIQUE (txn_id, account_id) -- retry-safe: a repeat insert violates this ); -- Every transfer writes two rows summing to zero, in one local transaction. -- Balance = SUM(amount_paise); a running-total column is a cache, never the truth. ``` Rows that are only ever added, never changed, give you safety against retries, a complete, auditable trail of everything that happened, and the ability to prove exactly where any number came from. This is genuinely how real payment systems are built, and proposing it in a payments design is a strong signal that you understand the domain. **Reconciliation is the safety net you should always mention, no matter how good your code is.** Even with flawless code, distributed systems drift apart over time: a webhook gets missed, a message gets dropped, a compensating action itself fails. Real production systems run a periodic job comparing the two sides against each other, like your own ledger against a payment provider's settlement report, or your inventory count against the warehouse's own count, and either fix small differences automatically or flag them for a person to look at. Saying "I'd add a daily job comparing our ledger to the payment provider's settlement report and alert on any mismatch" is exactly the sentence that shows you've operated a system like this for real. A few related ideas worth one sentence each. **The outbox pattern**, the fix for committing to a database and publishing an event as one atomic step, is covered under messaging and queues. **Change data capture** is how you feed other, derived stores without needing two separate writes at all. **TCC**, short for Try-Confirm-Cancel, is a variant of a saga where the first step only *reserves* something rather than committing to it outright; it's the model behind holding a seat, or reserving inventory, for a limited time before it expires. > **Remember:** never store just a mutable balance for money. Store immutable rows of every change, and compute the balance by summing them; that's what makes retries safe and history provable. ```knowledge-check { "questions": [ { "id": "ip45-hld-11-ledger-q1", "type": "mcq", "prompt": "Why do payment systems store immutable, append-only ledger rows instead of a single mutable balance column?", "options": [ {"id":"a","text":"Because adding up many rows is faster than reading one single column"}, {"id":"b","text":"Because append-only entries with a unique key per transaction and account make retries safe, give a complete, auditable history of how the balance was reached, and never suffer a lost update"}, {"id":"c","text":"Because databases cannot update a whole number column atomically"}, {"id":"d","text":"Because ledgers remove the need for any consistency guarantees at all"} ], "correct": "b", "explanation": "A single mutable balance loses all history and is vulnerable to a lost update, plus being applied twice on a retry. Immutable entries make every single change attributable to a specific event, and safe to repeat; a stored balance kept for speed is really just a cache derived from those entries." } ] } ``` ## Quick recap | Situation | Mechanism | |---|---| | Data must change atomically and is in one database | **Local transaction** — and consider keeping it that way | | Commit + publish an event | **Transactional outbox** (or CDC) | | Multi-step business workflow across services | **Saga**, orchestrated if 4+ steps | | Reserve now, confirm or cancel shortly after | **TCC / reservation with a TTL** | | Small number of participants, one datacenter, atomicity non-negotiable | **2PC**, knowing it blocks on coordinator failure | | Replicated state that must never diverge | **Consensus (Raft/Paxos)** | | Any of the above | **Idempotent steps + reconciliation job** | 52:T480e,Nearly every system eventually needs exactly one of something: one leader accepting writes, one scheduled job actually running, one worker holding a seat, one server owning a piece of data. Getting "exactly one" right, on a network where servers crash and messages get lost or delayed, is what consensus is built for. You won't be asked to build Raft, a well-known consensus algorithm, from scratch in an interview. You do need to know what it guarantees, when you actually need it, and why the distributed lock most people write on their first try is broken. ## Leader election and what a leader is for A **leader**, sometimes called a coordinator, primary, or master, is the one server temporarily given the right to do something exactly once: accept writes, hand out which server owns which shard, run a scheduled job, or drive a rebalance. Electing a leader well requires three properties. 1. **Safety**: at most one leader exists at any given moment. Breaking this is called split brain, and it's exactly how systems end up with corrupted data. 2. **Liveness**: if the leader dies, a new one gets elected within a reasonable amount of time. 3. **Fencing**: once the old leader eventually comes back, it must not be able to act as leader anymore. This is the part that quick, naive implementations usually skip. **Here's exactly why fencing is mandatory.** A leader can still be technically alive, but cut off from the network, or stuck for a while during a long garbage-collection pause, or simply stalled waiting on a slow disk. It still genuinely believes it's the leader the whole time. Meanwhile, the rest of the cluster has already elected a replacement. Now two separate servers both believe they hold the same authority. The fix is a **steadily increasing number, called an epoch or a fencing token**, handed out along with the leadership itself. Every write carries its own token, and whatever storage receives it **rejects any token lower than the highest one it has already seen**: ``` Leader A holds epoch 7, then pauses for 30 s (GC) Cluster elects Leader B with epoch 8; B writes with token 8 → accepted A wakes, writes with token 7 → REJECTED (7 < 8) → A steps down ``` Without that token, A's outdated write would silently overwrite B's newer one. This is the single most valuable detail in the entire topic, and almost nobody brings it up unprompted. Picture two office managers, each convinced they're the current one, because one of them simply never saw the memo saying they'd been replaced. A numbered memo, one that clearly states "this replaces every memo before it," is the only thing that actually stops the old manager's outdated instructions from being followed by mistake. **Heartbeats and leases.** A leader holds onto its authority through a lease it has to keep renewing every few seconds. Detecting a failure comes down to a timeout, and picking that timeout is a genuine trade-off: a short timeout catches failures quickly but can trigger a needless new election during a brief garbage-collection pause or a temporary network blip; a long timeout is more stable, but leaves the system unable to make progress for longer. Add a small amount of randomness to election timeouts, so that several candidates don't all start campaigning for leadership at exactly the same moment and split the vote between them. > **Remember:** a paused leader cannot know it's been replaced, so it can't police itself. Only a fencing token checked at the resource itself, meaning "reject anything older than the highest epoch I've seen," actually prevents split brain. ```knowledge-check { "questions": [ { "id": "ip45-hld-12-election-q1", "type": "mcq", "prompt": "A leader pauses for 30 seconds during a garbage collection cycle. The cluster elects a new leader. The old leader wakes up and tries to write. What prevents corruption?", "options": [ {"id":"a","text":"The old leader notices it was replaced and stops on its own"}, {"id":"b","text":"A fencing token: each term of leadership has a steadily increasing epoch number, and storage rejects any write carrying an epoch lower than the highest one it has already seen"}, {"id":"c","text":"The lease timeout by itself guarantees the old leader cannot write"}, {"id":"d","text":"The new leader locks the entire database"} ], "correct": "b", "explanation": "A paused server learns absolutely nothing while it's paused, so it has no way to police itself, and a lease timeout is only a promise that the paused node has already, unknowingly, broken. Only a check made right where the write actually lands, rejecting any outdated epoch, is genuinely safe." } ] } ``` ## Consensus: Raft in the amount you need Picture five friends in different cities trying to agree where the whole group will meet, over a group call where anyone's connection might drop at any moment. They need a rule that still produces one single agreed answer, even if two of them briefly lose signal. Consensus is exactly this: agreement on a value, or a whole sequence of values, among servers that can crash and whose network can drop or delay messages between them. In practice, almost every real use of consensus is really a **replicated state machine**: agree on one ordered list of commands, apply that same list in the same order everywhere, and every copy ends up in the identical state. **Here is Raft, a specific consensus algorithm, explained in five points, which is enough to answer any system design question about it:** 1. Every server is a **follower**, a **candidate**, or **the leader**. Time is split into numbered periods called **terms**, which act as the epoch number described above. 2. A follower that hasn't heard from a leader in a while becomes a candidate and asks the others for their vote. Each server grants exactly one vote per term. **A candidate that wins a majority of votes becomes the leader.** Requiring a majority is exactly what makes it impossible for two leaders to exist in the same term. 3. Every write goes to the leader, which appends it to its own log and copies it out to the followers. 4. An entry counts as **committed** only once a majority of servers have stored it; only then is it actually applied and confirmed back to the client. A committed entry is guaranteed to survive even if a minority of servers fail. 5. A server is only allowed to vote for a candidate whose log is at least as up to date as its own, which guarantees a new leader can never be missing an entry that was already committed. **The maths behind how many servers you need, worth being able to state instantly:** | Servers | Majority needed | Failures it survives | Note | |---|---|---|---| | 3 | 2 | 1 | The common default | | 5 | 3 | 2 | Better durability, but slower to commit | | 7 | 4 | 3 | Rarely worth the extra delay | | 4 | 3 | 1 | **No better than 3 servers**; always use an odd number | **Where you'll actually run into this in real systems**: etcd and ZooKeeper (built on Raft or a similar algorithm called ZAB) sit underneath Kubernetes, service discovery, and configuration management; Kafka's own controller uses a form of Raft; CockroachDB, TiDB, and Spanner all replicate each piece of their data using Raft or Paxos; and Consul uses it for its service catalogue and its locks. **The rule to follow in interviews is simple: use an existing, battle-tested consensus system, never build your own.** Saying "I'd store leadership information and cluster metadata in etcd, which gives me a perfectly consistent key-value store with leases and atomic compare-and-swap operations" is exactly the right depth of answer, and it also tells the interviewer you understand that consensus is expensive and belongs in a small control layer, not sitting directly in your main data path. > **Remember:** use a battle-tested consensus system like etcd or ZooKeeper. Building your own Raft implementation is a red flag, not a strength. ```knowledge-check { "questions": [ { "id": "ip45-hld-12-raft-q1", "type": "mcq", "prompt": "Why is a 5-server Raft cluster generally preferred over a 4-server one?", "options": [ {"id":"a","text":"5 servers commit changes faster than 4 do"}, {"id":"b","text":"Both need a majority of 3, so 4 servers only tolerate 1 failure while 5 tolerate 2; the fourth server adds cost and extra delay without adding any fault tolerance"}, {"id":"c","text":"Raft strictly requires the number of servers to be a prime number"}, {"id":"d","text":"A 4-server cluster simply cannot elect a leader at all"} ], "correct": "b", "explanation": "A majority of 4 servers is 3, and a majority of 5 servers is also 3, so an even-sized cluster is effectively wasting one server. This is exactly why every production consensus cluster you'll see is sized at 3, 5, or 7." } ] } ``` ## Distributed locks, and why the naive one is broken The actual requirement here is mutual exclusion across separate processes: only one worker should run this particular job, only one request should hold this particular seat. **Here is the naive Redis lock most people write first, and its two bugs:** ``` # BROKEN in two ways if redis.setnx("lock:job", "1"): # bug 1: no expiry → a crashed holder locks forever do_work() redis.delete("lock:job") # bug 2: deletes ANY holder's lock, not just mine ``` **Here is the corrected, single-instance version:** ``` token = str(uuid.uuid4()) # Atomic acquire with an expiry: NX = only if absent, EX = auto-release on crash. if redis.set("lock:job", token, nx=True, ex=30): try: do_work() finally: # Release only if we still hold it — compare-and-delete, atomically, in Lua. redis.eval( "if redis.call('get', KEYS[1]) == ARGV[1] " "then return redis.call('del', KEYS[1]) else return 0 end", 1, "lock:job", token, ) ``` Both fixes matter for a distinct reason: the **expiry** means a worker that crashes while holding the lock can't leave the whole system permanently deadlocked, and the **matching token before deleting** means a slow worker whose lock has already expired can't accidentally delete the lock a completely different worker is now legitimately holding. **There is still one problem left here that cannot be fixed.** Suppose the actual work takes longer than the lock's expiry time, because of a garbage-collection pause, a slow disk, or a stalled network call. The lock expires, a second worker picks it up, and now **two workers are running the same protected section of code at the same time**. No amount of clever Redis engineering removes this, because the original lock holder has no way of knowing it's already been evicted. So the rule to follow is: - **For efficiency**, meaning you just want to avoid doing the same work twice, and a duplicate is merely wasteful, a Redis lock is perfectly fine. - **For correctness**, meaning a duplicate would actually corrupt data or charge someone twice, a lock alone is **not** enough. You need a fencing token checked right at the resource itself, or you need to make the protected operation itself safe to repeat, or you need the resource to enforce the rule directly, such as a unique constraint or a conditional update like `UPDATE ... WHERE version = ?`. Redlock, a multi-server version of this same Redis locking idea, is controversial precisely because it doesn't solve this pause problem either; the exact same argument applies to it. When you genuinely need correctness under contention, **push the actual rule you need enforced into a system built to enforce it**: a database's unique constraint, a conditional update, or a lease from a consensus store like etcd or ZooKeeper, which hands out steadily increasing revision numbers you can fence against. > **Remember:** a Redis lock stops most double-work, but a paused worker can still outlive its own expiry time. Use a lock for efficiency; use a database constraint for correctness. ```knowledge-check { "questions": [ { "id": "ip45-hld-12-lock-q1", "type": "mcq", "prompt": "A worker holds a 30-second Redis lock, then stalls unexpectedly for 40 seconds. A second worker acquires the lock and starts running. What is the correct conclusion?", "options": [ {"id":"a","text":"Use a much longer expiry time; setting it to 5 minutes will make this impossible"}, {"id":"b","text":"A lock based on an expiry time cannot guarantee mutual exclusion, because the original holder has no way of knowing it was evicted. For correctness, enforce the actual rule at the resource itself, such as with a fencing token, a unique constraint, or a conditional update, rather than relying on the lock alone"}, {"id":"c","text":"Use Redlock across five separate Redis servers, which removes the problem entirely"}, {"id":"d","text":"Remove the expiry time entirely, so the lock never expires"} ], "correct": "b", "explanation": "Any expiry time, no matter how generous, can still be exceeded by an unexpected pause, and removing the expiry entirely just trades this failure for a lock that deadlocks forever if a worker crashes. Redlock doesn't solve the pause problem either. A lock is an optimisation; real correctness has to live at the resource itself." } ] } ``` ## Coordination in practice: what to actually use Most systems need far less coordination than people first assume. **The cheapest form of coordination is none at all:** | Instead of coordinating | Do this | |---|---| | A lock so only one worker processes an item | **Partition** the work by key, so only one specific worker ever owns that particular key | | A lock to prevent processing something twice | Make the operation itself **safe to repeat**, and let duplicates be harmless | | A single global counter | Keep a separate counter per server and add them up when you read, or use a probabilistic structure built for counting | | A lock around a read-then-write sequence | A single **atomic or conditional statement** run directly by the database | | A distributed lock for "run this scheduled job exactly once" | A **lease** held in etcd, or an insert with a unique key on the job's name and its scheduled time that simply does nothing if it already exists | That last row is genuinely worth remembering: a scheduled job protected by a unique constraint on its name and its run time gives you exactly-once scheduling, using nothing more than the database you're already running. **Here is where a real, dedicated coordination service is actually the right answer:** - Keeping track of which servers exist, and shared configuration (using etcd, ZooKeeper, or Consul) - Electing a leader for a control layer - Assigning and rebalancing which server owns which shard or partition - Service discovery, and knowing which servers are currently healthy - Feature flags and configuration that needs to notify listeners the moment it changes **Demand two properties from any of these tools**: leases that expire automatically, so a client that dies quietly releases its claim, and a way to atomically compare-and-swap using revision numbers, so you can build fencing on top of it. **One last warning, about time itself. Never coordinate using wall-clock time.** Clocks on different machines drift apart from each other by at least a few milliseconds even with time-syncing services running, they can occasionally jump backward, and a virtual machine can simply pause for a while. Use **monotonic clocks** for measuring how much time has actually elapsed, **logical clocks**, like Lamport timestamps or vector clocks, for figuring out which event happened before another, and consensus-issued revision numbers for fencing. Google Spanner's TrueTime, which needs actual GPS receivers and atomic clocks just to bound how uncertain its own clock might be, and then deliberately *waits out* that uncertainty on every single commit, is an honest measure of just how hard perfectly ordered global time really is to achieve. > **Remember:** the cheapest coordination is none. Partition the work so only one worker ever sees a given key, and most locks disappear on their own. ```knowledge-check { "questions": [ { "id": "ip45-hld-12-practice-q1", "type": "mcq", "prompt": "You must guarantee a nightly job runs exactly once, across 10 identical application instances. Which is the simplest mechanism that actually works?", "options": [ {"id":"a","text":"A Redis lock with a 1-hour expiry time"}, {"id":"b","text":"A unique constraint on the job's name and its scheduled time, combined with an insert that does nothing if a matching row already exists; whichever instance's insert succeeds is the one that runs the job, using only the database you already run"}, {"id":"c","text":"Designate instance number 1 as the runner directly in configuration"}, {"id":"d","text":"Have every single instance run it, and remove the duplicates afterward"} ], "correct": "b", "explanation": "A database's own unique index gives you an atomic, durable way to guarantee only one winner, which is exactly what \"exactly once\" actually needs, without introducing any extra system at all. A hardcoded instance has no failover if it goes down, and an expiry-based lock has both the eviction problem described above and one more system to depend on." } ] } ``` ## Quick recap ``` Need exactly one of something? → leader election, and FENCING is not optional. Fencing token = monotonically increasing epoch, checked and rejected AT THE RESOURCE. A paused (GC'd) leader cannot police itself — only the resource can. Raft: terms · majority vote · leader-only writes · commit on majority · up-to-date-log rule Cluster sizes: 3 (tolerate 1) · 5 (tolerate 2) · always ODD Use etcd / ZooKeeper / Consul. Do not implement consensus. Distributed lock (Redis): SET key token NX EX ttl + Lua compare-and-delete on release Locks give EFFICIENCY, never CORRECTNESS — a pause can exceed any TTL. Correctness lives at the resource: unique constraint · conditional UPDATE · fencing token Cheapest coordination is none: partition the work · make it idempotent · one atomic statement Time: monotonic clocks for elapsed, logical clocks for order, never wall clocks for ordering. ``` 53:T59ae,Every design interview eventually ends with some version of the question "what happens when this breaks?" If you've only ever drawn the happy path, this is where you'll stall. If you can name a failure, describe how far its damage spreads, and name the pattern that contains it, this is where you'll finish strong. This lesson gives you that exact vocabulary, plus rate limiting, which is the one resilience mechanism you'll actually be asked to build out in detail. ## Availability, SLOs, and the arithmetic of dependencies **Availability just means how much of the year a system is actually working, usually written as a percentage. Learn this ladder of numbers:** | Availability | Downtime a year | Downtime a month | Typical of | |---|---|---|---| | 99% ("two nines") | 3.65 days | 7.2 hours | Internal tools | | 99.9% | 8.8 hours | 43 minutes | Standard software-as-a-service | | 99.95% | 4.4 hours | 22 minutes | A paid business tier | | 99.99% | 53 minutes | 4.3 minutes | Critical infrastructure | | 99.999% | 5.3 minutes | 26 seconds | Telecom-grade, and very expensive to achieve | **Three closely related terms, worth telling apart precisely, since interviewers like to test this:** - **An SLI**, short for service level indicator, is the actual measurement: "the fraction of requests answered in under 300 milliseconds," or "the success rate of creating an order." - **An SLO**, short for service level objective, is your own internal target for that measurement: "99.9% of requests succeed, measured over the last 30 days." - **An SLA**, short for service level agreement, is the contractual promise made to customers, usually with financial penalties attached. It's always set looser than your own internal SLO, so that you find out about a problem before your customers file a complaint about it. - **An error budget** is simply the flip side of your SLO. A 99.9% SLO grants you 43 minutes of allowed failure a month, and that budget is really *permission to ship new features*. While the budget still has room left, you keep shipping. Once it's spent, you pause new features and focus entirely on reliability instead. Bringing up this framing yourself, unprompted, is a strong move. **Dependencies multiply together, and this is genuinely the single most useful piece of arithmetic in this lesson.** Picture five padlocks in a row, each 99.9% reliable on its own; you only get through if every single one opens. Five services called one after another, each available 99.9% of the time, work out like this: ``` 0.999^5 = 0.995 → 99.5% overall → 3.6 hours of downtime per month ``` Adding one more dependency onto the critical path always *lowers* your overall availability, never raises it. Three things follow from this. 1. **Redundancy running in parallel can raise availability back up.** Two genuinely independent copies, each 99% available on its own, together give you `1 - 0.01² = 99.99%`, but only if their failures are truly independent from each other. Two servers in the same availability zone, running the same deploy, sharing the same misconfiguration, are not independent at all. 2. **Make some dependencies non-critical on purpose.** If the recommendation service is down but the page still renders fine without recommendations shown, it was never really on your critical path to begin with. 3. **Count the chain out loud as you draw it.** For example: "this request touches four services one after another, so my ceiling on availability here is roughly 99.6%. I'd move the last two of them behind a queue instead." > **Remember:** picture five locks on one door, each 99.9% reliable; every extra lock in the chain multiplies together, so more calls in a row, one waiting on the next, means lower availability, not more safety. ```knowledge-check { "questions": [ { "id": "ip45-hld-13-availability-q1", "type": "mcq", "prompt": "A request calls four services one after another, each 99.9% available on its own. What is the approximate end-to-end availability, and what is the standard fix?", "options": [ {"id":"a","text":"99.9%, since the slowest dependency alone sets the overall number"}, {"id":"b","text":"About 99.6%, because availabilities multiply together along a chain of calls; the fix is removing non-essential calls from the critical path, by making them asynchronous, cached, or by degrading gracefully instead"}, {"id":"c","text":"99.99%, because redundancy always improves the overall number"}, {"id":"d","text":"100%, as long as each service retries on failure"} ], "correct": "b", "explanation": "0.999 to the fourth power is about 0.996. Every dependency called one after another multiplies into the total, which is exactly why the strongest fix is usually shortening that chain of calls, rather than trying to make each individual link only slightly more reliable." } ] } ``` ## Timeouts, retries, and the patterns that stop cascades **Every single network call needs a timeout.** A call with no timeout holds onto a thread, a connection, and the entire caller's own request, until something else eventually gives up on its behalf. This is exactly how one slow dependency can drain an entire fleet's supply of available threads. Set each timeout based on your **overall time budget for the whole request**, not based on the dependency's own average response time. If your whole request must answer within 300 milliseconds and you make two calls along the way, each one realistically gets about 100 milliseconds, once you account for overhead. Pass the remaining budget onward to the next service, often as a deadline header, so a service doesn't waste effort starting work its own caller has already given up waiting for. **Retries are a genuinely double-edged tool.** They turn a brief, temporary failure into a quiet success, but they can also turn an overloaded service into a full outage. Follow four rules. 1. **Use exponential backoff with a bit of randomness added, called jitter.** For example: `min(base × 2^attempt, cap) × random(0.5, 1.5)`. Without that randomness, every client's retries fall into sync and arrive together as one big wave. 2. **Only retry an operation that's safe to repeat**, meaning it's naturally idempotent, or it's protected by an idempotency key, a concept covered in the earlier API lesson. 3. **Only retry failures that are actually worth retrying.** A timeout, a "503 overloaded" response, or a dropped connection are worth retrying. A "400 bad request," "401 unauthorized," or "422 invalid" response never is; it will fail in exactly the same way every single time. 4. **Set a retry budget, on top of a simple per-call limit.** Cap total retries at, say, 10% of all requests. Otherwise, a struggling dependency suddenly receives 3 times its normal load at the exact moment it can least handle it, a pattern called a **retry storm**. **A circuit breaker** works like a fuse in your home's electrical panel. When a circuit draws too much current, the fuse trips instantly and cuts the power, rather than letting the wires overheat and potentially catch fire. A circuit breaker in software does the same thing: it stops calling a dependency that's clearly failing, so your own service fails fast instead of exhausting its resources waiting around. ``` CLOSED → calls pass through; count failures → failure rate exceeds threshold (e.g. 50% over 20 requests) ⇒ OPEN OPEN → reject immediately, no call made (fail fast, serve fallback) → after a cool-off (e.g. 30 s) ⇒ HALF-OPEN HALF-OPEN → allow a few trial calls → they succeed ⇒ CLOSED they fail ⇒ OPEN again ``` The benefit runs both ways: the caller stops wasting threads on calls that are doomed to fail anyway, and the struggling service gets some breathing room to recover, instead of being hammered continuously. **A bulkhead** isolates resources so that one failure can't consume everything else along with it, named after the watertight compartments built into a ship's hull. In practice, this means separate connection pools and separate thread pools for each dependency, so a slow recommendation service can't starve the checkout flow of the connections it needs, and separate queues per customer, so one especially noisy customer can't fill up a queue shared by everyone else. **Graceful degradation** means deciding *ahead of time* what a partially broken system should still be able to offer: search results without personalisation, a product page without its review count, a feed pulled from cache with a small "may be out of date" note attached. Naming this reduced mode of operation clearly is a far stronger answer than simply saying "it would return an error." **Load shedding** means, when the system is overloaded, immediately and cheaply rejecting some requests, favouring lower-value traffic first, so the rest can still be served correctly. A system that serves 70% of its traffic well beats one that tries to serve 100% of it and times out on all of it. Prioritise paying customers over free ones, writes over background analytics, and interactive requests over batch jobs. > **Remember:** a circuit breaker trips like a household fuse: stop calling a failing dependency immediately instead of letting every caller wait and pile up. ```knowledge-check { "questions": [ { "id": "ip45-hld-13-patterns-q1", "type": "mcq", "prompt": "A downstream service starts timing out. Every caller retries three times. What happens, and which pattern prevents it?", "options": [ {"id":"a","text":"The retries succeed quietly and hide the problem, so no pattern is actually needed"}, {"id":"b","text":"Load on the already-struggling service triples at the exact moment it's weakest (a retry storm), and every caller exhausts its own thread pool waiting for a reply; a circuit breaker fails fast once the failure rate crosses a threshold, and a retry budget caps how much the retries can amplify the load"}, {"id":"c","text":"The load balancer automatically routes around the problem"}, {"id":"d","text":"The database simply absorbs the extra load"} ], "correct": "b", "explanation": "Retries multiply the load on a struggling service during exactly the window it can least handle more traffic. Combining a circuit breaker, a retry budget, and backoff with jitter is the standard set of three fixes used together." } ] } ``` ## Rate limiting: the four algorithms Picture a water tank that drips in at a steady, constant rate, but can be drained through a tap in one quick burst, up to the tank's full size. That's exactly how a token bucket works, and it's the default answer among four different ways of controlling how fast requests get let through. Rate limiting protects a system from abuse, from clients that misbehave, and from its own retry storms. Interviewers often ask for these algorithms by name, so it's worth learning all four along with their trade-offs. **1. Fixed window.** Count requests within a fixed block of time, and reset the counter the moment that block ends. ``` key = f"rl:{user_id}:{int(time.time() // 60)}" # one counter per minute count = redis.incr(key) if count == 1: redis.expire(key, 60) allowed = count <= LIMIT ``` This is trivial and cheap to implement, but it has one real flaw: a **burst right at the boundary**. A client that sends 100 requests in the very last second of one minute, and another 100 in the very first second of the next, has just sent 200 requests within a single second, even under a limit meant to be "100 per minute." **2. Sliding window log.** Store a timestamp for every single request in a sorted structure, drop any entries older than your chosen time window, and count whatever's left. This is perfectly accurate, but its memory use grows with the number of requests, which gets expensive at high volume. ``` now = time.time() p = redis.pipeline() p.zremrangebyscore(key, 0, now - WINDOW) p.zadd(key, {str(uuid.uuid4()): now}) p.zcard(key) p.expire(key, WINDOW) allowed = p.execute()[2] <= LIMIT ``` **3. Sliding window counter.** This estimates the exact log above using just two numbers, by blending the previous fixed window's count with the current one: `count = prev_window_count × (overlap fraction) + current_count`. It's the usual practical compromise chosen in production, and it's the approach Cloudflare made popular. **4. Token bucket.** A bucket holds up to `B` tokens, and refills at a rate of `r` tokens every second; each request consumes one token, and an empty bucket means the request is rejected, or held until a token is free. This is the one to reach for by default, since it **allows a controlled burst** up to the bucket's size while still enforcing the average rate over time, which closely matches how real clients actually behave. ```python def allow(bucket, rate, capacity, now): elapsed = now - bucket["last"] bucket["tokens"] = min(capacity, bucket["tokens"] + elapsed * rate) # lazy refill bucket["last"] = now if bucket["tokens"] >= 1: bucket["tokens"] -= 1 return True return False # 5 requests/sec, burst of 5: the first 5 pass instantly, the 6th is rejected, # and one more token is available half a second later. bucket = {"tokens": 5.0, "last": 0.0} assert [allow(bucket, 5, 5, 0.0) for _ in range(5)] == [True] * 5 assert allow(bucket, 5, 5, 0.0) is False # burst exhausted assert allow(bucket, 5, 5, 0.5) is True # 0.5 s x 5/sec = 2.5 tokens refilled print("token bucket ok, tokens left:", round(bucket["tokens"], 2)) ``` **Leaky bucket** is closely related: requests queue up and drain out at a perfectly constant rate, smoothing the output completely. This works well for protecting a fragile downstream service that can't handle any burst at all, at the cost of adding some delay. | Algorithm | Memory used | Accuracy | Handling bursts | When to use it | |---|---|---|---|---| | Fixed window | Constant | Can let up to double the limit through at the boundary | Uncontrolled right at the boundary | Simple, internal limits | | Sliding log | Grows with request volume | Exact | None allowed | Low-volume, high-value limits | | Sliding counter | Constant | Very good | Smoothed out | A good default for production | | **Token bucket** | Constant | Good | **Controlled, up to B** | **The usual answer** | | Leaky bucket | Grows with the queue | Exact output rate | None, since requests just queue | Protecting a fragile downstream service | **Rate limiting across many servers at once is where the real difficulty shows up.** Limiting per server independently is wrong; 10 servers each allowing 100 requests a minute adds up to 1,000 a minute in total, not 100. So counters usually live centrally in Redis, which means an extra network call on every single request, and makes Redis itself a dependency your entire front door now relies on. The usual practical compromise is **local token buckets, each holding a share of one global budget**, periodically rebalanced against a shared central counter; this is approximate and fast, and it simply falls back to per-server limits if the central store becomes unreachable. Always return the standard contract to the client: a `429` status with a `Retry-After` header, plus `X-RateLimit-Limit`, `X-RateLimit-Remaining`, and `X-RateLimit-Reset` headers. Rate limit using the right key for the situation: user id for logged-in traffic, an API key for partners, and IP address only as a last resort, since mobile carriers and shared networks can put thousands of separate users behind a single IP address. > **Remember:** a token bucket lets a client burst up to the bucket size while still capping the long-run average. A fixed window can let a client sneak through double the limit right at the boundary. ```knowledge-check { "questions": [ { "id": "ip45-hld-13-ratelimit-q1", "type": "mcq", "prompt": "Why is a token bucket usually preferred over fixed-window counting for a public API?", "options": [ {"id":"a","text":"It uses less memory than a fixed-window counter does"}, {"id":"b","text":"It enforces the average rate over time while still allowing a controlled burst up to the bucket's size, and it has no boundary spike where a client could send double the limit in an instant"}, {"id":"c","text":"It needs no shared state at all in a distributed system"}, {"id":"d","text":"It guarantees that requests are never rejected"} ], "correct": "b", "explanation": "A fixed window can let through up to double its stated limit right at the boundary between two windows, and it refuses every burst that happens inside a single window. A token bucket's refill model matches how real clients actually behave: occasional bursts, with a bounded average over the long run. Both approaches use only a small, constant amount of state." } ] } ``` ## Failure modes, blast radius, and testing for failure **Name the ways your own design can fail before the interviewer has to ask you about them. Here's the recurring list:** | Failure | What it looks like | How to contain it | |---|---|---| | Single point of failure | One box, with no backup at all | Replicate it, spread it across zones, add automatic failover | | Cascading failure | One slow service ends up taking everything else down with it | Timeouts, circuit breakers, bulkheads, shedding load | | Retry storm | Load multiplies right as the system is already struggling | Backoff plus jitter, and a retry budget | | Thundering herd | Everything expires or reconnects at the exact same moment | Add jitter everywhere: to expiry times, retries, scheduled jobs, reconnect attempts | | Hot key / hot shard | One partition takes far more traffic than the rest | Cache it, split it up, isolate it on its own | | Poison message | One bad record blocks an entire partition behind it | Move it to a dead-letter queue after N attempts | | Unbounded queue | Response times climb steadily until the whole system dies | Bounded queues, backpressure, shedding load | | Correlated failure | Servers assumed to be "independent" actually share a zone, a config, or a deploy | Spread servers across zones, stagger deploys, keep configuration blast radius separate | | Grey failure | Not fully down, just slow or subtly wrong, while health checks still pass | Base alerts on latency and error rate, not just up-or-down; eject outliers automatically | | Metastable failure | The system stays broken even after whatever triggered it is long gone | Shed load hard to break the feedback loop; drain the backlog before letting traffic back in | **Blast radius is the vocabulary for how far a failure's damage actually spreads**: a cell or shard-based design, so one cell failing only affects 1 out of N users; isolating a large customer on their own resources; rolling out changes gradually, from a small canary group up to 1%, then 10%, then everyone, with automatic rollback if key metrics regress; and feature flags, which let you turn off a broken part of the system without needing a whole new deploy. **Two recovery targets are worth knowing by name, in case you're asked directly.** RTO, short for recovery time objective, is how long you're allowed to take to restore service. RPO, short for recovery point objective, is how much data you're allowed to lose. Asynchronous replication always implies an RPO greater than zero; say the actual number out loud when you propose it. **And actually prove all of this works, rather than just assuming it does**: run chaos experiments, like deliberately killing an instance, adding artificial latency, or cutting off an entire availability zone, inside a controlled window; run scheduled "game days" that rehearse a failure; run load tests to find the exact point where performance falls off a cliff; and run disaster-recovery drills that genuinely restore from a real backup. "A backup you've never actually restored from is not really a backup" is a fair thing to say. > **Remember:** naming the failure mode before you're asked, such as a hot key, a retry storm, or a metastable failure, is a strong signal that you've actually operated a system like this, and not only sketched one. ```knowledge-check { "questions": [ { "id": "ip45-hld-13-failure-q1", "type": "mcq", "prompt": "Traffic returns to normal after a spike, but the system stays broken: queues remain full, every request times out, and ongoing retries keep it saturated. What is this called, and what breaks the loop?", "options": [ {"id":"a","text":"A cache stampede; add a lock around the affected reads"}, {"id":"b","text":"A metastable failure, a self-sustaining feedback loop that outlives whatever originally triggered it. Break it by shedding load aggressively, pausing retries, and draining the backlog before letting traffic back in"}, {"id":"c","text":"A hot shard; re-partition the data"}, {"id":"d","text":"A grey failure; replace the health check"} ], "correct": "b", "explanation": "Retries amplifying load, combined with an already-saturated queue, keeps the system stuck in its failed state even once traffic has returned to normal. Only reducing the work being admitted, through shedding, pausing retries, and draining, lets it fall back into a healthy state; simply adding more capacity often doesn't fix this on its own." } ] } ``` ## Quick recap ``` 99.9% = 43 min/month · 99.99% = 4.3 min/month Synchronous dependencies MULTIPLY: 0.999^5 ≈ 99.5% → shorten the critical path Parallel redundancy adds nines — only if failures are truly independent SLI (measure) → SLO (target) → SLA (contract) → error budget = permission to ship Every call: TIMEOUT (from your latency budget, propagate the deadline) Retries: exponential backoff + JITTER, idempotent only, retryable only, retry BUDGET Circuit breaker: CLOSED → OPEN (fail fast) → HALF-OPEN (trial) → CLOSED Bulkhead: separate pools/queues per dependency and per tenant Degrade gracefully (decide the reduced mode in advance) · shed load by priority Rate limiting: fixed window (boundary burst) · sliding log (exact, costly) · sliding counter (good default) · TOKEN BUCKET (bursts + average) · leaky bucket (smooth output). Distributed: local buckets + central budget. Always: 429 + Retry-After + X-RateLimit-* headers. Failure vocabulary: SPOF · cascade · retry storm · thundering herd · hot shard · poison message · unbounded queue · correlated failure · grey · METASTABLE (survives its trigger — shed to escape) Blast radius: cells, per-tenant isolation, canary + auto-rollback, feature flags RTO = time to restore · RPO = data you may lose. Test it: chaos, game days, restore drills. ``` 54:T4890,Three topics rarely get their own dedicated question in a design interview, but they show up as follow-ups in almost every single one: "how would you know this is broken?", "how do you keep this secure?", and "what does this actually cost?" Adding two sentences on each of these, without being asked, at the end of your design, is one of the cheapest ways to sound like someone who has actually run a real system, not just someone who's drawn one. ## The three pillars, and the metrics that matter Picture a hospital. A heart-rate monitor's beeping alarm is a metric: cheap, instant, and it tells you *something* is wrong right now. An X-ray is a trace: it shows *where* the problem actually is. The patient's full case file is a log: it tells you *why*, in detail, after everything's already happened. **Metrics** are cheap, simple numeric measurements over time, good for dashboards and alerts. **Logs** are more expensive and detailed, and good for digging into one specific incident. **Traces** follow one single request's path across every service it touches, and answer "where did those 900 milliseconds actually go?" Two short phrases cover almost every dashboard you'll ever need to build. - **RED, for request-driven services**: **R**ate, meaning requests per second; **E**rrors, meaning failures per second or as a percentage; **D**uration, meaning the spread of how long requests take. - **USE, for a specific resource** like CPU, disk, a connection pool, or a queue: **U**tilisation, how busy it is; **S**aturation, how deep its queue or wait time is; **E**rrors, how often it fails. **Look at percentiles, not averages.** An average response time of 100 milliseconds is perfectly compatible with 5% of users waiting a full 3 seconds. Track the 50th, 95th, 99th, and 99.9th percentiles, usually written p50, p95, p99, and p99.9. Here's the arithmetic that makes the slowest requests, called the tail, matter so much: if loading one page makes 10 separate backend calls, the chance that at least one of those calls hits its own worst 1% of cases is about `1 − 0.99¹⁰`, which works out to roughly **10%**. In other words, tail latency, not average latency, is what most users actually experience on a page that fans out to many services. Never average percentiles taken from different servers together; that combined number means nothing meaningful. Instead, combine the raw distributions (called histograms) first, then calculate the percentile from that. **The piece most people forget is tying it all together.** Generate a single trace or request ID right at the edge of your system, pass it along through every single service the request touches, using a shared standard like W3C's `traceparent` header, and stamp that same ID onto every log line. That's what lets you go from a single alert straight to the exact request that caused it, in under a minute. Saying "I'd propagate a trace ID and include it in every log line and error response" is small, concrete, and something surprisingly few people actually mention. **Alert on symptoms, not on underlying causes.** Page someone when "the checkout error rate is above 1% for 5 minutes," since that's a real, user-visible problem, not when "CPU usage is above 80%," which might be completely fine on its own. Every page that wakes someone up should come with a clear runbook and a real action they can take; anything short of that belongs on a dashboard instead, since an alert that nobody ever acts on just trains everyone to start ignoring alerts. > **Remember:** metrics say something is wrong, traces say where, logs say why. A page needs a tag connecting all three, or you're guessing which request the alarm was even about. ```knowledge-check { "questions": [ { "id": "ip45-hld-14-observability-q1", "type": "mcq", "prompt": "A page makes 10 backend calls, each with a p99 latency of 500 milliseconds, meaning 1% of calls are that slow or slower. Roughly what fraction of page loads will include at least one of these slow calls?", "options": [ {"id":"a","text":"About 1%, the same as for a single call"}, {"id":"b","text":"About 10%, calculated as 1 minus 0.99 raised to the 10th power, which is exactly why tail latency, not average latency, defines what users actually experience on a page that fans out to many calls"}, {"id":"c","text":"About 0.1%, since the calls are independent of each other"}, {"id":"d","text":"100%, because the latencies simply add together"} ], "correct": "b", "explanation": "This effect is called tail amplification: when a page fans out to many calls, the probability of hitting a slow tail at least once grows with the number of calls made. It's the standard reason behind hedged requests, tighter timeouts, and simply reducing how many calls one page makes." } ] } ``` ## Security in a design interview You won't be asked to design a whole security system from scratch, but you are expected to place the right kinds of controls onto your own diagram. Picture a concert venue. A ticket scanner checking your ID at the main gate answers the question "who are you?" A completely separate check at the door of the VIP lounge answers a different question: "are you actually allowed in here?" Those are two distinct jobs, and mixing them up is a common way real systems end up getting breached. **Authentication versus authorization.** Authentication, often shortened to AuthN, means confirming who you are. Authorization, shortened to AuthZ, means deciding what you're allowed to do. Use both words, in the right places, when you describe your design. | Mechanism | How it works | Trade-off | |---|---|---| | Session cookie plus a server-side store | The server itself holds onto the session state | Revoking access is instant, but you need a shared store for sessions across servers | | **JWT**, short for JSON Web Token (signed, and stateless) | The client itself carries its own claims about who it is | No lookup needed on each request, but **revoking one before it expires is genuinely hard**; mitigated with a short expiry plus a separate refresh token | | OAuth 2.0 / OIDC | Lets a third party handle identity on your behalf | The standard approach for "sign in with Google" style flows, and for third-party API access | | API keys | A long-lived secret shared with a partner | Simple to hand out, but it must be possible to rotate and scope them | | mTLS, short for mutual TLS | Both sides present a certificate to prove who they are | The usual standard for service-to-service calls inside a mesh | The JWT trade-off comes up often: the very thing that makes them scale so well, needing no lookup on the server at all, is exactly what makes revoking one before it expires so hard. The standard answer is to use short-lived access tokens, lasting 5 to 15 minutes, alongside a separate refresh token that genuinely *is* checked against a list of revoked tokens. **A few common models for authorization.** RBAC, short for role-based access control, meaning roles map to permissions, covers most systems well enough. ABAC, short for attribute-based access control, adds rules based on attributes, like "the owner of this resource, and only during business hours." For any system serving multiple separate customers, called multi-tenant, the essential rule is that **every single query is scoped to the correct tenant at the data layer itself**, not by a check placed inside a controller that someone could easily forget to add. A row-level security policy, or a mandatory `WHERE org_id = ?` clause baked into a shared repository layer, is the right kind of design answer here. **Here's a checklist worth running over your own diagram.** - **In transit**: use encryption everywhere, including between your own services, using mTLS inside a mesh. No internal connection should ever be sent in plain text. - **At rest**: encrypt the disk and the database, and add extra field-level encryption for especially sensitive columns; keep encryption keys in a dedicated key management service with rotation, never in code or in an environment variable that gets committed anywhere. - **Secrets**: use a proper secret manager, short-lived credentials, and rotation. This is exactly where "never hardcode a fallback secret" becomes a real security control, not just a style preference. - **Validate every input at the boundary**, always use parameterised queries to prevent SQL injection, encode output to prevent cross-site scripting, and add CSRF protection for any browser using cookie-based login. - **SSRF**, short for server-side request forgery: any feature that fetches a URL supplied by a user must resolve that address and check it against a list of blocked internal ranges. This is the classic path attackers use to reach a cloud provider's internal credential service. - **Rate limiting and quotas per identity** are a security control just as much as a capacity one. - **PII**, personally identifiable information: know exactly where it lives, collect as little of it as you can, encrypt it, set a retention period, and be able to delete it on request, as laws like GDPR or India's DPDP require. Legal rules about where data may live can force you to partition data by geography. - **An audit log**: a separate, append-only record of who did what to which resource, and when, kept apart from your regular application logs. - **Least privilege**: give each service its own credentials, scoped only to the specific tables or storage buckets it actually needs. A compromised recommendation service should never be able to read your payments table. **"Defence in depth" is the framing to use here**: a web application firewall and DDoS protection at the edge, authentication at the gateway, authorization inside each service, and constraints enforced by the database itself. No single one of these layers is ever the whole answer on its own. > **Remember:** authentication answers "who are you," authorization answers "what can you do." A JWT scales beautifully because there's no lookup, but that's also exactly why revoking one before it expires is hard. ```knowledge-check { "questions": [ { "id": "ip45-hld-14-security-q1", "type": "mcq", "prompt": "What is the main operational drawback of stateless JWTs, and what is the standard way to soften it?", "options": [ {"id":"a","text":"They are too large to fit in a request header; fix it by compressing them"}, {"id":"b","text":"They cannot be revoked before they expire, since checking one requires no lookup on the server at all; soften this with short-lived access tokens plus a refresh token that is checked against a revocation list"}, {"id":"c","text":"They cannot carry a user's identity at all; fix it by adding a session cookie alongside it"}, {"id":"d","text":"They require a database read on every single request; fix it with caching"} ], "correct": "b", "explanation": "The exact property that makes JWTs scale so well, needing no server-side lookup, is also exactly what makes revoking one before it expires impossible. A short expiry time limits how long the damage window can last, and the refresh token is the one stateful piece that can actually be revoked." } ] } ``` ## Cost, and the deployment story Picture a family choosing between cooking every meal at home or ordering delivery every single night. Delivery is convenient, but the delivery fee, the cost of physically moving food across the city, is the surprise cost that quietly adds up, not the price of the food itself. In cloud systems, moving data across a network boundary, called egress, is exactly that delivery fee, and it's the line item on the bill that catches people off guard. **Cost is a real design constraint**, and simply mentioning it sets you apart, because so few people actually do. **Here is a rough sense of relative cost, useful for reasoning about trade-offs, not for quoting exact numbers:** | Resource | Relative cost | What it implies for your design | |---|---|---| | Compute (an on-demand virtual machine) | The baseline | Scale it automatically; use cheaper, interruptible capacity for batch jobs and background workers | | Object storage | Roughly a twentieth of the cost of block storage, per gigabyte | Large files should never live directly inside your database | | Cold or archive storage | Roughly a fifth of the cost of standard storage | Set up policies to automatically move old data there | | A managed database | Several times the cost of raw compute | Usually worth it, but don't end up running five different kinds at once | | **Cross-region or internet egress** | **The line item that most often surprises people** | Offload it to a CDN; keep chatty, frequent traffic inside a single region | | Storing logs and metrics | Grows quietly over time, often more than 10% of the total bill | Sample it, aggregate it, and set a clear retention period | Four decisions dominate almost every cloud bill: **where your bytes physically live** (object storage plus a CDN, instead of a database and your own servers), **how much data crosses a network boundary** (egress, and traffic between availability zones), **how long you keep data around** (shrinking and expiring old data on a schedule), and **how much spare capacity you keep sitting idle** (autoscaling, cheaper interruptible capacity, and right-sizing your servers). A sentence that lands well in an interview: *"Serving 75 gigabits per second directly from our own servers would dominate the bill entirely, so choosing a CDN isn't only about latency; it's also the cost decision."* **Deployment and change management make up the final third of running a real system.** - **Blue-green deployment**: run two full, separate environments, and simply flip traffic between them, which allows an instant rollback. It costs double the capacity for the duration of the switch. - **Canary deployment**: gradually shift traffic from 1%, to 10%, to everyone, watching your metrics the whole way, with an automatic rollback if something looks wrong. This is the default choice for most systems. - **Rolling deployment**: replace servers gradually, one at a time. This needs connections to drain properly, and both the old and new versions of your code need to work correctly side by side for a while. - **Feature flags**: separate the act of deploying code from the act of releasing a feature to users, so you can turn a broken part of the system off with a simple configuration change instead of a full new deploy. - **Backward-compatible database migrations**: follow the pattern of expand, then migrate, then contract. Add a new column that allows empty values, write to both the old and new column at once, backfill existing data in batches, switch reads over to the new column, and only then, in a later release, remove the old column. Never combine adding something and removing something in one single migration. **Multi-tenancy shapes nearly every software-as-a-service design, and there are three common approaches.** A shared database with a `tenant_id` column on every row is the cheapest, but needs airtight, careful scoping everywhere. A separate schema per tenant is a middle ground, though the overhead of running migrations grows as you add more tenants. A completely separate database per tenant gives the strongest isolation, at the heaviest operational cost. The usual answer most systems land on is a shared database with `tenant_id`, plus dedicated, separate databases reserved for the few large enterprise customers who genuinely need full isolation, which is also the standard fix for a hot-shard problem covered in an earlier lesson. > **Remember:** moving bytes across a network boundary, called egress, is usually the cost surprise, not compute. A CDN is a cost decision just as much as it is a speed decision. ```knowledge-check { "questions": [ { "id": "ip45-hld-14-cost-q1", "type": "mcq", "prompt": "You need to add a required column, one that cannot be empty, to a large table used by a service that's currently running. What is the safe sequence of steps?", "options": [ {"id":"a","text":"Run one single migration that adds the column as required, with a default value, during peak traffic hours"}, {"id":"b","text":"Expand, then migrate, then contract: add the column allowing empty values first, deploy code that writes to both the old and new columns, backfill existing data in batches, switch reads over to the new column, and only then make it required and drop the old column in a later release"}, {"id":"c","text":"Take the whole service offline for the entire duration of the migration"}, {"id":"d","text":"Create a brand new table and copy everything over inside a single transaction"} ], "correct": "b", "explanation": "Both the old and new versions of your code run side by side during any rollout, so every single step of a migration has to remain compatible with both of them at once. Following expand, then migrate, then contract keeps every individual deploy safely reversible, which is exactly the property that makes rollbacks actually safe to do." } ] } ``` ## Quick recap ``` Observability: metrics (that) → traces (where) → logs (why) RED for services: Rate, Errors, Duration. USE for resources: Utilisation, Saturation, Errors p50/p95/p99/p99.9 — never averages, never averaged percentiles Fan-out amplifies tails: 10 calls at p99=1% ⇒ ~10% of pages hit it Propagate a trace id into every log line and error response Alert on symptoms (SLO breach) with a runbook — not on CPU Security: authN ≠ authZ · JWT scales but can't be revoked (short TTL + refresh) TLS in transit + mTLS internally · encryption at rest + KMS · secrets manager Validate at the boundary · parameterised queries · CSRF · SSRF denylist Tenant scoping at the DATA layer, not the controller · least privilege per service PII: minimise, encrypt, retain briefly, be able to delete · audit log, append-only Cost: egress and retention are the surprises · blobs → object storage + CDN autoscale + spot for batch · sample logs · lifecycle old data Deploy: canary with auto-rollback (default) · blue-green (instant rollback, 2× cost) feature flags decouple deploy from release migrations: EXPAND → MIGRATE → CONTRACT, never both at once Multi-tenant: shared + tenant_id (default) · schema per tenant · DB per tenant (isolation) ``` 55:T542a,Fourteen lessons of building blocks are useless if you can't pull them out of your memory under pressure. Picture a firefighter: knowing all the theory about how fire spreads doesn't help if they can't find the right hose in the dark in three seconds. This lesson is exactly that kind of muscle memory: the decision trees you run through at the whiteboard, the numbers you should be able to say without thinking, the phrases that earn real points, the reusable building blocks every design reaches for, and a self-test you can repeat until it gets boring. Use this lesson three ways: read it once now, reread the recall cards the night before an interview, and run the drill at the very end of it, over and over, until every single answer comes back to you in under five seconds. ## The one-page map Here's everything in this section, laid out in the order you'll actually use it during a real interview. ``` FRAMEWORK Requirements → Estimation → API+Schema → HLD → Deep dive → Close 45 min: 5 / 5 / 5 / 10 / 15 / 5 ESTIMATION sec/day ≈ 100k · 1M/day ≈ 10 QPS · peak = 2–3× avg storage/yr = bytes/day × 400 × replicas → conclusion: which subsystem is actually hard? TRAFFIC IN DNS → CDN → LB → Gateway → stateless services protocol: REST public · gRPC internal · SSE push · WS duplex API: /v1, cursor pages, idempotency keys, 429 + Retry-After LB: L4 vs L7 · least-connections · readiness ≠ liveness · draining DATA cache-aside + delete-on-write + TTL jitter store chosen from the ACCESS PATTERN · index = left prefix B-tree (reads) vs LSM (writes) replication scales READS · partitioning scales WRITES partition key: cardinality · even access · query alignment CAP per operation · PACELC everyday · W+R>N ASYNC response-independent work → queue queue (delete on ack) vs log (retained, replayable) at-least-once + idempotent consumer · DLQ · consumer lag outbox for dual writes · saga for cross-service workflows exactly one of something → leader election + FENCING TOKEN OPERATE timeouts · backoff+jitter · circuit breaker · bulkhead · shed token bucket rate limiting · SLI/SLO/error budget RED + USE · p99 not average · trace id everywhere TLS + authZ at the data layer · expand-migrate-contract ``` > **Remember:** the map has five stops in order: get the numbers, get the traffic in, get the data right, make the slow parts async, then keep it alive under failure. ```knowledge-check { "questions": [ { "id": "ip45-hld-15-map-q1", "type": "mcq", "prompt": "In the 45-minute budget, which two steps together get the most time, and why?", "options": [ {"id":"a","text":"Requirements and estimation, because they determine everything else"}, {"id":"b","text":"High-level design (10 minutes) and the deep dive (15 minutes), because the deep dive is where technical depth and trade-off reasoning, the two highest-weight rows on the scorecard, are actually demonstrated"}, {"id":"c","text":"API design and data modelling, because they produce the concrete artefacts"}, {"id":"d","text":"The close, because last impressions matter most"} ], "correct": "b", "explanation": "Requirements and estimation are cheap and mandatory, but each is capped at around 5 minutes. Real depth only shows up during the deep dive, which is exactly why running over time on the earlier steps costs you so much." } ] } ``` ## Decision trees Run through these from top to bottom, right at the whiteboard. Each one turns a question into an answer, plus the cost that answer carries with it. **Which datastore?** ``` Relationships + ad-hoc queries + invariants ......... relational (Postgres) Known key, huge write rate, no joins ............... wide-column (Cassandra/DynamoDB) Whole documents, flexible schema ................... document (Mongo) Sub-ms, ephemeral, counters/sessions/queues ........ Redis Text relevance, faceting ........................... search index (Elasticsearch) High-rate timestamped metrics ...................... time-series (+ downsampling) Traversal of relationships ......................... graph Large blobs ........................................ object store + metadata row Scans over billions of rows ........................ columnar warehouse Unsure ............................................. Postgres, and say why you'd move ``` **Reads are slow.** ``` Is the query indexed? → composite index, equality cols first, range col last Still slow? → covering index / denormalise to avoid the join Volume too high for one node? → read replicas (mind replication lag) Same data re-read constantly? → cache-aside + TTL + jitter (invalidate on write) Expensive to compute per read? → precompute / materialise on write Dataset too large for a node? → partition, aligned with the dominant query ``` **Writes are slow.** ``` Are writes fsync-bound? → batch them; group commits Too many indexes? → drop the ones no query uses One node saturated? → shard on a high-cardinality, evenly-accessed key Bursty? → queue + workers (load levelling) Append-heavy at huge volume? → LSM-based store, or a log Contention on one row? → atomic UPDATE, or shard the counter, or a ledger ``` **Client needs updates.** ``` Rare updates, staleness fine ....... polling Server → client only ............... SSE Both directions .................... WebSocket (+ sticky routing + pub/sub backbone) Loss-tolerant media ................ UDP / WebRTC ``` **Two things must change together.** ``` Same database ...................... local transaction (and consider keeping it that way) DB write + event publish ........... transactional outbox / CDC Multi-service workflow ............. saga (orchestrated if 4+ steps) + compensations Reserve, then confirm/cancel ....... TCC / reservation with a TTL Must be atomic, few participants ... 2PC (blocks on coordinator failure) Replicated state, never diverges ... consensus (etcd/Raft) Always ............................. idempotent steps + a reconciliation job ``` **Something must happen exactly once.** ``` Scheduled job across N instances ... unique constraint on (job, run_at) — cheapest correct One owner per key ................. partition the work; no lock needed Duplicate is merely wasteful ...... Redis lock: SET NX EX + Lua compare-and-delete Duplicate corrupts data ........... fencing token / unique constraint / conditional UPDATE Cluster leadership ................ lease in etcd/ZooKeeper + epoch checked at the resource ``` > **Remember:** each tree converts a symptom into an answer plus its cost. If your answer has no cost attached, you skipped a branch. ```knowledge-check { "questions": [ { "id": "ip45-hld-15-trees-q1", "type": "mcq", "prompt": "Reads are slow, the query is already served by a good composite index, and one server's CPU is saturated purely by read volume. What is the next move?", "options": [ {"id":"a","text":"Shard the table immediately"}, {"id":"b","text":"Add read replicas, accepting some replication lag and routing that one user's own writes back to the leader for a moment, and/or cache the hot results; reads are exactly what replication and caching exist for"}, {"id":"c","text":"Switch the underlying storage engine to an LSM-tree"}, {"id":"d","text":"Raise the isolation level"} ], "correct": "b", "explanation": "High read volume on a query that's already correctly indexed is the textbook case for read replicas and caching. Sharding solves write and storage limits, and costs you joins and transactions in return; switching the storage engine speeds up writes, not reads." } ] } ``` ## Reusable building blocks Nearly every design you draw reaches for the exact same small toolbox. Knowing what each tool actually solves, and what it costs you in return, is what turns a plain box on a diagram into a decision you can actually defend. | Block | Solves | Watch out for | |---|---|---| | Load balancer (L4/L7) | Spreads traffic across servers, checks health | Sticky sessions break horizontal scaling | | CDN | Slow-loading static files for far-away users | Cache invalidation after a deploy | | Cache (Redis) | Slow reads, database overload | Stampede on expiry, stale data | | Message queue (Kafka/SQS) | Decoupling, async work, traffic spikes | Ordering guarantees, at-least-once delivery | | Database read replicas | Read scaling | Replication lag means stale reads | | Sharding | Write scaling, dataset too big for one node | Cross-shard queries and joins get expensive | | Rate limiter | Abuse protection, fairness between clients | Token bucket vs. sliding window trade-offs | | Consistent hashing | Even key distribution across nodes that change | Hot keys still need their own handling | | Object storage (S3-like) | Large files and media | Not a substitute for a database's own index | **A checklist for redesigning any system from scratch.** Run any design prompt through these six steps, in order. First, requirements: 3 to 5 core features, plus the scale numbers, meaning daily users, requests per second, the ratio of reads to writes, and a latency target. Second, a capacity estimate: rough storage and bandwidth maths. Third, API design: 3 to 5 endpoints with their request and response shapes. Fourth, the high-level architecture: boxes for the client, load balancer, service, cache, database, and queue, and how data actually flows between them. Fifth, a deep dive: pick the ONE hardest part and go deep specifically on that. Sixth, bottlenecks and trade-offs: where does this design break at 10 times the scale, and what did you give up to get here. > **Remember:** each building block solves one problem and creates a new watch-out. Naming both halves is what separates "I'd add a cache" from a real answer. ```knowledge-check { "questions": [ { "id": "ip45-hld-15-blocks-q1", "type": "mcq", "prompt": "A design needs to protect against abusive clients sending far too many requests per second. Which building block fits, and what is its main watch-out?", "options": [ {"id": "a", "text": "A rate limiter; the watch-out is choosing between algorithms like token bucket and sliding window, which trade off burst tolerance against precision"}, {"id": "b", "text": "A CDN; the watch-out is cache invalidation after a deploy"}, {"id": "c", "text": "Sharding; the watch-out is expensive cross-shard joins"}, {"id": "d", "text": "Object storage; the watch-out is that it isn't a substitute for a database index"} ], "correct": "a", "explanation": "A rate limiter is the block built specifically for abuse protection and fairness between clients. Every block in the table pairs a problem it solves with a specific cost, and matching the wrong pair together is a common mistake to make under pressure." } ] } ``` ## Numbers and phrases to have on instant recall **Numbers worth memorising:** ``` Time : memory 100 ns · SSD read 100 µs · DC round trip 500 µs cross-country 70 ms · cross-Atlantic 150 ms Throughput: Postgres ~10k QPS/node · Redis ~100k+ ops/sec · app server ~10k req/sec Kafka broker ~100k+ msg/sec · 10 Gbps NIC ≈ 1.25 GB/s Scale : sec/day ≈ 100k · 1M/day ≈ 10 QPS · 1B/day ≈ 10k QPS · peak = 2–3× Sizes : UUID 16 B · post 300 B · user row 1 KB · API response 1–10 KB thumbnail 50 KB · photo 2 MB · 1080p video 50 MB/min Uptime : 99.9% = 43 min/month · 99.99% = 4.3 min/month Quorum : W + R > N · clusters of 3, 5, 7 (odd) · majority tolerates ⌊(n−1)/2⌋ failures ``` **Phrases that earn real points.** These are worth practising word for word, because under real pressure you tend to say whatever you've already rehearsed saying, not whatever you're trying to think up fresh in the moment: 1. "Before I design anything, what scale are we targeting, and is this read-heavy or write-heavy?" 2. "I'll scope to X and Y, and treat Z as out of scope unless you'd like it covered." 3. "That's 100 reads for every write, so the interesting problem is the read path." 4. "Anything the user's response doesn't depend on goes behind a queue." 5. "I'm choosing X. The cost is Y, and I'd soften it with Z." 6. "This is CP for the payment and AP for the product page; the choice is per operation." 7. "Writing to the database and publishing to the broker aren't one atomic action, so I'd use a transactional outbox." 8. "At-least-once delivery plus an idempotent consumer gives me effectively-once behaviour." 9. "Replication lag breaks seeing your own writes, so I'd route that user to the leader for a few seconds." 10. "Every real system has a hot key; here it's the celebrity account, and I'd handle it with a separate read path." 11. "Four synchronous dependencies at 99.9% each caps me at about 99.6%; I'd move two of them off the critical path." 12. "I'd alert on the checkout SLO, propagate a trace id into every log line, and add a daily reconciliation job." **Anti-patterns that lose points**, so you can catch yourself doing them: drawing boxes before asking any requirements; naming technologies without justifying why; reaching for many small services, a message broker, or sharding at only 200 requests a second; claiming exactly-once delivery is actually achievable; presenting one design with no stated costs at all; going quiet while you think instead of narrating out loud; and running out of time because requirements alone took fifteen minutes. > **Remember:** rehearse the twelve phrases out loud until they come out naturally. Under pressure you say what you've already practiced saying, not what you newly think of. ```knowledge-check { "questions": [ { "id": "ip45-hld-15-phrases-q1", "type": "mcq", "prompt": "Which statement would an interviewer most likely mark as a mistake rather than a strength?", "options": [ {"id":"a","text":"\"We'll use Kafka's transactions to get exactly-once delivery end to end, so consumers don't need to handle duplicates.\""}, {"id":"b","text":"\"At-least-once delivery with an idempotent consumer, deduplicated on a unique message id.\""}, {"id":"c","text":"\"This is CP for the payment path and AP for the catalogue.\""}, {"id":"d","text":"\"I'd start with one Postgres primary and a replica; here's the load at which I'd shard.\""} ], "correct": "a", "explanation": "Kafka's transactions only give exactly-once behaviour for writes going back into Kafka itself, not for outside effects like charging a card or sending an email. Claiming true end-to-end exactly-once, and skipping consumer-side deduplication because of it, is a recognisable mistake." } ] } ``` ## The recall drill Answer each question out loud, from memory, then check yourself against the lesson named in brackets. Aim for every answer to come back to you inside five seconds, with no notes. Repeat this drill often; the whole point is practising recall, not simply rereading the material again. **Round 1, the framework and the numbers** 1. The six steps of a design interview, and the minutes given to each. [The System Design Interview Framework] 2. Seconds in a day, and what 1 million a day and 1 billion a day come to in requests per second. [Back-of-the-Envelope Estimation] 3. Memory versus SSD versus a cross-Atlantic round trip, in orders of magnitude. [Back-of-the-Envelope Estimation] 4. The four rows of the interviewer's scorecard. [The System Design Interview Framework] **Round 2, the request path** 5. When to use SSE instead of WebSocket, and what WebSocket costs you architecturally. [Networking and Protocols for Design] 6. Why cursor pagination beats page numbers, and why the cursor needs a tie-breaker. [API Design and Idempotency] 7. What an idempotency key protects against, and which database feature makes it actually correct. [API Design and Idempotency] 8. L4 versus L7: one thing only L7 can do. [Load Balancing, Proxies, and Scaling Out] 9. Why a health check must not test the database. [Load Balancing, Proxies, and Scaling Out] **Round 3, data** 10. On a write, do you update the cached value or delete it? Why? [Caching and CDNs] 11. Name the three cache failure modes and one fix for each. [Caching and CDNs] 12. An index on columns `(a, b, c)`: which queries does it actually help? [Choosing a Database] 13. B-tree versus LSM-tree, in one sentence. [Choosing a Database] 14. Which problem does Read Committed still allow, and the three ways to prevent it. [Choosing a Database] 15. What does replication scale? What does partitioning scale? [Replication, Partitioning, and Sharding] 16. The three tests for a good partition key. [Replication, Partitioning, and Sharding] 17. Why `hash(key) % N` is a trap, and what fixes it. [Replication, Partitioning, and Sharding] 18. What the "P" in CAP actually means, and why "CA" isn't a real thing. [CAP, PACELC, and Levels of Consistency] 19. State PACELC, and give the everyday half of it. [CAP, PACELC, and Levels of Consistency] 20. The quorum rule for a read to see the latest write. [CAP, PACELC, and Levels of Consistency] **Round 4, async work and coordination** 21. Queue versus log: the two questions that decide between them. [Messaging, Queues, and Event-Driven Architecture] 22. Why exactly-once delivery doesn't really exist, and what you say instead. [Messaging, Queues, and Event-Driven Architecture] 23. What the outbox pattern fixes, and how. [Messaging, Queues, and Event-Driven Architecture] 24. A saga: what replaces rollback, and the three obligations it places on you. [Distributed Transactions and Data Integrity] 25. Two-phase commit: what happens if the coordinator dies right after collecting the votes? [Distributed Transactions and Data Integrity] 26. What a fencing token is, and why a lease by itself isn't enough. [Coordination, Consensus, and Distributed Locks] 27. Why a Redis lock alone cannot guarantee correctness. [Coordination, Consensus, and Distributed Locks] 28. The cheapest way to run a nightly job exactly once, across 10 separate instances. [Coordination, Consensus, and Distributed Locks] **Round 5, operations** 29. The availability of four synchronous 99.9% dependencies chained together, and the fix. [Reliability, Resilience, and Rate Limiting] 30. Four rules for handling retries safely. [Reliability, Resilience, and Rate Limiting] 31. The circuit breaker's states, and the transitions between them. [Reliability, Resilience, and Rate Limiting] 32. Token bucket versus fixed window: the two advantages of the token bucket. [Reliability, Resilience, and Rate Limiting] 33. What a metastable failure is, and how you escape one. [Reliability, Resilience, and Rate Limiting] 34. RED and USE: what each one is actually for. [Observability, Security, and Cost] 35. The JWT trade-off, and how it's usually softened. [Observability, Security, and Cost] 36. Expand, migrate, contract: why all three steps are needed. [Observability, Security, and Cost] **Round 6, apply it.** Pick a system you use every day, like a food delivery app, a banking app, or a music streaming service, and give yourself six minutes: state the requirements, do the estimate, write one API endpoint, sketch one data model, draw one diagram, and name one bottleneck along with its fix and its cost. Six minutes, entirely out loud, no notes. Repeat this with a different system next time; it's the closest thing to a real interview you can practise entirely on your own. > **Remember:** rereading feels like learning but doesn't actually test recall. Answering out loud from memory, on a clock, is what actually sticks. ```knowledge-check { "questions": [ { "id": "ip45-hld-15-drill-q1", "type": "mcq", "prompt": "What makes this recall drill effective as a way to study, compared with simply rereading the lessons again?", "options": [ {"id":"a","text":"It covers more material in less time overall"}, {"id":"b","text":"It is retrieval practice: pulling an answer out of memory under a time limit strengthens your recall far more than rereading does, and it reveals exactly which items you only *recognise* rather than actually know"}, {"id":"c","text":"It removes the need to understand the underlying concepts at all"}, {"id":"d","text":"It guarantees the exact same questions will be asked in a real interview"} ], "correct": "b", "explanation": "Rereading builds familiarity, which feels a lot like real knowledge but tends to fall apart under actual interview pressure. Timed self-testing is the mechanism that actually makes your recall reliable, and as a side effect, it shows you exactly which items you're weak on." } ] } ``` ## Quick recap The two things worth memorising absolutely are the six-step framework and the 45-minute budget. Everything else, you can work back out from the decision trees once you're standing on the right branch. If a sentence you say in an interview doesn't include a real trade-off, it probably didn't earn you anything. 56:T3137,A URL shortener turns a long link into a short one, like turning `https://mindforge.test/blog/2026/09/a-very-long-post-title` into `sho.rt/aZ9kLm`. Visiting the short link redirects you to the long one. Interviewers love this question because it is simple enough to finish in 40 minutes, but it still forces you to scope requirements, do real math, pick a key-generation strategy, and think about a read-heavy system. Treat it as your warm-up: the same framework (requirements, estimates, API, data model, high-level design, deep dive, trade-offs) repeats in every design in this course. ## Requirements Start every design by splitting what the system must do (functional) from how well it must do it (non-functional). This keeps you from jumping straight to a diagram before you know what you're building. **Functional requirements** - Given a long URL, generate a short, unique code (`sho.rt/aZ9kLm`). - Visiting the short link redirects to the original URL. - Users can optionally request a custom alias. - Links can expire, either by default or a user-set date. - Basic click stats: total clicks, maybe referrer and timestamp. **Non-functional requirements** - High availability: if the redirect service goes down, every shared link breaks. Uptime matters more than perfect consistency. - Low latency: a redirect should feel instant, under 100ms on the server. - No two long URLs should silently collide on the same short code. - Short codes should not be easy to guess in sequence. - The system must handle billions of URLs and tens of thousands of redirects per second. > **Remember:** in every system design interview, say the functional and non-functional requirements out loud before you draw anything. It shows you're scoping the problem, not guessing at a diagram. ```knowledge-check { "questions": [ { "id": "system-design-url-shortener-requirements-q1", "type": "mcq", "prompt": "Why do non-functional requirements matter as much as functional ones in a URL shortener?", "options": [ {"id": "a", "text": "They don't, only functional requirements affect the design"}, {"id": "b", "text": "They decide trade-offs like availability over consistency, which shapes every later design choice"}, {"id": "c", "text": "They are only relevant for the final trade-offs section"}, {"id": "d", "text": "They are the same for every system, so they can be skipped"} ], "correct": "b", "explanation": "Picking availability over consistency here is what later justifies caching, eventual-consistency click counts, and read replicas." } ] } ``` ## Estimates Rough numbers, done out loud, tell you what kind of system you're building. Assume 100 million new URLs a month and a 100:1 read-to-write ratio, which is typical: people click links far more often than they create them. - **Writes per second:** 100,000,000 / (30 × 24 × 3600) ≈ 38 writes/sec on average. Design for 5-10x that at peak, so 200-400/sec. - **Reads per second:** 38 × 100 ≈ 3,800 redirects/sec on average, maybe 20,000/sec at peak. - **Storage:** each row is about 500 bytes (long URL plus metadata). Over 5 years: 100M/month × 60 months × 500 bytes ≈ 3 TB. Small enough to fit in one well-indexed table with read replicas. - **Cache size:** if 20% of links get 80% of the traffic (a common pattern), caching a day's hottest 20 million codes at 500 bytes each is about 10 GB, which fits easily in a Redis cluster. > **Remember:** the read:write ratio is the single number that should drive your whole design. A 100:1 ratio means "optimize the read path first" before anything else. ## API ``` POST /api/v1/shorten body: { long_url, custom_alias?, expires_at? } resp: { short_code, short_url, expires_at } GET /{short_code} -> 301/302 redirect to original long_url GET /api/v1/{short_code}/stats resp: { short_code, long_url, click_count, created_at, last_accessed_at } DELETE /api/v1/{short_code} (owner only) ``` One real decision hides in that redirect line: 301 or 302? A 302 ("temporary redirect") is usually right for a shortener. Browsers won't cache it forever, so you keep accurate click counts and can still change or expire the destination later. A 301 ("permanent redirect") saves you server load because browsers cache it, but you lose click tracking. Say this trade-off out loud if asked. ## Data model ``` urls id bigint PK short_code varchar(10) UNIQUE INDEX long_url text user_id bigint NULL (FK -> users) created_at timestamp expires_at timestamp NULL click_count bigint DEFAULT 0 clicks (optional, for analytics — append-only, often a separate store) id bigint PK short_code varchar(10) INDEX clicked_at timestamp referrer text NULL ip_hash varchar(64) NULL ``` Don't update `click_count` on every redirect with a synchronous `UPDATE`. That turns your hot read path into a hot write path, and popular links start fighting over the same row lock. Instead, treat `click_count` as an eventually-consistent number: fire an event onto a queue and let a separate worker update the count in the background. ```knowledge-check { "questions": [ { "id": "system-design-url-shortener-datamodel-q1", "type": "mcq", "prompt": "Why shouldn't a redirect synchronously increment click_count in the database?", "options": [ {"id": "a", "text": "Because click counts don't matter to the business"}, {"id": "b", "text": "Because it turns the hot read path into a hot write path and causes row-lock contention on popular links"}, {"id": "c", "text": "Because Postgres cannot increment a counter column"}, {"id": "d", "text": "Because click_count must always be exactly accurate"} ], "correct": "b", "explanation": "Redirects happen far more often than link creation. Adding a synchronous write to the busiest path in the system slows everyone down for the sake of a number that's fine to be a few seconds stale." } ] } ``` ## High-level design ``` Client | v Load Balancer | +--> Write Service (POST /shorten) --> Key Generation Service --> Primary DB | | +--> Read Service (GET /{code}) <-- Cache (Redis) <----------------+ | (cache miss) --> Read Replica DB ``` Picture two separate lanes on a highway. The write lane is quiet: someone submits a long URL, the service picks a short code, writes it to the database, and hands back the short link. The read lane is the busy one: every redirect checks the cache first. A hit means an instant redirect. A miss means one query to a read replica, then the cache is filled so the next person gets a hit. This pattern, check the cache first and fall back to the database, is called **cache-aside**. It fits here because reads vastly outnumber writes, and a cold cache heals itself the moment someone requests a missing code. ## Deep dives ### How do you generate a short code without collisions? **Option A: random string, then check for a collision.** Generate 7 random characters from `[a-zA-Z0-9]` (62 possible characters per slot), then check the database for a clash and retry if one exists. - Simple, and codes are unpredictable. - The problem: as the table fills up, more of your random guesses collide, so writes slow down under a growing number of retries. **Option B: base-62 encode a number that's already unique.** Get a unique, ever-increasing number (a database sequence, or a distributed ID generator) and encode it in base 62. Seven base-62 characters give you 62⁷ ≈ 3.5 trillion possible codes. ```python ALPHABET = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz" def encode_base62(num: int) -> str: if num == 0: return ALPHABET[0] digits = [] base = len(ALPHABET) while num: num, rem = divmod(num, base) digits.append(ALPHABET[rem]) return "".join(reversed(digits)) ``` Base-62 encoding guarantees uniqueness by construction, with no collision check needed. The trade-off: a plain incrementing ID is guessable (code `aaaaaab` is obviously one more than `aaaaaaa`). Fix that by handing out IDs in shuffled blocks instead of one global counter. The strongest answer in an interview: a **Key Generation Service (KGS)**. It pre-generates a big pool of unique keys ahead of time and hands blocks of, say, 1,000 keys to each app server. Every server picks from its own block, so no two servers ever fight over the same counter, and no write ever needs a collision check. > **Remember:** a Key Generation Service removes the collision check from the write path entirely, instead of hoping random strings don't clash. ```knowledge-check { "questions": [ { "id": "system-design-url-shortener-keygen-q1", "type": "mcq", "prompt": "What is the main advantage of base-62 encoding a unique ID over generating a random string and checking for collisions?", "options": [ {"id": "a", "text": "Base-62 codes are always shorter"}, {"id": "b", "text": "It guarantees uniqueness by construction, so no collision check or retry is needed on write"}, {"id": "c", "text": "Random strings cannot be stored in a database"}, {"id": "d", "text": "Base-62 encoding is required by HTTP"} ], "correct": "b", "explanation": "Since the underlying number is already unique, encoding it never produces a duplicate, which removes an expensive collision-check round trip from every write." } ] } ``` ### What happens when a link goes viral? A viral link turns one Redis key into a hot key that gets hammered by millions of reads a minute. Three fixes, and they stack: - Put a CDN or edge cache in front of the redirect service, so most requests never even reach your servers. - Add a short-lived, in-process cache on each app server so not every request round-trips to Redis. - Replicate that one hot key across multiple Redis nodes so no single node becomes the bottleneck. ### How do expired links get cleaned up without scanning the whole table? Two mechanisms, used together. On a cache miss, check `expires_at` and treat an expired link as not found (lazy expiration). Separately, run a low-priority background job that deletes expired rows in small batches (active expiration), so the table doesn't grow forever. Redis uses this same combination internally. ## Trade-offs and follow-up questions - **Relational vs sharded database.** A single Postgres or MySQL instance handles this fine for a long time, since every lookup is by primary key with no joins. Shard by a hash of `short_code` only once one primary can't keep up with write volume or storage. - **Consistency vs availability.** This system should favor availability. A redirect that fails is a real problem; a click count that's a few seconds stale is not. - **Analytics off the hot path.** Never let click tracking block a redirect. Fire an event onto a queue and let a separate consumer update counts and write detailed click rows asynchronously. **Q: How do you prevent short-code collisions at scale without checking on every write?** A: Use a pre-generated key pool (the KGS above), or base-62 encode a globally unique, monotonically increasing ID so no two servers can ever produce the same code. **Q: How would you handle a link that suddenly goes viral?** A: CDN/edge caching in front of the redirect service, a short local cache on each app server, and replicating the hot key across more than one Redis node. **Q: How do you expire links without scanning the whole table?** A: Lazy expiration on read (check `expires_at` on a cache miss) plus a background job that deletes expired rows in batches. ```knowledge-check { "questions": [ { "id": "system-design-url-shortener-tradeoffs-q1", "type": "mcq", "prompt": "Why does a URL shortener favor availability over strict consistency?", "options": [ {"id": "a", "text": "Because a broken redirect breaks every shared link, while a slightly stale click count costs nothing"}, {"id": "b", "text": "Because Postgres cannot guarantee consistency"}, {"id": "c", "text": "Because availability is always more important than consistency in every system"}, {"id": "d", "text": "Because redirects don't need a database at all"} ], "correct": "a", "explanation": "The cost of an unavailable redirect (a broken link everywhere it was shared) is far higher than the cost of a click count being a few seconds out of date." } ] } ``` 57:T30b5,A rate limiter caps how many requests one client (a user, an API key, or an IP address) can make in a time window. It sits at the edge, before requests reach your backend, and protects you from abuse, runaway retries, and surprise cloud bills. This question is less about drawing boxes and more about comparing algorithms and picking one with a reason. Interviewers use it to check whether you understand the difference between a textbook counter and something that survives 50 gateway instances running at once. ## Requirements **Functional requirements** - Limit requests per identity (user ID, API key, or IP) to N requests per time window. - Return `429 Too Many Requests` with a `Retry-After` header when the limit is hit. - Support different limits per plan (free vs. paid). **Non-functional requirements** - Accuracy costs latency: a perfectly precise limiter needs coordination between servers, which is slower. An approximate limiter is faster but may let a small burst through. - The limiter check itself must add only single-digit milliseconds. - It must work correctly across a fleet of stateless gateway instances, not just on one machine. - It must fail in a predictable way if its counter store goes down. Usually fail open (let requests through) for availability, fail closed (reject) for security-critical endpoints. > **Remember:** a rate limiter that only works correctly on one server is not a rate limiter, it's a demo. The real question is always "does this hold up across a fleet?" ```knowledge-check { "questions": [ { "id": "system-design-rate-limiter-requirements-q1", "type": "mcq", "prompt": "Why is a rate limiter that only tracks counts in one server's memory a problem in production?", "options": [ {"id": "a", "text": "It isn't a problem, in-memory counters are always correct"}, {"id": "b", "text": "With N gateway instances each keeping its own counter, a client effectively gets N times the intended limit"}, {"id": "c", "text": "In-memory counters are slower than a database"}, {"id": "d", "text": "It only matters for very small companies"} ], "correct": "b", "explanation": "If a client's requests spread across 50 gateway instances and each one counts independently, the client can send 50 times the intended limit before any single instance notices." } ] } ``` ## The five algorithms, and how to picture each one **Fixed window counter.** Picture a whiteboard tally that gets erased every minute on the clock. Simple, O(1) memory, but a client can send N requests at 0:59 and another N at 1:00, getting 2N requests in two seconds right at the boundary. **Sliding window log.** Picture keeping every receipt, then on each check throwing away receipts older than the window and counting what's left. Perfectly accurate, no boundary burst, but memory grows with request volume and each check costs more (you're storing every timestamp). **Sliding window counter.** Picture two overlapping buckets: last window's count and this window's count, blended by how much of the previous window still overlaps "now." `estimated_count = current_window_count + previous_window_count × (1 - elapsed_fraction_of_current_window)` Near-accurate, O(1) memory, cheap to compute. This is the industry-favored answer (Cloudflare and Stripe-style gateways use it) because it balances accuracy and cost. **Token bucket.** Picture a prepaid wallet. Every request spends one credit; credits refill at a steady rate up to a cap. This naturally allows a burst up to the bucket's size while still capping sustained abuse, which matches how real APIs behave: a page load firing 10 requests at once is fine, sustained hammering isn't. **Leaky bucket.** Picture a queue draining at a constant speed. Requests join the back of the queue; if the queue is full, new ones are dropped. This smooths bursty traffic into a steady outflow, useful when the thing behind you can't handle spikes at all, but legitimate bursts get delayed instead of allowed. Token bucket and leaky bucket are mirror images: one grants credit that drains over time, the other drains a fixed-rate queue in the opposite direction. If you can explain one, you can derive the other on a whiteboard. | Algorithm | Tracks | Allows bursts | Memory | Best for | |---|---|---|---|---| | Fixed window | count + reset time | yes, at the boundary | O(1) | Simple counters | | Sliding window log | every timestamp | no | O(n) | Precise enforcement | | Sliding window counter | two window counts | partially | O(1) | Distributed systems | | Token bucket | credits | yes | O(1) | API rate limiting | | Leaky bucket | queue depth | no | O(1) | Traffic shaping | **The interview-favored pick:** token bucket, or the sliding window counter, for API gateways. Bursts are normal client behavior, and you want to allow that while still capping sustained abuse. > **Remember:** token bucket lets bursts through and caps the average; fixed window is simple but leaks double the limit at the boundary. ```knowledge-check { "questions": [ { "id": "system-design-rate-limiter-algorithms-q1", "type": "mcq", "prompt": "What is the classic weakness of the fixed window counter algorithm?", "options": [ {"id": "a", "text": "It uses too much memory to be practical"}, {"id": "b", "text": "A client can send close to double the limit in a short window that straddles two counting periods"}, {"id": "c", "text": "It cannot be implemented with Redis"}, {"id": "d", "text": "It never allows any bursts at all"} ], "correct": "b", "explanation": "Sending N requests right before a window boundary and another N right after lets a client get 2N requests within a couple of seconds, even though each window individually stayed under the limit." } ] } ``` ## Where to store counters: Redis vs. in-memory | | In-memory (per instance) | Redis (shared) | |---|---|---| | Accuracy across a fleet | Wrong: N instances effectively multiply the limit by N | Correct: one shared source of truth | | Latency | Fastest, no network hop | About 1ms extra for the round trip | | Survives a restart | No | Yes | | Complexity | Simple | Needs a Redis cluster plus a TTL/eviction plan | In-memory only works if you pin a client to one gateway instance forever, which is fragile and breaks the moment you scale up or down. For a real distributed gateway, use Redis: `INCR key` with `EXPIRE`, or a Lua script so the check-and-increment happens in one atomic round trip. That avoids a race where two concurrent requests both see "under limit" before either one increments. The Redis primitive follows the algorithm: - **Fixed window:** `INCR ratelimit:{key}:{window}`, with `EXPIRE` set only on the first increment. The key self-cleans via TTL. - **Sliding window log:** `ZADD` the timestamp into a sorted set, `ZREMRANGEBYSCORE` to drop anything older than `now - window`, then `ZCARD` to count. Wrap all three in one Lua script so nothing interleaves. - **Sliding window counter:** two plain `INCR` keys, one per window. Read both, apply the weighted formula above. No Lua needed for reads. ``` -- Redis Lua script sketch for token bucket local tokens = tonumber(redis.call('GET', KEYS[1]) or capacity) local now = tonumber(ARGV[2]) -- refill based on elapsed time, then attempt to consume 1 token if tokens >= 1 then redis.call('SET', KEYS[1], tokens - 1, 'EX', ttl) return 1 -- allowed else return 0 -- rejected end ``` ## API ``` Config per tier: { tier: "free", limit: 100, window_seconds: 60 } { tier: "pro", limit: 10000, window_seconds: 60 } Every incoming request: key = f"ratelimit:{user_id}:{current_window}" allowed = check_and_increment(key, limit) if not allowed: return 429, headers: { "Retry-After": seconds_until_reset } ``` ## High-level design ``` Client --> API Gateway (stateless, N instances) | v Rate Limiter Middleware <---> Redis Cluster (counters, TTL per key) | v (if allowed) Backend Services ``` The limiter is middleware, not a separate network hop. It runs inline in the gateway's request path, calls Redis synchronously before forwarding the request, and Redis is the one shared truth every gateway instance checks. TTLs on every key mean old counters clean themselves up. ## Deep dives ### What breaks when you go distributed? - **Race conditions.** Two concurrent requests from the same client can both read "count = 9, limit = 10" before either writes, letting both through. Fix it with an atomic Redis operation (`INCR`, or a Lua script) instead of a separate read then write. - **Redis as a single point of failure.** If Redis goes down, decide up front: fail open (allow everything, risk overload) or fail closed (reject everything, risk false 429s for real users). Most production gateways fail open and lean on other safeguards, like autoscaling and circuit breakers, as a backstop. - **Clock skew across regions.** Wall-clock-based windows can drift slightly when gateway instances span regions. Sliding window algorithms tolerate this better than fixed windows. - **Multi-region counters.** A true global limit across regions needs either one global Redis (adds cross-region latency) or per-region limits that roughly sum to the global target (simpler, eventually consistent, usually good enough). ```knowledge-check { "questions": [ { "id": "system-design-rate-limiter-deepdive-q1", "type": "mcq", "prompt": "How do you avoid a race condition where two concurrent requests both pass a rate-limit check they shouldn't?", "options": [ {"id": "a", "text": "Add a longer timeout to the request"}, {"id": "b", "text": "Use an atomic operation, like Redis INCR or a Lua script, so the check and the increment happen in a single step"}, {"id": "c", "text": "Increase the rate limit so it doesn't matter"}, {"id": "d", "text": "Store the counter in each gateway's local memory instead"} ], "correct": "b", "explanation": "Reading a count and then writing it back in two separate steps leaves a window where two requests can both read the old value. An atomic increment closes that window." } ] } ``` ## Trade-offs and follow-up questions Sharding counters across a Redis Cluster scales horizontally, but one very abusive client still hammers a single shard. That's usually fine, since it's one client's traffic, not global traffic. Add a local "fast reject" cache: if a client is already known to be far over the limit, reject it without even calling Redis, saving a network hop on the abuse case. Also return rate-limit headers (`X-RateLimit-Limit`, `X-RateLimit-Remaining`, `X-RateLimit-Reset`) so well-behaved clients can throttle themselves before hitting the wall. **Q: How do you avoid a race condition when two requests arrive at nearly the same instant?** A: Use an atomic operation: Redis `INCR` or a Lua script that reads, checks, and writes in one round trip, so nothing can interleave. **Q: What happens if Redis is temporarily unreachable?** A: Decide and document the failure mode up front. Fail-open protects availability but risks abuse during the outage; fail-closed protects backends but causes false rate-limit errors. Most gateways fail open and rely on other safeguards. **Q: How would you rate-limit anonymous IP traffic differently from authenticated API-key traffic?** A: Different key prefixes and different configs (`ratelimit:ip:{ip}` vs. `ratelimit:key:{api_key}`), typically with the stricter IP-based limit applied first at the edge, and the more generous authenticated limit enforced deeper in the gateway. ```knowledge-check { "questions": [ { "id": "system-design-rate-limiter-tradeoffs-q1", "type": "mcq", "prompt": "Why do most production API gateways fail open rather than fail closed when the rate-limit store goes down?", "options": [ {"id": "a", "text": "Failing open is always more secure"}, {"id": "b", "text": "They prioritize availability, accepting some risk of abuse over rejecting all legitimate traffic"}, {"id": "c", "text": "Failing closed is not technically possible"}, {"id": "d", "text": "Redis never goes down in practice"} ], "correct": "b", "explanation": "For most APIs, a false 429 rejecting real users is worse than a short window of unmetered traffic, so gateways lean toward availability and use other safeguards as backup." } ] } ``` 58:T3e21,A notification service takes one event ("order shipped") and delivers it to a user across email, SMS, and push, while respecting what that user actually wants to receive. It's one of the most common real-world backend problems, so interviewers reach for it often: it tests whether you reach for a queue instead of a blocking call, whether you understand at-least-once delivery, and whether your retry logic protects a struggling downstream provider instead of hammering it. ## Requirements **Functional requirements** - Send notifications through multiple channels: email, SMS, push. - Support templated messages, e.g. "Your order {{order_id}} has shipped." - Track delivery status per notification: queued, sent, delivered, failed. - Let other internal services trigger a notification through an API or event. - Respect per-user, per-channel preferences (opted out of SMS, quiet hours) and let users unsubscribe from a category or from everything. **Non-functional requirements** - Reliability: a notification must never be silently lost. - Ordering: for one user, notifications should generally land in the order they were triggered. A "payment failed" alert shouldn't arrive after a "payment succeeded" one that fired later. - Retry logic: transient failures (a timeout, a 500 from the SMS gateway) must retry with backoff, not just get dropped. - Unsubscribes must take effect immediately, checked at the moment of sending, not just flipped in a settings screen. This is a legal requirement (CAN-SPAM, TCPA, GDPR), not just good UX. - Scale to millions of sends a day, each channel bound by its own provider rate limit. > **Remember:** unsubscribe enforcement is one of the few places in system design where "eventually consistent" is the wrong answer. The cost of getting it wrong is regulatory, not just a bad user experience. ```knowledge-check { "questions": [ { "id": "system-design-notifications-requirements-q1", "type": "mcq", "prompt": "Why must an unsubscribe be checked at the moment a notification is sent, rather than only when a user toggles a setting?", "options": [ {"id": "a", "text": "Because checking earlier is technically impossible"}, {"id": "b", "text": "Because a notification already queued before the unsubscribe could otherwise still go out, which is a compliance failure"}, {"id": "c", "text": "Because users never actually mean to unsubscribe"}, {"id": "d", "text": "Because it makes the API simpler"} ], "correct": "b", "explanation": "A batch send can be mid-flight when a user unsubscribes. Checking at send time, not just at enqueue time, is what actually stops that message from going out." } ] } ``` ## Estimates Assume 100 million users, each getting about 3 notifications a day across all channels: 300 million sends/day. - **Average rate:** 300,000,000 / 86,400 ≈ 3,500/sec, with bursts 10-50x higher during a mass event like an incident alert or a marketing campaign. - **Channel split (illustrative):** about 70% push (cheap, high volume), 25% email (moderate cost), 5% SMS (expensive per message, tightly capped by carriers). This spread is exactly why you throttle each channel independently instead of treating "notifications" as one undifferentiated stream. - **Provider limits are usually the real bottleneck.** An SMS gateway might cap you at a few hundred messages/sec per account. That external ceiling, not your own servers, decides your SMS throughput. - **Storage:** a notification record is about 1 KB. At 300M/day, that's 300 GB/day. Archive records older than a few months to cheap cold storage rather than keeping everything in the hot database forever. ## API ``` POST /notifications/send { user_id, category, template_id, data, channels?: ["push","email"] } -> { notification_id, status: "queued" } GET /notifications/{id}/status -> { status, per_channel: {push: "delivered", email: "sent"} } POST /preferences/{user_id} { category, channel, enabled: bool } GET /preferences/{user_id} -> { preferences[] } POST /unsubscribe { user_id, category? } -- category omitted = unsubscribe all ``` Callers send a logical `category` (`security_alert`, `order_update`, `marketing`), not a specific channel. The notification service resolves the actual channel(s) from the user's own preferences, so the triggering service never has to know what that user wants. Every request also carries an `idempotency_key` (for example `order-123-shipped`). If a caller retries the trigger call, the service upserts on that key instead of creating a duplicate notification. ## Data model ``` notifications id, user_id, category, template_id, data, created_at, status notification_deliveries notification_id, channel, status (queued|sent|delivered|failed| suppressed), provider_ref, attempted_at, delivered_at templates id, category, channel, subject_template, body_template preferences user_id, category, channel, enabled (bool) unsubscribes user_id, category (NULL = all), unsubscribed_at ``` `notification_deliveries` holds one row per (notification, channel). One logical notification can fan out into several delivery attempts, each tracked and retried on its own, so a failed SMS send doesn't affect the email send for the same event. ## High-level design ``` Triggering service --> POST /notifications/send | Notification service: resolve preferences + unsubscribes --> determine eligible channels --> render template with data | write notification_deliveries row(s), status=queued | push to per-channel job queues (one queue per channel, so a slow or rate-limited channel never blocks the others) | +-------------------------+-------------------------+ v v v Push worker pool Email worker pool SMS worker pool (calls APNs/FCM) (calls SES/SendGrid) (calls Twilio-style) v v v delivery receipt / webhook --> update notification_deliveries.status ``` Picture three separate conveyor belts, one per channel, instead of one shared belt. If SMS is slow because a carrier is rate-limiting you, that belt backs up on its own, while push and email keep moving. That's the single most important structural decision in this design: **per-channel queues, not one shared queue.** ## Deep dives ### Why does each channel need its own queue and worker pool? If every channel shared one queue, a burst of bulk marketing email could sit in front of a time-sensitive OTP SMS, or a slow email provider could back up push notifications that have nothing to do with email. Splitting the queue by channel means each one scales and degrades independently, matched to that channel's own provider limits. Inside a channel, a priority sub-queue keeps security-critical sends (a login code) ahead of bulk sends (a newsletter). > **Remember:** isolate queues at the same boundary where your external rate limits live. If SMS has its own cap, SMS needs its own queue. ```knowledge-check { "questions": [ { "id": "system-design-notifications-queues-q1", "type": "mcq", "prompt": "Why split notification queues by channel instead of using one shared queue for push, email, and SMS?", "options": [ {"id": "a", "text": "Separate queues are always faster no matter the traffic pattern"}, {"id": "b", "text": "So a rate-limited or slow channel, like SMS, can't back up unrelated channels like push"}, {"id": "c", "text": "Because a single queue cannot hold more than one message type"}, {"id": "d", "text": "To save on storage costs"} ], "correct": "b", "explanation": "Each channel has its own external rate limit and failure pattern. A shared queue lets the worst-behaved channel slow down every other channel too." } ] } ``` ### How does retry with backoff actually work? Distinguish two kinds of failure. A **transient** error (timeout, a 5xx, a rate limit) is worth retrying. A **permanent** error (invalid phone number, malformed payload) is not, retrying it five times just wastes time before the message reaches the dead-letter queue anyway. ```python import random import time MAX_ATTEMPTS = 5 BASE_DELAY_SECONDS = 1.0 class ProviderTransientError(Exception): """Retryable: timeout, 5xx, rate limit.""" class ProviderPermanentError(Exception): """Not retryable: invalid recipient, malformed payload.""" def send_with_retry(notification: dict, send_fn) -> str: """Returns 'sent' or raises after exhausting retries, so the caller can route to a dead-letter queue instead of losing the message.""" last_err: Exception | None = None for attempt in range(1, MAX_ATTEMPTS + 1): try: send_fn(notification) # idempotency_key passed through to the provider return "sent" except ProviderPermanentError: raise # no point retrying a malformed request except ProviderTransientError as err: last_err = err if attempt == MAX_ATTEMPTS: break # exponential backoff with jitter, so a fleet of workers retrying # the same failing provider doesn't hammer it in lockstep delay = BASE_DELAY_SECONDS * (2 ** (attempt - 1)) delay += random.uniform(0, delay * 0.1) time.sleep(delay) raise RuntimeError(f"exhausted retries, routing to dead-letter: {last_err}") if __name__ == "__main__": calls = {"n": 0} def flaky_send(notification: dict) -> None: calls["n"] += 1 if calls["n"] < 3: raise ProviderTransientError("simulated timeout") assert send_with_retry({"id": "abc"}, flaky_send) == "sent" assert calls["n"] == 3 def always_permanent(notification: dict) -> None: raise ProviderPermanentError("invalid phone number") try: send_with_retry({"id": "def"}, always_permanent) assert False, "expected raise" except ProviderPermanentError: pass print("ok") ``` The jitter matters as much as the backoff itself. Without it, every worker retrying against the same degraded provider backs off in lockstep and re-hammers it at the exact same instant it starts to recover. Pair this with a **circuit breaker** per provider: after N consecutive failures, stop sending to that provider for a while and fail fast to the dead-letter queue or a fallback provider, instead of letting worker threads pile up waiting on a service you already know is down. After `max_attempts` is exceeded, move the notification to a dead-letter queue for a human or automated process to inspect, fix, and requeue. Never retry forever: a permanently broken payload retried endlessly wastes capacity and hides real outages in your dashboards. ### Why do templates get rendered at send time, not trigger time? Store templates with versioned placeholders (`{{order_id}}`) and render them right before sending, not when the event first fires. If a message sits in the queue for a while, this guarantees the latest template and branding get used, not a stale version. Support per-locale variants (`shipped_en`, `shipped_es`) keyed by the user's locale. ### Why is delivery confirmation different per channel? This is worth naming out loud, because treating all three channels as equally observable is a common mistake: - **Push** has real delivery receipts. APNs and FCM report back whether the device actually got the message. - **Email** has deliverability signals (bounce, complaint) but "delivered" usually just means "accepted by the recipient's mail server," not "the person read it." - **SMS** is the most opaque. Many carriers never reliably report final delivery, so "accepted by the provider" is often the practical ceiling of what you can confirm. For a genuinely critical alert, don't rely on one channel's guarantee alone: if no delivery confirmation arrives within a few minutes for a high-priority category, fire a second channel (push, then email) as a fallback. ```knowledge-check { "questions": [ { "id": "system-design-notifications-delivery-q1", "type": "mcq", "prompt": "Why can't you treat push, email, and SMS as equally reliable at confirming delivery?", "options": [ {"id": "a", "text": "They all use the exact same confirmation mechanism, so there's no difference"}, {"id": "b", "text": "Push has real device-level receipts, email only confirms the mail server accepted it, and SMS delivery confirmation from carriers is often unreliable"}, {"id": "c", "text": "SMS is always more reliable than push"}, {"id": "d", "text": "Delivery confirmation is not possible on any channel"} ], "correct": "b", "explanation": "Each channel gives you a different level of proof that the message actually reached the person, and a strong design states that difference instead of assuming uniform reliability." } ] } ``` ## Trade-offs and follow-up questions **At-least-once delivery is the realistic guarantee.** True exactly-once delivery across a third-party provider isn't achievable. The `idempotency_key`, checked both at the API layer and again by the worker before sending, is what turns retries (ours or the caller's) into safe no-ops instead of duplicate sends. **Ordering vs. throughput.** Partitioning a channel's queue by `user_id` keeps one user's notifications in order without limiting overall throughput, since per-user volume is naturally low. **Provider fan-out for reliability.** Support a primary and fallback provider per channel (SendGrid primary, SES fallback), and fail over automatically when the primary's error rate spikes, using the same circuit breaker from the retry deep dive. **Q: How do you guarantee a user never gets the same notification twice?** A: An idempotency key at the API layer dedupes on insert, and the worker checks the notification's current status before sending. If it's already `sent` or `delivered`, it skips. That makes both queue redelivery and caller retries safe. **Q: A batch marketing send to 5 million users is mid-flight when a user unsubscribes. How do you make sure they don't get it?** A: The preference and unsubscribe check runs when each individual send is dequeued and processed, not once upfront when the whole batch was enqueued. A worker that hasn't reached that user yet sees the updated status and suppresses the send, recorded as `suppressed` for audit purposes rather than silently dropped. **Q: How would you prevent a bug in a calling service from spamming a user with the same alert hundreds of times?** A: A dedup key derived from `user_id + category + a business identifier` (like `order_id`), checked against recently sent notifications before enqueueing, with a reasonable dedup window measured in minutes to hours depending on the category. ```knowledge-check { "questions": [ { "id": "system-design-notifications-tradeoffs-q1", "type": "mcq", "prompt": "Why is checking preferences and unsubscribes at dequeue time better than checking once when a batch is first enqueued?", "options": [ {"id": "a", "text": "It's not better, checking once upfront is sufficient"}, {"id": "b", "text": "It closes the race where a user unsubscribes after enqueueing but before their specific send is processed"}, {"id": "c", "text": "It reduces the total number of database queries"}, {"id": "d", "text": "It makes the API faster"} ], "correct": "b", "explanation": "A large batch can take minutes to fully process. Checking at the moment each message is actually about to send catches an unsubscribe that happened after the batch started." } ] } ``` 59:T2bb7,A job queue is the system behind "process this in the background": Sidekiq, Celery, SQS, and every button in a real product that says "we'll email you when it's ready." A producer enqueues a job, a worker picks it up later and runs it. This question tests whether you understand delivery guarantees, retry logic, and what happens to ordering once you have more than one worker. ## Requirements **Functional requirements** - Producers enqueue jobs with a payload, like "resize image X" or "send email Y." - Workers pull jobs, run them, and report success or failure. - Failed jobs retry with backoff, up to a maximum number of attempts. - Jobs can be scheduled to run in the future. - Jobs support priorities: high, default, low. - Jobs that fail permanently land in a dead letter queue for a human to inspect. **Non-functional requirements** - At-least-once delivery: never silently drop a job. - Thousands of workers can pull from the same queues at once. - Enqueueing must be fast; a producer should never block waiting on a job to run. - Someone can see queue depth, failure rate, and inspect a stuck job. - Job handlers must be idempotent, since at-least-once delivery means a job can run twice. > **Remember:** "at-least-once" is a promise about delivery, not about your handler's side effects. Making the handler safe to run twice is your job, not the queue's. ```knowledge-check { "questions": [ { "id": "system-design-jobqueue-requirements-q1", "type": "mcq", "prompt": "Why must job handlers be written to be idempotent (safe to run more than once)?", "options": [ {"id": "a", "text": "Because idempotent code is always faster"}, {"id": "b", "text": "Because at-least-once delivery means a worker crash or retry can cause the same job to run twice"}, {"id": "c", "text": "Because the queue itself guarantees exactly-once execution"}, {"id": "d", "text": "Idempotency is only needed for payment systems"} ], "correct": "b", "explanation": "A distributed queue with independent producers and consumers can't guarantee exactly-once delivery. The realistic guarantee is at-least-once, so the handler has to tolerate duplicates itself." } ] } ``` ## Estimates Assume a mid-size product with 50 million jobs a day. - **Average rate:** 50,000,000 / 86,400 ≈ 580 jobs/sec. - **Peak (3x during business hours):** roughly 1,750 jobs/sec. - **Storage:** at 1 KB per job and a 7-day retention window for debugging, that's about 350 GB, comfortable for a single Postgres instance or a Kafka topic with retention. - **Worker fleet:** if a job takes 200ms on average, one worker handles 5 jobs/sec. Sustaining 1,750 jobs/sec needs about 350 concurrent workers; provision 500+ for headroom. Say this arithmetic out loud in an interview. It's what justifies picking a DB-backed queue over Kafka, or the other way around, later. ## API ``` POST /jobs body: { queue: "emails", payload: {...}, priority: "default", scheduled_at?: ISO8601, max_attempts?: 5 } -> { job_id, status: "queued" } GET /jobs/{job_id} -> { job_id, status, attempts, last_error, created_at, updated_at } POST /jobs/{job_id}/cancel (only if still queued, not yet leased) GET /queues/{queue}/stats -> { depth, in_flight, failed_last_hour, dlq_count } POST /dlq/{job_id}/requeue ``` Workers never call this HTTP API to fetch jobs. They speak the broker's native pull protocol directly: Redis `BLPOP`, SQS `ReceiveMessage`, or a database `SELECT ... FOR UPDATE SKIP LOCKED`. The HTTP surface above exists for producers and for humans operating the system. ## Data model ``` jobs id UUID PK queue TEXT -- "emails", "thumbnails", "webhooks" payload JSONB status TEXT -- queued | in_progress | succeeded | failed | dead priority SMALLINT -- 0 = high ... 2 = low attempts INT DEFAULT 0 max_attempts INT DEFAULT 5 scheduled_at TIMESTAMPTZ -- when it becomes eligible to run locked_by TEXT NULL -- worker id, set on lease locked_at TIMESTAMPTZ NULL last_error TEXT NULL created_at TIMESTAMPTZ updated_at TIMESTAMPTZ INDEX (queue, status, priority, scheduled_at) -- the "give me the next job" query ``` If you use a broker like Redis, SQS, or Kafka instead of a DB-backed queue, this table becomes the job's status and audit record in Postgres, while the broker holds the lightweight queue of message pointers. Many real systems, including Sidekiq and SQS-backed setups, run this exact hybrid: a fast broker for delivery, a durable database for state. ## High-level design ``` Producer --> [API / enqueue call] --> Broker (Redis/SQS/Kafka) --+--> Job metadata store (Postgres) | Worker pool <--- pull/lease -----------------------------------+ | +--> execute handler --> success: ack, mark succeeded --> failure: nack, increment attempts, requeue with backoff or move to DLQ Scheduler (cron-like) --> polls "scheduled_at <= now() AND status = queued" --> pushes into broker ``` Three moving pieces do three different jobs: the **broker** delivers, the **metadata store** tracks state and audit history, and **workers** execute. Some systems collapse the broker and metadata store into one database-backed queue, simpler to run but with a lower throughput ceiling. Others split them, Kafka for delivery and Postgres for state, trading two systems to keep in sync for a much higher ceiling. ## Deep dives ### Why is leasing better than locking a row forever? A worker doesn't hold a database lock for the entire time it processes a job. That would block visibility into the job and make crash recovery painful. Instead it uses a **visibility timeout**: `UPDATE jobs SET status='in_progress', locked_by=$1, locked_at=now() WHERE id=$2 AND status='queued'`. If the worker crashes mid-job, a reaper process periodically finds jobs whose `locked_at` is older than the visibility timeout and requeues them. SQS calls this a visibility timeout; Sidekiq calls it a watchdog. Same idea, different name. > **Remember:** a job stuck at "in_progress" past its visibility window isn't stuck, it's waiting for the reaper to notice and hand it to someone else. ```knowledge-check { "questions": [ { "id": "system-design-jobqueue-leasing-q1", "type": "mcq", "prompt": "What happens to a job when the worker processing it crashes mid-execution?", "options": [ {"id": "a", "text": "The job is lost permanently"}, {"id": "b", "text": "A reaper process notices the lease has expired (locked_at is past the visibility timeout) and requeues the job for another worker"}, {"id": "c", "text": "The database automatically retries it within milliseconds"}, {"id": "d", "text": "The job stays in_progress forever with no way to recover it"} ], "correct": "b", "explanation": "Because the worker never held a permanent lock, a background reaper can detect the stale lease and safely hand the job to a different worker, which is exactly why handlers must be idempotent." } ] } ``` ### How does retry and the dead letter queue work? Retry with exponential backoff plus jitter: `delay = base * 2^attempts + random_jitter`, capped at something reasonable like 15 minutes. Jitter matters because without it, every failed job retries at the exact same instant and can re-trigger the very outage it's recovering from. After `max_attempts`, move the job to `status = 'dead'` and stop retrying automatically. A human or automated process inspects dead jobs, fixes the root cause, and requeues them through `POST /dlq/{id}/requeue`. Never retry forever: a permanently broken payload retried endlessly wastes capacity and can hide a real outage inside your dashboards. ### How do priorities and ordering actually work? The cheapest way to implement priority is separate queues per level (`queue:high`, `queue:default`, `queue:low`), with workers polling high before default before low, using weighted round-robin so low-priority jobs don't starve completely. A single queue with a priority sort column gets expensive to sort on every dequeue under real load. Full global ordering across a sharded, multi-worker queue is expensive and rarely needed. If one specific ordering guarantee matters (say, "events for the same user must process in order"), use a partition key: Kafka partitions, or pinning a key to one worker, so everything for that key lands on the same worker in order while different keys still run in parallel. ## Trade-offs and follow-up questions | Choice | Pro | Con | |---|---|---| | DB-backed queue (Postgres `SKIP LOCKED`) | Simple to run, transactional with business data, easy DLQ | Throughput ceiling in the low thousands/sec; polling adds latency | | Redis-backed (Sidekiq-style) | Very high throughput, low latency, simple primitives | Durability depends on persistence config; not a great long-term audit log | | Managed broker (SQS) | No ops burden, built-in visibility timeout and DLQ | Vendor lock-in, per-message cost at scale, at-least-once only | | Kafka | Massive throughput, replay, ordering per partition | Heavier to run, overkill for a simple task queue | Pick based on scale: under roughly 1,000 jobs/sec, a DB-backed queue or Redis is the pragmatic choice. Above that, or if you need to replay events at the stream level, reach for Kafka. **Q: How do you guarantee exactly-once processing when the network can duplicate delivery?** A: You don't guarantee it at the delivery layer, you guarantee it at the application layer with an idempotency key. The handler checks a dedup row (`INSERT ... ON CONFLICT DO NOTHING`, keyed on a deterministic key derived from the job) before doing the actual work. Delivery stays at-least-once; the effect becomes exactly-once. **Q: A worker crashes mid-job. What happens to that job?** A: It stays `in_progress` with a `locked_at` timestamp. A reaper scans for jobs whose lease has expired and requeues them, incrementing attempts and resetting status. This is exactly why handlers must be idempotent, since the job may partially run twice. **Q: How do you stop one noisy queue from starving the others?** A: Separate queues per tenant or job type, with weighted round-robin polling or dedicated worker pools per queue, plus rate-limiting on the producer side if one source is flooding the system. ```knowledge-check { "questions": [ { "id": "system-design-jobqueue-tradeoffs-q1", "type": "mcq", "prompt": "Above roughly what throughput does the interview-favored answer shift from a DB-backed or Redis queue toward Kafka?", "options": [ {"id": "a", "text": "10 jobs/sec"}, {"id": "b", "text": "Around 1,000 jobs/sec, or when you need to replay the stream"}, {"id": "c", "text": "There is no such threshold, always use Kafka"}, {"id": "d", "text": "1 million jobs/sec exactly"} ], "correct": "b", "explanation": "Below that range a simpler DB-backed or Redis queue is the pragmatic choice; Kafka earns its extra operational cost once throughput or replay needs grow past it." } ] } ``` 5a:T361a,A chat app like WhatsApp lets two people, or a group, send messages that arrive in real time when everyone's online and wait patiently when they're not. This is one of the best interview questions for separating candidates who've only built request/response APIs from those who understand a live, stateful connection at scale: it forces you to reason about persistent connections, message ordering, and what happens when a phone is switched off for three days. ## Requirements **Functional requirements** - One-on-one and group messaging. - Message delivery status: sent, delivered, read (the WhatsApp checkmarks). - Offline users receive queued messages the moment they reconnect. - Media messages (photos, video, voice notes) alongside text. - Messages are end-to-end encrypted: the server never sees plaintext. - Typing indicators and online/last-seen presence. - A message sent from a phone should also show up on a linked desktop client (multi-device). **Non-functional requirements** - Real-time delivery: sub-second latency for anyone currently online. - Offline support: a message persists and delivers reliably no matter how long the recipient stays offline, even days. - Message ordering within one conversation must look the same to every participant. - Massive connection scale: hundreds of millions of devices holding a connection open at once. > **Remember:** the hardest number in this design is not messages per second, it's connections held open at once. That's what makes a chat system architecturally different from a normal REST API. ```knowledge-check { "questions": [ { "id": "system-design-chat-requirements-q1", "type": "mcq", "prompt": "What makes a chat system's scaling problem fundamentally different from a typical REST API's?", "options": [ {"id": "a", "text": "Chat messages are larger than typical API payloads"}, {"id": "b", "text": "It must hold hundreds of millions of persistent connections open at once, not just handle a burst of short-lived requests"}, {"id": "c", "text": "Chat systems never need a database"}, {"id": "d", "text": "REST APIs cannot use WebSockets"} ], "correct": "b", "explanation": "A REST API serves a request and moves on. A chat system has to keep a live connection open for every online user, which is a fundamentally different infrastructure problem than request throughput." } ] } ``` ## Estimates Assume 2 billion monthly active users, with about 500 million connected at any given peak moment. - **Messages/sec:** at roughly 40 messages/user/day, 2B × 40 / 86,400 ≈ 900,000 messages/sec on average, several times higher during a real-world spike like New Year's Eve. - **Message size:** a text message is small, around 1 KB including metadata and encryption overhead, so 900,000/sec × 1 KB ≈ 900 MB/sec. Trivial for the actual message pipeline. - **Media:** roughly 5% of messages carry a photo or voice note, averaging 200 KB to 2 MB each. This is the real bandwidth driver, and it's handled by uploading straight to object storage and sending only a reference through the messaging pipeline, never the raw bytes. - **Connections:** 500 million concurrent long-lived connections is the standout number. At around 10,000-40,000 connections per commodity server, that's tens of thousands of servers just to hold sockets open, architected completely separately from message processing. Lead with the connection count, not the message volume, when you present your numbers. It's the constraint that actually shapes this design. ## API Chat is push/pull over a persistent connection more than classic request/response, but the shape looks like this: ``` WS /v1/connect # persistent connection, authenticated client -> server: { type: "send", to: user_id|group_id, ciphertext, msg_id (client-generated) } server -> client: { type: "ack", msg_id, server_seq } server -> client: { type: "message", from, ciphertext, server_seq } client -> server: { type: "delivered", msg_id } client -> server: { type: "read", msg_id } GET /v1/messages/sync?since_seq=... # pull missed messages after reconnect POST /v1/media/upload # media uploaded separately, returns a reference POST /v1/groups body: { name, member_ids } ``` The client generates its own `msg_id` before the first send attempt. That one detail is what turns "the network might deliver this twice" into "the user never sees a duplicate": if a send is retried after a dropped acknowledgment, the server recognizes the same `msg_id` and treats it as a no-op. ## Data model ``` User(user_id PK, phone_number, public_key, devices[]) Device(device_id PK, user_id FK, push_token, last_seen) Conversation(conversation_id PK, type[direct|group], member_ids[]) Message(message_id PK, conversation_id FK, sender_id, server_seq, ciphertext, sent_at, delivered_to[], read_by[]) -- ciphertext only: server cannot read content, only routes it MessageQueue(user_id/device_id, message_id, enqueued_at) -- per-device durable queue for offline delivery, drained on reconnect Status(status_id PK, user_id FK, media_ref, posted_at, expires_at) ``` The key detail: `Message.ciphertext` is opaque to the server. Encryption happens client-to-client, so the schema stores unreadable blobs, and the server's whole job is store-and-forward routing plus retention, never reading content. ## High-level design ``` [Sender Device] --(persistent conn)--> [Connection Gateway tier] | [Message Router/Dispatcher] / \ recipient online? recipient offline? | | [route via Connection [write to per-device Gateway holding durable queue, recipient's socket] trigger push notification] | [on reconnect, drain queue via sync API] [Media]: uploaded directly to [Object Storage] by sender, reference shared through the message pipeline, fetched by recipient from [Object Storage/CDN] directly. ``` Picture the **Connection Gateway tier** as a giant switchboard: a huge, horizontally scaled fleet whose only job is holding sockets open and knowing which node holds which user's connection, tracked in a shared registry (a distributed cache). The **Message Router** looks up the recipient. Online, it forwards straight to the gateway node holding that socket. Offline, it writes to a durable per-device queue and fires a push notification to wake the app, which reconnects and syncs later. Media bytes never touch this hot path, only a reference does, the same pattern Netflix uses for video and Airbnb uses for photos: bytes go through object storage and a CDN, never the transactional pipeline. ## Deep dives ### How does ordering work without a global clock? Each message gets a `server_seq`, a number that only increases, scoped to one conversation, assigned by the router at write time. Clients use this to spot gaps: "I have 100 and 102, where's 101?" and request a resync. A simple per-conversation counter is enough; you don't need vector clocks or a global clock for a chat app. ### How do you turn at-least-once delivery into something that feels like exactly-once? The client keeps retrying a send until it gets a server acknowledgment. Those retries are safe because the client attaches its own `msg_id`, a UUID generated before the very first attempt. The server's write is an upsert (`INSERT ... ON CONFLICT (msg_id) DO NOTHING`), so a retried send that already succeeded is simply a no-op instead of a duplicate message. Memorize this pattern: it reappears almost unchanged in payment idempotency and in notification systems. > **Remember:** the network can duplicate a message, but a client-generated ID plus an upsert on the server makes the duplicate invisible to the user. ```knowledge-check { "questions": [ { "id": "system-design-chat-idempotency-q1", "type": "mcq", "prompt": "How does a chat system avoid showing a duplicate message when a client retries a send after a dropped acknowledgment?", "options": [ {"id": "a", "text": "It doesn't, duplicates are an accepted cost of the design"}, {"id": "b", "text": "The client attaches a UUID it generated before the first attempt, and the server upserts on that ID so a retry becomes a no-op"}, {"id": "c", "text": "The server waits several seconds before accepting any message to avoid duplicates"}, {"id": "d", "text": "Duplicates are only possible on the recipient's device, never the server"} ], "correct": "b", "explanation": "A client-generated idempotency key checked with an upsert is what turns unreliable at-least-once delivery into a duplicate-free experience for the user." } ] } ``` ### How does end-to-end encryption change the design? The server must never see plaintext, so it becomes purely a relay. The real-world standard is the **Signal Protocol**, using something called the Double Ratchet algorithm: each pair of devices sets up a shared secret through a key exchange when the conversation starts, and every message afterward advances a "ratchet" that derives a fresh key. Compromising one message's key doesn't expose past or future messages. For groups, each member either gets their own encrypted copy of the key, or the system uses a more advanced scheme to avoid encrypting the same message once per recipient in large groups. Media follows the same idea: the sender uploads to object storage, often encrypting client-side first, so the storage layer never sees plaintext media either. The message itself carries only a reference plus a decryption key, both wrapped inside the encrypted message payload. ### How does a message reach every registered device for one person? Multi-device support means a message has to reach every device linked to an account, not just one. Model delivery per-device, not per-user: the message queue and delivery/read receipts are tracked by `device_id`. When someone links a new device, it does a bounded history sync rather than replaying every message ever sent. ### How do you handle a message to a 500-person group? Fan-out-on-write: the router resolves the group's member list once and dispatches the message to each member's queue or live connection in parallel. Group chats are read far more often than any single message is sent, so the extra write work is worth the simpler read path. For very large broadcast-style groups, a hybrid works better: fan out immediately to online members, and write lazily for offline ones, to keep the write burst manageable. ## Trade-offs and follow-up questions | Concern | Choice | Trade-off | |---|---|---| | Connection handling | A dedicated Connection Gateway tier, separate from message processing | Isolates the hardest scaling problem (500M sockets) from business logic, at the cost of a registry lookup on every route | | Delivery guarantee | At-least-once plus a client-generated idempotent `msg_id` | Simple and reliable, needs dedup logic on write | | Ordering | A per-conversation monotonic sequence number | Simple and sufficient, not a global order across all conversations, which isn't needed anyway | | Offline delivery | A per-device durable queue plus a push notification to wake the app | Guarantees delivery without keeping every socket open 24/7 | | Encryption | Signal Protocol (Double Ratchet), client-side only | True end-to-end privacy, but the server genuinely cannot help with search or moderation on message content | **Q: A user's phone is off for three days. What happens to messages sent to them?** A: They sit in that user's per-device durable queue, written at send time regardless of whether the recipient is reachable. Push notifications are a best-effort attempt to wake the app, not a delivery mechanism the system depends on. When the device reconnects, it syncs from its last known sequence number, and the server drains the queue in order. **Q: How do you handle a message to a very large group efficiently?** A: Fan-out-on-write for normal groups, since reads vastly outnumber writes. For huge broadcast-style groups, mix in a fan-out-on-read style approach for offline members, the same hybrid idea used for celebrity accounts in a social feed. **Q: How would you add server-side search over someone's messages without breaking end-to-end encryption?** A: You can't, not meaningfully. The server only ever sees ciphertext. Search has to happen client-side: the device decrypts messages locally and keeps its own on-device search index. This is a real, known cost of end-to-end encryption, worth stating plainly rather than glossing over. ```knowledge-check { "questions": [ { "id": "system-design-chat-tradeoffs-q1", "type": "mcq", "prompt": "Why can't a WhatsApp-style server offer full-text search across a user's message history?", "options": [ {"id": "a", "text": "Full-text search is technically impossible at any scale"}, {"id": "b", "text": "The server only ever sees encrypted ciphertext, so it cannot index or search message content"}, {"id": "c", "text": "Search would violate message ordering guarantees"}, {"id": "d", "text": "Users don't want search in a chat app"} ], "correct": "b", "explanation": "End-to-end encryption means the server never has plaintext to index. Any search has to happen on the device, where the content is actually decrypted." } ] } ``` 5b:T3d88,An analytics pipeline, think Mixpanel, Segment, or an internal event tracker, ingests events like `page_view` and `purchase` from every client and service, then turns them into dashboards and reports. It tests instincts pure web-app design doesn't: streaming ingestion, storage trade-offs, and what to do when data shows up late. There's no single "right" architecture here, so the interview is really about whether you can justify your trade-offs out loud. ## Requirements **Functional requirements** - Ingest arbitrary events (`page_view`, `purchase`, `signup`, custom events) with a flexible schema. - Generate aggregate reports: counts, funnels, time-series dashboards like "daily active users over the last 30 days." - Support ad-hoc SQL-like queries from analysts. - Support both near-real-time dashboards and exact historical reports. **Non-functional requirements** - High throughput: absorb bursty ingestion, potentially millions of events/sec at peak, without dropping data. - Data accuracy: no silent data loss; duplicate and late events are handled explicitly, not ignored. - Cost-efficient storage at a scale of petabytes, since raw event data is huge and mostly cold. - Query latency: dashboards refresh in seconds to low minutes; a one-off historical query can take longer. ## Estimates Assume 1 billion events a day from a mid-size product's tracking code. - **Events/sec:** 1,000,000,000 / 86,400 ≈ 11,600/sec average, peaking around 10x during a launch or a flash sale, so roughly 116,000/sec. - **Event size:** about 500 bytes each (event name, user ID, timestamp, properties), so 1B × 500 bytes = 500 GB/day raw. - **Storage over a year:** 500 GB/day × 365 ≈ 180 TB raw. A columnar format like Parquet with compression typically shrinks that 5-10x, down to 20-35 TB compressed. That's exactly why data lakes use columnar formats instead of raw JSON for long-term storage. - **Retention tiers:** hot data (last 7-30 days, fast queries) lives in a data warehouse; cold data moves to cheap object storage, queried on demand through something like Athena or Presto. ## API ``` POST /api/v1/events (client SDK -> ingestion endpoint) body: { event_name, user_id, timestamp, properties: {...}, event_id } resp: 202 Accepted (fire-and-forget, always fast) GET /api/v1/reports/dau?from=2026-06-01&to=2026-07-01 GET /api/v1/reports/funnel?steps=signup,activate,purchase POST /api/v1/query (ad-hoc SQL against the warehouse, for analysts) ``` The ingestion endpoint has one job: respond fast. It validates shape, hands off to the pipeline, and returns `202 Accepted` without waiting for anything downstream. The client-generated `event_id` is what lets later stages dedupe. ## Data model ``` raw_events (append-only, partitioned by date + event_name) event_id uuid event_name varchar user_id bigint timestamp timestamp -- when the event occurred (client clock) ingested_at timestamp -- when we received it (server clock) properties jsonb / map -- Aggregated / rollup tables (materialized by batch or stream jobs) daily_active_users (date, count) event_counts_hourly (event_name, hour_bucket, count) funnel_results (funnel_id, date, step, user_count) ``` Two timestamps do all the work in this design: **event time** (`timestamp`, when it really happened) and **processing time** (`ingested_at`, when your pipeline saw it). Keeping both separate is exactly what makes late-arriving data solvable, covered in the deep dive below. ```knowledge-check { "questions": [ { "id": "system-design-analytics-datamodel-q1", "type": "mcq", "prompt": "Why does the raw_events table store both a timestamp (event time) and an ingested_at (processing time)?", "options": [ {"id": "a", "text": "It's redundant, only one is ever needed"}, {"id": "b", "text": "Because they can differ, especially for offline clients, and that gap is what lets late-arriving data be corrected later"}, {"id": "c", "text": "Databases require two timestamp columns by convention"}, {"id": "d", "text": "To make the table larger for compression testing"} ], "correct": "b", "explanation": "A mobile client can queue an event offline for hours before sending it. Keeping event time separate from processing time lets a batch job later fold that late event into the correct time bucket." } ] } ``` ## High-level design ``` Client SDKs / Services | v Ingestion API (stateless, horizontally scaled) | v Event Stream (Kafka / Kinesis) -- partitioned by user_id or event_name | +-----------------------------+ v v Stream Processor Batch Processor (Flink/Kafka Streams) (Spark, scheduled hourly/daily) -> real-time rollups -> full re-aggregation, corrections | | v v Real-time OLAP store Data Lake (S3, Parquet) --> Data Warehouse (Redshift/BigQuery/Snowflake) (Druid/ClickHouse) | | v v Ad-hoc query engine (Presto/Athena) Live Dashboards ``` The ingestion API writes straight to the stream, the same "accept now, process later" pattern as a notification service. The stream is a durable buffer that absorbs bursts and lets independent consumers, both real-time and batch, read the same data without stepping on each other. Picture two workers reading the same firehose at different speeds. The **stream processor** produces approximate, low-latency numbers ("events in the last 5 minutes") for live dashboards, trading perfect completeness for speed. The **batch processor** runs on a schedule over the full data lake, recomputing exact numbers including anything that arrived late, trading speed for correctness. Running both together is called a **Lambda architecture**. ## Deep dives ### How does the pipeline handle data that arrives late? A mobile client can queue events offline and send them hours or days later, so the event's `timestamp` looks old even though `ingested_at` is now. Stream processors use a **watermark**: an estimate of "we've probably seen everything up to this point in event time." Aggregation windows stay open a bit past their nominal end to admit slightly-late data before finalizing. But some data arrives later than even a generous watermark allows, so the nightly or hourly **batch job re-aggregates from the immutable raw data lake** using event time, folding in anything that missed the stream's window. This is exactly why keeping raw, replayable data is non-negotiable, and why real-time dashboard numbers should be labeled "approximate, subject to revision." > **Remember:** real-time numbers are a fast, approximate guess; the batch job is the source of truth that corrects it later. That's not a bug, it's the design. ```knowledge-check { "questions": [ { "id": "system-design-analytics-latedata-q1", "type": "mcq", "prompt": "Why might a real-time dashboard show a slightly different number than the official report generated the next day?", "options": [ {"id": "a", "text": "This means something is broken in the pipeline"}, {"id": "b", "text": "The real-time number is an approximate, bounded-watermark estimate, while the batch job recomputes from complete data including late arrivals"}, {"id": "c", "text": "Real-time dashboards always overcount events"}, {"id": "d", "text": "The two numbers should always match exactly"} ], "correct": "b", "explanation": "This is expected Lambda-architecture behavior. Labeling the real-time number as approximate sets the right expectation instead of treating the discrepancy as a bug." } ] } ``` ### Data lake vs. data warehouse: where does data actually live? | | Data lake (S3 + Parquet) | Data warehouse (Redshift/BigQuery/Snowflake) | |---|---|---| | Schema | Schema-on-read, flexible | Schema-on-write, structured | | Cost | Cheap per GB | More expensive, optimized for query speed | | Use case | Raw archive, ML training data, exploration | Fast structured queries, BI dashboards | | Query engine | Presto/Athena/Spark, pay per query | Built-in, columnar, indexed | The typical pattern: land raw events in the cheap, durable, replayable data lake first, then load structured or pre-aggregated subsets into the warehouse for fast dashboard queries. Don't pipe a raw, high-cardinality event stream directly into an expensive warehouse; pre-aggregate first. ### Deep dive: adding A/B testing on top of the pipeline A/B testing doesn't need its own pipeline, it rides on the analytics pipeline you just built, and it's a common follow-up: "how would you know if a change actually helped?" An A/B test splits users into a control group (current experience) and a treatment group (the change), then compares a target metric between them to see whether the change actually caused a difference, not just correlated with one. **A worked example.** You test a redesigned checkout button against conversion rate: 100,000 users see the old button, 100,000 see the new one. Over the test window, 8,200 of the control group check out (8.2%) versus 8,600 of the treatment group (8.6%), a 0.4 percentage-point lift, about 4.9% relative. Before calling it a win, ask two questions. **Is this real or noise?** A significance test on those two proportions gives a p-value; below your threshold (commonly 0.05) means the gap probably isn't random chance in who got assigned where. **Is it big enough to matter?** A statistically real 0.4-point lift might still be too small to justify shipping it, or it might be exactly the kind of small, compounding win worth taking. Report the actual effect size alongside the p-value, not just "significant: yes or no." Then check guardrails. Suppose the new button's heavier animation library added 200ms to page load in the treatment group. Even with a clean conversion win, that's a real cost the conversion number alone would never show you, which is why a test is never judged on one metric. **Assigning users consistently.** Almost always assign by user ID, hashed into a bucket, not by session or request. A user should see the same experience every visit, or the test ends up measuring confusion instead of the real change: `hash(user_id + experiment_name) % 100`. This is deterministic, so you don't need to store an assignment per user anywhere. **Sample size and duration.** Compute the minimum sample size needed to detect the smallest effect worth caring about, before launching, given a target statistical power (commonly 80%) and significance level (commonly 5%). A one-week minimum is common even once you hit that sample size, to average out weekday-vs-weekend behavior. **Primary metric vs. guardrail metrics.** Pick one primary metric the test is meant to move, and a small set of guardrails that must not regress, like page load time or error rate. A test can win on its primary metric while quietly breaking something else, exactly like the page-load example above. **How it fits the architecture:** ``` User request | v Experiment Assignment Service <--> Experiment Config Store (which experiments are live, split %) | v (bucket: control | treatment, deterministic via hashed user_id) Application serves the appropriate variant | v Event Logging (impressions + downstream metric events) --> Analytics Pipeline --> Dashboard ``` Assignment sits on the critical path of every request touched by an experiment, so it's a local hash computation, not a network call, with experiment configs cached on app servers rather than fetched per request. Every metric event needs to carry which variant the user was in at the time, logged alongside the business event so analysis can be re-sliced later by platform or region without rerunning the experiment. **Common pitfalls to name.** **Peeking:** checking results repeatedly and stopping the moment they look significant inflates the false-positive rate, since every peek is another chance to catch a random fluctuation. Decide the duration in advance. **Novelty effect:** a change can perform well simply because it's new, with the effect fading over time; a too-short test mistakes this for a durable win. **Sample ratio mismatch:** if the actual observed split (say 96,000/104,000 instead of roughly 100,000/100,000) deviates meaningfully from the intended split, something is broken in assignment or logging, and no other result from that test should be trusted until it's root-caused. ```knowledge-check { "questions": [ { "id": "system-design-analytics-abtesting-q1", "type": "mcq", "prompt": "Why is a statistically significant result not automatically a reason to ship a change?", "options": [ {"id": "a", "text": "Statistical significance is meaningless in A/B testing"}, {"id": "b", "text": "A real but tiny effect might not be worth the engineering cost, and a guardrail metric like page load time could have regressed"}, {"id": "c", "text": "Significant results are always false positives"}, {"id": "d", "text": "You should only ever look at the p-value, never the effect size"} ], "correct": "b", "explanation": "A test result needs both a real effect size worth acting on and a check that no guardrail metric quietly got worse, not just a pass/fail significance label." } ] } ``` ## Trade-offs and follow-up questions **Throughput vs. latency.** Batching writes into the warehouse in micro-batches trades a few seconds of delay for much higher write throughput and lower cost than inserting row by row. **Exactly-once vs. at-least-once.** True end-to-end exactly-once is hard to achieve. Most pipelines use at-least-once ingestion plus idempotent aggregation, deduping on `event_id`, to get effectively-once results. **Cardinality control.** An unbounded `properties` field, where clients can send any key they want, can blow up storage and indexing cost. Enforce a schema registry or an allowlist of properties for high-volume events. **Q: How do you avoid double-counting an event a flaky client sent twice?** A: The client generates a UUID `event_id` per event. Downstream dedup, a Redis set with a TTL on the stream path, or a merge-on-insert on the batch path, drops repeats. Aggregation counts distinct `event_id`s, not raw rows. **Q: How would you support ad-hoc analyst queries without one bad query taking down the pipeline?** A: Isolate query compute from ingestion compute entirely. Analysts query through a separate engine (Presto, Athena, BigQuery) with its own resource limits, never touching Kafka or the stream processors. Add query timeouts and row-scan limits. ```knowledge-check { "questions": [ { "id": "system-design-analytics-tradeoffs-q1", "type": "mcq", "prompt": "Why should analyst ad-hoc SQL queries run through a separate query engine rather than against the live ingestion pipeline?", "options": [ {"id": "a", "text": "Analysts don't need SQL access at all"}, {"id": "b", "text": "A single expensive or badly written query could otherwise degrade or take down the ingestion path that every other consumer depends on"}, {"id": "c", "text": "Separate engines are always cheaper"}, {"id": "d", "text": "It has no real benefit, it's just convention"} ], "correct": "b", "explanation": "Isolating query compute from ingestion compute means one bad analyst query can be capped with a timeout without ever threatening the pipeline that every dashboard and downstream job relies on." } ] } ``` 5c:T34f0,Multi-tenancy means one system serves many customers (tenants), each believing they have the product to themselves. Picture an apartment building: every tenant has their own locked unit, but they share the same plumbing, elevators, and foundation. Get the isolation wrong and one tenant can see another's data, which is the single biggest incident category in B2B SaaS. This question is less "draw a diagram" and more "reason about isolation, cost, and blast radius at the same time." ## Requirements **Functional requirements** - Each tenant's data is isolated; one tenant must never see another's records. - Per-tenant billing based on usage: seats, API calls, storage. - Tenant admins manage their own users and roles, scoped only to their own tenant. - Tenant-specific customization: branding, feature flags, custom fields. **Non-functional requirements** - Security and isolation: a bug or a bad query must never leak data across tenants. - Performance: one noisy, high-volume tenant must not slow down everyone else (the "noisy neighbor" problem). - Operational simplicity: migrations, backups, and scaling should work the same way no matter how many tenants exist. - Fast onboarding: adding a new tenant should take seconds, not days. Before you design anything, ask a few clarifying questions: how many tenants, and how fast is that number growing? Does any tenant's data need to stay in a specific region for compliance? Will tiny self-serve tenants and huge enterprise tenants coexist? Is this greenfield, or does an existing single-tenant system need to migrate? The answers change which model below is right. ## The three tenancy models **Pool: shared database, shared schema.** Every table has a `tenant_id` column, and every tenant's rows live in the same tables. Cheapest to run, simplest to operate, and the fastest to onboard a new tenant (just insert a row). The risk: isolation depends entirely on every query remembering to filter by `tenant_id`. Miss one `WHERE tenant_id = ?` and you have a cross-tenant leak. **Bridge: shared database, separate schema per tenant.** One database instance, but each tenant gets its own schema namespace, like `tenant_123.users` versus `tenant_456.users`. Stronger isolation than Pool, since a schema-scoped connection literally cannot see another tenant's tables, but migrations now have to run once per schema, and schema count becomes a real management burden past a few thousand tenants. **Silo: separate database per tenant.** Each tenant gets a fully independent database, sometimes even a dedicated instance for the biggest ones. This is the strongest isolation: a query physically cannot reach another tenant's data. It's also the most expensive, since idle capacity is paid per tenant, and migrations must run across every tenant database. > **Remember:** Pool is cheap and fast to onboard, Silo is expensive but bulletproof, Bridge sits in between. Most real SaaS products use a hybrid: Pool for most tenants, Silo as a premium tier for the ones who need it. ```knowledge-check { "questions": [ { "id": "system-design-saas-tenancy-q1", "type": "mcq", "prompt": "What is the main risk of the Pool model (shared database, shared schema, tenant_id column)?", "options": [ {"id": "a", "text": "It is too expensive to run for most companies"}, {"id": "b", "text": "Isolation depends on every query correctly filtering by tenant_id, so one missed filter is a cross-tenant data leak"}, {"id": "c", "text": "It cannot support more than 100 tenants"}, {"id": "d", "text": "It requires a separate database per tenant"} ], "correct": "b", "explanation": "Because every tenant's rows sit in the same tables, correctness depends on application code remembering the tenant_id filter every single time, which is exactly why database-level enforcement matters." } ] } ``` **How to decide.** Ask yourself: if tenant A's data leaked into tenant B's response, would that ever be acceptable? A hard no, common in finance, health, or education, pulls you toward Silo or Bridge. A low-stakes, unlikely leak allows Pool with strong safeguards. Then narrow further: compliance and data-residency rules push toward Silo/Bridge; many small tenants push toward Pool, since per-tenant overhead becomes unaffordable at volume; a handful of large enterprise tenants with real noisy-neighbor risk push toward Silo/Bridge; a mix of tiny and huge tenants is the classic hybrid signal, pool the small ones, dedicate a schema or database for the large ones. ## Estimates Assume 10,000 tenants averaging 50 users each, 500,000 users total. In a shared schema, one well-indexed table, with `tenant_id` as the leading column of every composite index, comfortably holds 100 million rows as long as every query filters by tenant first. Once a single table crosses tens of millions of rows, partition it by `tenant_id` hash or range, so a large tenant's data and a small tenant's data don't fight over the same index pages. For the largest 1% of tenants by volume, route them to a dedicated shard while the long tail of small tenants stays in the shared pool. Slack and Shopify both run this pattern in production. ## Data model ``` tenants id bigint PK name varchar plan enum(free, pro, enterprise) created_at timestamp users id bigint PK tenant_id bigint INDEX (leading column in composite indexes) email varchar role varchar -- every tenant-scoped table follows this shape: resources id bigint PK tenant_id bigint INDEX ... UNIQUE (tenant_id, some_natural_key) -- uniqueness is scoped per tenant, not global ``` Never trust isolation to application code alone. Enforce it at the database layer with Postgres Row-Level Security: ```sql ALTER TABLE resources ENABLE ROW LEVEL SECURITY; CREATE POLICY tenant_isolation ON resources USING (tenant_id = current_setting('app.tenant_id')::bigint); -- every connection, set once per request: SET app.tenant_id = '123'; ``` With this policy in place, even a developer who forgets the `WHERE tenant_id = ?` clause still can't read another tenant's rows. The database enforces it regardless of what the application code does. ## High-level design ``` Client --> API Gateway --> Auth Middleware (resolves tenant_id from JWT/subdomain) | v Application Servers (stateless) | SET app.tenant_id = X (per-request, before any query) | v Shared DB (RLS-enforced) <--- for most tenants | Dedicated DB <--- for enterprise/compliance tenants (routed separately) ``` Tenant identity usually comes from the subdomain (`acme.mindforge.com`), a custom domain mapping, or a claim in the auth token. Resolve it once, at the edge, and carry it through every downstream call. Never re-derive it deeper in the request. ## Deep dives ### How does the application layer keep tenant identity straight, request after request? The same pattern shows up under different names in every framework, and it's worth naming explicitly since this is exactly where isolation bugs happen in practice: 1. **Resolve the tenant early**, at the edge: subdomain, custom domain, or a JWT claim. 2. **Attach it to request-scoped context**, not a global variable. In Django this is middleware storing it somewhere request-scoped; in FastAPI it's a dependency that resolves the tenant per request. 3. **Every database session picks it up from there.** For Pool, every query is filtered by the resolved `tenant_id`, backstopped by Row-Level Security. For Bridge, the connection's schema is switched to that tenant's schema before any query runs. 4. **Clear the context when the request finishes**, in a teardown step. A pooled worker reused across requests, common in Gunicorn or Uvicorn, can leak a stale tenant into the next unrelated request if this step is skipped. That's the same bug class as forgetting to reset thread-local state in any pooled-worker framework. > **Remember:** the isolation bug that actually happens in production isn't a missing WHERE clause, it's a stale tenant ID left over from a reused worker. Always clear context in a teardown step. ```knowledge-check { "questions": [ { "id": "system-design-saas-context-q1", "type": "mcq", "prompt": "What real bug can happen if a pooled worker (reused across requests) never clears the resolved tenant_id after a request finishes?", "options": [ {"id": "a", "text": "Nothing, workers are always isolated per request automatically"}, {"id": "b", "text": "A stale tenant_id can leak into the next unrelated request handled by that same worker"}, {"id": "c", "text": "The database connection pool will run out of connections"}, {"id": "d", "text": "The server will crash immediately"} ], "correct": "b", "explanation": "Because pooled workers are reused, tenant context set on one request can silently carry over to the next if it isn't cleared in a teardown step, causing a real cross-tenant bug." } ] } ``` ### How does RBAC work when roles are per-tenant? Roles are scoped to a tenant: `(tenant_id, user_id, role)`. The same person can be an admin in one organization and a regular member in another, common for a contractor working across multiple customer accounts. Within a tenant, roles are usually multi-level (system admin, org admin, user, sub-user), not just a flat admin-or-member split. Your own internal support staff need a separate, explicitly audited "platform admin" role that bypasses normal tenant scoping. Every access through that role should be logged, since it's the highest-risk isolation bypass by design. ### How do you support per-tenant customization without a schema migration every time? Store branding and settings as a `tenant_settings` JSONB blob keyed by `tenant_id`, so a new setting never needs a migration. For custom fields on a business entity, a `custom_fields jsonb` column on the base table is usually the pragmatic choice; add a GIN index if a tenant needs those fields to be efficiently searchable, or move that tenant to a dedicated search index if the volume justifies it. Feature flags per tenant work the same way: a `tenant_features` table, or a flag service, lets you roll a feature out to specific tenants without a deploy. Keep the underlying business logic tenant-agnostic and push what actually varies into data: config rows, JSONB, flags. A codebase forked per customer does not scale; a config-driven core does. ## Trade-offs and follow-up questions Isolation is a spectrum, not a binary choice: an RLS-enforced shared schema is good enough for most B2B SaaS, and a dedicated database is what you sell as a premium or compliance tier. Even within a shared schema, mitigate noisy neighbors with per-tenant query timeouts, connection pool limits, and rate limiting at the gateway keyed by `tenant_id`. Backups follow the same split: shared schema means one backup covers everyone, simple, but a restore touches every tenant; a dedicated database gives one tenant its own backup and restore granularity. A regulated tenant, health, finance, or education, or one bound to a specific region, can force Silo or Bridge for that single tenant regardless of what the rest of the platform uses, and usually also needs per-tenant audit logging. That's worth naming if asked "when would you not use shared schema even at small scale?" **Q: How do you guarantee a bug in application code can never leak one tenant's data to another?** A: Don't rely on every developer remembering the `WHERE tenant_id = ?` clause. Enforce isolation at the database layer with Row-Level Security tied to a session variable set once per request, so even a forgotten filter is still constrained by the database. **Q: A single large enterprise tenant is generating 10x the query load of everyone else. What do you do?** A: Spot it through per-tenant query metrics, then migrate that tenant to a dedicated database with an online migration: copy their rows, verify counts match, cut over traffic. Offer dedicated infrastructure as a paid tier for tenants that outgrow the shared pool. **Q: How would you support custom fields per tenant without a migration every time?** A: A `custom_fields jsonb` column on the base tables. Add a GIN index if it needs to be efficiently queryable, or move that tenant to a search index if the volume justifies the extra complexity. ```knowledge-check { "questions": [ { "id": "system-design-saas-tradeoffs-q1", "type": "mcq", "prompt": "Why would a regulated tenant (health, finance) sometimes force a Silo model even if the rest of the platform uses Pool?", "options": [ {"id": "a", "text": "Regulated tenants always pay more, so they get a nicer database"}, {"id": "b", "text": "Legal or data-residency requirements can mandate stronger isolation and audit logging for that specific tenant"}, {"id": "c", "text": "Pool cannot technically support regulated industries at all"}, {"id": "d", "text": "This never actually happens in practice"} ], "correct": "b", "explanation": "Compliance obligations are a real constraint that can override the platform's default tenancy model for one specific tenant, regardless of scale." } ] } ``` 5d:T408d,A social feed shows you posts from people you follow, roughly newest first. This is the classic "design Facebook/Instagram/Twitter" question, and it's asked constantly because it forces one real decision under conflicting constraints: reads vastly outnumber writes, feed loads must feel instant, and "who sees what, in what order" is both a product problem and an engineering one. Whichever platform the interviewer names, the design underneath is the same, so this lesson covers the general feed and then the extra pieces (search, viral spikes, explicit sharding) that show up once the interviewer says "at Twitter scale." ## Requirements **Functional requirements** - Users post text, image, or video content, up to some length limit. - Users follow other users. - A user's home feed shows posts from people they follow, roughly newest-first. - Users can like, comment, and (for Twitter-style feeds) retweet. - The feed supports infinite scroll. - Search posts by keyword or hashtag, and show trending topics (Twitter-specific). **Non-functional requirements** - Read-heavy: feed reads happen orders of magnitude more often than posts are written. - Feed load latency under 200ms for the first page. - Eventual consistency is fine for counts (a like count lagging a second is okay); a post disappearing is not. - High availability over strict consistency: a slightly stale feed beats an error page. - The system must survive a single post or account going viral without degrading for everyone else. > **Remember:** the read:write ratio is the number that should drive almost every choice in this design: aggressive caching, precomputed feeds, and read replicas all exist because of it. ```knowledge-check { "questions": [ { "id": "system-design-feed-requirements-q1", "type": "mcq", "prompt": "Why does a social feed favor availability over strict consistency?", "options": [ {"id": "a", "text": "Consistency is impossible to achieve at any scale"}, {"id": "b", "text": "A slightly stale feed or like count is a minor UX issue, while an error page loses the user entirely"}, {"id": "c", "text": "Feeds never need to be correct"}, {"id": "d", "text": "Availability and consistency are the same thing"} ], "correct": "b", "explanation": "The cost of showing a feed that's a few seconds behind is tiny compared to the cost of the feed failing to load at all, so the design deliberately accepts eventual consistency." } ] } ``` ## Estimates Assume 200 million daily active users, each posting rarely but reading often. - **Posts/day:** if 5% of DAU post daily, that's 10M posts/day, about 116/sec average, 350/sec at peak. - **Feed reads/day:** each DAU opens the feed about 10 times/day, so 2B reads/day, about 23,000/sec average, 70,000/sec at peak. - **Read:write ratio:** roughly 200:1. This one number justifies nearly every design choice below. - **Follower spread:** most users have a few hundred follows; a celebrity might have 50 million followers. This spread, not the average, is what creates the "celebrity problem" covered in the deep dive. - **Storage:** 10M posts/day × 1 KB of metadata ≈ 10 GB/day. Media goes to blob storage and a CDN, not the database, and easily dwarfs the metadata by 100x. At Twitter's larger, published scale (300M DAU, 500M tweets/day), the fan-out multiplier matters more than the raw numbers: one tweet from a 50-million-follower account, if pushed to every follower's timeline, is 50 million writes from a single post. That single fact is why celebrity accounts need special handling, not just more servers. ## API ``` POST /posts { text, media_urls[] } -> { post_id, created_at } GET /feed?cursor=&limit=20 -> { posts[], next_cursor } POST /posts/{id}/like -> { like_count } POST /posts/{id}/comments { text } -> { comment_id } GET /posts/{id}/comments?cursor= -> { comments[], next_cursor } POST /follows { target_user_id } GET /search?q=&cursor= -> { posts[], next_cursor } GET /trending?region= ``` Use cursor-based pagination, not offset-based. `OFFSET 50000` forces the database to scan and discard 50,000 rows, and it breaks under concurrent inserts, since items shift between pages while someone's scrolling. The cursor is just the last-seen post's `(created_at, post_id)`, encoded opaquely. ## Data model ``` users id, username, follower_count, following_count posts id (snowflake), author_id, text, media_urls, created_at follows follower_id, followee_id, created_at PK(follower_id, followee_id) likes post_id, user_id, created_at PK(post_id, user_id) comments id, post_id, author_id, text, created_at -- the precomputed feed (fan-out on write), keyed for fast range reads feed_items user_id, post_id, author_id, created_at -- one row per (feed owner, post) PK(user_id, created_at, post_id) -- sorted for cheap pagination -- search index, a separate system, never the primary DB post_search post_id, tokens[], author_id, created_at, engagement_score ``` `feed_items` is a denormalized, per-user timeline: one row for every post that should appear in a given user's feed. A Redis sorted set (`ZADD feed:{user_id} {timestamp} {post_id}`) or a wide-column store like Cassandra fits this pattern better than a relational table, since the access pattern is simple range reads by `user_id` at high write volume. At Twitter scale, use a **Snowflake-style ID** for posts: timestamp bits, shard bits, and a sequence number packed into one integer. This gives you globally unique, roughly time-sortable IDs with no single point of contention, and the ID itself tells you which shard to route to. ```knowledge-check { "questions": [ { "id": "system-design-feed-datamodel-q1", "type": "mcq", "prompt": "Why use a Snowflake-style ID instead of a simple auto-increment column for posts at Twitter scale?", "options": [ {"id": "a", "text": "Auto-increment IDs take up more storage"}, {"id": "b", "text": "It avoids a single point of contention, stays roughly time-sortable, and encodes shard routing directly in the ID"}, {"id": "c", "text": "Snowflake IDs are required by every relational database"}, {"id": "d", "text": "Auto-increment cannot generate unique values across multiple servers under any circumstances"} ], "correct": "b", "explanation": "A single auto-increment counter becomes a bottleneck and a single point of failure once many servers are writing concurrently; a Snowflake ID solves both problems and adds shard routing for free." } ] } ``` ## High-level design ``` Post service --> writes post to Posts DB --> publishes "post_created" event | Fan-out worker (async) | looks up follower list, pushes post_id into each follower's feed_items (Redis sorted set / Cassandra) — SKIPPED for celebrity accounts Feed read path: Client --> Feed API --> read feed_items[user_id] (Redis) --> hydrate post details from Post cache (Redis) / Posts DB --> merge in real-time query for celebrity follows the user has --> return page ``` At larger scale, add a search indexer and a trending aggregator reading off the same "post_created" event: ``` +-------------------------+--+----------------------+ | | | Fan-out worker Search indexer (async) Trending aggregator (skips celebrities) (tokenize, push to (sliding-window Elasticsearch) count of hashtags) ``` ## Deep dives ### Fan-out on write vs. fan-out on read: the core decision **Fan-out on write (push):** the moment a user posts, immediately push it into every follower's precomputed feed. A feed read becomes one cheap lookup. This wins for the common case, a user with a normal follower count, because it moves cost to write time, which is rare, and keeps reads, which happen roughly 200 times more often, fast. **Fan-out on read (pull):** a feed read dynamically queries "give me recent posts from everyone I follow" and merges on the fly. No write amplification, but every read is now an expensive fan-in query across hundreds of relationships. **The hybrid, what production systems actually run:** fan-out on write for normal users, and for celebrity or high-follower accounts (say, above 100,000 followers), skip the fan-out entirely, since pushing one post to 50 million `feed_items` rows is a write storm. Instead, merge their posts into the feed at read time: fetch the precomputed feed, separately check "any new posts from celebrities I follow" (a small, cacheable list), and interleave by timestamp. > **Remember:** fan-out on write makes reads cheap and writes expensive; fan-out on read is the reverse. The hybrid picks whichever is cheap for each account, based on follower count. ```knowledge-check { "questions": [ { "id": "system-design-feed-fanout-q1", "type": "mcq", "prompt": "Why do production feed systems use fan-out on read specifically for celebrity accounts, instead of applying it everywhere?", "options": [ {"id": "a", "text": "Because fan-out on read is always faster"}, {"id": "b", "text": "Because pushing one post to millions of followers' feeds at write time would be a write storm, while normal accounts have too few followers for that to matter"}, {"id": "c", "text": "Because celebrity accounts post less often"}, {"id": "d", "text": "Because fan-out on write doesn't work for text posts"} ], "correct": "b", "explanation": "The hybrid exists because the cost of fan-out on write scales with follower count. Below a threshold it's cheap; above it, it becomes a write storm that fan-out on read avoids." } ] } ``` ### What about search, trending topics, and a viral post? **Search doesn't belong in the primary transactional store.** Posts are asynchronously indexed into Elasticsearch (or a similar inverted-index engine), keyed by tokenized text, hashtags, and author. Search queries hit that index, not the posts database, which decouples search scaling (needs relevance scoring and inverted indexes) from write-path scaling (needs low-latency sharded writes). Accept a few seconds of indexing lag as the cost. **Trending topics** are a streaming aggregation problem: maintain a sliding-window count of hashtag occurrences, using something like Redis `ZINCRBY` with time-bucketed keys, or a stream processor for larger scale. Decay older buckets, so trending reflects "spiking right now," not "popular historically." Without decay, an always-popular topic (a celebrity's name) would permanently occupy the trending list. **A post going viral**, say jumping from 10,000 to 10 million impressions in minutes, stresses three layers at once. The fan-out system needs to dynamically promote the post to the read-merge path once engagement crosses a threshold, if it wasn't already there. The cache layer hits a hot-key problem, one post ID gets hammered, fixed with a local in-process cache on top of Redis or by replicating the hot key across multiple cache nodes. And like/retweet counters need to be incremented asynchronously through a counting service rather than a synchronous write per like, to avoid every fan hammering the same row lock. ### How do you shard so a post goes to the right place, and stays findable? Shard posts and `feed_items` by `author_id` (or the shard bits already embedded in a Snowflake ID), using **consistent hashing** rather than `hash(user_id) % N`. A plain modulo remaps almost every key the moment N changes; consistent hashing only remaps the keys landing in a newly added node's range, which keeps resharding cheap. This makes "get a user's own posts" cheap, at the cost of a home timeline needing posts from many authors across many shards, which is exactly why the precomputed `feed_items` table exists: it pays the cost of gathering across shards once, at fan-out time, instead of on every read. ### Two things every feed design has to handle explicitly **The cold-start problem.** A brand-new user follows nobody, so their feed is empty. Standard fixes: show trending or popular content as filler, prompt onboarding to follow suggested accounts, and backfill `feed_items` from a new followee's recent posts synchronously at follow-time, rather than waiting for the async fan-out worker. **Ranking beyond chronological.** Pure `ORDER BY created_at DESC` is simple but buries good older posts. Algorithmic ranking scores each candidate post on recency, how often you interact with that author, and engagement velocity, then reorders the same candidate set the fan-out mechanism already produced. Ranking sits on top of fan-out, it never replaces the need for a candidate set to rank in the first place. ## Trade-offs and follow-up questions | Decision | Benefit | Cost | |---|---|---| | Fan-out hybrid (push + celebrity read-merge) | Fast reads for the common case, survives celebrity posts | Two code paths to build, test, and reason about | | Feed storage in Redis sorted sets | Fast reads and writes | Memory-bound; cap feed length and evict old items | | Shard by author_id with consistent hashing | Cheap "user's own posts" queries, cheap resharding | Home timeline needs the precomputed fan-out table to avoid a scatter-gather query | | Separate search index (Elasticsearch) | Search scales independently of the write path | Indexing lag of a few seconds; two systems to keep in sync | | Async counters for likes/retweets | Survives hot-row contention during a viral spike | Counts are eventually consistent, briefly stale under load | **Q: A user with 50 million followers posts. Walk through what happens differently than for a normal user.** A: The fan-out worker sees the follower count cross the threshold and skips the per-follower push entirely. The post is written once to the posts database and cache. Every follower's feed read does a lightweight merge: fetch their precomputed feed, separately check "recent posts from celebrities I follow," and interleave by timestamp. **Q: How do you handle a user unfollowing someone right after a big fan-out just happened?** A: The precomputed feed already has that author's recent posts in it. Either lazily filter them at read time by checking current follow status, or accept a short staleness window. Most products accept a few minutes of staleness here rather than pay for a full feed purge, since it's a minor visual glitch, not a correctness bug. **Q: A post gets deleted. What has to happen across the system?** A: The primary row is soft-deleted, not removed immediately, for audit and moderation. A deletion event propagates asynchronously to the search index (removed), the fan-out feed items (lazily filtered at read time, since deletes are rare relative to reads), and any cached copies (invalidated by post ID). **Q: How do you shard so that adding capacity later doesn't mean moving all the data?** A: Consistent hashing instead of a plain modulo. Only the keys landing in the newly added node's range get remapped, which minimizes data movement during a reshard. ```knowledge-check { "questions": [ { "id": "system-design-feed-tradeoffs-q1", "type": "mcq", "prompt": "What is the practical cost of using consistent hashing instead of hash(user_id) % N for sharding?", "options": [ {"id": "a", "text": "There is no cost, it is strictly better in every way"}, {"id": "b", "text": "It adds some implementation complexity (a hash ring or virtual nodes) in exchange for only remapping a small fraction of keys when the shard count changes"}, {"id": "c", "text": "It makes reads slower than a plain modulo"}, {"id": "d", "text": "It only works for numeric keys"} ], "correct": "b", "explanation": "Consistent hashing trades a bit of extra implementation complexity for dramatically less data movement during a reshard, which is exactly the property that matters at scale." } ] } ``` 5e:T2eb1,Autocomplete (typeahead) shows suggestions as you type, like Google guessing "pizza near me" after you type "piz". It's a favorite interview question because it's small enough to fully design in 45 minutes, yet it touches a real data structure (the trie), a ranking problem, and a hard latency limit: it fires on almost every keystroke, so it has to be fast. ## Requirements **Functional requirements** - As a user types a prefix, return the top-K most relevant completions. - Suggestions reflect how popular a query has actually been. - Suggestions update as new searches come in; they aren't frozen forever. **Non-functional requirements** - Latency under 100ms per keystroke, ideally under 50ms. This is a hard UX limit, not a nice-to-have. - Very high read volume, since it fires on nearly every keystroke of every active user. - Freshness: a trending query should surface within minutes to hours, not wait for a full daily rebuild. - Availability over strict consistency: a slightly stale suggestion list beats a slow or failed one. > **Remember:** autocomplete has to be fast enough that the user never notices it's a network call at all. That single constraint is what rules out "just query the database" as an answer. ```knowledge-check { "questions": [ { "id": "system-design-autocomplete-requirements-q1", "type": "mcq", "prompt": "Why is a sub-100ms latency requirement unusually strict for autocomplete compared to most other API endpoints?", "options": [ {"id": "a", "text": "It isn't strict, 100ms is a normal API latency target"}, {"id": "b", "text": "Because it fires on nearly every keystroke, so any lag is immediately visible to the user as the UI feels laggy"}, {"id": "c", "text": "Because databases cannot respond faster than 100ms"}, {"id": "d", "text": "Because autocomplete only runs once per search"} ], "correct": "b", "explanation": "Unlike a page load that happens once, autocomplete requests fire continuously as someone types, so any lag compounds into a visibly sluggish experience." } ] } ``` ## Estimates Assume a search product with 500 million searches a day, and each typed query averages about 20 characters, meaning roughly 20 potential autocomplete requests per search. - **Raw keystroke events:** 500M × 20 = 10 billion/day, about 116,000/sec average. Client-side debouncing, only firing after a short pause or every few characters, cuts this 5-10x in practice, still tens of thousands of requests per second. - **Unique query space:** assume 100 million unique query strings, about 20 bytes each, 2 GB of raw text. Small enough to fit an entire trie, or a precomputed top-K table, in memory. - **Update volume:** roughly 500M query events a day need to feed back into rankings, but this can be batched (hourly, say) rather than applied instantly. The number that matters most: query *volume* is enormous, but the unique query *space* is small enough to precompute and hold entirely in memory. That gap between "huge traffic" and "small unique data" is what makes this design possible. ## API ``` GET /autocomplete?prefix=piz&limit=10 -> { suggestions: ["pizza near me", "pizza hut", "pizza recipe", ...] } ``` That's essentially the whole external contract. Every bit of complexity lives in how the backend serves this fast and keeps it fresh, which is what the rest of this lesson covers. ## Data model The serving structure is a **trie**: a tree where each node represents one character, so walking from the root spells out a prefix. Picture climbing a tree letter by letter, "p" then "i" then "z", and each branch you take narrows down to fewer and fewer matching words. Each node also caches its own top-K most frequent completions, so a lookup never has to explore the rest of the tree below it. ``` TrieNode children: map[char]TrieNode top_k: [(query_string, frequency)] -- precomputed, sorted desc, size K (e.g., 10) ``` The trie is rebuilt from a source-of-truth table that tracks how often each query has actually been searched: ``` query_frequency query_text TEXT count BIGINT last_seen TIMESTAMPTZ PRIMARY KEY (query_text) ``` ## High-level design ``` Search logs / query events --> Aggregation job (batch, e.g. hourly Spark/Flink job) | updates query_frequency counts | Trie builder job --> builds new trie snapshot | pushes snapshot to Trie-serving nodes (in-memory, sharded by prefix) | Client keystroke --> Autocomplete API --> route to shard owning this prefix --> return top_k --> (cache hot prefixes in a CDN/edge cache too) ``` Search activity feeds a batch job that periodically recomputes frequency counts, a separate job builds a fresh trie snapshot from those counts, and that snapshot gets pushed out to the servers actually answering requests. The path a user's keystroke takes is short and entirely in-memory: hit the API, route to the shard that owns this prefix, return the cached top-K. ## Deep dives ### Why does every trie node precompute its own top-K, instead of ranking at query time? This is the single most important decision in the whole design. A naive trie lookup walks down to the prefix's node, then explores the entire subtree below it to collect and rank every possible completion. For a short, common prefix like "a" or "th", that subtree can hold millions of words, and ranking all of them at request time blows straight through your latency budget. The fix: do that ranking once, offline, while building the trie, and cache the answer directly on the node. A query then costs O(prefix length) to walk down to the right node, plus O(1) to return the cached list. No live ranking, no subtree walk, on the request path at all. > **Remember:** precomputing the top-K per node is what turns "rank millions of completions" into "look up a cached answer." Do the expensive work once, offline, not on every keystroke. ```knowledge-check { "questions": [ { "id": "system-design-autocomplete-trie-q1", "type": "mcq", "prompt": "Why can't autocomplete rank completions at query time for a short prefix like \"a\"?", "options": [ {"id": "a", "text": "Short prefixes are technically invalid input"}, {"id": "b", "text": "A short prefix can match millions of completions, and ranking all of them live would blow the latency budget"}, {"id": "c", "text": "The trie data structure cannot handle prefixes shorter than 3 characters"}, {"id": "d", "text": "Ranking at query time is actually fine and commonly done"} ], "correct": "b", "explanation": "The whole point of precomputing top-K per node is to avoid exactly this: exploring a huge subtree and ranking it within a single request's time budget." } ] } ``` ### How do you rank completions, and keep them fresh without rebuilding everything? The simplest ranking signal is raw historical frequency. A better one decays frequency over time (`score = count * decay(time_since_last_seen)`), so a query that was popular a year ago fades out while genuinely trending queries rise quickly. Personalization, boosting a user's own recent searches, is applied as a thin re-ranking step on top of the shared global top-K, not baked into the trie itself, which keeps the trie shareable across every user. Freshness is solved with two tiers, not one. The main trie snapshot rebuilds on a slower, predictable cadence, say hourly, from batched aggregated counts: cheap and consistent, but not instant. For anything spiking faster than that, like breaking news, maintain a small, separately-updated "hot" structure, a bounded count-min sketch or a simple hash map of trending terms updated in near real time, and merge it into the response at query time as an overlay on top of the trie's cached top-K. This avoids rebuilding a multi-gigabyte trie every time one query spikes, while still surfacing genuinely fast-moving trends within minutes. ### How does one server hold a query space that doesn't fit in memory? The trie needs to live entirely in RAM to hit the latency target, which means it's memory-bound, not disk-bound. Once the full query space is too big for one machine, shard the trie by the first character or two of the prefix, so different servers each hold only a slice of the structure. A request for "piz" routes to whichever shard owns prefixes starting with "p" (or "pi"), and that one shard fully answers it without needing data from anywhere else. Replicate each shard for availability and extra read throughput. When it's time to rebuild, build the new snapshot on a separate builder node and hot-swap it into the serving nodes, the in-memory equivalent of a blue/green deploy, so there's no downtime and no query pays a rebuild cost. Very short prefixes ("a", "th") are both the highest-traffic case and the least useful one, since the results are too broad to be helpful. Many products simply don't fire autocomplete until the user has typed at least two characters, which also cuts a meaningful amount of load. ## Trade-offs and follow-up questions | Choice | Benefit | Cost | |---|---|---| | Precomputed top-K per trie node | O(prefix length) query latency | Rebuild cost when frequencies change; some staleness between rebuilds | | Batch (hourly) trie rebuild | Simple, consistent, cheap | Not truly real-time, fixed by the hot-term overlay | | Sharding by prefix | Spreads load and memory across nodes | A prefix only ever needs one shard, so cross-shard queries are simply never needed | | In-memory serving | Meets the sub-100ms budget | Memory cost scales with the unique query space and must fit per shard | | Edge/CDN caching of common prefixes | Cuts backend load and latency further | Adds a small extra layer of staleness on top of the trie's own | **Q: How do you keep the trie fresh without rebuilding it constantly?** A: A two-tier approach: a periodic full rebuild (hourly, say) from batched frequency aggregation covers the stable long tail cheaply, plus a lightweight, frequently-updated trending overlay covers anything spiking faster than that cadence. The API merges both at response time. **Q: The trie for the full query space doesn't fit on one machine. What do you do?** A: Shard by prefix, first character or first two characters, so each serving node holds only a fraction of the trie. A thin routing layer sends each request to the one shard that can fully answer it. **Q: How would you personalize suggestions per user without breaking the shared trie's precomputation?** A: Keep the shared trie's top-K global and un-personalized, since that's what makes the precomputation cheap and reusable across every user. Apply personalization afterward, as a thin re-ranking step that boosts items from a small, per-user cache of recent searches. ```knowledge-check { "questions": [ { "id": "system-design-autocomplete-tradeoffs-q1", "type": "mcq", "prompt": "Why is personalization applied as a re-ranking step on top of the shared trie, instead of baking each user's history directly into the trie?", "options": [ {"id": "a", "text": "Personalization is not actually useful for autocomplete"}, {"id": "b", "text": "Baking per-user data into the trie would mean building a separate trie per user, losing the shared, cheap precomputation that makes the system fast"}, {"id": "c", "text": "Tries cannot store more than one ranking per node"}, {"id": "d", "text": "Re-ranking is always faster than precomputation"} ], "correct": "b", "explanation": "The whole design depends on one shared, precomputed structure serving every user cheaply. Personalizing the trie itself would multiply the memory and rebuild cost by the number of users." } ] } ``` 5f:T358b,Dropbox, or Google Drive, lets you upload files, sync them across devices, and share them with others. This is a genuinely different problem shape from a CRUD app or a feed: you're moving large binary data, not just database rows, and you need chunked uploads that can resume, deduplication, and a plan for when two devices edit the same file at once. ## Requirements **Functional requirements** - Upload and download files, organized into folders. - Sync changes across multiple devices automatically. - Share files and folders with other users. - Handle large files with chunked, resumable uploads. - Deduplicate identical file content across users. **Non-functional requirements** - Metadata needs fairly strong consistency: you shouldn't see a stale folder listing right after your own upload finishes. Syncing across devices can lag by a few seconds, that's fine. - Durability: essentially never lose a file, matching the "eleven nines" real object storage services target. - Availability: uploads and downloads should degrade gracefully during a partial outage, not fail outright. - Bandwidth efficiency: never re-upload bytes that haven't changed. > **Remember:** this design only works because it separates two very different problems: structured, transactional metadata (which folder a file is in) from large, immutable binary blobs (the file's actual bytes). Mixing them into one store is the mistake to avoid. ```knowledge-check { "questions": [ { "id": "system-design-filestorage-requirements-q1", "type": "mcq", "prompt": "Why is it a mistake to store a file's raw bytes in the same database as its metadata (name, folder, owner)?", "options": [ {"id": "a", "text": "It's not a mistake, this is the standard approach"}, {"id": "b", "text": "Metadata and blob storage scale along completely different axes, and mixing them prevents each from scaling on its own"}, {"id": "c", "text": "Databases cannot store binary data at all"}, {"id": "d", "text": "It would make folder listing impossible"} ], "correct": "b", "explanation": "Metadata needs fast transactional queries at moderate size; blob bytes need to scale to petabytes with completely different access patterns. Separating them lets each scale independently." } ] } ``` ## Estimates Assume 50 million users, averaging 5 GB stored each. - **Total logical storage:** 50M × 5 GB = 250 petabytes. Deduplication (many users storing the same popular files, OS images, common documents) brings the real physical number down meaningfully, but plan capacity off the logical total. - **Daily upload traffic:** if 10% of users upload something daily, averaging 10 MB each, that's 5 million uploads/day × 10 MB = 50 TB/day of new traffic. - **Chunk size:** 4 MB is a common choice: large enough that per-chunk overhead stays low, small enough that a failed chunk only costs 4 MB of re-upload, not the whole file. - **Metadata:** 50M users × roughly 10,000 files each = 500 billion file records. At about 500 bytes per record, that's 250 TB of metadata alone, which needs its own sharded, horizontally scaled store, separate from where the bytes live. ## API ``` POST /files/upload/init { filename, size, folder_id, chunk_hashes[] } -> { upload_id, chunks_needed[] } -- server tells client which chunks it doesn't already have (dedup) PUT /files/upload/{upload_id}/chunk/{chunk_index} (binary body, with chunk hash header) -> { received: true } POST /files/upload/{upload_id}/complete -> { file_id, version } GET /files/{file_id}/download -> presigned blob URL GET /folders/{folder_id} -> { files[], folders[] } POST /files/{file_id}/share { target_user_id, permission } -- sync GET /sync/changes?since_cursor= -> { changes[], next_cursor } ``` ## Data model ``` files id UUID PK owner_id UUID folder_id UUID name TEXT size BIGINT content_hash TEXT -- hash of the full file (post-reassembly), used for dedup version INT created_at, updated_at chunks hash TEXT PK -- content hash of this chunk (e.g., SHA-256) blob_key TEXT -- pointer into blob storage (S3 key) ref_count INT -- how many files reference this chunk, for safe GC size INT file_chunks file_id UUID chunk_index INT chunk_hash TEXT -- FK to chunks.hash PRIMARY KEY (file_id, chunk_index) folders id, owner_id, parent_id, name shares file_id or folder_id, owner_id, target_user_id, permission (view/edit) ``` Splitting `chunks` (content-addressed, one row per unique piece of data, keyed by its own hash) from `file_chunks` (the ordered list of which chunks make up one specific file) is the one decision that makes both resumable upload and cross-user dedup work. A chunk is stored once, no matter how many files or users point at it. ```knowledge-check { "questions": [ { "id": "system-design-filestorage-datamodel-q1", "type": "mcq", "prompt": "What does splitting chunks (content-addressed) from file_chunks (per-file ordering) enable?", "options": [ {"id": "a", "text": "It's only for organizational neatness, with no functional benefit"}, {"id": "b", "text": "It lets identical bytes be stored exactly once across every file and every user, while still tracking each file's own chunk order"}, {"id": "c", "text": "It makes uploads slower but more secure"}, {"id": "d", "text": "It removes the need for a folders table"} ], "correct": "b", "explanation": "Because a chunk is keyed by its content hash rather than by which file it belongs to, two files (or two users) that happen to share the same bytes automatically share one stored chunk." } ] } ``` ## High-level design ``` Client --> chunk the file locally, hash each chunk --> Upload API | check chunk hashes against `chunks` table (skip chunks that already exist — dedup) | upload only missing chunks --> Blob Storage (S3/GCS) | on complete: write file_chunks + files metadata (Postgres, sharded) | publish "file_changed" event --> Sync service | notifies other devices (long-poll / websocket / push) | other devices pull /sync/changes, download new chunks ``` ## Deep dives ### How does resumable upload work, and why does it come almost for free? The client splits the file into fixed-size chunks, hashes each one locally, and sends the list of hashes to `upload/init`. The server checks each hash against the `chunks` table and responds with only the ones it doesn't already have, whether from an earlier partial upload by this same client, or from another user entirely (cross-user dedup, covered next). The client uploads just those missing chunks. If the connection drops halfway through, the client simply calls `init` again on retry, and the server reports whatever chunks are still missing. Resume isn't a special protocol bolted on top, it falls naturally out of content-addressing: the server already knows exactly what it has and doesn't. ### How does deduplication actually save storage? Because chunks are stored by content hash rather than by owner or file, two different users uploading the same file, or two files sharing a common chunk like a document template, physically store that chunk exactly once. `ref_count` on the `chunks` table tracks how many `file_chunks` rows point at it, and garbage collection only deletes the underlying blob once that count hits zero. This is the single biggest storage-cost lever in the whole system: popular installers, templates, and stock assets let real physical storage land well below the logical total. > **Remember:** dedup only saves storage; it never changes who can access a file. Ownership and permissions live entirely in the metadata layer (`files`/`shares`), so sharing a chunk's bytes never leaks another user's content. ```knowledge-check { "questions": [ { "id": "system-design-filestorage-dedup-q1", "type": "mcq", "prompt": "If two different users upload the exact same file, does deduplication let User A see or access User B's copy?", "options": [ {"id": "a", "text": "Yes, dedup merges their files into one shared file"}, {"id": "b", "text": "No, only the underlying bytes are shared in blob storage. Access and ownership are enforced separately in the metadata layer"}, {"id": "c", "text": "Yes, but only if both users are in the same folder"}, {"id": "d", "text": "Deduplication is disabled whenever two different users are involved"} ], "correct": "b", "explanation": "Dedup operates purely at the storage layer to avoid keeping duplicate bytes. Each user still has their own files row, folder placement, and permissions, completely independent of who else's bytes happen to be identical." } ] } ``` ### How does sync across devices, and conflict handling, work? Each device keeps a local cursor, a token representing "the last change I've seen." On reconnect, or periodically, it calls `GET /sync/changes?since_cursor=` to pull only what changed since then, instead of re-listing the entire file tree. For near-real-time sync, a lightweight WebSocket or long-poll connection pushes a "something changed, go pull" signal, so devices don't have to poll aggressively; the actual change data still flows through the pull endpoint, keeping the protocol simple and resumable. Conflicts happen when two devices edit the same file while offline and then both reconnect. Detect this with version numbers: each device remembers the version it last synced from, and if the server's current version has moved past that when the device tries to push its own edit, that's a real conflict, not a simple fast-forward. Don't silently overwrite one edit with the other. Write both: `filename.docx` and `filename (conflicted copy from Device B, 2026-07-16).docx`, exactly what Dropbox actually does, and let the person reconcile manually. True automatic merging only works for structured, mergeable formats (like a Google Docs-style editor), not arbitrary binary files. ## Trade-offs and follow-up questions | Decision | Benefit | Cost | |---|---|---| | Content-addressed chunking | Resume and cross-user dedup come for free | Client-side hashing cost; garbage collection needs correct ref-counting | | Blob storage for bytes, database for metadata | Each layer scales on its own axis | Two systems to keep consistent: a file only "exists" once both agree | | Push notification plus pull sync | Near-real-time without constant polling | A little extra complexity running a signaling channel alongside the pull API | | Conflicted-copy resolution | Never silently loses data | Worse UX than a true merge, acceptable since true merge isn't possible for arbitrary binary files | **Q: How do you avoid re-uploading a file that a different user already uploaded?** A: Chunk hashing plus content-addressed storage. If another user's file shares identical chunks, or the whole file matches by `content_hash`, `upload/init` reports those chunks as already present and the client skips uploading them. Storage is physically shared through `ref_count`; access is still enforced entirely at the metadata layer, so dedup never leaks content between users. **Q: What if two different chunks hash to the same value but aren't actually identical?** A: Use a cryptographically strong hash like SHA-256, where a collision is astronomically unlikely, unlikely enough that essentially every production system treats a hash match as a content match. If extra caution is required, add a cheap secondary check like byte-length comparison before treating two chunks as identical. **Q: How do you delete a file without breaking other files that share its chunks through dedup?** A: Deleting a file removes its `file_chunks` rows and decrements `ref_count` on each chunk it referenced. The underlying blob is only queued for garbage collection once `ref_count` reaches zero, meaning no other file still needs it. That's exactly why ref-counting, not just tracking a file ID, is required for safe dedup-aware deletion. ```knowledge-check { "questions": [ { "id": "system-design-filestorage-tradeoffs-q1", "type": "mcq", "prompt": "Why does deleting a file only decrement a chunk's ref_count instead of deleting the chunk's bytes immediately?", "options": [ {"id": "a", "text": "Because deletes are processed asynchronously for performance reasons only"}, {"id": "b", "text": "Because other files might still reference that same chunk through dedup, and deleting it immediately would corrupt them"}, {"id": "c", "text": "Because blob storage does not support deletion"}, {"id": "d", "text": "Ref counting is unnecessary and only adds complexity"} ], "correct": "b", "explanation": "A chunk can be shared by many files across many users. Only when ref_count reaches zero is it safe to know no one else still depends on those bytes." } ] } ``` 60:T35b5,Google Docs lets many people edit the same document at once and see each other's changes appear live. This question tests distributed-systems thinking directly: how do you let several people mutate the same piece of data at the same time, over an unreliable network, and guarantee every device ends up showing the exact same final document, without a central lock freezing everyone else out? ## Requirements **Functional requirements** - Multiple users edit the same document at once and see each other's changes live. - Cursor and selection presence is visible to collaborators. - Full edit history with undo/redo, attributed to the right person. - Rich formatting (bold, headings, lists, comments), not just plain text. - Offline edits sync and merge automatically once connectivity returns. **Non-functional requirements** - Edits propagate to other viewers in under 200ms on a good network. - Every replica must converge to the identical document, no matter the order edits arrive in or how the network delayed them. - Availability over strict consistency: you should be able to keep typing even while briefly disconnected. - A document can grow to hundreds of pages; the system must never re-send the whole thing on every keystroke. > **Remember:** the interview isn't really asking "can you build a text editor," it's asking "do you know how two people's edits, arriving in different orders on different machines, still end up as the same document." That's the whole problem. ```knowledge-check { "questions": [ { "id": "system-design-googledocs-requirements-q1", "type": "mcq", "prompt": "What is the core distributed-systems problem a Google Docs-style design has to solve?", "options": [ {"id": "a", "text": "How to store text efficiently on disk"}, {"id": "b", "text": "How every client converges to the same final document even when edits arrive in different orders over an unreliable network"}, {"id": "c", "text": "How to render bold and italic text in a browser"}, {"id": "d", "text": "How to authenticate users before they can edit a document"} ], "correct": "b", "explanation": "Storage and rendering are solved problems. The genuinely hard part unique to this design is making concurrent, out-of-order edits converge to one consistent result for everyone." } ] } ``` ## Estimates Assume 1 billion total documents, with 5 million editing sessions open concurrently at peak. - An active session produces roughly one edit every half-second to a second while someone is typing, so system-wide that's on the order of 1-2 million operations/sec at peak. But what actually matters for capacity is per-document load: a single popular shared doc with 50 concurrent editors sees maybe 50-100 ops/sec, which is the number that decides how much one server needs to handle. - Each edit is tiny, 50-200 bytes (operation type, position, content, revision number), so bandwidth per keystroke is trivial. The hard part is ordering and merging, not bytes on the wire. - An average document is about 50 KB of content. Storing every historical operation forever for a billion documents is expensive, so history gets compacted into periodic snapshots over time. - Cursor and presence updates run at roughly 5 million/sec, far higher volume than content edits, but they're ephemeral: losing one doesn't matter, so they run on a separate lightweight channel from the durable edit log. ## API ``` WS /v1/docs/{doc_id}/session # persistent connection for the editing session client -> server: { op: {type, pos, content}, base_revision, client_id } server -> client: { op, revision, author_id } # broadcast to all connected clients client -> server: { type: "cursor", pos, selection } server -> client: { type: "presence", user_id, cursor } GET /v1/docs/{doc_id} # fetch latest snapshot + revision number GET /v1/docs/{doc_id}/history # revision list for undo/redo and version browsing POST /v1/docs/{doc_id}/restore body: { revision } ``` The live editing session runs over a WebSocket. REST only handles the initial document load and browsing history. ## Data model ``` Document(doc_id PK, title, owner_id, created_at, current_revision) DocSnapshot(doc_id FK, revision, content_blob, created_at) -- periodic full-state checkpoint Operation(op_id PK, doc_id FK, revision, client_id, author_id, op_type, payload, applied_at) DocumentAccess(doc_id FK, user_id FK, role[owner|editor|viewer]) Comment(comment_id PK, doc_id FK, anchor_position, author_id, text, resolved) ``` `Operation` is an append-only log. That single property is what makes undo/redo and version history possible at all: replaying operations from a snapshot up to any revision reconstructs the document exactly as it looked at that point. ## High-level design ``` [Client A] <---WS---+ +---WS---> [Client B] | | [Document Session Server] (owns in-memory state for this doc_id, single for one doc, or shard writer per document) of docs) | [Operation Transform / CRDT engine] | [Operation Log] ---async---> [Snapshot Service] | | [Presence/Cursor broadcast] [Document Store: blob storage (ephemeral, in-memory) for snapshots + metadata DB] ``` Every document is owned by exactly one Document Session Server instance at a time; consistent hashing routes every client editing that `doc_id` to the same server. Picture one referee for each document: that single referee decides the order of every edit, so you get one clean point of ordering without needing a distributed consensus vote on every keystroke. That server holds the live, in-memory state, applies incoming edits in order, resolves concurrent ones, and broadcasts the result to every connected client. The operation log is written to durable storage asynchronously, so a server crash loses at most a few hundred milliseconds of unacknowledged edits, recoverable by replaying from the last saved revision. ## Deep dives ### Operational Transformation vs. CRDTs: know both, pick one, and say why This is the heart of the interview. **Operational Transformation (OT).** Each client sends an edit relative to a known base revision. If the server already applied a different edit at that revision, it transforms the incoming edit against whatever happened in between, so it still lands correctly. If someone inserted 5 characters before your cursor position, your insert position shifts by 5 to compensate. This needs a central server to decide the canonical order, which is exactly what Google Docs actually uses. It's mature and fits naturally with a server you already need for other things (auth, presence), but the transform rules are notoriously tricky to get exactly right for every combination of operations. **CRDT (Conflict-free Replicated Data Type).** The document is represented as a structure where every insert carries a globally unique, order-preserving identifier (client ID plus a logical clock), not just a plain integer position. Merges are commutative by construction, so any order of applying edits from any replica converges to the same state, with no central server required for correctness. This works naturally offline and peer-to-peer, but the per-character metadata can bloat storage, and deleted content needs periodic cleanup. The answer worth giving out loud: "I'd use OT with a central per-document session server, because I already need a centralized server for presence, access control, and history. Since there's a natural single point of truth per document anyway, OT's server-authoritative model fits. I'd reach for a CRDT if the product needed true offline-first peer-to-peer sync with no guaranteed connection to a central server." > **Remember:** OT needs a referee (a central server); CRDTs don't need one, but pay for that freedom in extra per-character metadata. ```knowledge-check { "questions": [ { "id": "system-design-googledocs-otcrdt-q1", "type": "mcq", "prompt": "Why does Google Docs use Operational Transformation with a central server rather than a CRDT?", "options": [ {"id": "a", "text": "CRDTs cannot represent text documents"}, {"id": "b", "text": "Docs already needs a central server for presence, access control, and history, so OT's server-authoritative model fits naturally without the extra per-character metadata CRDTs require"}, {"id": "c", "text": "OT is always faster than CRDTs in every scenario"}, {"id": "d", "text": "CRDTs only work for numeric data, not text"} ], "correct": "b", "explanation": "The choice follows from the architecture: since a central point of truth already exists for other reasons, OT's simpler server-authoritative merge model is the better fit than paying CRDT's metadata overhead for a decentralization guarantee that isn't actually needed." } ] } ``` ### How does a concrete conflict actually get resolved? Two users, A and B, both start at revision 10. A inserts "cat" at position 5. B, also based on revision 10, deletes characters 3 through 7. Both edits reach the server. It applies A's insert first (now revision 11), then transforms B's delete against A's insert: since A's 3 new characters landed inside B's delete range, the transform adjusts B's delete range to account for them, producing a delete that removes the originally intended content correctly even though the document shifted underneath it. The transformed operation is applied as revision 12 and broadcast to both clients, so they converge on the same final text. ### How does undo work when other people have kept editing? A naive undo, just revert the last operation, breaks the moment someone else has edited that same region since. The standard fix is **selective undo**: transform the inverse of your own operation against everything that happened after it, using the same transform logic that resolves concurrent edits, so your undo removes only your own contribution even if the document has moved on. Undo and redo stacks are per-user, never global. ### How is history stored without keeping every keystroke forever? Take periodic snapshots, say every 500 operations or every few minutes of active editing, and keep the operation log since the last snapshot for replay and undo. Beyond a retention window, older logs get compacted away, keeping only occasional snapshots for long-term version history. Recent history stays fine-grained; old history gets coarser. ## Trade-offs and follow-up questions | Concern | Choice | Trade-off | |---|---|---| | Concurrency model | OT with a single-writer session server per document | Simple correctness story, but needs consistent-hash routing and failover if that server dies | | Merge algorithm | OT, not CRDT | Matches Google Docs' real architecture; a CRDT would suit offline-first/peer-to-peer better, at the cost of metadata overhead | | Presence and cursors | Separate ephemeral, in-memory channel | High-frequency, loss-tolerant traffic never touches the durable log | | History | Operation log plus periodic snapshots, compacted over time | Bounds storage growth while keeping recent undo fine-grained | | Offline editing | The client buffers edits locally and replays them on reconnect using the same transform logic | Works well for short disconnects; a long offline session risks a large, painful merge | **Q: The Document Session Server for a popular doc crashes mid-edit. What happens?** A: Clients detect the dropped connection, reconnect, and consistent hashing routes them to a server instance for that `doc_id`, which rehydrates by loading the latest snapshot and replaying the log since. Any unpersisted edits are gone from the log, but each client resends its own unacknowledged edits after reconnecting, so no user-visible data is lost as long as clients retry. **Q: How do you scale beyond one server per document when thousands of people are viewing the same doc, like a company all-hands?** A: Separate the read/broadcast path from the write path. Keep one authoritative writer for ordering, but have it publish accepted edits to a pub/sub layer that many read-only broadcast nodes subscribe to, so thousands of viewer connections aren't all terminating on the one server doing the transform math. **Q: How would comments fit into this model?** A: Anchor each comment to a stable position or range in the document, using the same position-transform logic as edits, so the anchor shifts correctly as surrounding text changes. Store comments in a separate table, since they have different lifecycle and permission rules than the document's own content. ```knowledge-check { "questions": [ { "id": "system-design-googledocs-tradeoffs-q1", "type": "mcq", "prompt": "Why does undo need to be a selective, per-user operation instead of simply reverting the last change made to the document?", "options": [ {"id": "a", "text": "Because undo is never actually needed in a collaborative editor"}, {"id": "b", "text": "Because another user may have edited the same region since, and blindly reverting the last change could destroy their work"}, {"id": "c", "text": "Because the document format doesn't support deletion"}, {"id": "d", "text": "Because undo only works for single-user documents"} ], "correct": "b", "explanation": "In a multi-user document, the 'last change' might not even be yours. Selective undo transforms the inverse of your own operation against everything since, so it only removes your contribution." } ] } ``` 61:T3a5f,A code review system, think GitHub or GitLab pull requests, combines several distinct problems into one product: showing a diff efficiently even for a huge repository, a multi-person approval workflow, real-time commenting, and a live connection to an external CI system whose results decide whether a merge is even allowed. This question tests whether you can break a "big product" prompt into clean service boundaries instead of one giant tangled design. ## Requirements **Functional requirements** - Submit a change (a pull or merge request) as a diff against a base branch. - Reviewers comment on specific lines, and approve or request changes. - Track review status and merge readiness: approvals, CI status, conflicts. - Integrate with CI/CD: trigger builds and tests on new commits, surface results, and gate merging on passing checks. **Non-functional requirements** - Diff computation and display must stay fast, even for large files and large repositories. - Comments and status updates should feel real-time to everyone viewing the same pull request. - Merge decisions must be consistent: a pull request should never be mergeable while it's actually missing required approvals or has failing checks, even under concurrent updates. - Must scale to many concurrent pull requests across many repositories, without one huge, busy repository slowing down a quiet one. > **Remember:** this system's hard problem is workflow correctness, not raw throughput. A code review platform handles nowhere near the traffic of a chat app, but getting "is this actually mergeable right now" wrong is a real bug, not a minor inconvenience. ```knowledge-check { "questions": [ { "id": "system-design-codereview-requirements-q1", "type": "mcq", "prompt": "What is the central hard problem in a code review system, compared to a high-traffic consumer app?", "options": [ {"id": "a", "text": "Handling millions of requests per second"}, {"id": "b", "text": "Getting workflow correctness right, like accurately knowing whether a pull request is truly mergeable at any given moment"}, {"id": "c", "text": "Storing large amounts of user-generated video content"}, {"id": "d", "text": "There is no hard problem, it's a simple CRUD app"} ], "correct": "b", "explanation": "Traffic here is modest compared to consumer-scale systems. The genuine difficulty is correctness under concurrent updates: approvals, CI status, and conflicts all have to agree before a merge is allowed." } ] } ``` ## Estimates Assume a large engineering platform: 500,000 active repositories, 2 million open pull requests at any time, and 5 million pull-request events a day (commits pushed, comments added, reviews submitted, CI updates). - **Event rate:** 5,000,000 / 86,400 ≈ 58/sec average, modest compared to the consumer-scale systems earlier in this course. - **Diff size:** most diffs are tens of lines, but the system has to survive an occasional huge one, thousands of lines or a large generated file, without falling over. This is a long-tail cost problem, not an average-cost one. - **CI trigger volume:** assuming every push triggers a run, and pushes happen about 3 times per pull request before merge, that's roughly 6 million CI triggers a day, each one potentially spinning up a build that costs far more compute than the tiny event that triggered it. CI compute cost, not request volume, is the real capacity concern. ## API ``` POST /repos/{repo}/pulls { source_branch, target_branch, title, description } -> { pr_id, diff_id } GET /pulls/{pr_id}/diff -> { files[], hunks[] } POST /pulls/{pr_id}/comments { file, line, body } -> { comment_id } POST /pulls/{pr_id}/review { verdict: "approve"|"request_changes"|"comment", body } GET /pulls/{pr_id}/status -> { approvals[], ci_status, mergeable } POST /pulls/{pr_id}/merge -> { status } POST /webhooks/ci-status { pr_id, commit_sha, status, checks[] } -- inbound from CI system ``` ## Data model ``` pull_requests id, repo_id, source_branch, target_branch, base_sha, head_sha, status (open|merged|closed), created_at commits pr_id, sha, parent_sha, pushed_at reviews id, pr_id, reviewer_id, verdict, body, commit_sha_reviewed, created_at comments id, pr_id, file_path, line_number, body, thread_id, resolved (bool), created_at ci_checks pr_id, commit_sha, check_name, status (pending|success|failure), updated_at merge_rules repo_id, required_approvals, required_checks[] ``` Every review is tied to `commit_sha_reviewed`, not just to the pull request as a whole. That detail matters: if a reviewer approves at one commit and the author pushes another commit afterward, whether that approval still counts is a policy decision the system has to make explicit, not something left implicit. ```knowledge-check { "questions": [ { "id": "system-design-codereview-datamodel-q1", "type": "mcq", "prompt": "Why does the reviews table store commit_sha_reviewed instead of just linking a review to the pull request?", "options": [ {"id": "a", "text": "It's redundant information with no real purpose"}, {"id": "b", "text": "Without it, the system couldn't answer whether an approval was given against the current head or a since-superseded commit"}, {"id": "c", "text": "Git requires every table to store a commit sha"}, {"id": "d", "text": "It's only used for display purposes in the UI"} ], "correct": "b", "explanation": "Tracking exactly which commit a review was given against is what makes it possible to enforce a staleness policy when the author pushes new commits after an approval." } ] } ``` ## High-level design ``` Author pushes commits --> Git service stores commits/refs (existing git infrastructure, not reinvented here) --> "commits_pushed" event | Diff service: compute diff between base_sha and head_sha (cached, recomputed only when either sha changes) | CI trigger --> external CI/CD system runs build/tests --> webhook POST /webhooks/ci-status --> ci_checks updated | Reviewer views PR --> Diff service (cached diff) + Comments (real-time via websocket/long-poll for collaborators viewing the same PR) + reviews | PR status aggregation: mergeable = (required_approvals met) AND (all required_checks passing) AND (no merge conflicts against target_branch) | POST /pulls/{pr_id}/merge --> re-validate mergeable at merge time (not just display time) --> perform the merge --> pr.status = merged ``` ## Deep dives ### Should diffs be stored, or computed on demand? Computed and cached, never stored as a separate copy. The source of truth is the git repository itself, its commits, trees, and blobs. The system shouldn't duplicate that. A pull request's diff is derived on demand between `base_sha` and `head_sha` using standard diff machinery, then cached by that sha pair, since the same diff gets requested repeatedly by every viewer until either side moves. This is the same "keep a durable source of truth separate from a fast derived structure" pattern that shows up in the file storage design, git is the durable source, the diff cache is the fast-read structure on top of it. For a very large file, the computation itself can get expensive, not just serving the result. Mitigate with size limits (collapse or truncate a diff past some threshold, showing "this file is too large to display inline") and by computing large diffs asynchronously, showing a "diff pending" state instead of blocking the page load. ### How do live comments work without a merge algorithm like Google Docs needs? Multiple reviewers viewing the same pull request should see new comments and status changes appear without a manual refresh, delivered over a lightweight push channel (WebSocket or server-sent events). Unlike Google Docs, comment threads don't need operational-transform-style merging: each comment is an independent, append-only entry in a thread, keyed by `file_path` plus `line_number` or a `thread_id`, so two reviewers commenting at the same time simply both succeed with nothing to reconcile. The only real requirement is timely delivery, not merging. > **Remember:** not every real-time feature needs a merge algorithm. Comments are independent append-only events; only truly shared, mutable content (like Google Docs text) needs OT or CRDTs. ```knowledge-check { "questions": [ { "id": "system-design-codereview-comments-q1", "type": "mcq", "prompt": "Why don't pull request comments need the same operational-transform merge logic that Google Docs requires?", "options": [ {"id": "a", "text": "Comments are too unimportant to bother merging correctly"}, {"id": "b", "text": "Each comment is an independent, append-only entry, so two simultaneous comments never actually conflict with each other"}, {"id": "c", "text": "Comments are never shown in real time"}, {"id": "d", "text": "WebSockets automatically handle merging for any data type"} ], "correct": "b", "explanation": "Merge algorithms exist to resolve conflicting edits to the same shared content. Comments don't have that problem: each one is its own independent row, so there's nothing to reconcile." } ] } ``` ### How does the CI/CD gate actually work, and what happens when approvals go stale? The review system never runs builds itself. It triggers an external CI system on new commits and later receives an asynchronous status update through `POST /webhooks/ci-status`, updating the `ci_checks` table. This is a fire-and-forget trigger with a callback arriving later, since CI runs can take anywhere from seconds to tens of minutes. `mergeable` is computed by checking every check the repo actually requires against `ci_checks`; a pending required check correctly blocks merge rather than being silently ignored. Approval staleness is a policy question the design has to answer explicitly, not something to leave ambiguous: if a reviewer approves at commit A and the author then pushes commit B, is that approval still valid? Common answers are auto-dismissing the approval on any new commit (safest, but adds friction for a trivial typo fix), or letting it persist unless the repo's rules specifically require re-approval on push. Either way, `commit_sha_reviewed` is what makes the policy enforceable at all. ### How do you stop a merge that's actually not ready from slipping through? The `mergeable` value shown on a pull request's page is a read, and it can go stale the moment before someone clicks merge, another commit landed, or a check just flipped to failing. The merge endpoint must re-check `mergeable` atomically at the moment of merging, never trusting whatever the client last displayed. This is the same principle as re-checking inventory at checkout instead of trusting a stale "in stock" label: recompute at the point of the state-changing action, not at the point of display. If the target branch has also moved because someone else merged a conflicting change first, the merge attempt has to detect that and reject cleanly rather than producing a broken merge commit. ## Trade-offs and follow-up questions | Decision | Benefit | Cost | |---|---|---| | Compute and cache diffs, never store them | No duplicated storage of git data; cache invalidates cleanly on sha change | A cache miss pays a real computation cost, worse for very large diffs | | Async CI trigger plus webhook callback | Correctly models CI runs that take minutes without blocking the author | The API and UI must honestly represent a "pending" state | | Comment threads as independent entries, no merge logic | Simple, nothing to reconcile | Doesn't generalize to true collaborative text editing, which is fine since comments aren't that | | Re-validate mergeable atomically at merge time | Prevents merging something that's actually missing approvals or checks | A bit more work on the merge endpoint than trusting a cached flag | | Shard by repo_id | Isolates a busy repository from a quiet one | A cross-repo query, like "all my open PRs everywhere," needs a fan-out or a separate index | **Q: A reviewer clicks approve at the exact moment the author force-pushes a new commit. What happens?** A: The approval is tied to the commit sha the reviewer was actually looking at, captured client-side when they loaded the review, not assumed to be "whatever the current head is" on the server. The system records the approval against the sha it was actually given for, then applies the repo's staleness policy when computing current mergeability, so an approval never silently applies to code the reviewer never saw. **Q: How do you keep diff computation fast for a pull request touching a 50,000-line generated file?** A: Apply practical limits instead of trying to diff arbitrary sizes fast: detect oversized files and collapse them by default ("this file has X changes, click to expand"), skip expensive line-level diffing for files a repo marks as generated (lockfiles, minified bundles), and compute large diffs asynchronously with a pending state rather than blocking the page. **Q: Two pull requests touching the same file merge in quick succession. How do you stop the second merge from silently discarding the first one's changes?** A: This is git's own merge-conflict detection, not something the review system reinvents. At merge time, the second merge attempts a real merge against the current target branch, which now includes the first pull request's changes, and either succeeds cleanly or reports a conflict a human has to resolve before merging can continue. ```knowledge-check { "questions": [ { "id": "system-design-codereview-tradeoffs-q1", "type": "mcq", "prompt": "Why must the merge endpoint re-check mergeable status atomically at merge time, instead of trusting the status shown on the PR page?", "options": [ {"id": "a", "text": "Because the PR page's status is always wrong"}, {"id": "b", "text": "Because that displayed status can go stale in the moments between when it was computed and when the user clicks merge"}, {"id": "c", "text": "Because git does not support checking mergeability at all"}, {"id": "d", "text": "Because re-checking is required by law for code review tools"} ], "correct": "b", "explanation": "A new commit, a flipped check, or a competing merge can all happen after the status was last displayed. Only re-checking at the moment of the actual merge action guarantees correctness." } ] } ``` 62:T3053,Netflix streams video to hundreds of millions of people at once, and the interesting engineering problem isn't a database, it's bandwidth. This question forces you to design around planetary-scale data transfer: how do you encode one video into dozens of formats, deliver it without buffering, and place it physically close to whoever is watching. It's also the clearest example of choosing availability over consistency you'll see in this course. ## Requirements **Functional requirements** - Upload and encode video into multiple qualities and formats. - Stream to clients with adaptive bitrate, so quality adjusts to network conditions automatically. - Recommend content to each user. - Resume playback where you left off, even after switching devices. **Non-functional requirements** - Minimize buffering. This is the single most important thing a streaming service can get right. - Support massively parallel viewing, millions of concurrent streams during peak hours. - Deliver with low latency worldwide. - Favor availability over consistency: a slightly stale "continue watching" position beats a failed stream. > **Remember:** for Netflix, a failed stream is a disaster and a stale resume point is a shrug. That priority order shapes almost every trade-off in this design. ```knowledge-check { "questions": [ { "id": "system-design-netflix-requirements-q1", "type": "mcq", "prompt": "Why does Netflix favor availability over consistency for its watch-progress feature?", "options": [ {"id": "a", "text": "Consistency is technically impossible for video streaming"}, {"id": "b", "text": "A stream failing to play is a severe user experience failure, while a resume point being a few seconds stale is a minor, forgettable annoyance"}, {"id": "c", "text": "Netflix doesn't track watch progress at all"}, {"id": "d", "text": "Availability and consistency always mean the same thing in practice"} ], "correct": "b", "explanation": "The cost of the two failure modes is wildly different: blocking playback to guarantee a perfectly synced resume point would make the far more common, far more painful failure (a stream not starting) more likely." } ] } ``` ## Estimates Assume 250 million subscribers, with 30% watching concurrently at peak (a realistic evening prime-time fraction), so 75 million concurrent streams. - **Peak bandwidth:** at an average 5 Mbps per stream across the SD/HD/4K mix, 75M × 5 Mbps = 375 Tbps of egress at peak. That single number is why "just serve from origin servers" isn't viable, a global CDN with edge caching is mandatory, not a nice-to-have. - **Encoding workload:** assume 1,000 hours of new content processed a week, each hour encoded into around 10 quality and codec variants (240p through 4K, across H.264, HEVC, AV1), so 10,000 encode-hours a week of compute. This is a batch workload, not a real-time one, and it's easy to parallelize. - **Storage:** the full catalog, roughly 15,000 titles averaging 1.5 hours each, across multiple encoded variants, lands in the multiple-petabyte range, replicated across regional storage and CDN edges. ## API ``` GET /catalog/browse?genre=&cursor= -> { titles[], next_cursor } GET /titles/{id} -> { metadata, available_qualities[] } GET /playback/{title_id}/manifest -> { manifest_url } -- HLS/DASH manifest listing available bitrates POST /playback/{title_id}/progress { position_seconds } -- resume point, fire periodically GET /recommendations?user_id= -> { titles[] } ``` The actual video bytes never touch this API. A client fetches the manifest, then pulls video segments directly from the nearest CDN edge, following the adaptive bitrate protocol. ## Data model ``` titles id, name, metadata, genres[] video_assets id, title_id, codec, resolution, bitrate, cdn_path watch_progress user_id, title_id, position_seconds, updated_at, device_id user_events user_id, title_id, event_type (play/pause/complete), timestamp -- feeds recommendations ``` Watch progress is the one piece of genuinely "live" state in this whole system, and it's deliberately simple. Almost all the engineering difficulty lives in the encoding pipeline and the delivery network, not the data model. ## High-level design ``` Upload path: Studio/content team --> raw video upload --> Encoding pipeline (parallelized, chunked transcode) | produces multiple resolution/bitrate/codec variants + generates HLS/DASH manifest (segment list per quality) | pushed to origin storage --> replicated to CDN edge caches globally Playback path: Client --> Playback API --> manifest_url --> Client's adaptive bitrate player fetches segments directly from nearest CDN edge, switching quality per segment based on measured throughput/buffer health | client periodically POSTs watch_progress --> Progress service (async, eventually consistent) Recommendation path (offline/batch, mostly): user_events stream --> batch/streaming ML pipeline --> per-user recommendation scores --> cached, served by Recommendations API ``` ## Deep dives ### How does one video become dozens of streamable files? Uploaded source video is split into chunks and transcoded in parallel, independent workers each encode a segment, and the segments are stitched together afterward, into a full matrix of quality variants: say 240p at 500kbps, 480p at 1.5Mbps, 720p at 3Mbps, 1080p at 6Mbps, and 4K at 25Mbps, each encoded in both H.264 (broad compatibility) and a more efficient codec like HEVC or AV1 (less bandwidth, needs a newer client). This is a batch pipeline, not something on the playback critical path. It's fine if it takes minutes to hours per title, since it happens once, long before anyone streams it. The output includes an HLS or DASH manifest: a playlist naming every available quality and where its segments live. ### How does the client decide what quality to play, moment to moment? The client never asks for "1080p" directly. It fetches the manifest, then continuously measures its own download throughput and how much video is already buffered ahead, and picks the next segment's quality itself, segment by segment, usually a few seconds at a time. If the network degrades mid-stream, the next segment simply comes from a lower-bitrate variant. That's the actual mechanism behind "the video adjusts to your connection": it's entirely client-side logic. The server's whole job is making sure every variant is sitting ready at the CDN edge. ### Why can't origin servers handle this traffic directly? At roughly 375 Tbps of peak egress, no origin server fleet can serve that directly to end users. Content has to be cached physically close to viewers. Netflix's real approach, called Open Connect, places CDN appliances directly inside ISP networks, pre-loaded with whatever content is predicted to be popular in that region, refreshed overnight during off-peak hours rather than fetched on demand during the evening rush. That turns "deliver 4K to 75 million concurrent viewers" from a real-time origin-fetch problem into a mostly-precomputed cache-hit problem. A cache miss falls back through a regional origin, then a global one, in a tiered hierarchy. > **Remember:** Netflix doesn't wait for people to request content before caching it. It predicts what will be popular and pushes it to the edge overnight, ahead of demand. ```knowledge-check { "questions": [ { "id": "system-design-netflix-cdn-q1", "type": "mcq", "prompt": "Why does Netflix pre-position content at CDN edges overnight rather than caching it reactively as requests come in?", "options": [ {"id": "a", "text": "Reactive caching is technically impossible for video"}, {"id": "b", "text": "With a relatively small, predictable catalog, proactive placement avoids a real-time origin fetch during peak demand, which the required egress bandwidth simply can't support"}, {"id": "c", "text": "Overnight bandwidth is free"}, {"id": "d", "text": "It's purely a marketing decision, not a technical one"} ], "correct": "b", "explanation": "Netflix's catalog is small and predictable enough to forecast demand and push content out ahead of time, turning peak-hour serving into a cache-hit problem instead of a live-fetch problem at an unsustainable bandwidth level." } ] } ``` ### How do recommendations work without recomputing everything live? Recommendations are fundamentally an offline machine learning problem feeding a fast online serving layer, not a real-time computation. User events, plays, pauses, completions, ratings, stream into a pipeline that periodically retrains or updates a model, blending collaborative filtering ("users who watched X also watched Y") with content-based signals like genre and cast similarity. The serving path stays simple and fast: precomputed per-user lists, cached and served on request, refreshed periodically rather than computed live per page load. A lightweight real-time re-rank can layer on top for in-session signals, the same personalization-as-a-thin-layer pattern used in autocomplete design. ## Trade-offs and follow-up questions | Layer | Approach | Trade-off | |---|---|---| | Encoding | Batch, parallelized, done once per title | Slow, but that's fine since it's off the playback critical path | | Delivery | Global CDN, edge-cached, ISP-embedded appliances | High infrastructure investment, but the only way to hit the required egress bandwidth | | Quality adaptation | Client-driven, over HLS/DASH | Server stays simple; all adaptive logic lives on the client | | Recommendations | Offline batch ML, cached serving | Not instantly reactive to a single click, an acceptable trade for serving speed | | Watch progress | Eventually consistent, async writes | Occasional minor resume-position drift, in exchange for never blocking playback | **Q: How does the client decide when to switch video quality mid-stream?** A: It continuously measures recent download throughput and current buffer health. If throughput comfortably exceeds the current bitrate and the buffer is healthy, it steps up on the next segment; if throughput drops, it steps down. This is a purely client-side algorithm; the server's only job is making every quality variant available. **Q: How do you pre-position content on CDN edges before anyone has watched it (cold content)?** A: Predictive placement based on regional popularity models and release schedules. A high-profile new title gets pushed to edge caches ahead of its release, informed by historical patterns rather than waiting for organic demand, using off-peak hours so it doesn't compete with live streaming traffic. **Q: The recommendation model is a day old. How do you make it feel responsive to what someone just watched?** A: Layer a lightweight real-time re-rank on top of the cached daily recommendation list, boosting titles similar to what was just watched, rather than recomputing the whole model live. Expensive computation stays batch and offline; cheap adjustments happen per request. ```knowledge-check { "questions": [ { "id": "system-design-netflix-tradeoffs-q1", "type": "mcq", "prompt": "Why is the video encoding pipeline allowed to take minutes to hours per title without hurting the user experience?", "options": [ {"id": "a", "text": "Users are willing to wait that long to start watching"}, {"id": "b", "text": "Encoding is a batch process that happens once, well before any viewer requests the content, so it's entirely off the playback critical path"}, {"id": "c", "text": "Encoding actually happens live, in real time, as someone streams"}, {"id": "d", "text": "Slow encoding is an unavoidable limitation with no workaround"} ], "correct": "b", "explanation": "Because encoding happens once ahead of any viewing, its latency has zero effect on what a viewer experiences when they hit play, which is exactly why it's fine for it to be slow." } ] } ``` 63:T36ff,YouTube looks like Netflix on the surface, both stream video, both need adaptive bitrate and a CDN, but the interview is testing something different. YouTube's content comes from millions of independent uploaders, not a curated studio catalog, and that one difference changes the upload path, how recommendations handle a brand-new video, and just how unpredictable "this thing might suddenly get huge" really is. This lesson reuses the streaming fundamentals from the Netflix design and focuses on what changes when anyone can upload and any video can go viral. ## Requirements **Functional requirements** - Any user can upload a video, which gets processed and becomes streamable. - Viewers stream with adaptive quality. - Per-video recommendations ("up next") and a personalized home feed. - View counts, likes, and comments on videos. **Non-functional requirements** - The upload path must handle huge files, hours of raw 4K footage, reliably, with resume support. - Transcoding must scale horizontally and elastically, since upload volume is unpredictable and spiky. - Viewing has to handle the fact that any video can go viral, not just a known catalog of popular titles. - Read-heavy at massive scale, similar bandwidth pressure to Netflix, but spread across a far longer and less predictable tail of content. > **Remember:** the difference that actually matters between YouTube and Netflix isn't raw traffic, it's catalog predictability. Netflix knows roughly what will be popular; YouTube genuinely doesn't. ```knowledge-check { "questions": [ { "id": "system-design-youtube-requirements-q1", "type": "mcq", "prompt": "What is the key structural difference between YouTube and Netflix that reshapes YouTube's design?", "options": [ {"id": "a", "text": "YouTube videos are always shorter than Netflix titles"}, {"id": "b", "text": "YouTube's catalog comes from millions of independent uploaders and is far less predictable, so any video can go viral with no warning"}, {"id": "c", "text": "YouTube does not use adaptive bitrate streaming"}, {"id": "d", "text": "YouTube has fewer total viewers than Netflix"} ], "correct": "b", "explanation": "Netflix's small, curated catalog is predictable enough to plan around. YouTube's enormous, user-generated catalog isn't, which forces a different approach to caching and capacity." } ] } ``` ## Estimates Assume 2 billion monthly active users, with about 500 hours of video uploaded every minute, YouTube's real published order of magnitude. - **Upload volume:** 500 hours/min × 60 = 30,000 hours/day of raw video. Each hour needs transcoding into roughly 10 quality variants, so about 300,000 encode-hours/day of heavily parallelized batch compute. - **Views:** over a billion hours watched per day, at roughly 5 Mbps average, works out to hundreds of petabytes of daily egress. Similar order of magnitude to Netflix's CDN pressure, but spread across a vastly larger and less predictable catalog, tens of millions of actively watched videos instead of a few thousand curated titles, which is exactly what changes the caching strategy. - **Metadata:** hundreds of millions of videos, each with title, description, tags, and stats. A large but standard sharded-database problem, not the bottleneck here. ## API ``` POST /videos/upload/init { filename, size } -> { upload_id, chunk_urls[] } PUT /videos/upload/{id}/chunk/{n} (binary body) POST /videos/upload/{id}/complete -> { video_id, status: "processing" } GET /videos/{id} -> { metadata, status, manifest_url (once ready) } GET /videos/{id}/recommendations -> { videos[] } -- "up next" sidebar GET /feed/home?cursor= -> { videos[], next_cursor } POST /videos/{id}/view -- fired by client to count a view (rate-limited/verified) ``` ## Data model ``` videos id, uploader_id, title, description, status (processing|ready|failed), duration, created_at video_assets video_id, resolution, bitrate, codec, cdn_path -- one row per encoded variant view_events video_id, user_id, timestamp, watch_duration -- feeds both counts and recommendations video_stats video_id, view_count, like_count, comment_count -- denormalized, async-updated counters ``` ## High-level design ``` Upload path: Client --> chunked resumable upload (same pattern as the Dropbox-style file storage design) --> raw video in upload storage --> "upload_complete" event --> Transcoding pipeline | elastic worker pool transcodes in parallel into variant matrix (same pattern as Netflix's encoding pipeline) | on completion: video.status = "ready", manifest published | pushed to CDN edge caches (reactively, on-demand for the long tail — NOT pre-positioned like Netflix's curated catalog, since YouTube's catalog is too large and unpredictable to pre-place) Playback + recommendations: same adaptive-bitrate/CDN pattern as Netflix, plus: view_events stream --> batch + near-real-time ML pipeline --> per-video "up next" candidates --> per-user home feed candidates --> cached, served with light real-time re-rank ``` ## Deep dives ### How does upload at this scale actually work? Reuse the chunked, resumable upload pattern from the file storage design directly: large raw video files are split into chunks on the client, uploaded independently with resume on failure, and reassembled once every chunk arrives. Unlike Dropbox, though, content-addressed deduplication barely matters here, since video uploads are rarely bit-identical to each other. The real emphasis is making the transcoding step elastic: upload volume is bursty, 30,000 hours a day but not evenly spread, and a fixed-size transcoding fleet would either sit over-provisioned most of the time or fall behind during a spike. Transcoding workers scale automatically based on queue depth, the same job-queue pattern where each video is a job, workers pull and process it, and failures retry. ### Why does YouTube's CDN strategy have to work differently from Netflix's? Netflix's catalog is a few thousand titles with strong predictability, so content can be proactively pushed to edge caches ahead of demand. YouTube's actively-watched catalog spans tens of millions of videos with a long, genuinely unpredictable tail, any video can go viral without warning, so pre-positioning everything everywhere simply isn't feasible. The practical answer is reactive, on-demand edge caching: a video gets cached at an edge location the first time someone in that region requests it, and later requests hit that cache. This uses a shorter, LRU-based eviction policy compared to Netflix's curated pre-placement, with a smaller proactive tier reserved for videos already trending or from very large channels, where a demand spike is at least somewhat predictable. > **Remember:** Netflix pre-positions because it can predict demand. YouTube reacts because it can't. Same underlying CDN idea, opposite starting assumption. ```knowledge-check { "questions": [ { "id": "system-design-youtube-cdn-q1", "type": "mcq", "prompt": "Why does YouTube rely mostly on reactive, on-demand CDN caching instead of Netflix's proactive pre-positioning?", "options": [ {"id": "a", "text": "YouTube's CDN technology is less advanced than Netflix's"}, {"id": "b", "text": "YouTube's catalog is orders of magnitude larger and far less predictable, since any upload can go viral, making proactive placement of everything infeasible"}, {"id": "c", "text": "YouTube videos are smaller in file size than Netflix titles"}, {"id": "d", "text": "Reactive caching is always superior to proactive caching"} ], "correct": "b", "explanation": "The choice follows directly from catalog size and predictability, not raw traffic volume. A catalog too large and unpredictable to forecast can't be pre-placed economically, so caching has to react to real demand instead." } ] } ``` ### What happens when an obscure video suddenly goes viral? A previously obscure video can jump from 100 views/hour to a million views/hour within minutes. This stresses the same layers as a viral social media post: cache hot-key contention on that one video's metadata and manifest, fixed with local, in-process caching layered on top of the CDN, and its view/like counters under write contention, fixed with async batched increments through a counting service rather than a synchronous write per view. The CDN edge cache for that specific video also needs to scale its replica count dynamically as request volume spikes, which is why reactive caching systems monitor per-object request rate and automatically promote hot objects to wider replication. ### How do "up next" and the home feed differ, and how do you stop view-count fraud? Recommendations follow the same core pattern as Netflix: an offline batch pipeline blending collaborative filtering with content signals, consuming the `view_events` stream, producing cached candidate lists topped with a lightweight real-time re-rank. Two things are specific to YouTube. "Up next" is driven heavily by co-watch patterns ("people who watched this also watched"), while the home feed is driven by personal watch history, different candidate-generation queries against the same underlying data. And cold start for a brand-new video with zero view history falls back to content-based signals, title, tags, category, channel, until enough view events accumulate to activate the collaborative signal. Naively trusting every client-fired view call invites obvious fraud (bots, refresh scripts). Keep ingestion fast and unfiltered, every view call is logged immediately, and run fraud detection as an asynchronous downstream stage: minimum watch duration, per-user dedup within a time window, and anomaly detection on view velocity from one IP or account cluster, before those events roll up into the publicly displayed count. ## Trade-offs and follow-up questions | Decision | Benefit | Cost | |---|---|---| | Elastic transcoding worker pool | Absorbs bursty upload volume without over-provisioning | A backlog grows during extreme spikes, increasing publish latency | | Reactive/LRU CDN caching | Feasible for a catalog too large to pre-place | The first-ever request from a region pays a cache miss | | Async batched view/like counters | Survives viral write contention on a single hot row | Counts are eventually consistent, briefly stale under extreme load | | Separate "up next" vs. home feed queries | Each is optimized for its own signal | Two candidate-generation paths to maintain against the same data | **Q: A video uploaded 10 minutes ago suddenly gets a million views in the next 10 minutes. What breaks first, and how do you fix it?** A: First, the CDN edge cache for that video's manifest and segments, since a newly-cached object may only be replicated to a small number of edges, fixed by dynamically promoting hot objects to wider replication based on per-object request-rate monitoring. Second, the view and like counters, fixed with async batched increments instead of a synchronous write per view. Neither the transcoding pipeline nor the upload path is affected, since the video was already fully processed before the spike hit. **Q: How is YouTube's CDN strategy fundamentally different from Netflix's, given both stream video?** A: Netflix has a small, highly predictable catalog it can pre-position ahead of demand, mostly during off-peak hours. YouTube's catalog is orders of magnitude larger and far less predictable, so its strategy is predominantly reactive, on-demand caching with dynamic replication for objects that prove hot, reserving a smaller proactive tier for content with more predictable demand. **Q: How would you prevent view-count fraud without slowing down the pipeline from upload to visible view?** A: Keep raw ingestion fast and unfiltered, and run fraud detection as an asynchronous downstream stage, minimum watch duration, per-session dedup, and velocity anomaly detection, before events roll up into the public count. This decouples ingestion latency from fraud-detection complexity, at the cost of the public count lagging the raw stream by the detection pipeline's processing delay, typically seconds to a few minutes. ```knowledge-check { "questions": [ { "id": "system-design-youtube-tradeoffs-q1", "type": "mcq", "prompt": "Why is view-count fraud detection run as an asynchronous downstream stage rather than checked before a view event is even accepted?", "options": [ {"id": "a", "text": "Fraud detection is too unimportant to prioritize"}, {"id": "b", "text": "It keeps raw ingestion fast and simple, decoupling the fast write path from the slower, more complex fraud-detection logic"}, {"id": "c", "text": "It's technically impossible to detect fraud before accepting an event"}, {"id": "d", "text": "Fraud only matters for uploads, not for views"} ], "correct": "b", "explanation": "Blocking every view event on a complex fraud check would slow down the entire ingestion path. Accepting quickly and reconciling asynchronously keeps the hot path fast while still catching fraud before it reaches the public count." } ] } ``` When an interviewer asks "how is this different from a similar system you already designed," the strongest answer names the specific difference that's actually driving the divergence, catalog size and predictability here, not a vague "it's bigger." 64:T31c0,A music streaming service tests a different muscle than a ride-hailing app. It's dominated by large, unchanging audio files served to a huge number of listeners, plus a recommendation pipeline that runs entirely in the background and never gets in the way of playback. The interesting decisions here are about CDN strategy, adaptive delivery, and syncing state across a user's devices, not about coordinating people racing for the same resource. ## Requirements **Functional requirements** - Search for and stream tracks, albums, and podcasts. - Create, edit, and share playlists. - Recommend tracks and playlists based on listening history. - Download tracks for offline playback, a paid feature. - Artists and labels upload and manage catalog metadata and audio. **Non-functional requirements** - Low startup latency: audio should start within about 200ms of pressing play. - High availability: streaming should degrade to a lower bitrate on a bad connection rather than fail outright. - Massive read fan-out: a handful of popular tracks account for a hugely disproportionate share of daily plays. - Licensing constraints: some tracks are restricted to certain regions, or must be pulled from the catalog quickly. - Playlist state stays reasonably in sync across a user's phone, desktop, and web app; a few seconds of lag is fine. > **Remember:** this system is bound by bandwidth and CDN reach, not by database throughput. The core engineering problem is getting audio bytes to listeners cheaply and fast. ```knowledge-check { "questions": [ { "id": "system-design-spotify-requirements-q1", "type": "mcq", "prompt": "What is the dominant engineering constraint in a music streaming service like Spotify?", "options": [ {"id": "a", "text": "Database transaction throughput"}, {"id": "b", "text": "Getting large audio files to a huge number of listeners cheaply and fast, which makes it a CDN and bandwidth problem"}, {"id": "c", "text": "Coordinating concurrent writers to the same row"}, {"id": "d", "text": "Real-time geospatial matching"} ], "correct": "b", "explanation": "Unlike a system with heavy concurrent writes, music streaming is almost entirely about serving large, unchanging files to enormous numbers of readers, which is fundamentally a delivery and caching problem." } ] } ``` ## Estimates Assume 500 million monthly active users, 200 million daily active, averaging an hour of listening a day. - **Track starts:** an average track runs about 3.5 minutes, so roughly 17 track plays per user per day. 200M × 17 ≈ 3.4 billion track starts/day, about 40,000/sec average, several times higher during the evening peak. - **Audio file size:** a 3.5-minute track at 128kbps is about 3.4 MB per quality tier. Storing three tiers (say 96/160/320 kbps) is roughly 10 MB per track across all of them. - **Catalog size:** 100 million tracks × 10 MB across tiers = 1 petabyte of audio. This is exactly why virtually all of it sits in object storage behind a CDN, never served directly from app servers. - **Metadata** (track, album, artist, playlist rows) is comparatively tiny, tens of millions of rows, fitting comfortably in a normal database with caching. ## API ``` GET /v1/search?q=...&type=track,album,artist GET /v1/tracks/{track_id} GET /v1/tracks/{track_id}/stream?quality=high resp: 302 redirect to a signed CDN URL, or an HLS/DASH manifest POST /v1/playlists body: { name, description } PUT /v1/playlists/{playlist_id}/tracks body: { track_id, position } GET /v1/playlists/{playlist_id} GET /v1/users/{user_id}/recommendations POST /v1/playback-events body: { track_id, event: "play"|"skip"|"complete", position_ms, device_id } POST /v1/tracks/{track_id}/download # returns an encrypted offline bundle + license ``` Playback events are fire-and-forget, sent to an asynchronous pipeline rather than blocking the request path. They feed both recommendations and royalty accounting. ## Data model ``` Track(track_id PK, title, artist_id, album_id, duration_ms, isrc, explicit, available_regions[]) Artist(artist_id PK, name, bio) Album(album_id PK, title, artist_id, release_date) AudioAsset(track_id FK, quality_tier, storage_url, codec, bitrate) Playlist(playlist_id PK, owner_id, name, is_public, updated_at) PlaylistTrack(playlist_id FK, track_id FK, position, added_at) User(user_id PK, plan[free|premium], region) PlaybackEvent(event_id PK, user_id, track_id, event_type, position_ms, ts) -- append-only, streamed to analytics UserTasteProfile(user_id PK, embedding_vector, updated_at) -- derived, rebuilt offline ``` `AudioAsset` is separate from `Track` because one track has several encoded variants, and the actual bytes live in object storage. The database row only holds a pointer, never the audio itself. ## High-level design ``` [Client: mobile/desktop/web] | [API Gateway] | +-----+-----------------+------------------+ | | | [Catalog/Search [Playback/Streaming [Playlist Service] Service] Service] | | | [Metadata DB] [Search Index issues signed URL / (Elasticsearch)] manifest, doesn't | proxy audio bytes [Metadata DB] | [CDN edge cache] <---- [Object Storage: S3/GCS, origin] ^ | actual audio bytes served directly from edge to client [Playback Events] --async--> [Event Queue (Kafka)] --> [Recommendation Pipeline] --> [Royalty/Analytics Pipeline] ``` The **Playback Service** never proxies audio through app servers. It authenticates the request, checks licensing and subscription status, and hands back a signed, time-limited CDN URL, or a manifest for adaptive bitrate. The client then talks directly to the CDN. The **Recommendation Pipeline** is fully decoupled from serving, so a slow or broken recommender never touches playback. ## Deep dives ### How does adaptive streaming keep audio playing smoothly? Encode each track into multiple bitrate tiers, chunked into short segments, so a client can switch quality mid-stream based on measured bandwidth without restarting playback. Because popularity follows a power-law curve, a small set of hot tracks stays cache-warm at nearly every CDN edge, pushing the cache hit rate for top content close to 100%, which is what keeps origin bandwidth costs under control at this scale. For fast startup, prefetch the first few seconds of the most likely next track, the next item in a queue, while the current one is still playing. > **Remember:** the reason "top" content streams instantly everywhere is that a small share of the catalog accounts for most plays, so the CDN keeps it warm at nearly every edge by default. ```knowledge-check { "questions": [ { "id": "system-design-spotify-cdn-q1", "type": "mcq", "prompt": "Why does a small set of popular tracks achieve near-100% cache hit rates at CDN edges without special handling?", "options": [ {"id": "a", "text": "Popular tracks are given priority storage by policy"}, {"id": "b", "text": "Play counts follow a power-law distribution, so the same small set of tracks gets requested constantly at every edge, naturally keeping them cache-warm"}, {"id": "c", "text": "All tracks are cached everywhere regardless of popularity"}, {"id": "d", "text": "Popular tracks are smaller in file size"} ], "correct": "b", "explanation": "Because a small fraction of the catalog accounts for a disproportionate share of plays, ordinary LRU-style caching naturally keeps those tracks resident everywhere without needing explicit pre-positioning logic." } ] } ``` ### How do playlists stay in sync across devices without a merge algorithm? Model a playlist as a small ordered list carrying a monotonically increasing version number. Each client caches the playlist locally and does a conditional fetch, checking the version, rather than polling the full content every time. Concurrent edits from two devices resolve with last-write-wins at the playlist-version level, which is fine for casual use. The operational-transform-style merging that Google Docs needs would be overkill here for something as simple as reordering a list. ### How do recommendations run without slowing down playback? Two layers, both entirely offline from the playback path. **Collaborative filtering** finds "users like you also played X" through a batch job over the user-track interaction matrix, run nightly or hourly. **Content-based embeddings**, built from audio features and metadata, recommend acoustically similar tracks, useful for a brand-new track with little play history yet. Both feed a fast key-value store mapping user ID to a precomputed track list, refreshed periodically. Recommendations are never computed synchronously on the request path. ### How does offline playback and licensing enforcement work? A premium user's download request returns an encrypted bundle, the audio file locked with a device-bound key, plus a time-limited license. Playback of a downloaded track still requires periodic license validation, the app has to "phone home" within some window, say every 30 days, so a lapsed subscription eventually blocks offline playback too. This is a licensing requirement, not just a caching detail, worth naming explicitly. Track availability is scoped by region, and a rights holder can demand a track be pulled globally within hours. Implement this as a fast, cached flag check in the Playback Service on every stream request, with a short TTL, so a takedown propagates in seconds rather than needing to bust the entire CDN. ## Trade-offs and follow-up questions | Concern | Choice | Trade-off | |---|---|---| | Audio delivery | CDN plus object storage, signed URLs, adaptive bitrate | Scales to almost any read volume once caches warm up, at the cost of encoding pipeline complexity | | Search | A dedicated search index synced via change-data-capture | Fast fuzzy search, but eventually consistent with the metadata database | | Recommendations | Fully offline, served from a precomputed key-value store | Never touches playback latency, at the cost of being up to a few hours stale | | Playlist sync | Version-based conditional fetch, last-write-wins | Simple and sufficient for casual multi-device use, not real-time collaborative | | Offline playback | Encrypted bundle plus periodic license check | Enforces subscription status without needing constant connectivity | **Q: How do you avoid a "thundering herd" when a hyped new album drops and everyone streams it at once?** A: Pre-warm CDN edge caches ahead of a scheduled release by pushing the audio out before the public release time, and rate-limit the origin fetch so a cache-miss stampede doesn't hit object storage from every edge simultaneously. **Q: How would you support a real-time collaborative playlist, like a party playlist multiple people edit live?** A: Swap last-write-wins for an operation-based approach: treat each add, remove, or reorder as a discrete event broadcast over a WebSocket, and use a sequence CRDT so concurrent inserts converge without conflict, the same idea as Google Docs' collaborative editing. **Q: A track needs to be pulled globally due to a rights dispute. Walk through what happens.** A: Flip the track's status flag in the metadata database, which invalidates the short-TTL cache in the Playback Service within seconds, so no new stream URLs are issued. Existing signed URLs are already time-limited and expire naturally. For offline copies, the next mandatory license check revokes playback. ```knowledge-check { "questions": [ { "id": "system-design-spotify-tradeoffs-q1", "type": "mcq", "prompt": "Why is a track takedown implemented as a fast, short-TTL cached flag check rather than by purging the entire CDN?", "options": [ {"id": "a", "text": "Purging a CDN globally is technically impossible"}, {"id": "b", "text": "A short-TTL flag check propagates the takedown within seconds without the cost and complexity of busting cached content across every edge"}, {"id": "c", "text": "Takedowns are rare enough that speed doesn't matter"}, {"id": "d", "text": "The flag check only works for free-tier users"} ], "correct": "b", "explanation": "Checking a cheap, frequently-refreshed flag on every stream request achieves near-instant enforcement without needing to actively invalidate content already cached at every CDN edge worldwide." } ] } ``` 65:T3993,Ride-hailing combines four hard problems at once: finding nearby drivers fast, tracking millions of moving points in real time, matching riders to drivers under a tight time limit, and pricing that reacts to supply and demand. Interviewers use it to check whether you can break a big, vague product into services with clean boundaries, and whether you understand why the naive approach, scan every driver, lock one match at a time, falls apart at scale. ## Requirements **Functional requirements** - A rider requests a trip from pickup to drop-off; the system estimates fare and ETA before confirming. - The system matches the rider to a nearby available driver. - Both parties see live location updates during the trip. - Fare (base plus distance, time, and surge) is computed and payment captured at trip end. - Trip history, receipts, and ratings are available afterward. **Non-functional requirements** - Fast matching: driver assignment should finish within about 3 seconds of the request. - High availability: the dispatch path cannot go down during peak demand, like holidays or a big event letting out. - Real-time location: a driver's position updates every 3-4 seconds and should reach the rider within about a second. - Trip history and analytics can be eventually consistent; matching and payment need stronger guarantees, no double-assigning a driver, no double-charging a rider. - Geographic partitioning: the system scales per city or region independently. Traffic in one city should never touch another city's shard. > **Remember:** this design has three different subsystems with three different scaling problems: location is a volume problem, matching is a latency problem, and payment is a consistency problem. Keep them separate in your head and in your architecture. ```knowledge-check { "questions": [ { "id": "system-design-uber-requirements-q1", "type": "mcq", "prompt": "Why does a ride-hailing system need three genuinely different scaling strategies instead of one?", "options": [ {"id": "a", "text": "Because the interviewer expects three diagrams"}, {"id": "b", "text": "Because location updates are a volume problem, matching is a latency problem, and payment is a consistency problem, each needing a different kind of store and guarantee"}, {"id": "c", "text": "Because location, matching, and payment always use the same database in practice"}, {"id": "d", "text": "There's actually only one real scaling problem here"} ], "correct": "b", "explanation": "Each subsystem has a fundamentally different bottleneck: raw write volume for location, response time for matching, and correctness for payment. Treating them as one undifferentiated problem misses what actually needs to scale." } ] } ``` ## Estimates Assume a mid-size ride-hailing company: 20 million daily active riders, 1 million active drivers, across 100 major metros. - **Trips:** roughly 10 million trips/day, about 115/sec average, 5-8x that during rush hour, so 700-900/sec at peak. - **Location pings:** 1 million drivers online at peak, each pinging every 4 seconds, is 1,000,000 / 4 ≈ 250,000 location writes/sec at peak. This is the dominant write load, far bigger than trip creation. Each ping is small, about 100 bytes, so roughly 25 MB/sec of ingest. - **Matching requests:** 900 trips/sec, each triggering a "find nearby drivers" geospatial query. This read load is comparable to the write load and must be served from memory, not disk. - **Trip records:** 10M/day × about 2 KB each ≈ 20 GB/day, roughly 7 TB/year, trivial for durable storage, so trip history goes to an ordinary relational store, well outside the hot path. ## API ``` POST /v1/trips/estimate body: { pickup: {lat,lng}, dropoff: {lat,lng}, product: "standard" } resp: { fare_estimate, eta_minutes, surge_multiplier } POST /v1/trips body: { rider_id, pickup, dropoff, product } resp: { trip_id, status: "matching" } GET /v1/trips/{trip_id} resp: { status, driver: {id, name, location}, eta } POST /v1/drivers/{driver_id}/location body: { lat, lng, heading, timestamp } # sent every ~4s from driver app POST /v1/trips/{trip_id}/events body: { type: "driver_arrived" | "trip_started" | "trip_completed" } POST /v1/trips/{trip_id}/rate body: { rating, comment } ``` Location updates and trip status also push over a persistent WebSocket, so both apps get sub-second updates without needing to poll. ## Data model ``` Driver(driver_id PK, name, vehicle_info, status[online|offline|on_trip], rating) DriverLocation(driver_id PK, geohash, lat, lng, heading, updated_at) -- hot, in-memory Rider(rider_id PK, name, payment_method_id, rating) Trip(trip_id PK, rider_id, driver_id, status, pickup, dropoff, requested_at, matched_at, started_at, completed_at, fare_cents, surge_multiplier, distance_m) TripEvent(event_id PK, trip_id FK, type, created_at) -- append-only audit trail Payment(payment_id PK, trip_id FK, amount_cents, status, idempotency_key) ``` `DriverLocation` deliberately lives apart from `Driver`. It's overwritten 250,000 times a second and read constantly, so it belongs in an in-memory geospatial store, never in the same durable relational database holding `Trip` and `Payment`. ```knowledge-check { "questions": [ { "id": "system-design-uber-datamodel-q1", "type": "mcq", "prompt": "Why is DriverLocation stored separately from the durable Driver table, in an in-memory store instead of the relational database?", "options": [ {"id": "a", "text": "Relational databases cannot store latitude and longitude values"}, {"id": "b", "text": "It's overwritten hundreds of thousands of times per second, a write pattern a durable relational store isn't built for, and losing a stale location is harmless"}, {"id": "c", "text": "In-memory stores are always more secure"}, {"id": "d", "text": "Driver and DriverLocation must always be in separate databases by convention"} ], "correct": "b", "explanation": "The extreme write frequency and the fact that a location is stale within seconds anyway both point away from durable storage and toward a fast, in-memory geospatial store." } ] } ``` ## High-level design ``` [Rider App] [Driver App] | HTTPS/WS | HTTPS/WS + periodic POST v v [API Gateway / LB] | +-----------------+------------------+ | | | [Trip Service] [Location Service] [Pricing Service] | | | | [Geospatial Index] [Surge Calculator] | (Redis GEO / S2) (reads live supply/demand) | | +----->[Matching Service]<----------+ | [Dispatch Queue] | +------------+-------------+ | | [Notification Service] [Trip State Store] (push to driver app) (Trip/Payment DB) ``` The **Location Service** ingests the 250,000/sec location stream and writes into an in-memory geospatial index for matching, plus a lightweight time-series store for support and fraud tooling, never touching the durable trip database. The **Trip Service** is the source of truth for trip state, orchestrating the sequence: requested, matching, matched, driver arriving, in progress, completed. The **Pricing Service** computes fare and surge, consulted both at estimate time and again at match time, when the fare is locked to avoid disputes. ## Deep dives ### How do you find nearby drivers without scanning every driver? Store driver locations in geohashes or S2 cells rather than raw latitude and longitude, so "find drivers near me" becomes a lookup against a handful of cells instead of a scan of everyone. Redis's geospatial commands, backed by geohash-sorted sets, are the standard first answer; at very large scale, companies build a custom in-memory quadtree sharded by region, since a single-key model becomes a bottleneck at hundreds of thousands of writes a second. Picture the map cut into roughly 1km² cells. A driver's update rewrites their entry in one cell. A rider's match request queries their own cell plus a ring of neighbors, expanding the ring only if too few drivers turn up. That turns an O(all drivers) scan into an O(drivers in a few cells) lookup. > **Remember:** a geospatial index turns "search everyone" into "search the handful of cells near me." That's the entire trick behind fast nearest-driver matching. ```knowledge-check { "questions": [ { "id": "system-design-uber-geospatial-q1", "type": "mcq", "prompt": "Why does dividing the map into geohash cells make nearby-driver search fast?", "options": [ {"id": "a", "text": "It doesn't actually help; a full scan is equally fast"}, {"id": "b", "text": "It narrows a search over every driver down to a search over just the cells near the rider, expanding only if too few drivers are found"}, {"id": "c", "text": "Geohashing eliminates the need to store driver locations at all"}, {"id": "d", "text": "It only works for drivers, not for riders"} ], "correct": "b", "explanation": "Instead of comparing a rider's location against every driver in the system, the query only has to check drivers already known to be in the same or a nearby cell, which is dramatically cheaper." } ] } ``` ### How does matching actually decide who gets the trip? The naive approach, find nearby drivers and pick the closest, has real problems: two requests can race for the same driver, and "closest" isn't always best, a driver 2 minutes away about to drop off another rider might beat one 90 seconds away but stuck at a light. Real systems batch requests: collect ride requests and available drivers over a short window, a second or two in dense areas, then solve a bipartite matching problem that minimizes total wait time across every pending request at once, rather than greedily matching one request at a time. That's why the car you get isn't always the literal closest one: the system is optimizing globally, not per-request. Once a candidate match is chosen, the driver gets a push notification with a short accept window, 10-15 seconds. If declined or timed out, the request goes back into the pool for the next round, with that driver temporarily excluded. A distributed lock, or a single-writer-per-cell pattern, guarantees a driver is never offered two trips at once. ### How does surge pricing work, and what happens if it changes mid-wait? Surge is a real-time supply-and-demand ratio computed per geographic cell: `surge_multiplier = f(open_requests_in_cell / available_drivers_in_cell)`, smoothed over a short rolling window and capped, say 1.0x to 5.0x, to avoid runaway pricing. It's recalculated every 30-60 seconds per cell and cached, since it's read on every fare estimate. The multiplier gets locked into the trip record the moment a match happens, so the rider is charged what they were quoted, never a multiplier that changed while they were still waiting. This is a common follow-up question, and locking the price at match time is the answer. ### How do 250,000 location writes a second stay off the durable database? They never touch it. Ingestion flows through a message queue partitioned by geographic region, with the Location Service as the consumer writing into the in-memory index. This also lets analytics and fraud pipelines consume the same stream independently, without adding any load to the hot matching path. ## Trade-offs and follow-up questions | Concern | Choice | Trade-off | |---|---|---| | Driver location store | In-memory geospatial index, sharded by region | Fast reads and writes, but ephemeral, which is fine since a stale-by-seconds location doesn't matter | | Matching | Batched bipartite matching every 1-2 seconds | Better global outcomes than greedy nearest-driver, at the cost of a small added latency window | | Trip state consistency | One source of truth, driver assignment via a per-driver lock | Prevents double-dispatch, at the cost of coordination overhead | | City partitioning | Shard location, matching, and pricing by metro region | Independent scaling and fault isolation, at the cost of special-casing rare cross-city trips | | Payment | Charge asynchronously after trip completion, with idempotency keys | Avoids blocking trip completion on a payment gateway call, needs a reconciliation path for failures | **Q: How do you prevent two riders from being matched to the same driver at the same instant?** A: Treat "assign driver to trip" as an atomic compare-and-swap on the driver's status, or a per-driver lock with a short TTL. The matching service must flip the driver from available to pending-offer before sending the push notification; any competing match attempt fails that swap and retries with a different candidate. **Q: The rider's app loses connectivity for 30 seconds mid-trip. What happens?** A: The driver's location stream keeps flowing to the Location and Trip Services regardless of the rider's connectivity, since trip state lives entirely server-side. When the rider's app reconnects, it re-fetches the trip's current state rather than relying on missed push messages, and resubscribes to the live channel. **Q: How would you extend this to support pooled rides with multiple riders per trip?** A: The matcher becomes a constrained optimization problem instead of a one-to-one assignment, considering route overlap, added detour time per rider, and a maximum-detour limit. A reasonable answer at interview depth: solve a small routing subproblem per driver candidate, bounded to 2-3 open seats, without going deeper into full vehicle-routing algorithms unless asked. ```knowledge-check { "questions": [ { "id": "system-design-uber-tradeoffs-q1", "type": "mcq", "prompt": "Why is the surge multiplier locked into the trip record at match time rather than recalculated at trip completion?", "options": [ {"id": "a", "text": "Locking it has no real purpose, it's just convention"}, {"id": "b", "text": "So the rider is charged exactly what they were quoted, not a different multiplier that may have changed while they were waiting"}, {"id": "c", "text": "Because surge pricing cannot be recalculated more than once"}, {"id": "d", "text": "Because drivers set their own surge multiplier manually"} ], "correct": "b", "explanation": "Locking the fare at match time avoids the real user complaint of being charged a different price than what was quoted, since surge naturally fluctuates minute to minute." } ] } ``` 66:T34c0,Airbnb pairs two hard problems interviewers like testing together: search over a huge, constantly-changing catalog with location and filter queries, and booking correctness, guaranteeing two guests can never both book the same property for overlapping dates. It's a great test of knowing exactly when to reach for strong consistency and when eventual consistency is fine. ## Requirements **Functional requirements** - Hosts list properties with details, photos, pricing, and an availability calendar. - Guests search listings by location, dates, price, and amenity filters. - Guests book a listing for a date range; a booking must never overlap an existing reservation. - Payments are processed and split (guest charge, host payout, platform fee) after booking. - Guests and hosts leave reviews after a completed stay. **Non-functional requirements** - No double-booking, ever. This is the one hard consistency requirement in the whole system. - Search must return results in under a second, despite complex location-and-filter queries over millions of listings. - High availability for browsing and search; booking can tolerate a bit more latency in exchange for correctness. - Search results can lag reality by a few minutes; booking state must be correct the instant it changes. > **Remember:** search and booking have opposite priorities in this design. Search wants speed and can tolerate staleness; booking wants correctness and can tolerate a slightly slower write. ```knowledge-check { "questions": [ { "id": "system-design-airbnb-requirements-q1", "type": "mcq", "prompt": "Why can Airbnb's search results be a few minutes stale while the booking system cannot tolerate any staleness?", "options": [ {"id": "a", "text": "Search staleness and booking staleness are equally acceptable in practice"}, {"id": "b", "text": "A stale search result at worst shows a listing that's actually unavailable, caught at booking time; a stale booking check could let two guests book the same dates"}, {"id": "c", "text": "Search is technically incapable of being kept fresh"}, {"id": "d", "text": "Booking staleness only matters for expensive listings"} ], "correct": "b", "explanation": "The cost of staleness differs completely between the two: search staleness is a minor inconvenience corrected at booking time, while booking staleness is a real double-booking, an unrecoverable correctness failure." } ] } ``` ## Estimates Assume 7 million active listings worldwide, 150 million users, and 2 million bookings a day. - **Bookings/sec:** 2,000,000 / 86,400 ≈ 23/sec average, spiking 5-10x during a flash sale or peak booking season, so 150-200/sec at peak. That's a moderate load, well within a well-indexed relational database as long as the locking is designed correctly. - **Search traffic dominates:** with 150 million users doing a handful of searches a month while planning trips, that's tens of millions of searches a day, hundreds per second on average, bursting well beyond that. Nearly all of this hits a search index, not the booking database. - **Listing data:** 7 million listings, about 5 KB of metadata plus roughly 20 photos at 200 KB each, is about 28 TB of images alone, served from object storage and a CDN, the same pattern used for Spotify's audio. - **Availability calendar:** if modeled as one row per listing per day, 7M listings × 365 days ≈ 2.5 billion rows. That number alone is a strong hint the calendar shouldn't be modeled densely, covered in the data model below. ## API ``` GET /v1/search?lat=&lng=&radius_km=&checkin=&checkout=&guests=&filters=... resp: [{ listing_id, title, price_per_night, thumbnail, rating, distance_km }, ...] GET /v1/listings/{listing_id} GET /v1/listings/{listing_id}/availability?start=&end= POST /v1/bookings body: { listing_id, checkin, checkout, guests, payment_method_id } resp: { booking_id, status: "confirmed" } | 409 Conflict { reason: "dates_unavailable" } POST /v1/bookings/{booking_id}/cancel POST /v1/listings/{listing_id}/reviews body: { rating, text } ``` `POST /v1/bookings` returning a `409` when a booking loses a race is the detail worth calling out unprompted. It signals you've thought about the concurrency case, not just the happy path. ## Data model ``` Listing(listing_id PK, host_id, title, description, lat, lng, geohash, base_price_cents, amenities[], max_guests, status) BlockedDate(listing_id FK, date, reason[booked|host_blocked], booking_id NULLABLE) -- sparse: only dates that are unavailable get a row, not all 365 days Booking(booking_id PK, listing_id FK, guest_id, checkin, checkout, status[pending|confirmed|cancelled], total_price_cents, created_at) Payment(payment_id PK, booking_id FK, guest_charge_cents, host_payout_cents, platform_fee_cents, status, idempotency_key) Review(review_id PK, booking_id FK, author_id, target[host|guest], rating, text) ``` `BlockedDate` is sparse: since most listing-days are available, only booked or host-blocked dates get a row at all, which avoids the 2.5-billion-row problem above. A unique constraint on `(listing_id, date)` is what actually prevents double-booking at the database level, covered next. ## High-level design ``` [Guest App] [Host App] | | [API Gateway] | +----------------+-----------------+ | | | [Search Service] [Booking Service] [Listing Service] | | | [Search Index [Booking DB [Listing DB + (Elasticsearch, (relational, Object Storage/CDN geo + facets)] strong for photos] ^ consistency)] | | +---sync via CDC-----+ | [Payment Service] --> external payment gateway ``` The **Listing Service** is the source of truth for listing metadata, propagated to the search index asynchronously, which is exactly why search can lag reality by a few minutes. The **Booking Service** owns the one part of this system that must be strongly consistent: checking availability and writing the reservation happen as a single atomic operation. The **Search Service** is read-optimized and denormalized, and never talks to the booking database directly, so search load never competes with booking writes. ## Deep dives ### How do you actually prevent double-booking under real concurrency? This is the centerpiece of the question. The wrong answer is "check availability, then insert," done as two separate steps. That's a classic race: two guests can both pass the availability check before either one's write actually lands. The correct answer makes the reservation atomic using a database constraint, not application logic: 1. **A unique constraint on `(listing_id, date)` in `BlockedDate`.** Booking a 3-night stay inserts one row per date in a single transaction. If any date already has a row, the constraint violation rolls back the whole transaction. The database itself rejects the double-booking, no explicit locking code required. This is the simplest correct answer, and the one to lead with. 2. **A row-level lock on the listing** during the booking transaction, if you'd rather hold one lock instead of inserting N per-night rows. Simpler to reason about for long stays, and serializing all bookings for one listing is fine, since one listing's booking volume is naturally low. Either way, a guest sees tentative availability in search results, but the reservation is only confirmed by winning the database-level atomic write at the actual moment of booking. Present a losing guest with a `409 Conflict` and a prompt to pick different dates, never a silent overwrite. > **Remember:** never implement "check, then write" for anything where two people might both pass the check. Push the correctness check into the database itself, as a constraint the database enforces, not a race application code can lose. ```knowledge-check { "questions": [ { "id": "system-design-airbnb-doublebooking-q1", "type": "mcq", "prompt": "Why is a unique constraint on (listing_id, date) a stronger fix for double-booking than checking availability in application code before inserting a booking?", "options": [ {"id": "a", "text": "Both approaches are equally safe under concurrency"}, {"id": "b", "text": "The constraint is enforced atomically by the database itself, closing the race window where two requests could both pass an application-level check before either writes"}, {"id": "c", "text": "Application-level checks are always slower"}, {"id": "d", "text": "A unique constraint prevents any two bookings from ever happening on the same listing"} ], "correct": "b", "explanation": "A check-then-write in application code has a window between the check and the write where a second request can slip through. A database constraint eliminates that window entirely, since the database rejects the conflicting write outright." } ] } ``` ### How does search stay fast with dozens of filters over millions of listings? Denormalize listing data, price, location, amenities, rating, an approximate availability signal, into a dedicated search index that handles combined location, facet, and full-text queries efficiently. Geospatial queries use the same geohash-style indexing idea as ride-hailing's nearby-driver search. Availability in the search index is a fast, approximate signal, "likely available," which is fine for filtering results even when slightly stale, because the actual booking attempt re-validates against the authoritative `BlockedDate` table regardless of what search showed. ### How does payment timing and review integrity work? Payment happens after a booking is confirmed: charge the guest, and pay out the host on a delay, commonly 24 hours after check-in, to allow room for an early cancellation or dispute. An idempotency key on the payment request, tied to the booking ID, guarantees retries from a network blip or a client double-submit never double-charge. Reviews are only allowed after a completed stay, enforced server-side, never just hidden in the UI. To reduce retaliatory reviews, Airbnb uses a **double-blind reveal**: both guest and host submit their reviews independently, and neither is shown publicly until both have submitted, or a fixed window (say 14 days) expires. Naming this mechanism is a strong answer if a review system comes up. ## Trade-offs and follow-up questions | Concern | Choice | Trade-off | |---|---|---| | Double-booking prevention | A database unique constraint or row lock at booking time | Correct under concurrency, at the cost of slightly higher write latency per booking | | Search freshness | Async sync from the listing database to the search index | Search can lag by minutes, but stays fully isolated from booking writes | | Availability calendar | Sparse rows for blocked dates only | Scales with actual bookings, not listings times 365 | | Payment timing | Capture at booking, payout to host after a delay | Protects against cancellation churn, adds payout-scheduling complexity | | Review integrity | Double-blind submission with a reveal window | Reduces retaliatory reviews, adds a pending-review state to track | **Q: Two guests click "book" on the same last-available night within the same millisecond. Walk through what happens.** A: Both requests open a transaction attempting to insert the same `BlockedDate` row, or acquire the same listing lock. The database serializes them; whichever commits first succeeds, and the second hits the constraint violation. The Booking Service returns `409 Conflict` to the loser with a prompt to pick different dates. No external coordination service is needed; the database's own guarantees handle it. **Q: How would you support instant-book versus host-approval-required listings?** A: A `requires_approval` flag on the listing. For approval-required listings, booking creates a pending record and places a temporary hold on the dates, using the same unique-constraint mechanism so no one else can grab them, with an expiry. If the host doesn't approve in time, a background job releases the hold. **Q: How do you keep search fast when filtering on dozens of amenity facets across millions of listings?** A: This is exactly what a dedicated search engine is for. It maintains an inverted index per facet, so a query like "wifi and pool and pet-friendly within 10km" becomes a fast intersection of index lists rather than a table scan, which is why listing search is never served from the relational booking database. ```knowledge-check { "questions": [ { "id": "system-design-airbnb-tradeoffs-q1", "type": "mcq", "prompt": "Why does Airbnb pay hosts on a delay (like 24 hours after check-in) rather than immediately at booking?", "options": [ {"id": "a", "text": "To reduce transaction fees"}, {"id": "b", "text": "To leave a window for early cancellations or disputes before money is irreversibly sent to the host"}, {"id": "c", "text": "Because payment processors require a mandatory delay"}, {"id": "d", "text": "Hosts prefer to be paid later"} ], "correct": "b", "explanation": "Delaying payout gives the system room to handle a cancellation or dispute cleanly before the funds have already left the platform, which is much harder to unwind after the fact." } ] } ``` 67:T34e6,Ticketmaster is a concurrency problem wearing a CRUD costume: thousands of people trying to buy the same 20 seats in the same second. This question tests whether you know how to actually prevent double-booking under real contention, not just say "use a transaction," and whether you can build fairness into a system without collapsing its throughput. ## Requirements **Functional requirements** - Browse events, view seat maps and availability. - Select seats and complete a purchase within a time-limited hold. - Handle a high-demand on-sale event with thousands of concurrent buyers for one show. - Support a waiting room or virtual queue for extreme-demand events. **Non-functional requirements** - Zero double-booking. This is the one correctness property that can never be relaxed. - High concurrency: tens of thousands of simultaneous requests for a few thousand seats at the exact moment tickets go on sale. - Fairness: no one should be able to skip the queue with bots or aggressive refreshing. - Reasonable latency even under peak load. A slow but correct queue beats a fast but broken one. > **Remember:** most requests in this system are supposed to fail. The job isn't to serve everyone, it's to fail the losing requests fast and fairly instead of letting them thrash the database. ```knowledge-check { "questions": [ { "id": "system-design-ticketmaster-requirements-q1", "type": "mcq", "prompt": "In a major on-sale event with 500,000 buyers for 5,000 seats, what is the actual design goal for the 495,000 requests that will fail?", "options": [ {"id": "a", "text": "To somehow let everyone succeed by adding more servers"}, {"id": "b", "text": "To fail them fast and fairly, without letting them overwhelm the database with wasted contention"}, {"id": "c", "text": "To ignore them entirely and let requests time out"}, {"id": "d", "text": "To randomly select which requests get processed at all"} ], "correct": "b", "explanation": "With 100:1 contention, most requests are mathematically guaranteed to fail. The design goal is to make that failure fast, fair, and cheap, rather than letting every request hammer the same contended rows." } ] } ``` ## Estimates Assume a major on-sale event: 5,000 seats, with 500,000 people trying to buy in the first 10 minutes, a realistic arena-tour scenario. - **Peak request rate:** 500,000 users hitting refresh or joining the queue over 10 minutes is about 830 requests/sec sustained, with a much sharper burst right at the on-sale second. - **Contention ratio:** 500,000 buyers for 5,000 seats is 100:1. That ratio is exactly why a naive "select, then update" approach collapses: the vast majority of requests are guaranteed to fail and need to fail fast, not thrash the database trying. - **Seat hold duration:** typically 5-10 minutes to complete checkout before a hold expires and the seat returns to the pool. - **Waiting room throughput:** if 5,000 seats sell out in about 2 minutes, checkout needs to sustain roughly 40+ completed purchases/sec at peak to drain the queue into that small inventory before it looks stalled. ## API ``` POST /queue/join { event_id } -> { queue_token, position_estimate } GET /queue/status?token= -> { status: "waiting"|"admitted", position } GET /events/{id}/seats -> { seat_map, availability } POST /seats/hold { event_id, seat_ids[] } -> { hold_id, expires_at } -- requires admitted queue_token POST /checkout { hold_id, payment_info } -> { order_id, status } POST /seats/release { hold_id } -- explicit release or auto on expiry ``` ## Data model ``` events id, venue_id, name, starts_at seats id, event_id, section, row, seat_number, status (available|held|sold) seat_holds id, seat_id, user_id, expires_at, status (active|completed|expired) orders id, user_id, event_id, seat_ids[], total, status, created_at ``` ``` seats id UUID PK event_id UUID status TEXT -- available | held | sold held_by UUID NULL hold_expires TIMESTAMPTZ NULL version INT -- optimistic concurrency token UNIQUE constraint on (event_id, section, row, seat_number) ``` Concurrency control lives in `seats.status` plus a version column, not in application logic alone. That's the detail the rest of this lesson builds on. ## High-level design ``` Client --> Waiting Room service (admits users at a controlled rate) --> issues queue_token | Admitted client --> Seat Selection service | POST /seats/hold --> atomic seat lock (DB row-level lock / Redis SETNX with TTL) | Checkout service --> payment --> on success: seat.status = sold; on failure/timeout: seat auto-released back to available | Hold-expiry reaper (background) sweeps expired holds back to available, independent of client behavior ``` ## Deep dives ### How do you actually prevent double-booking, not just "use a transaction"? The mechanism is an atomic conditional update, never a read-then-write from application code: ``` UPDATE seats SET status='held', held_by=$user, hold_expires=now()+interval '10 min', version=version+1 WHERE id=$seat_id AND status='available' AND version=$expected_version ``` If zero rows are affected, someone else already got there first, and the client is told immediately to pick a different seat. This is optimistic concurrency control: no long-held lock, just a compare-and-swap at the row level, which scales far better than a pessimistic lock under heavy contention on a small set of hot rows. An often faster-under-load alternative is Redis `SET seat:{id} {user_id} NX EX 600`, set-if-not-exists with a TTL, as the actual hold mechanism, with the database as the durable record synced asynchronously behind it. That trades a small window of eventual consistency for much higher throughput on the hottest path. > **Remember:** a single-row atomic compare-and-swap is enough here because the entire contested resource, one seat, lives on one row. No distributed lock, no two-phase commit needed. ```knowledge-check { "questions": [ { "id": "system-design-ticketmaster-cas-q1", "type": "mcq", "prompt": "Why does an atomic conditional update (WHERE status='available') scale better under heavy contention than a pessimistic row lock held for the duration of the transaction?", "options": [ {"id": "a", "text": "They perform identically under any load"}, {"id": "b", "text": "The conditional update never holds a lock while waiting; it either succeeds instantly or fails instantly, so losing requests don't queue up waiting on each other"}, {"id": "c", "text": "Pessimistic locks are not supported by relational databases"}, {"id": "d", "text": "Conditional updates only work for reads, not writes"} ], "correct": "b", "explanation": "Optimistic concurrency avoids making 499,999 losing requests wait in line behind a lock; each one gets an immediate, cheap failure instead of contending for a held lock." } ] } ``` ### Why does a hold-then-checkout flow matter, and who cleans up an abandoned hold? Never sell in one atomic step straight from browsing to sold. Always route through an explicit, time-boxed hold. This gives a buyer a fair window to complete payment without another buyer racing them for the same seat, while guaranteeing the hold expires, via the `hold_expires` field plus a background reaper, or the Redis TTL doing it automatically, so a seat never gets permanently stuck when someone abandons checkout. That reaper existing independently of any client action is critical. Never rely on a client calling `/seats/release` to free inventory, since clients disappear constantly: a closed tab, a crashed app, a lost connection. If payment fails or times out after a hold was granted, the seat has to return to available promptly, either because checkout explicitly releases it on failure, or, more safely, because the expiry reaper reclaims it regardless of whether checkout cleaned up after itself. ### How does the waiting room actually help, and how big should it be? For an extreme-demand on-sale, admitting all 500,000 simultaneous requests straight into seat selection would overwhelm the seat-locking path with near-total contention and wasted work, since most requests are guaranteed to lose anyway. Instead, a waiting room admits users into seat selection at a controlled rate matched to actual checkout throughput, a few thousand at a time, admitting more as holds expire or orders complete. This is implemented as a queue, either FIFO by join order or randomized to avoid rewarding the fastest-clicking bots. Its real contribution is moving contention out of the database and into a much cheaper "am I admitted yet" polling loop. Size the admission rate against observed checkout completion throughput, not raw incoming demand. If checkout reliably completes in an average of T seconds and you want, say, 10,000 users actively in the funnel at once, admit new users at roughly 10,000/T per second, adjusting dynamically based on real-time completion and hold-expiry rates so the admitted pool neither starves nor overwhelms the seat-locking layer. ### How do you stop bots from scalping past the queue? Layer several imperfect measures together, since no single one solves it alone: rate-limit queue-join per IP or account, require authentication before entering the queue to raise the cost of running many bot accounts, add a CAPTCHA or proof-of-work at the join step, and cap tickets per account per event. Naming the layered approach, rather than claiming any single measure "solves" scalping, is the strong interview answer. ## Trade-offs and follow-up questions | Decision | Benefit | Cost | |---|---|---| | Optimistic concurrency (compare-and-swap on the seat row) | No long-held locks, scales under contention | The client must handle "someone else got it" and retry seat selection | | Redis-based holds with a TTL | Very high throughput, automatic expiry | A second system that must stay consistent with the database's source of truth | | Waiting room before seat selection | Keeps database contention bounded regardless of demand spike size | Adds latency and complexity for the common case where a queue isn't even needed | | Explicit hold-then-checkout | Fair, prevents an accidental double-sell during payment processing | Seats sit "held but unsold" during the hold window, temporarily reducing visible availability | **Q: Two users click "buy" on the same seat within milliseconds of each other. Walk through exactly what happens.** A: Both requests race to the same atomic conditional update, or the same Redis `SETNX`. The underlying store guarantees only one succeeds. The losing request gets zero rows affected, or a `false`, and is immediately told the seat is unavailable, prompting reselection. No distributed lock or two-phase coordination is needed, since the entire contested resource lives on a single row. **Q: How do you decide the waiting room's admission rate?** A: Match it to observed checkout completion throughput, not to raw incoming demand, adjusting dynamically based on real-time completion and hold-expiry rates so the admitted pool neither starves nor overwhelms seat locking. **Q: What happens if the waiting room service itself goes down during a major on-sale?** A: The waiting room should be a thin, horizontally scalable, mostly stateless layer, with queue state in a distributed store rather than in process memory, so it's the easiest component to scale out and recover. It should fail toward "hold everyone in queue" rather than "let everyone through," since the seat-locking layer's correctness matters more than the waiting room's availability. An outage should degrade to slower admission, never bypass the queue into the contested path. ```knowledge-check { "questions": [ { "id": "system-design-ticketmaster-tradeoffs-q1", "type": "mcq", "prompt": "If the waiting room service fails during a major on-sale, what should it fail toward?", "options": [ {"id": "a", "text": "Letting everyone through immediately, bypassing the queue"}, {"id": "b", "text": "Holding everyone in queue rather than letting the seat-locking layer face unmoderated contention"}, {"id": "c", "text": "Shutting down the entire ticketing system"}, {"id": "d", "text": "Randomly admitting half of waiting users"} ], "correct": "b", "explanation": "The waiting room's job is to protect the seat-locking layer from unmoderated contention. Failing open (letting everyone through) would defeat that purpose exactly when it matters most." } ] } ``` 68:T4da2,An e-commerce store like Amazon has three parts that behave completely differently: a huge, read-heavy catalog people browse constantly, a cart that needs to feel instant, and a checkout flow that has to be perfectly correct, no overselling, no double charges, ever. This question is deliberately broad, so interviewers can watch you scope it: which part do you design deeply, and which do you sketch? ## Requirements **Functional requirements** - Browse and search a product catalog with availability shown per item. - Add, remove, and update items in a cart, and the cart persists across sessions and devices. - Checkout collects address and payment and confirms an order. - Purchases decrement inventory correctly, with zero overselling. - Returns and refunds update inventory and order state correctly. - Recommendations, "customers also bought," personalized to the shopper. **Non-functional requirements** - Zero overselling, the same class of correctness problem as a ticket-booking system, applied to inventory counts instead of seats. - High read throughput on the catalog; browsing vastly outnumbers buying. - Cart operations must feel instant, since friction here is a direct cause of abandoned carts. - Checkout correctness: no double-charging, no order created without a successful payment, or one clearly marked failed or pending. - Idempotency: a retried checkout submission, from a double-click or a network retry, must never create a duplicate order or a duplicate charge. - Consistency on inventory counts is required at the moment of purchase; eventual consistency is fine for search freshness and recommendations. > **Remember:** cart storage optimizes for availability and speed; checkout optimizes for strict correctness. Conflating the two gives you either a sluggish cart or a checkout flow with a real consistency hole. ```knowledge-check { "questions": [ { "id": "system-design-ecommerce-requirements-q1", "type": "mcq", "prompt": "Why do cart operations and checkout operations need different consistency guarantees?", "options": [ {"id": "a", "text": "They don't, both should use the strongest possible consistency"}, {"id": "b", "text": "A cart is low-stakes and recoverable, so it should favor speed and availability, while checkout involves real money and inventory, so it must favor strict correctness"}, {"id": "c", "text": "Carts are always stored client-side only"}, {"id": "d", "text": "Checkout doesn't actually need to be consistent, only fast"} ], "correct": "b", "explanation": "The cost of getting each one wrong is completely different: losing a cart edit is a minor annoyance fixed by re-adding an item, while a checkout consistency bug means a real double charge or a real oversold item." } ] } ``` ## Estimates Assume a large marketplace: 100 million active SKUs and 10 million orders a day. - **Orders:** 10,000,000 / 86,400 ≈ 116/sec average, 500+/sec at peak during a flash sale or holiday rush. - **Catalog browsing dominates:** with roughly 20 page views per completed order, catalog reads outnumber purchase writes by somewhere between 100:1 and 1000:1, the same read-skew shape seen in a social feed, which justifies the same response: aggressive caching, and a search index kept separate from the transactional inventory store. - **Cart traffic:** if each shopper touches their cart about 8 times per session across 50 million daily sessions, that's 400 million cart operations/day, roughly 4,600/sec average, several times higher at peak. Cart size itself is tiny, a handful of line items, well under 10 KB, so this is a latency problem, not a storage problem. - **Checkout attempts:** with cart abandonment commonly in the 60-80% range, 10 million completed orders imply roughly 33 million checkout attempts/day, about 380/sec average. - **Inventory contention:** most SKUs see no contention at all, but a flash-sale item with limited stock creates the exact same 100:1 contention shape as a ticket on-sale, concentrated on a small number of hot rows. - **Returns:** assume roughly 5% of orders are returned within 30 days, a real secondary write path that must never corrupt inventory counts. ## API ``` GET /catalog/search?q=&cursor= -> { items[], next_cursor } GET /items/{id} -> { details, price, available_qty } GET /cart -> { items[], subtotal } POST /cart/items { item_id, qty } -> { items[], subtotal } PUT /cart/items/{item_id} { qty } DELETE /cart/items/{item_id} POST /checkout/init { cart_id } -> { checkout_id, reserved_items[] } POST /checkout/{id}/address { shipping_address } POST /checkout/{id}/payment { payment_method } POST /checkout/{id}/confirm { idempotency_key } -> { order_id, status } GET /checkout/{id}/status -> { status } GET /orders/{id} -> { status, items[], tracking } POST /orders/{id}/return { item_ids[], reason } -> { return_id, status } GET /recommendations?item_id= or ?user_id= ``` ## Data model ``` items id, name, description, price, category inventory item_id, warehouse_id, available_qty, reserved_qty -- split available vs reserved carts id, user_id (or session_id for guests), updated_at cart_items cart_id, item_id, qty checkouts id, cart_id, status (started|reserved|paid|confirmed|failed|abandoned), idempotency_key, created_at, expires_at checkout_reservations checkout_id, item_id, qty, warehouse_id -- mirrors inventory.reserved_qty orders id, checkout_id, user_id, total, status, created_at order_items order_id, item_id, qty, price_at_purchase payments id, order_id, provider_ref, amount, status, idempotency_key returns id, order_id, item_id, qty, status (requested|received|refunded), created_at -- search is a separate, async-indexed system item_search item_id, tokens[], category, price, rating ``` Two design decisions live in this schema. Splitting `available_qty` from `reserved_qty` on the inventory row, instead of one raw count, is what lets checkout reserve stock atomically without yet committing to a completed sale. And the `checkouts` table is the piece a simpler CRUD design wouldn't have: an explicit state machine tracking one checkout attempt from start through payment through order confirmation, distinct from the cart (pre-checkout, casual, mutable) and the order (post-checkout, immutable, authoritative). ```knowledge-check { "questions": [ { "id": "system-design-ecommerce-datamodel-q1", "type": "mcq", "prompt": "Why does the inventory table split available_qty and reserved_qty instead of using one raw stock count?", "options": [ {"id": "a", "text": "It's purely for reporting purposes"}, {"id": "b", "text": "It lets checkout atomically claim stock the moment a purchase starts, without yet committing to a sale that payment might still fail"}, {"id": "c", "text": "Databases require at least two columns per table"}, {"id": "d", "text": "It has no functional purpose, only historical convention"} ], "correct": "b", "explanation": "Payment can take time and can fail. Splitting the count lets the system reserve stock immediately at checkout start, then either commit it on payment success or release it back to available on failure." } ] } ``` ## High-level design ``` Browse/search path (read-heavy): Client --> Search API --> item_search (async-indexed from items/inventory changes) --> Catalog API --> cached item details (in front of items/inventory DB) Cart (low-latency, high availability): Client --> Cart API --> Cart store (fast key-value store, keyed by user_id/session_id, with a periodic durable sync so a guest cart survives a restart, or a login merges a guest cart into the user's account cart) Checkout (strict correctness): Client --> POST /checkout/init --> atomically reserve inventory: UPDATE inventory SET available_qty = available_qty - qty, reserved_qty = reserved_qty + qty WHERE item_id=$id AND available_qty >= qty --> checkout.status = "reserved" | Client --> POST /checkout/{id}/payment --> Payment provider (external) --> webhook/callback | on success: checkout.status = "paid" --> create order (idempotent, keyed on checkout_id) --> checkout.status = "confirmed" --> commit reservation (reserved_qty -= qty, permanently sold) | on failure/timeout: checkout.status = "failed" --> release reservation (available_qty += qty, reserved_qty -= qty) Abandoned-checkout reaper (background): sweeps checkouts stuck in "started"/"reserved" past a timeout (e.g., 15-30 min) and releases their reservations. Returns path: Client --> Returns API --> return.status = requested --> (warehouse receives item) --> return.status = received --> inventory.available_qty += qty --> trigger refund --> return.status = refunded ``` ## Deep dives ### How do you prevent overselling, exactly? Same mechanism as a ticket-booking system: an atomic conditional update on the inventory row. ``` UPDATE inventory SET available_qty = available_qty - qty WHERE item_id = $id AND available_qty >= qty ``` If zero rows are affected, there wasn't enough stock, and checkout fails immediately with a clear "insufficient inventory" response, rather than proceeding into a state that would require an awkward rollback. For a high-contention flash-sale item, the same Redis-based reservation pattern used for ticket sales, an atomic decrement with a bound check, trades a small consistency window for much higher throughput than hitting the relational database on every attempt. Since inventory is a quantity rather than discrete labeled seats, the check `available_qty >= requested_qty` also naturally supports partial-fulfillment logic ("only 1 left, but you asked for 2"), which a seat system doesn't need. ### Why split reserved from available instead of decrementing straight to "sold"? Payment processing takes real time, sometimes several seconds with fraud checks, and it can fail. If inventory were decremented straight to "sold" before payment confirms, a failed payment would mean carefully reversing a state that other concurrent purchases may already be relying on. Splitting into `available_qty` (purchasable right now) and `reserved_qty` (claimed, pending payment) makes the state machine explicit: reserve atomically when checkout starts, then either commit (payment succeeds, order confirmed) or release (payment fails or times out, stock returns to available). This needs a background reaper too, the same shape as releasing an expired ticket hold, for reservations stuck in "reserved" past a timeout, so an abandoned checkout doesn't lock inventory forever. > **Remember:** reserve early, at the start of checkout, not at the final confirm step. Losing an item to a competing shopper in the middle of filling out a shipping form is a far worse experience than a small, bounded inventory lock. ```knowledge-check { "questions": [ { "id": "system-design-ecommerce-reservation-q1", "type": "mcq", "prompt": "Why does inventory get reserved at checkout/init rather than waiting until payment actually succeeds?", "options": [ {"id": "a", "text": "Reserving early has no real benefit"}, {"id": "b", "text": "Waiting until payment success risks a shopper completing the entire checkout form only to be told at the last step that the item sold out"}, {"id": "c", "text": "Payment providers require inventory to be reserved before they'll process a charge"}, {"id": "d", "text": "Reserving late would make the database faster"} ], "correct": "b", "explanation": "Reserving at init trades a temporary, bounded inventory lock for a checkout flow that, once started, is very unlikely to fail due to a stock race partway through." } ] } ``` ### How does cart persistence work, and how do guest and logged-in carts merge? A cart needs to survive a page refresh, an app restart, and a login from a different device, but it's low-stakes compared to an order, so it should optimize for availability and speed over strict durability. The common real-world design: cart state lives primarily in a fast key-value store keyed by session (guest) or user ID (logged in), with periodic async persistence to a relational table so it isn't purely ephemeral. On login, a guest cart merges into the user's persistent cart; a simple rule (sum quantities for items in both, keep items unique to either) is enough, since a cart merge conflict has no correctness implications, unlike a checkout conflict. ### Why isn't checkout one big database transaction? Checkout is a sequence, `started` → `reserved` → `paid` → `confirmed`, with `failed` and `abandoned` branches, precisely because it coordinates with an external system, the payment provider, whose latency and failure modes you don't control. You cannot roll back a call to an external payment API inside a database transaction, so checkout can't be modeled as one atomic operation spanning "reserve inventory, call payment provider, create order." Instead, each state transition is its own independently retriable, idempotent step, and the `checkouts` table itself is the durable record of how far an attempt got, so a crash or retry at any point can resume or correctly unwind from the last known state instead of leaving an inconsistent partial write behind. ### How do you stop a double-click or a network retry from creating two orders? The client generates, or the checkout flow assigns at `init`, an idempotency key tied to that specific checkout attempt. `POST /checkout/{id}/confirm` is built so a repeated call with the same key returns the existing result, the order already created, rather than making a new one. This is typically enforced with a unique constraint on `orders.checkout_id` plus a check-before-insert, or a dedicated idempotency-key lookup table that short-circuits a duplicate request before it ever reaches the payment provider a second time. The trickiest case is an ambiguous failure: the payment call times out and you genuinely don't know whether it succeeded. Never blindly retry a raw charge call here, that risks a real double charge. Instead, query the payment provider's own status endpoint using the same idempotency key as the original attempt (most providers support exactly this) before deciding whether to retry or treat it as failed. This defers the ambiguity to the one system that actually knows the truth. ### How do multiple warehouses and returns fraud get handled? Real marketplaces track inventory per warehouse, not as one global count, and checkout has to pick which warehouse fulfills an order, usually the nearest one with enough stock. That turns the single-row atomic update into a routing decision first, then the same reserve-then-commit pattern against the chosen warehouse's row. If no single warehouse has enough stock, an order can split across warehouses into multiple shipments. A return is its own multi-step workflow that has to survive partial failure: requested, then received at the warehouse, verified before crediting inventory to prevent a refund claimed without the item actually being returned, then inventory restored, then refund issued. Model this as an explicit state machine rather than one transaction, since "received at the warehouse" is an external, asynchronous event that can't live inside a database transaction. Each transition should be independently idempotent, since a step like issuing a refund may itself need retries against a flaky payment provider. ## Trade-offs and follow-up questions | Decision | Benefit | Cost | |---|---|---| | Available/reserved split with an atomic conditional update | Zero overselling without long-held locks | Needs a reservation-timeout reaper for abandoned checkouts | | Redis-backed cart with async durable sync | Fast, available cart operations | A rare failure could lose very recent cart edits, acceptable since carts are low-stakes and recoverable | | Explicit checkout state machine, not one transaction | Correctly coordinates with an external payment provider, crash-safe at every step | More states to design and test than a naive single-transaction approach | | Reserve inventory at checkout/init, not at confirm | Prevents losing the item to a competing shopper mid-checkout | Needs an abandoned-checkout reaper so inventory doesn't sit locked indefinitely | | Idempotency keys on confirm and on the payment charge | Eliminates double-order and double-charge risk from retries | Needs an idempotency-key store with a bounded TTL and careful scoping | | Explicit returns state machine | Survives partial failure, prevents return fraud via receipt verification | Refunds aren't instant; the user sees a multi-step status | **Q: A flash sale drops 1,000 units of a popular item, and 50,000 people try to buy it in the first minute. How is this different from a ticket on-sale, if at all?** A: Structurally identical: the same 100:1 contention shape, just applied to a quantity instead of discrete seats. The same atomic conditional decrement, or Redis-based reservation, prevents overselling, and the same reserve-then-commit pattern applies. If demand is extreme enough, a waiting-room layer ahead of checkout keeps the same contention off the hot path. **Q: A user's payment succeeds, but the server crashes before it can create the order record. What happens on the next request?** A: The client retries confirm with the same idempotency key. The handler first checks whether an order already exists for this checkout, or checks the payment provider's status using the original key, before attempting to charge or create anything new. Since payment already succeeded upstream, it detects that and creates the order idempotently, rather than double-charging or leaving the user charged with no order. **Q: How do you prevent a user from claiming a refund without actually returning the item?** A: The returns state machine requires an explicit "received at warehouse" transition, verified by staff or a scanning process, before inventory is restored and a refund triggers. Nothing is credited purely on the basis of a customer's request, the same principle as verifying a claimed action before trusting it, used elsewhere for view-count fraud. ```knowledge-check { "questions": [ { "id": "system-design-ecommerce-tradeoffs-q1", "type": "mcq", "prompt": "Why must a payment timeout never be handled by simply retrying the raw charge call?", "options": [ {"id": "a", "text": "Retrying is always fine as long as it's fast"}, {"id": "b", "text": "A timeout means the outcome is genuinely unknown, and blindly retrying the charge risks a real double charge if the original request actually succeeded"}, {"id": "c", "text": "Payment providers block all retries automatically"}, {"id": "d", "text": "Retrying would violate the idempotency key format"} ], "correct": "b", "explanation": "The correct response to an ambiguous timeout is to check the payment provider's own status endpoint with the original idempotency key, deferring to the system that actually knows what happened, rather than guessing and risking a double charge." } ] } ``` 69:T3cf7,A payment system is what the checkout flow treats as an external black box: the thing that actually moves money. This is the strictest-consistency design in the whole course, because the domain has zero tolerance for the sloppy trade-offs that are fine elsewhere. No double charges, no lost money, full auditability, and regulatory rules (PCI compliance) that shape the architecture directly instead of being an afterthought. ## Requirements **Functional requirements** - Process a payment (charge a card or other method) for an order. - Support full and partial refunds. - Support disputes and chargebacks initiated by the payment network or the cardholder. - Provide an auditable transaction history. **Non-functional requirements** - Idempotency is non-negotiable. The same charge request, retried, must never result in two charges. - Strong consistency on money movement: a payment's state must be unambiguous at all times, never silently lost. - Security: PCI-DSS compliance constrains where raw card data is even allowed to live. - Auditability: every state transition is logged, immutable, and traceable, required for debugging and for regulatory and dispute purposes. - Reliability over raw throughput. This system would rather be slow and correct than fast and wrong. > **Remember:** every other system in this course has picked availability or speed over consistency somewhere. This one doesn't. If an interviewer asks you to trade correctness for speed here, the right answer is to push back. ```knowledge-check { "questions": [ { "id": "system-design-payments-requirements-q1", "type": "mcq", "prompt": "Why does a payment system prioritize correctness and reliability over raw throughput, unlike most other systems in this course?", "options": [ {"id": "a", "text": "Payment systems never actually need to scale"}, {"id": "b", "text": "The cost of getting it wrong is a real, unrecoverable loss of money or a double charge, which is categorically worse than the cost of being briefly slow"}, {"id": "c", "text": "Throughput and correctness are the same thing"}, {"id": "d", "text": "Payment providers handle all correctness concerns automatically"} ], "correct": "b", "explanation": "Unlike a stale like count or a slightly delayed feed, a payment error has a real financial consequence with no acceptable margin, which is exactly why this system leans so heavily toward correctness." } ] } ``` ## Estimates Reuse the checkout volume from the e-commerce design: roughly 10 million successful payments a day, 33 million payment attempts a day including failures and abandonment. - **Peak rate:** 33,000,000 / 86,400 ≈ 380/sec average, several times higher during a flash sale, modest compared to the read-heavy systems earlier in this course. That's the point: this system's hard problem is correctness, not throughput. - **Refunds:** assuming roughly 5% of orders are refunded, that's 500,000 refund operations a day, a much lower-volume, non-latency-critical path. - **Audit retention:** financial and regulatory requirements typically mandate multi-year retention, often 7 years, a very different storage lifecycle than something like raw analytics events, which can be pruned aggressively. - **Disputes:** a small fraction of transactions, typically well under 1%, but each one needs a fully reconstructable history. This is a low-volume, high-stakes-per-record workload, the opposite shape from most systems in this course. ## API ``` POST /payments/charge { order_id, amount, payment_method_token, idempotency_key } -> { payment_id, status: "pending"|"succeeded"|"failed" } GET /payments/{id} -> { status, amount, order_id, history[] } POST /payments/{id}/refund { amount?, reason, idempotency_key } -> { refund_id, status } POST /webhooks/payment-provider -- inbound async status updates from the provider GET /payments/{id}/audit-log -> { events[] } -- immutable event history ``` Notice `payment_method_token`, not a raw card number. The API never accepts a raw card number from your own backend at all; tokenization happens client-side directly against the payment provider, covered in the PCI deep dive below. ## Data model ``` payments id, order_id, amount, currency, status (pending|succeeded|failed|refunded| partially_refunded), provider_ref, idempotency_key, created_at, updated_at payment_events id, payment_id, event_type (charge_attempted|charge_succeeded|charge_failed| refund_issued|dispute_opened), payload, created_at -- append-only, immutable refunds id, payment_id, amount, status, provider_ref, created_at disputes id, payment_id, reason, status, opened_at, resolved_at UNIQUE constraint on payments.idempotency_key ``` `payment_events` is deliberately append-only and immutable: never update a row, only insert. This is the audit trail, and it's what makes disputes and debugging possible. The `payments.status` column is a derived, cached summary; `payment_events` is the actual source of truth for what happened, and in what order. ```knowledge-check { "questions": [ { "id": "system-design-payments-datamodel-q1", "type": "mcq", "prompt": "Why is payment_events an append-only log instead of just updating payments.status directly as things change?", "options": [ {"id": "a", "text": "It's redundant and adds no real value"}, {"id": "b", "text": "A single mutable status field destroys history, while an append-only log preserves the full sequence of what happened, required for disputes and audits"}, {"id": "c", "text": "Append-only tables are always faster to query"}, {"id": "d", "text": "It's only needed for regulatory reasons in certain countries"} ], "correct": "b", "explanation": "Once a status field is overwritten multiple times, you can no longer reconstruct the full timeline of a transaction. The append-only log is what lets you answer 'what happened, when' for a dispute or an audit." } ] } ``` ## High-level design ``` Checkout service --> POST /payments/charge (idempotency_key from the checkout flow) | Payment service: check idempotency_key first (short-circuit duplicates) | write payment_events "charge_attempted" --> call external payment provider (Stripe/Adyen/etc.) with the SAME idempotency key passed through | +---------+----------+ | | synchronous response async webhook callback (immediate accept/ (final settlement status, decline for cards) common for bank transfers, | 3D-Secure follow-up, etc.) | | +---------+----------+ | write payment_events (succeeded/failed) --> update payments.status --> notify order service (order confirmed / payment failed) ``` ## Deep dives ### Why does idempotency have to be enforced at two separate boundaries? This is the single most important property in the whole system. It has to hold twice: between your checkout client and your payment service, where the idempotency key from checkout is enforced via the unique constraint on `payments.idempotency_key`, so a retried charge call with the same key returns the existing payment record instead of creating a new one, and between your payment service and the external provider, where you pass that same key through to the provider's own API. Stripe, Adyen, and similar providers support this natively, guaranteeing that even if your own service's retry logic double-sends the outbound call, the provider still only charges once. Two layers, because a failure can happen on either side of that boundary, and each side needs its own protection. > **Remember:** idempotency at only one layer isn't idempotency. A retry can originate on either side of a network call, so both sides need their own dedup key. ```knowledge-check { "questions": [ { "id": "system-design-payments-idempotency-q1", "type": "mcq", "prompt": "Why isn't a single idempotency key check at the payment service enough to prevent all double charges?", "options": [ {"id": "a", "text": "It is enough, a second check adds nothing"}, {"id": "b", "text": "A failure or retry can also happen between the payment service and the external provider, which needs its own idempotency protection independent of the client-facing check"}, {"id": "c", "text": "Payment providers don't support idempotency keys"}, {"id": "d", "text": "Idempotency keys expire immediately after use"} ], "correct": "b", "explanation": "The client-to-service boundary and the service-to-provider boundary are two separate points where a retry can occur, so each needs its own idempotency guarantee to fully close the double-charge risk." } ] } ``` ### Why do webhooks exist instead of just a synchronous response? Card charges often do resolve synchronously, an approval or decline within the request. But many payment flows are inherently asynchronous: bank transfers settle over days, 3D-Secure authentication needs an out-of-band step from the customer, and disputes are opened by the card network days or weeks later. The system has to treat "final settlement status" as something that can arrive well after the initial request, delivered through a webhook the provider calls back into your system. Webhook handlers must themselves be idempotent, since providers routinely retry webhook delivery, and must verify the request's authenticity, a signature check against the provider's signing secret, before trusting anything in the payload. An unauthenticated webhook endpoint is a direct path to payment fraud: an attacker could simply POST a fake "payment succeeded" event to mark an order paid without actually paying. ### How does PCI compliance actually shape the architecture? The single biggest architectural consequence of PCI-DSS: your own backend should ideally never touch a raw card number at all. Card data is tokenized client-side, directly against the payment provider's own SDK or hosted fields. Your frontend collects card details into a component the provider controls, which returns an opaque token, and that token, not the raw number, is what flows through `payment_method_token` in the API above. This dramatically shrinks your PCI compliance scope, since you're handling tokens, not cardholder data, and it's why "just store the card number in our database" is never the right answer in a payments design interview. Say this explicitly; it's a strong signal. ### How do you handle a failed charge, and one where you genuinely don't know the outcome? A decline, insufficient funds, a fraud flag, an expired card, is a normal expected outcome, not a system failure. Write it to `payment_events`, set the payment's status to failed, and let checkout release its inventory reservation and prompt for a different payment method. The harder case is an ambiguous failure: the provider call times out, and you genuinely don't know if it succeeded. Never blindly retry a raw charge here, that risks a real double charge. Query the provider's status endpoint using the original idempotency key before deciding whether to retry or treat it as failed, deferring the ambiguity to the one system that actually knows the truth instead of guessing. ### How are refunds and disputes tracked without corrupting the original charge record? A refund is its own idempotent, auditable operation with its own idempotency key. Never mutate the original payment row's amount; insert a `refunds` row instead, and let the payment's status become `refunded` or `partially_refunded`, preserving the original charge event intact for audit purposes. Disputes are typically initiated by the payment network, not your own API, and arrive as a webhook event, tracked in a `disputes` table through evidence submission and resolution. The append-only `payment_events` log is what lets you reconstruct the full timeline of a disputed transaction on demand, often a contractual or regulatory requirement, not a nice-to-have. ## Trade-offs and follow-up questions | Decision | Benefit | Cost | |---|---|---| | Idempotency keys at two layers (client-to-service, service-to-provider) | Eliminates double-charge risk from a retry at either boundary | Needs careful key scoping and a durable idempotency-key store | | Append-only payment_events, derived payments.status | Full audit trail, supports dispute reconstruction, never loses history | More storage than mutating one row in place; queries need "latest event" logic | | Tokenization at the client, never touching raw card numbers server-side | Drastically reduces PCI compliance scope | The frontend must integrate the provider's SDK rather than a plain form | | Async webhook handling for final settlement status | Correctly models genuinely asynchronous methods (bank transfers, 3DS, disputes) | Webhook handlers must be idempotent and signature-verified, a second ingestion path | **Q: Your service calls the payment provider's charge API, but the network times out before you get a response. What do you do?** A: Never blindly retry the raw charge; the original call may have already succeeded on the provider's side. Retry using the same idempotency key, so the provider returns the existing result instead of charging again, or explicitly query the provider's status endpoint for that key before deciding the outcome. Only after confirming genuine non-completion do you mark the payment failed and release the reservation. **Q: Why not just store payments.status and skip the separate payment_events audit log?** A: A single mutable status field destroys history. You can no longer answer what happened, in what order, once a row has been overwritten multiple times. Disputes, regulatory audits, and debugging all require the full sequence of events, not just the current state, which is exactly what the append-only log preserves and the status column can't. **Q: A payment provider sends you a webhook, but you can't tell if it's genuinely from them or spoofed. How do you handle that?** A: Verify the webhook's cryptographic signature against the provider's published signing secret before processing anything in the payload. Every major provider signs webhook payloads specifically so receivers can authenticate them; skipping this check is a direct fraud vector. ```knowledge-check { "questions": [ { "id": "system-design-payments-tradeoffs-q1", "type": "mcq", "prompt": "Why must a webhook's signature be verified before trusting a 'payment succeeded' event it delivers?", "options": [ {"id": "a", "text": "Signature verification is optional hardening, not strictly necessary"}, {"id": "b", "text": "An unverified webhook endpoint could be sent a forged success event by an attacker, marking an order paid without any real payment"}, {"id": "c", "text": "Webhooks are never actually used for payment status"}, {"id": "d", "text": "Signatures are only relevant for refunds, not charges"} ], "correct": "b", "explanation": "Without signature verification, anyone who discovers the webhook URL could POST a fabricated success event, making signature verification a mandatory first step rather than an optional one." } ] } ``` 6a:T3dd4,A logging and monitoring platform, think Datadog, Splunk, or an internal setup built on the ELK stack, is infrastructure for infrastructure: every other system quietly depends on it. This question tests whether you understand splitting the write path from the read path at extreme volume, the real difference between logs and metrics, and how alerting has to trade detection speed against false-positive noise. ## Requirements **Functional requirements** - Collect logs (structured or unstructured text events) from many services. - Collect metrics (numeric time series: request rate, latency, error rate, CPU). - Search logs by service, time range, and free text or fields. - Alert when a metric crosses a threshold, or a log pattern signals an incident. **Non-functional requirements** - Extremely high write throughput. Every service in the organization emits continuously; this system cannot become the bottleneck for everything else. - The write path must never block the emitting application. A slow logging pipeline should never slow down the actual service being watched. - Query and search latency matters for incident response: someone debugging a live outage needs results in seconds. - Tiered retention: recent data (hours to days) needs fast access; older data (weeks to months) can be slower and cheaper. - Alerting must balance detection speed against false-positive fatigue. > **Remember:** a monitoring system that can slow down or crash the applications it watches has failed at its one job. Everything about the write path in this design exists to prevent that. ```knowledge-check { "questions": [ { "id": "system-design-logging-requirements-q1", "type": "mcq", "prompt": "Why is \"never block the emitting application\" treated as a non-negotiable requirement for a monitoring system?", "options": [ {"id": "a", "text": "It's a nice-to-have that can be relaxed under normal conditions"}, {"id": "b", "text": "A monitoring system's entire purpose is to observe other services, so if it slows or crashes them, it has actively made the thing it's supposed to help worse"}, {"id": "c", "text": "Blocking only matters for metrics, not for logs"}, {"id": "d", "text": "Applications are expected to handle monitoring outages themselves"} ], "correct": "b", "explanation": "The whole point of observability tooling is to watch the real system without becoming part of its critical path. A monitoring system that can take down what it monitors defeats its own purpose." } ] } ``` ## Estimates Assume a mid-to-large organization: 5,000 service instances, each emitting continuously. - **Logs:** if each instance emits about 50 log lines/sec on average (more under load or errors), that's 250,000 log lines/sec across the fleet, about 21.6 billion lines a day. At roughly 300 bytes per line, that's about 6.5 TB/day of raw log volume. - **Metrics:** if each instance reports about 50 distinct metrics every 10 seconds, that's 5 metric points/sec/instance × 5,000 = 25,000 points/sec, about 2.16 billion points a day. Each point is small, a timestamp, a number, and a few tags, tens of bytes, but sampled far more frequently and queried far more often (every dashboard refresh, every alert check) than logs are ever read. - The gap between log volume (terabytes a day, mostly written once and read rarely) and metric query volume (constant reads against a much smaller footprint) is exactly why logs and metrics end up as architecturally different systems under one product. - **Retention:** a hot tier for fast queries commonly covers 7-14 days; a cold, compressed tier extends to months or years for compliance and historical analysis. ## API ``` POST /ingest/logs { service, level, message, fields{}, timestamp } -- high-volume, fire-and-forget from clients POST /ingest/metrics { metric_name, value, tags{}, timestamp } -- high-volume GET /logs/search?query=&service=&from=&to=&cursor= -> { logs[], next_cursor } GET /metrics/query?metric=&tags=&from=&to=&aggregation= -> { series[] } -- e.g. avg/p99/sum over time buckets POST /alerts { metric_or_query, condition, threshold, notify_channels[] } GET /alerts/{id}/history -> { firings[] } ``` Ingestion endpoints are optimized purely for high-throughput accept-and-buffer, not for validation-heavy processing. Anything expensive, parsing, indexing, enrichment, happens asynchronously downstream, never inside the request the emitting application is waiting on. ## Data model ``` -- Logs: append-only event stream, indexed for search log_events id, service, level, message, fields (JSON), timestamp -- indexed into an inverted-index search engine (Elasticsearch-style), not queried directly against a row store at read time -- Metrics: time-series, optimized for range + aggregation queries metric_points metric_name, tags (label set), timestamp, value -- stored in a time-series-optimized store, NOT a general relational table — row-per-point relational storage does not scale to billions of points/day -- Alerts alert_rules id, name, metric_or_query, condition, threshold, evaluation_window alert_firings id, alert_rule_id, fired_at, resolved_at, severity ``` ## High-level design ``` Service instances --> local lightweight agent (buffers, batches, never blocks the app) | (logs) (metrics) | | Log ingestion pipeline Metrics ingestion pipeline (Kafka-style buffer --> (Kafka-style buffer --> stream processor --> aggregator/downsampler --> indexer) time-series DB) | | Search index (Elasticsearch-style) Time-series store (Prometheus/ -- hot tier fast, cold tier InfluxDB/TimescaleDB-style) compressed/archived -- hot + downsampled cold tiers | | +------------------+------------------+ | Query API (search, dashboards) | Alert evaluator (polls/streams metrics against alert_rules) --> fires --> notification system (reuse the channel-routing pattern from the notification service design) ``` ## Deep dives ### Why aren't logs and metrics just one system? Logs are unstructured-ish text, written far more often than read, and searched deeply, full-text, arbitrary field filters, but rarely, usually by one engineer investigating a specific incident. Metrics are strictly numeric, written frequently and read even more frequently, since every dashboard panel and every alert evaluation is a metrics read, and they need fast time-range aggregation like an average or a p99 over a window, not text search. Those completely different access patterns justify genuinely different storage engines underneath: an inverted-index search engine for logs, and a purpose-built time-series database for metrics that stores and compresses timestamp-value-tag tuples far more efficiently than a general row store would. A design that tries to cram both into the same general-purpose database underperforms at both jobs. > **Remember:** logs and metrics look similar on the surface, both are "data about what happened," but their read patterns are opposites: logs are read rarely and deeply, metrics are read constantly and numerically. That difference is what forces two separate storage engines. ```knowledge-check { "questions": [ { "id": "system-design-logging-splitstore-q1", "type": "mcq", "prompt": "Why do logs and metrics need genuinely different storage engines instead of sharing one general-purpose database?", "options": [ {"id": "a", "text": "It's purely a historical accident, not a real technical need"}, {"id": "b", "text": "Their access patterns are fundamentally different: logs are searched deeply but rarely, while metrics are read constantly for numeric aggregation, and each pattern needs its own optimized engine"}, {"id": "c", "text": "Logs and metrics cannot both exist in the same organization"}, {"id": "d", "text": "Metrics are always more important than logs, so they get their own database"} ], "correct": "b", "explanation": "A single general-purpose store optimized for neither full-text search nor time-series aggregation would perform worse at both jobs than two purpose-built systems would." } ] } ``` ### How does the write path avoid ever slowing down the application it's monitoring? Every emitting service runs a lightweight local agent that batches log lines and metric points in a local buffer and ships them asynchronously, rather than the application making a synchronous network call per line or point. This is non-negotiable. If the ingestion pipeline is degraded or unreachable, the agent buffers locally, bounded, with a sensible drop policy under sustained backpressure, rather than blocking the application's own thread. Both ingestion endpoints then write straight into a high-throughput durable buffer the instant they receive data, decoupling "accept the data" from "process, index, and store the data." Downstream stream processors consume from that buffer to parse, enrich, downsample, and index at whatever pace the storage backend can sustain. This buffer is exactly what absorbs a traffic spike, a service emitting a burst of error logs during an incident, ironically exactly when you most need the logging system to not fall over, without ever pushing that backpressure onto the emitting applications. ### How do you avoid paying to store every raw data point forever? A common pattern: keep raw-resolution data in a hot tier for a short window, days, then progressively downsample into 1-minute, then 1-hour rollups as data ages into cold storage. Recent debugging genuinely needs fine-grained resolution, but a dashboard showing CPU usage over the last six months doesn't need every 10-second sample, and storing it that way wastes enormous space for no real query benefit. The same tiering idea applies to logs: hot and fully indexed for recent data, compressed and archived, often with reduced indexing fidelity, for older data kept mainly for compliance or rare historical lookup. Log search itself always hits the inverted-index engine, never the raw ingestion buffer or a full-table scan, with indexing happening asynchronously as part of the pipeline, the same separate-the-write-path-from-the-read-index pattern that shows up in search-heavy designs elsewhere. A brief indexing lag of a few seconds between a log being emitted and becoming searchable is an accepted trade-off. ### How does alerting avoid paging someone for a one-second blip? An alert evaluator continuously checks metric values against alert rules. The core tension: evaluate too eagerly on noisy, single-point data and you get flapping alerts that page someone for a meaningless blip, which causes alert fatigue and makes people start ignoring real incidents too. Evaluate too conservatively, long averaging windows, high thresholds, and you're slow to catch a genuine problem. The standard fix is a sustained-condition requirement: "error rate must exceed 5% for 3 consecutive 1-minute windows," not a single sample, combined with severity tiering, a brief mild breach logs for later review but doesn't page anyone, while a sustained severe breach pages on-call immediately. For highly variable traffic, rate-of-change or anomaly detection against a learned baseline beats a static threshold, since normal daily or weekly cycles shouldn't trigger a "traffic dropped" alert just because 3am traffic is naturally low. ## Trade-offs and follow-up questions | Decision | Benefit | Cost | |---|---|---| | Separate log store (search index) vs. metric store (time-series DB) | Each is optimized for its actual access pattern | Two storage systems to run instead of one | | Local agent buffering, async shipping | The emitting application is never slowed by monitoring | A small window of possible data loss if the buffer overflows during a sustained outage | | Ingestion buffer ahead of processing | Absorbs traffic spikes without back-pressuring producers | Adds a component and a small end-to-end delay before data is queryable | | Tiered retention with downsampling | Massive storage savings for old data | Old data loses fine-grained resolution, acceptable since it's rarely needed at that detail | | Sustained-condition alerting, not single-sample | Fewer false-positive pages, less alert fatigue | Slightly slower detection of genuine, brief incidents | **Q: During a major incident, log volume spikes 20x as every affected service logs errors aggressively. How does the system avoid falling over exactly when it's needed most?** A: The local agent buffer and the ingestion buffer are both sized to absorb multi-x traffic spikes without back-pressuring the emitting services, since ingestion is decoupled from processing. If the downstream indexer genuinely can't keep up, indexing lag increases, logs become searchable a bit later than usual, rather than ingestion failing outright or applications slowing down. That's graceful degradation instead of a hard failure, exactly the trade-off the write-path requirement demands. **Q: How would you detect a slow, gradual anomaly, like a slow traffic decline, that a simple threshold alert would miss?** A: Compare current metric behavior against a learned baseline for the same time of day and day of week, accounting for normal cyclical patterns, and alert on a significant deviation from that baseline rather than a fixed number. This catches a genuinely anomalous slow decline that a threshold calibrated for a sudden drop would miss. **Q: Why not just log everything and compute metrics from log queries instead of running two systems?** A: Computing aggregates like average latency or p99 by querying raw log text at read time doesn't scale to dashboard-refresh and alert-evaluation frequencies. A time-series database precomputes exactly the structure needed for fast range and aggregation queries, while a log search index is built for a completely different query shape. Using logs as a metrics backend pays an expensive full-text-search cost for what should be a cheap numeric aggregation. ```knowledge-check { "questions": [ { "id": "system-design-logging-tradeoffs-q1", "type": "mcq", "prompt": "Why does the system respond to an ingestion overload by increasing search indexing lag rather than dropping incoming logs or slowing the emitting applications?", "options": [ {"id": "a", "text": "Dropping logs would actually be the better choice here"}, {"id": "b", "text": "Because the write path must never block applications, graceful degradation (slower search availability) is the correct trade-off compared to a hard failure"}, {"id": "c", "text": "Indexing lag is always zero regardless of load"}, {"id": "d", "text": "The system has no way to detect an overload"} ], "correct": "b", "explanation": "Given the stated requirement that the write path must never block the emitting application, letting search results arrive a bit later during extreme load is the acceptable failure mode, not dropping data or slowing down services." } ] } ``` 6b:T2e29,You've now studied a full set of case studies one at a time, with time to think. A real interview gives you none of that: one prompt, 40 minutes, and someone watching how you think out loud. This lesson is about closing that gap. There is no new system design content here, only the script, the timing, and the rubric for turning what you've learned into something you can actually perform under pressure. ## How to run a full 40-minute mock round Pick any case study from this section and treat it as if you'd never seen it before. Set a timer. The shape below is the same one every lesson in this section already follows, which is exactly the point: the framework should feel automatic by now. 1. **Clarify (2-4 minutes).** Ask before you design. What's in scope, what's out? What's the read:write ratio? Is strong consistency required anywhere specific? What's the rough scale? A strong candidate spends this time extracting constraints instead of jumping straight to a diagram, and lets the interviewer's answers shape the design that follows, rather than just going through the motions of asking questions and then ignoring the answers. 2. **State requirements out loud (1-2 minutes).** Functional, then non-functional. This is fast because you just clarified it. 3. **Estimate (3-5 minutes).** Real numbers: requests/sec, storage, read:write ratio. Say the arithmetic out loud. This number should drive design choices later, not sit unused. 4. **Define the API (2-3 minutes).** The contract between client and system. This forces you to nail down what data flows where before you draw boxes. 5. **Design the data model (3-5 minutes).** Tables or documents, and which field is the natural sharding or partition key. 6. **Draw the high-level design (5-8 minutes).** Boxes and arrows, then narrate the request path through them out loud. 7. **Deep-dive (10-15 minutes).** Go deep on whatever the interviewer steers toward, or the single hardest part of the system if they don't steer you anywhere. This is where most of the signal comes from; don't stay shallow here to save time elsewhere. 8. **Trade-offs and follow-ups (3-5 minutes).** Name what breaks first, and how you'd fix it. Answer curveballs by adapting your existing design, not restarting from scratch. > **Remember:** the clock is not your enemy, vague scope is. Almost every mock round that runs out of time ran out because the first five minutes were spent drawing boxes instead of asking questions. ```knowledge-check { "questions": [ { "id": "system-design-mock-script-q1", "type": "mcq", "prompt": "What is the most common reason a candidate runs out of time in a 40-minute system design round?", "options": [ {"id": "a", "text": "The deep-dive phase always takes too long no matter what"}, {"id": "b", "text": "Skipping or rushing the clarifying-questions phase, which leads to designing the wrong thing or re-scoping midway through"}, {"id": "c", "text": "Spending too much time on the data model"}, {"id": "d", "text": "Asking too many clarifying questions up front"} ], "correct": "b", "explanation": "Time spent clarifying scope early is what prevents a costly mid-interview pivot later. Skipping it to 'save time' usually costs far more time than it saves." } ] } ``` ## The 40-minute grading signals: what a strong round actually looks like Grade yourself, or a study partner, against these signals after every mock round: - Time on requirements and estimates stays under about 10 minutes total. - You drive the conversation and propose the next step yourself, rather than waiting to be asked "so what's next?" - The deep dive gets real detail on one component, a data model, an algorithm, a protocol, not just more boxes on the same diagram. - You make at least two explicit "I chose X over Y because Z" statements during the round, not just a list of technologies. - You handle a curveball (the interviewer changes a requirement mid-design) by adapting your existing design, not by starting over. For confident systems, ones you could explain start to finish in under 10 minutes out loud with no pause longer than 3 seconds, that fluency is the actual target for every case study in this section. For weaker areas, the honest goal is different: nail requirements, the API, and the high-level design even if the deep dive is where you slow down. Knowing which of your systems are which is more useful than pretending they're all equally solid. ## A general-purpose scoring rubric Use this rubric for any case study in this section, not just the ones it was originally written for: - Asked clarifying questions before designing, and let the answers actually shape the design. - Covered both functional and non-functional requirements explicitly, and used the non-functional ones to justify later design choices. - Named at least two real trade-offs, with a reasoned pick, not just a list of options. - Handled a follow-up ("what if this server dies," "what if traffic goes up 10x") confidently, with a concrete change to the design. - Was honest about weaknesses in the design instead of pretending it was complete. A senior answer names what it would do with more time, rather than hand-waving past a gap. > **Remember:** an interviewer isn't grading whether you can recite a known-good architecture. They're grading whether you can reason about trade-offs live, including admitting where your design is weaker. ```knowledge-check { "questions": [ { "id": "system-design-mock-rubric-q1", "type": "mcq", "prompt": "What does a strong system design candidate do when asked about a weakness in their own design, rather than pretending it doesn't exist?", "options": [ {"id": "a", "text": "Deflects the question and moves to a different topic"}, {"id": "b", "text": "Names the weakness honestly and states what they'd do about it with more time or information"}, {"id": "c", "text": "Insists the design has no weaknesses"}, {"id": "d", "text": "Refuses to discuss anything not already covered"} ], "correct": "b", "explanation": "Interviewers are listening for judgment under uncertainty, not a flawless design. Naming a real gap and how you'd address it is a stronger signal than claiming the design is complete." } ] } ``` ## The 15-minute speed round: a warm-up drill Before a full 40-minute mock, or as a standalone drill, run this fast variant on two different case studies back to back: 1. State functional and non-functional requirements out loud, 60 seconds. 2. Draw the high-level box diagram (client, load balancer, service, cache, database), 3-4 minutes. 3. Name the single hardest part of the system and describe, in two sentences, how you'd approach it, without actually solving it, 2 minutes. 4. Stop. Move to the next design. This drills structuring a design under real time pressure without freezing on where to start. Think of it as a warm-up, not a substitute for the full 40-minute round: it builds the habit of moving fast through the parts of the framework that shouldn't take long, so you have more time left for the parts that should. ## The hard part, per system: a recap table For each case study in this section, the interview almost always narrows to one genuinely hard decision. If you can name it from memory before opening the lesson, you've internalized the design. | System | The hard part | |---|---| | URL shortener | Collision-free code generation at scale (a Key Generation Service beats checking for collisions on every write) | | Rate limiter | Distributed counting without a single point of failure | | Notification service | Fan-out to many channels plus delivery and read tracking, without one slow channel blocking the others | | Job queue | Delivery guarantees (at-least-once, not exactly-once) and what that means for handler design | | Chat / messaging | Message ordering and delivery guarantees across devices, without the server ever seeing plaintext | | Analytics pipeline | Reconciling a fast approximate stream with a slow exact batch job for late-arriving data | | Multi-tenant SaaS | Choosing an isolation model (Pool, Bridge, Silo) and enforcing it at the database layer, not just in code | | Social feed / Twitter | Fan-out on write vs. fan-out on read for celebrity accounts | | Search autocomplete | Precomputing top-K per trie node instead of ranking live on every keystroke | | File storage (Dropbox) | Content-addressed chunking for resume, dedup, and safe ref-counted deletion | | Google Docs | Choosing and correctly implementing OT or CRDT-based conflict resolution | | Code review system | Re-validating mergeability atomically at merge time, not trusting a stale display state | | Netflix | CDN-first delivery and proactive edge placement for a predictable catalog | | YouTube | Elastic, unpredictable upload and cache demand for a catalog too large to pre-place | | Spotify | CDN-bound audio delivery plus licensing enforcement that must propagate in seconds | | Uber / ride-sharing | Real-time geospatial matching (geohash or a quadtree) at scale | | Airbnb | Preventing double-booking with an atomic database constraint, not a check-then-write | | Ticketmaster | Converting extreme contention into a controlled admission queue, not just rate limiting | | E-commerce cart/checkout | A crash-safe checkout state machine that survives an external payment call it can't roll back | | Payment system | Idempotency at two layers, plus an immutable audit log as the real source of truth | | Logging/monitoring | Never letting the write path block the very applications it's observing | ## Trade-offs and follow-up questions **Q: How do I know if I'm ready to stop drilling and just take the real interview?** A: When you can run the 40-minute script on any case study in this section without checking notes, and your deep dive consistently goes into real detail rather than staying at the box-diagram level. If you're still pausing to remember requirements or the API shape, that's a sign to run a few more speed rounds on that specific system, not the whole section again. **Q: The interviewer keeps interrupting with follow-up questions before I finish my planned structure. Is that a bad sign?** A: No. Interviewers change a requirement mid-design specifically to see whether you adapt your existing design or panic and restart. Treat an interruption as a chance to show that skill, not as a derailment. Adjust the part of the design the new constraint actually affects, and say out loud what changes and why. **Q: I finished a design in 25 minutes with time to spare. Did I move too fast?** A: Probably. Extra time almost always means the deep dive was too shallow. Use remaining time to go one level deeper into whatever component you glossed over, discuss a second failure mode, or walk through a concrete numeric example, rather than just stopping early. ```knowledge-check { "questions": [ { "id": "system-design-mock-followup-q1", "type": "mcq", "prompt": "An interviewer changes a requirement partway through your design (e.g., \"actually, assume 10x more traffic\"). What's the strongest response?", "options": [ {"id": "a", "text": "Restart the design from scratch with the new number in mind"}, {"id": "b", "text": "Adapt the specific parts of the existing design the new constraint actually affects, and explain what changes and why"}, {"id": "c", "text": "Ignore the new information and finish the original plan"}, {"id": "d", "text": "Ask the interviewer to keep the original assumption instead"} ], "correct": "b", "explanation": "A curveball is testing adaptability, not memorization. Adjusting the affected parts of an already-solid design, out loud, is exactly the skill the interviewer is checking for." } ] } ``` 6c:T5798,High-level design asks "how many servers do you need?" Low-level design asks a completely different question: "what classes exist, what does each one own, and how do they talk to each other?" Picture being asked to design a parking lot, or an elevator, or a movie-ticket app, in about 45 minutes. The interviewer is not counting how many design patterns you can name. They are watching whether your classes are clean, whether you could add a new feature without rewriting everything, and whether you know what breaks when two people use the system at the exact same moment. Like HLD, this has a fixed order of steps. Learn the order once, and every problem in this section becomes the same six steps with different nouns. > **The six steps** — **R**equirements, **E**ntities, **R**elationships, **I**nterfaces, **C**oncurrency, **E**xtensibility. Say it as *"Real Engineers Rarely Ignore Corner Errors."* ## What the interviewer is actually grading Picture the interviewer holding a scorecard. It has four rows, and they matter in this order. | They're checking | Good looks like | Bad looks like | |---|---|---| | **A clean object model** | Each class does one clear job, with a name a normal person would recognise | One giant `Manager` class doing everything; classes named `Helper`, `Util`, `Data` | | **Sensible relationships** | Parts that can't exist without their whole are owned by it; the pieces likely to change sit behind an interface | Long inheritance chains; everything wired directly to everything else | | **Room to grow** | "Add a new vehicle type" or "add a new payment method" means writing one new class | Adding anything means editing five old files and hoping nothing breaks | | **Correctness when two things happen at once** | You can say out loud which piece of shared data is at risk and how it's protected | Two users book the same seat and the bug ships to production | Two habits separate people who pass from people who don't: - **They build small and finished, not big and half-done.** Ten classes with real methods beat thirty class names with nothing inside them. - **They talk about the actual problem, not about pattern names.** "A `ParkingSpot` knows its size and whether it's free" is design. Saying "I'll use the Strategy pattern" without saying what actually varies is just vocabulary. > **Remember:** the strongest signal in an LLD interview is that a plausible new requirement fits in as one new class, not five edited ones. ```knowledge-check { "questions": [ { "id": "ip45-lld-01-signal-q1", "type": "mcq", "prompt": "Which of these is the strongest sign of a good LLD answer?", "options": [ {"id":"a","text":"Naming as many of the 23 classic design patterns as will fit"}, {"id":"b","text":"Adding a new vehicle type or payment method means adding one class, not editing an existing if/else chain"}, {"id":"c","text":"Having the largest possible number of classes"}, {"id":"d","text":"Using inheritance for every relationship in the design"} ], "correct": "b", "explanation": "Interviewers test what happens when they add a plausible new requirement mid-interview. Name-dropping patterns, piling up classes, and reaching for inheritance by default are all things weaker designs tend to do." } ] } ``` ## Step 1 — Requirements: who uses this, and what do they do Spend about five minutes here. It works the same way HLD's first step does, just one level closer to the code. **Ask who the actors are.** For a parking lot: a driver, an attendant, an admin. Each actor's needs turn into use cases, and use cases turn into the public methods on your main class. **Write the use cases as verbs.** Park a vehicle. Retrieve a vehicle. Pay. Check availability. These map almost directly onto the methods you'll write later, which is exactly why writing them down first is worth the minute it takes. **Ask questions that actually change the design**, and skip the ones that don't: | Question | Why it matters | |---|---| | How many kinds of X are there, and will more show up later? | Decides between an enum, a family of classes, or a pluggable strategy | | Is there more than one Y? (floors, branches, currencies) | Decides whether Y is just a field, or its own class | | Do we need history, or only the current state? | Decides whether "events" need to exist as their own objects | | Who is allowed to do what? | Decides where permission checks live | | Is this one process, or many at once? | Decides whether you need locks, or immutable data, or database-level checks | | Does this live in memory, or get saved somewhere? | Decides whether you need a repository interface | **Then say the scope out loud**: "I'll build parking, un-parking, spot assignment, and fee calculation in memory. I'll define a `PaymentProcessor` interface, but I won't wire up a real payment gateway." > **Remember:** a question like "will this change later?" is the interviewer handing you your extension point. Use it. ```knowledge-check { "questions": [ { "id": "ip45-lld-01-requirements-q1", "type": "mcq", "prompt": "Which clarifying question most directly changes your class design?", "options": [ {"id":"a","text":"\"What programming language should I use?\""}, {"id":"b","text":"\"Will new vehicle types get added later, and does the fee change per type?\" — the answer decides between an enum, a family of subclasses, and a pluggable pricing strategy"}, {"id":"c","text":"\"How many users will the system have?\""}, {"id":"d","text":"\"Should I write tests?\""} ], "correct": "b", "explanation": "Questions about what might change and how often decide where your extension points go. Scale questions belong in an HLD interview; language and testing habits don't reshape the class model." } ] } ``` ## Step 2 — Entities: turning nouns into classes **Start by listing every noun.** "A *driver* parks a *vehicle* in a *spot* on a *floor* of a *parking lot*, gets a *ticket*, and makes a *payment*." That sentence alone hands you six candidate classes. Not every noun deserves to be a class, though. Sort them: | If the noun is… | Model it as… | |---|---| | Something with an identity that changes over time | An **entity** (`Vehicle`, `Ticket`, `User`) | | A value with no identity of its own | A **value object**, ideally one that never changes (`Money`, `TimeSlot`, `Address`) | | A small, fixed set of options | An **enum** (`VehicleSize`, `SpotStatus`, `PaymentStatus`) | | Behaviour that might vary | An **interface** with several implementations (`PricingStrategy`, `NotificationChannel`) | | Just a detail of something else | A plain **field**, not a class (`colour`, `licencePlate`) | | Something that coordinates several other things | A **service** (`ParkingLotService`, `BookingService`) | | A collection you need to search | A **repository** (`SpotRepository`, `TicketRepository`) | Two habits worth picking up right away: - **Reach for an enum before a boolean or a bare string.** `SpotStatus.OCCUPIED` beats `is_taken = True`, because tomorrow there's a `RESERVED` status and an `OUT_OF_SERVICE` status, and a boolean has nowhere to put them. - **Make value objects unchangeable.** `Money`, `Point`, `TimeRange` should never change after they're built. That removes a whole category of bugs where two things secretly share the same mutable object, and it makes those objects safe to hand to another thread. Here's the noun list turned into small, runnable code — about the level of detail an interviewer wants to see on the whiteboard: ```python from dataclasses import dataclass from enum import Enum class VehicleSize(Enum): MOTORCYCLE = 1 COMPACT = 2 LARGE = 3 class SpotStatus(Enum): FREE = "free" OCCUPIED = "occupied" OUT_OF_SERVICE = "out_of_service" @dataclass(frozen=True) # value object: never changes, has no identity of its own class Money: paise: int def __add__(self, other: "Money") -> "Money": return Money(self.paise + other.paise) def __str__(self) -> str: return f"Rs {self.paise / 100:.2f}" @dataclass class Vehicle: # entity: identified by its plate plate: str size: VehicleSize class ParkingSpot: # entity: has a lifecycle def __init__(self, spot_id: str, size: VehicleSize): self.spot_id = spot_id self.size = size self.status = SpotStatus.FREE self.vehicle: Vehicle | None = None def can_fit(self, vehicle: Vehicle) -> bool: return self.status == SpotStatus.FREE and self.size.value >= vehicle.size.value def occupy(self, vehicle: Vehicle) -> None: if not self.can_fit(vehicle): raise ValueError(f"spot {self.spot_id} cannot take {vehicle.plate}") self.vehicle, self.status = vehicle, SpotStatus.OCCUPIED def release(self) -> None: self.vehicle, self.status = None, SpotStatus.FREE spot = ParkingSpot("A-01", VehicleSize.COMPACT) bike = Vehicle("KA-01-1234", VehicleSize.MOTORCYCLE) truck = Vehicle("KA-05-9999", VehicleSize.LARGE) assert spot.can_fit(bike) and not spot.can_fit(truck) # a compact spot fits a bike, not a truck spot.occupy(bike) assert spot.status is SpotStatus.OCCUPIED and not spot.can_fit(bike) spot.release() assert spot.status is SpotStatus.FREE print("entity model behaves:", Money(4990) + Money(1010)) ``` ```java + import java.util.Objects; public class Main { enum VehicleSize { MOTORCYCLE(1), COMPACT(2), LARGE(3); final int rank; VehicleSize(int rank) { this.rank = rank; } } enum SpotStatus { FREE, OCCUPIED, OUT_OF_SERVICE } // Value object: final fields, no identity, equality based on the value itself. static final class Money { private final long paise; Money(long paise) { this.paise = paise; } Money plus(Money other) { return new Money(this.paise + other.paise); } @Override public boolean equals(Object o) { return o instanceof Money m && m.paise == paise; } @Override public int hashCode() { return Objects.hash(paise); } @Override public String toString() { return String.format("Rs%.2f", paise / 100.0); } } record Vehicle(String plate, VehicleSize size) {} static class ParkingSpot { private final String spotId; private final VehicleSize size; private SpotStatus status = SpotStatus.FREE; private Vehicle vehicle; ParkingSpot(String spotId, VehicleSize size) { this.spotId = spotId; this.size = size; } boolean canFit(Vehicle v) { return status == SpotStatus.FREE && size.rank >= v.size().rank; } // Idiomatic Java: throw an exception the caller can catch, instead of // returning a boolean that's easy to ignore. void occupy(Vehicle v) { if (!canFit(v)) throw new IllegalStateException("spot " + spotId + " cannot take " + v.plate()); this.vehicle = v; this.status = SpotStatus.OCCUPIED; } void release() { this.vehicle = null; this.status = SpotStatus.FREE; } SpotStatus status() { return status; } } public static void main(String[] args) { ParkingSpot spot = new ParkingSpot("A-01", VehicleSize.COMPACT); Vehicle bike = new Vehicle("KA-01-1234", VehicleSize.MOTORCYCLE); Vehicle truck = new Vehicle("KA-05-9999", VehicleSize.LARGE); assert spot.canFit(bike) && !spot.canFit(truck); spot.occupy(bike); assert spot.status() == SpotStatus.OCCUPIED; spot.release(); assert spot.status() == SpotStatus.FREE; System.out.println("entity model behaves: " + new Money(4990).plus(new Money(1010))); } } ``` > **Remember:** if a "thing" in your design is really just two booleans pretending to be a state, turn it into one enum before you write another line. ```knowledge-check { "questions": [ { "id": "ip45-lld-01-entities-q1", "type": "mcq", "prompt": "You're modelling whether a parking spot is free. Why pick an enum like `SpotStatus` over a plain `isOccupied` boolean?", "options": [ {"id":"a","text":"Enums use less memory than booleans"}, {"id":"b","text":"More statuses are coming — RESERVED, OUT_OF_SERVICE, CLEANING — and a boolean would force you to bolt on extra flags that can combine into nonsense, while an enum just grows by one case"}, {"id":"c","text":"Booleans cannot be compared to each other"}, {"id":"d","text":"Enums are required by the State pattern"} ], "correct": "b", "explanation": "Two booleans give you four combinations, and at least one of them makes no sense. An enum only ever allows real states, and it grows cleanly — that's why \"reach for an enum, not a boolean\" is a habit worth having." } ] } ``` ## Step 3 — Relationships and the UML you'll actually use You will draw a class diagram at some point. You need five arrows for it, not the full UML spec. ``` ┌──────────────────┐ │ ParkingLot │ class box: name / fields / methods ├──────────────────┤ │ - name: str │ - private │ + floors: List │ + public ├──────────────────┤ │ + park(v): Ticket│ └──────────────────┘ RELATIONSHIPS A ──────▷ B inheritance "A IS-A B" Car ──▷ Vehicle A ┈┈┈┈┈▷ B implements "A fulfils B" CreditCard ┈▷ PaymentMethod A ◆────── B composition "A OWNS B, B dies with A" Floor ◆── Spot A ◇────── B aggregation "A HAS B, B lives on" Team ◇── Player A ───────> B association "A uses/knows B" Order ──> Customer A ┈┈┈┈┈┈> B dependency "A mentions B briefly (a parameter)" ``` Put **multiplicity** on each end of an arrow: `1`, `0..1`, `1..*`, `*`. `ParkingLot 1 ◆── 1..* Floor` reads as "one lot owns at least one floor." The one distinction interviewers actually check for is **composition vs. aggregation**. Picture it this way: - **Composition** — think of a house and its rooms. A room without its house makes no sense. Delete the `Floor`, and its `ParkingSpot`s go with it. - **Aggregation** — think of a sports team and its players. Delete the `Team`, and the `Player`s are still real people who play elsewhere. A `Playlist` works the same way with its `Song`s. Ask yourself one question to tell them apart: *if I destroy the whole thing, does the part still make sense on its own?* Yes → aggregation. No → composition. Sketching a sequence diagram for the main use case is also worth thirty seconds, because it forces you to decide who calls whom: ``` Driver ParkingLotService SpotAllocator TicketRepo │ park(vehicle) │ │ │ ├────────────────>│ │ │ │ │ findSpot(vehicle) │ │ │ ├────────────────────>│ │ │ │<─── spot ───────────┤ │ │ │ spot.occupy(vehicle) │ │ │ save(ticket) │ │ │ ├─────────────────────────────────────>│ │<──── ticket ────┤ │ │ ``` > **Remember:** ask "does the part still make sense if the whole is gone?" A room doesn't survive its house; a song survives its playlist. ```knowledge-check { "questions": [ { "id": "ip45-lld-01-uml-q1", "type": "mcq", "prompt": "A `Playlist` holds `Song` objects that also appear in other playlists and exist in the music library on their own. What relationship is that?", "options": [ {"id":"a","text":"Composition — the playlist owns the songs"}, {"id":"b","text":"Aggregation — the songs exist on their own and are shared across playlists, so deleting one playlist must never delete the songs"}, {"id":"c","text":"Inheritance — a playlist is a kind of song collection"}, {"id":"d","text":"Dependency — the playlist only mentions songs briefly, as a parameter"} ], "correct": "b", "explanation": "Ask the lifecycle question: destroy the whole, and does the part still make sense? Songs outlive playlists, so this is aggregation (a hollow diamond). Rooms don't outlive a house, so that's composition." } ] } ``` ## Steps 4–6 — Interfaces, concurrency, extensibility **Step 4 — write the public surface of each class.** What does it accept, and what does it return? Design mistakes usually surface right here, the moment you write it down. ``` from abc import ABC, abstractmethod class PricingStrategy(ABC): # something that varies → an interface @abstractmethod def price(self, hours: float, size: "VehicleSize") -> int: ... class ParkingLotService: # something that coordinates → a service def park(self, vehicle: "Vehicle") -> "Ticket": ... def unpark(self, ticket_id: str) -> int: ... # returns the fee, in paise def availability(self) -> dict["VehicleSize", int]: ... ``` Three rules for this step: - **Only put an interface where you genuinely expect change** — pricing, payment, notifications, storage — and use plain concrete classes everywhere else. An interface with exactly one implementation and no realistic second one is just extra work with no payoff. - **Return real objects, not raw primitives**, whenever a primitive could be misread. `Money` is clearer than a bare `int`; a `TicketId` is clearer than a `str` when a plate number is also a string. - **Check for valid input in the constructor**, so an object can never exist in a broken state in the first place. **Step 5 — concurrency.** Say out loud: *"the shared mutable state here is the set of free spots"* — or seats, or inventory, whatever fits the problem — then say what protects it. The full treatment lives in the Concurrency lesson later in this section, but at interview speed, your answer is always one of these: | Situation | What protects it | |---|---| | Two threads might grab the same slot or seat | A lock around "check, then take," or an atomic compare-and-swap | | A number shared across threads | An atomic counter, never a plain `count += 1` | | Data that's shared but never changed | Nothing needed — it can't go wrong if it never changes | | Independent items | A lock per item, not one giant lock for everything | | Multiple processes or servers | The database enforces it: a unique constraint, or a conditional `UPDATE` | **Step 6 — extensibility.** Close by walking a plausible new requirement through your design out loud: *"if we add electric vehicles with charging spots, I add an `ELECTRIC` size and a `ChargingSpot` subclass. The allocator doesn't change, because it only ever asks `can_fit`."* If that walkthrough means editing five existing classes, redesign before the interviewer points it out. Three shapes of change to prepare for: *a new type* should mean a new class, *a new rule* should mean a new strategy, and *a new listener for an event* should mean a new observer. > **Remember:** an interface with one implementation and no plausible second one is a cost with no benefit. Only add one where change is actually expected. ```knowledge-check { "questions": [ { "id": "ip45-lld-01-interfaces-q1", "type": "mcq", "prompt": "When should you reach for an interface instead of a plain concrete class?", "options": [ {"id":"a","text":"For every class, so the design stays as flexible as possible"}, {"id":"b","text":"At the exact points you genuinely expect to change — pricing rules, payment methods, notification channels, storage — where a second implementation is likely or already needed"}, {"id":"c","text":"Only for classes that will be unit tested"}, {"id":"d","text":"Never; interfaces belong to HLD, not LLD"} ], "correct": "b", "explanation": "Interfaces pay off wherever behaviour genuinely varies, and cost you extra layers everywhere else. An interface with one implementation and no realistic second one is exactly the kind of over-design reviewers mark down." } ] } ``` ## Quick recap **The six steps and roughly how long each takes:** | Step | Minutes | What you produce | |---|---|---| | 1. Requirements | 5 | Actors, use-case verbs, the questions that matter, a stated scope | | 2. Entities | 8 | Nouns sorted into entities, value objects, enums, services, repositories | | 3. Relationships | 8 | A class diagram with the five arrows and multiplicities | | 4. Interfaces | 10 | Real method signatures on the core classes; interfaces where things vary | | 5. Concurrency | 7 | The shared mutable state, named, plus how it's protected | | 6. Extensibility | 5 | One new requirement, walked through the design out loud | - Nouns become classes, verbs become methods, small fixed sets become enums, changing behaviour becomes an interface. - Prefer enums over booleans, prefer unchangeable value objects over mutable bags of fields, and validate inside the constructor. - Prefer composition over inheritance, and use "does the part survive the whole?" to tell composition from aggregation. - One job per class. No class named `Manager`, `Helper`, or `Util`. - Say out loud which piece of state is shared and mutable, and how it's protected — before anyone asks. - Finish by walking a plausible new requirement through your design. **What's next**: the OOP and SOLID lessons make steps 2 through 4 much sharper. The pattern lessons give you ready answers to "what varies here." The concurrency lesson covers step 5 properly. And from lesson 9 onward, you'll run this whole framework end to end on the problems you're most likely to be asked. 6d:T6c82,Almost everyone can recite "encapsulation, abstraction, inheritance, polymorphism" from memory. Far fewer can say why encapsulation actually matters when someone is reviewing their code, or when inheritance is the wrong tool, or what "tight coupling" costs in a real bug report. This lesson closes that gap. You'll leave it able to defend each pillar as a decision, not just name it. ## The four pillars, as decisions you can defend **Encapsulation — hide the data, expose safe actions.** This isn't about typing `private` in front of a field. The real point is: **an object should never let outside code put it into a broken state.** Picture a bank account. If any code anywhere can just set `balance = -500`, the rule "balance never goes negative" has to be remembered and re-checked by every single piece of code that touches an account. That's fragile. Move the rule inside the account instead, and it only has to be right once. ```python # Weak: the rule "balance never goes negative" lives in every caller's head. class BadAccount: def __init__(self): self.balance = 0 # anyone can write anything here # Strong: the rule lives in one place, and the class enforces it. class Account: def __init__(self, opening_paise: int = 0): if opening_paise < 0: raise ValueError("opening balance cannot be negative") self._balance = opening_paise # private by convention @property def balance(self) -> int: # read-only view return self._balance def deposit(self, paise: int) -> None: if paise <= 0: raise ValueError("deposit must be positive") self._balance += paise def withdraw(self, paise: int) -> None: if paise > self._balance: raise ValueError("insufficient funds") self._balance -= paise acct = Account(10_000) acct.deposit(5_000) acct.withdraw(2_000) assert acct.balance == 13_000 for bad in (lambda: acct.withdraw(999_999), lambda: acct.deposit(-1), lambda: Account(-5)): try: bad() raise AssertionError("invalid operation was allowed") except ValueError: pass print("invariants held; balance =", acct.balance) ``` Here's the payoff: if a bug report says "balance went negative," you now have exactly three methods to check, not the whole codebase. And here's a trap worth knowing: **writing a public getter and a public setter for every field is not encapsulation.** A setter that accepts anything is just a public field wearing a disguise. Real encapsulation means exposing *actions* (`withdraw`) that keep the object's rules intact, not raw access to its fields. **Abstraction — show what something does, hide how.** `PaymentProcessor.charge(amount)` tells you nothing about whether it's Stripe or Razorpay underneath, so your code never has to care. Abstraction is what lets you swap one for the other later without touching anything else. People mix up abstraction and encapsulation constantly, so here's the one line that separates them: **encapsulation hides data. Abstraction hides implementation.** | | Abstraction | Encapsulation | |---|---|---| | Hides | Complexity — the *how* | Data — the internal state | | Goal | Give a simple front door to something complicated | Stop invalid changes to internal state | | Typical tool | An interface, an abstract class, a well-named method | Private fields, properties | | Example | `car.start()` hides the ignition sequence and fuel injection | `self.__balance` can't be poked from outside the class | ```python class BankAccount: def __init__(self, balance): self.__balance = balance # encapsulation: name-mangled, not reachable from outside def deposit(self, amount): # abstraction: the caller never sees HOW this is checked if amount <= 0: # or stored — just that deposit() does the right thing raise ValueError("Deposit must be positive") self.__balance += amount @property def balance(self): return self.__balance # controlled read access — this is the encapsulation part ``` `deposit()` is abstraction: it gives the caller one simple verb and hides the validation underneath. `__balance` plus the read-only `balance` property is encapsulation: it stops `account.__balance = -1000` from skipping the rules entirely (Python renames `__balance` internally so outside code can't reach it directly). The two work as a pair: abstraction shapes the *interface*, encapsulation decides *who gets to touch what* behind it. **Inheritance — share a contract, not a shortcut to reuse code.** The one legitimate reason to inherit is that the child is genuinely, always substitutable for the parent — a `SavingsAccount` really is an `Account` everywhere an `Account` is expected. Inheriting purely to avoid retyping a method is the single most common design mistake in this whole topic, and the next section shows exactly why. **Polymorphism — one call, many behaviours.** This is the thing that gets rid of long chains of `if type == ...`. ```python from abc import ABC, abstractmethod class Shape(ABC): @abstractmethod def area(self) -> float: ... class Circle(Shape): def __init__(self, r: float): self.r = r def area(self) -> float: return 3.14159 * self.r ** 2 class Rectangle(Shape): def __init__(self, w: float, h: float): self.w, self.h = w, h def area(self) -> float: return self.w * self.h # One line calls .area() on anything. Adding Triangle means adding a class — nothing here changes. shapes: list[Shape] = [Circle(1), Rectangle(2, 3)] total = sum(s.area() for s in shapes) assert abs(total - 9.14159) < 1e-6 print(f"total area = {total:.5f}") ``` Here's a quick test for whether polymorphism is doing real work: **can you add a new type without touching any existing code?** If adding `Triangle` means hunting down an `if shape_type == ...` chain somewhere and editing it, you've written types without actually using polymorphism. **Python doesn't even require a shared parent for this to work.** This is called **duck typing**: "if it walks like a duck and quacks like a duck, treat it like a duck." ```python class Circle: def __init__(self, r): self.r = r def area(self): return 3.14159 * self.r ** 2 class Square: # note: does NOT inherit from anything def __init__(self, side): self.side = side def area(self): return self.side ** 2 for shape in [Circle(2), Square(3)]: print(shape.area()) # works on both — Python never checks a shared ancestor ``` When that loop runs, Python doesn't ask "is this a `Shape`?" anywhere. It just calls whatever `.area()` method the object happens to have. This is looser than Java, where the compiler checks a declared interface before your code even runs. **Operator overloading is polymorphism applied to symbols like `+` and `==`.** Python routes those symbols to methods with special names: ```python class Vector: def __init__(self, x, y): self.x, self.y = x, y def __add__(self, other): return Vector(self.x + other.x, self.y + other.y) def __eq__(self, other): return self.x == other.x and self.y == other.y v = Vector(1, 2) + Vector(3, 4) # this line is really Vector(1, 2).__add__(Vector(3, 4)) ``` Python has no special-case rule for `+` on a `Vector`. The `+` symbol is *defined* to call `.__add__()` on whatever sits on its left, and `Vector` happens to provide one. That call returns a brand new `Vector(4, 6)`. > **Remember:** encapsulation hides data, abstraction hides how something works. A public getter-and-setter pair is not encapsulation — it's a field wearing a disguise. ```knowledge-check { "questions": [ { "id": "ip45-lld-02-pillars-q1", "type": "mcq", "prompt": "A class has a public getter and setter for every single one of its private fields. What has that actually achieved?", "options": [ {"id":"a","text":"Proper encapsulation, since the fields themselves are private"}, {"id":"b","text":"Basically nothing — a public setter is a public field with extra typing; real encapsulation means exposing actions that protect the object's rules (like withdraw), not accessors that let outside code set anything"}, {"id":"c","text":"Abstraction, because callers now go through methods"}, {"id":"d","text":"Polymorphism, because the setters could be overridden"} ], "correct": "b", "explanation": "Encapsulation is about who is responsible for keeping an object valid. If anyone can set any field to any value, that responsibility has leaked out to every caller — exactly what encapsulation is supposed to prevent." } ] } ``` ## Composition over inheritance This is the single most useful habit in this whole topic, and it's the one interviewers lean on hardest. **Here's the problem with inheritance.** It's the tightest coupling a language offers — a subclass depends on the parent's actual implementation, not just its promises. Change the parent, and every child might quietly break. This is called the "fragile base class" problem. Worse, inheritance can only express *one* dimension of change at a time. The moment two things vary independently, your class tree explodes. ``` Vehicle ├── ElectricCar ├── PetrolCar ├── ElectricTruck this explodes: ├── PetrolTruck (fuel type) × (body type) needs one class PER combination ├── ElectricMotorcycle └── ... ``` **The fix: make the varying part something the object *has*, not something it *is*.** ```python from abc import ABC, abstractmethod class Engine(ABC): @abstractmethod def start(self) -> str: ... class PetrolEngine(Engine): def start(self) -> str: return "vroom" class ElectricMotor(Engine): def start(self) -> str: return "hum" class Vehicle: """One class. The thing that varies is a field, not a branch of a class tree.""" def __init__(self, name: str, engine: Engine, wheels: int): self.name, self.engine, self.wheels = name, engine, wheels def start(self) -> str: return f"{self.name} ({self.wheels} wheels): {self.engine.start()}" car = Vehicle("car", PetrolEngine(), 4) bike = Vehicle("bike", ElectricMotor(), 2) assert car.start().endswith("vroom") and bike.start().endswith("hum") # You can even swap the engine while the program is running — inheritance can't do this. car.engine = ElectricMotor() assert car.start().endswith("hum") print(car.start(), "|", bike.start()) ``` ```java + public class Main { interface Engine { String start(); } static class PetrolEngine implements Engine { @Override public String start() { return "vroom"; } } static class ElectricMotor implements Engine { @Override public String start() { return "hum"; } } static class Vehicle { private final String name; private final int wheels; private Engine engine; // the varying part, injected — not a subclass Vehicle(String name, Engine engine, int wheels) { this.name = name; this.engine = engine; this.wheels = wheels; } void setEngine(Engine engine) { this.engine = engine; } String start() { return name + " (" + wheels + " wheels): " + engine.start(); } } public static void main(String[] args) { Vehicle car = new Vehicle("car", new PetrolEngine(), 4); Vehicle bike = new Vehicle("bike", new ElectricMotor(), 2); assert car.start().endsWith("vroom") && bike.start().endsWith("hum"); car.setEngine(new ElectricMotor()); // swapped while running assert car.start().endsWith("hum"); System.out.println(car.start() + " | " + bike.start()); } } ``` | | Inheritance | Composition | |---|---|---| | Relationship | IS-A | HAS-A | | Decided | When the code is written | While the program runs — swappable | | Coupling | Tight — to the parent's actual code | Loose — only to an interface | | Two things varying at once | Class count explodes | One field per varying thing | | Testing | Must build the whole family tree | Just hand it a fake collaborator | **When inheritance is genuinely the right call**: a real IS-A relationship where the child can stand in for the parent everywhere (a `SavingsAccount` really is an `Account`), a stable parent you control, and only one thing varying. A shallow tree — one or two levels — is usually fine and often the clearest option. Here's a sentence worth having ready: **"I'd use composition here, because fuel type and body type vary independently. Inheritance would need one class per combination."** > **Remember:** the moment two things vary independently, stop reaching for subclasses and start reaching for a field. ```knowledge-check { "questions": [ { "id": "ip45-lld-02-composition-q1", "type": "mcq", "prompt": "A design already has `ElectricCar`, `PetrolCar`, `ElectricTruck`, `PetrolTruck` — and now needs hybrid engines and vans too. What's actually wrong here?", "options": [ {"id":"a","text":"There just aren't enough subclasses yet — add HybridVan and it's fine"}, {"id":"b","text":"Two things vary independently — power source and body type — but they're being forced through single-branch inheritance, so classes multiply; model each one as a field instead"}, {"id":"c","text":"The base class needs more methods"}, {"id":"d","text":"These should all be interfaces instead"} ], "correct": "b", "explanation": "A class tree can really only express one axis of change cleanly. Every extra independent axis multiplies the class count. Turning each axis into a field means hybrid engines cost one new class, not one per body type." } ] } ``` ## Coupling and cohesion These are the two words a reviewer actually means when they say a design is "clean." **Coupling — how much one piece of code has to know about another.** Lower is better. | Level | What it looks like | Verdict | |---|---|---| | **Data coupling** | Passing a plain number | Best | | **Stamp coupling** | Passing a whole object when only one field gets used | Fine, a little wasteful | | **Control coupling** | Passing a flag that changes what the method does (`save(dryRun=True)`) | A smell — usually should be two methods | | **Common coupling** | Shared global state anyone can change | Bad — dependencies become invisible | | **Content coupling** | Reaching straight into another object's insides (`order.items[0].price = 0`) | Worst | Two quick tests to run on any design: *if I change class A, how many other classes have to change too?* And: *how many objects do I need to build just to test A on its own?* Both answers should be small. **Cohesion — how well the contents of one class actually belong together.** Higher is better. A cohesive class has a name that tells you exactly what it does. A class with low cohesion tends to be named `Utils`, `Manager`, or `Helper`, and different methods inside it use completely different subsets of its fields. There's a rule that makes low coupling concrete, called the **Law of Demeter**: *only talk to your immediate friends.* ```python # A long chain — this method now depends on the shape of Order, Customer, AND Address. def bad(order): return order.get_customer().get_address().get_city().upper() # Ask the object you already have, and let IT answer the question. def good(order): return order.shipping_city().upper() ``` Every extra `.` past the first one is one more thing that can break your code later. **A five-item checklist you can run against any design**, with the standard fix for each: | Smell | What it looks like | Fix | |---|---|---| | **God class** | `OrderManager` with 40 methods | Split it up by why each part would change | | **Feature envy** | A method that mostly reads some other class's fields | Move the method to the class that owns the data | | **Primitive obsession** | A plain string standing in for money, an id, a phone number | Wrap it in a value object: `Money`, `PhoneNumber`, `TicketId` | | **Shotgun surgery** | One small change means editing seven different files | The idea is scattered — pull it into one class | | **Long parameter list** | `create(a, b, c, d, e, f, g)` | Bundle the parameters into an object, or use a builder | > **Remember:** every extra dot past the first one in a chain is a dependency you just took on. Ask the thing you already hold, don't reach through it. ```knowledge-check { "questions": [ { "id": "ip45-lld-02-coupling-q1", "type": "mcq", "prompt": "`invoice.getCustomer().getAddress().getCountry().getTaxRate()` breaks the Law of Demeter. Why does that actually matter?", "options": [ {"id":"a","text":"It runs more slowly than a single method call"}, {"id":"b","text":"This code now depends on the internal shape of four different classes, so a change to any of them can break it — asking `invoice.taxRate()` instead leaves only one dependency, and everything behind it can change freely"}, {"id":"c","text":"It can't be written in a statically typed language"}, {"id":"d","text":"It prevents the use of interfaces"} ], "correct": "b", "explanation": "Every extra dot is knowledge of another class's internal shape. Shrinking the chain down to one call on an object you already hold means only that one object's contract can break you." } ] } ``` ## Interfaces, abstract classes, and dependency injection **Interface vs. abstract class shows up in almost every LLD interview**, and the answer really comes down to one question: *what are you sharing?* **Abstract class means "IS-A."** Use it when the things involved share both a type relationship and some actual code. A `Dog` **is an** `Animal`. **Interface means "CAN-DO."** Use it when unrelated things need to promise the same *capability*, with no code in common. A `Dog` **can** `Swim`; so **can** a `Boat`, and a `Boat` is definitely not an `Animal`. | | Interface | Abstract class | |---|---|---| | Shares | Just a promise — "here's what I can do" | A promise, plus some real code | | Holds state | No (constants only) | Yes — fields, a constructor | | How many | A class can implement many | One parent only, in most languages | | Answers | "What can you do, no matter what you are?" | "What kind of thing are you, and what do you already do?" | | Cost of a change | Adding a method breaks everything that implements it | Adding a concrete method breaks nobody | **In Python specifically**, there's no separate `abstract class` keyword. `abc.ABC` plus `@abstractmethod` gives you the same guarantee: ```python from abc import ABC, abstractmethod class Shape(ABC): def __init__(self, color: str): self.color = color # shared state — every Shape has a colour def describe(self) -> str: # a real method, shared by every subclass return f"A {self.color} shape with area {self.area():.2f}" @abstractmethod def area(self) -> float: ... # every subclass MUST provide this class Circle(Shape): def __init__(self, color: str, radius: float): super().__init__(color) self.radius = radius def area(self) -> float: return 3.14159 * self.radius ** 2 Shape("red") # TypeError: Can't instantiate abstract class Shape Circle("red", 2).describe() # "A red shape with area 12.57" ``` Trying to build a plain `Shape` raises a `TypeError` the instant you try. Python checks this while the program is running, not before, since there's no separate compile step. A subclass that forgets to write `area()` is also unbuildable, and the error only shows up the first time someone actually tries to construct it. **Python's real answer to "CAN-DO" is `typing.Protocol`, not a keyword.** Java's `implements` requires you to declare the relationship up front — that's called nominal typing. Python's `Protocol` just checks the *shape* of an object — that's structural typing: ```python from typing import Protocol class Swimmer(Protocol): def swim(self) -> str: ... class Dog: def swim(self) -> str: return "paddles" class Boat: def swim(self) -> str: return "cuts through water" def race(swimmer: Swimmer) -> str: return swimmer.swim() race(Dog()) # works — Dog never said "I implement Swimmer", it just has the method race(Boat()) # also works — Boat has nothing to do with Dog at all ``` Neither `Dog` nor `Boat` inherits from `Swimmer`. They satisfy it just by happening to have a matching method. When `race(Dog())` runs, Python doesn't check any declared relationship at all — it just calls `.swim()` and trusts that whatever was handed to it has one. That's the concrete Python answer to "CAN-DO": no shared parent, no shared code, just a shared ability, checked either by a type checker or simply by trying it at runtime. **Abstract classes earn their keep through the Template Method pattern**: the abstract class nails down the *order* of a series of steps, and each subclass only fills in the steps that actually change. ```python class DataPipeline(ABC): def run(self) -> None: # the fixed order — never overridden data = self.extract() cleaned = self.transform(data) self.load(cleaned) @abstractmethod def extract(self): ... @abstractmethod def transform(self, data): ... @abstractmethod def load(self, data): ... class CsvPipeline(DataPipeline): def extract(self): return open("in.csv").read() def transform(self, data): return data.upper() def load(self, data): open("out.csv", "w").write(data) ``` `run()` never changes. The *shape* of the process is fixed in the parent class, and only the individual steps vary per subclass. Calling `CsvPipeline().run()` runs `DataPipeline.run`, which calls `extract`, `transform`, and `load` in that exact order — but each one resolves to `CsvPipeline`'s own version. This is the answer to "why not just give me three methods and let me call them in the right order myself?" The abstract class owns and guarantees the order, so nobody can call the steps out of sequence or skip one by mistake. Two interview questions worth having answers ready for: **"Can an abstract class have a constructor if you can't build one directly?"** Yes — it runs whenever a subclass is built, through `super().__init__()`. You can't construct the parent alone, but its constructor is still part of building every child. **"Why not just use Strategy instead of Template Method?"** Strategy swaps out a *whole* algorithm through composition — you hand in a different object. Template Method fixes the *order* of steps at write-time and only lets subclasses change individual steps. Pick Template Method when the sequence must never change. Pick Strategy when you need to swap the entire thing while the program runs. **Dependency injection is what turns "depend on an interface" from advice into working code**: a class receives the things it needs from outside, instead of building them itself. ```python class SmtpMailer: def send(self, to: str, body: str) -> None: print(f"[smtp] to {to}: {body}") class FakeMailer: def __init__(self): self.sent: list[tuple[str, str]] = [] def send(self, to: str, body: str) -> None: self.sent.append((to, body)) class SignupService: def __init__(self, mailer): # handed in — not `self.mailer = SmtpMailer()` self.mailer = mailer def register(self, email: str) -> None: self.mailer.send(email, "Welcome!") fake = FakeMailer() SignupService(fake).register("a@mindforge.test") assert fake.sent == [("a@mindforge.test", "Welcome!")] # tested with no real mail server SignupService(SmtpMailer()).register("b@mindforge.test") print("sent:", fake.sent) ``` Building your own dependency inside the class (`self.mailer = SmtpMailer()`) locks the class to one implementation, makes it impossible to test without real infrastructure, and hides what the class actually needs from anyone reading its constructor. Injecting it instead puts every dependency right there in the signature — which is also why **a constructor with eight parameters is a warning sign**: that class is doing eight different jobs. > **Remember:** interface means "can do," abstract class means "is a." When in doubt, ask what's actually being shared — a promise, or a promise plus real code. ```knowledge-check { "questions": [ { "id": "ip45-lld-02-di-q1", "type": "mcq", "prompt": "Why is `def __init__(self): self.mailer = SmtpMailer()` worse than accepting the mailer as a constructor argument?", "options": [ {"id":"a","text":"It's slower to construct the object"}, {"id":"b","text":"It locks the class to one implementation, hides the dependency from anyone reading the constructor, and makes the class impossible to test without a real mail server — passing it in instead makes the dependency visible and swappable"}, {"id":"c","text":"Constructors can't build other objects in most languages"}, {"id":"d","text":"It breaks encapsulation of the mailer"} ], "correct": "b", "explanation": "Passing a dependency in buys you three things at once: you can swap it, you can test with a fake, and the constructor honestly documents what the class needs." } ] } ``` ## Quick recap ``` Encapsulation : hide state, expose actions that keep the object valid. A public setter is a public field. Validate in the constructor. Abstraction : hide HOW something works behind a simple interface (encapsulation hides DATA, abstraction hides HOW) Inheritance : share a contract, not just code. IS-A + substitutable + one axis + shallow. Polymorphism : one call, many behaviours. Test: can I add a type with zero edits elsewhere? Python also does this via duck typing — no shared parent required. COMPOSITION OVER INHERITANCE Inheritance = fixed at write-time, tight coupling, one axis → class count explodes Composition = swappable while running, loose coupling, one field per axis, easy to fake Coupling (low is good): data < stamp < control < common < content ← worst Law of Demeter: every dot past the first is a new dependency. Ask, don't reach through. Cohesion (high is good): a class whose name tells you exactly what it does. Smells: god class · feature envy · primitive obsession · shotgun surgery · long param list Interface = a promise only, many per class, unrelated types (CAN-DO) Abstract class = a promise plus real code, one per class (IS-A) Python: ABC + @abstractmethod for "IS-A"; Protocol (structural) for "CAN-DO" Template Method: the abstract class fixes the ORDER, subclasses fill in the STEPS Dependency injection: receive collaborators, never build them yourself. A constructor with 8 parameters means that class is doing 8 jobs. ``` - **Encapsulation is about who's responsible for keeping the object valid** — and the answer has to be the class itself, never its callers. - **Reach for composition first, every time**, and be ready to say why: independent things that vary, swapping while the program runs, easier testing. - **Coupling and cohesion are the words reviewers actually use.** "This `Manager` class has low cohesion — I'd split pricing away from saving to disk" is exactly what a real design conversation sounds like. - **Every smell in that checklist has a standard fix**, and knowing the pair — smell, then fix — is what lets you improve a design live, on the spot, when the interviewer pushes back. 6e:T4ea6,SOLID is the vocabulary interviewers reach for when they explain why one design beats another. That's exactly why "explain SOLID with an example" is one of the most common LLD questions there is. Just reciting the five names earns you nothing. What actually earns points is showing a bad design, naming the exact principle it breaks, and fixing it — which is exactly how each section below is built. Hold onto this one idea: **every SOLID principle exists to make change cheap.** Each one answers the same question in a different way: "when the requirements change, how much code has to change with them?" ## S — Single Responsibility Principle > A class should have one reason to change. "One reason to change" is a sharper test than "does one thing." Here's the actual question to ask: **who, in the real world, would ask for a change to this class?** If the finance team, the design team, and the ops team could all separately trigger an edit, that class has three jobs, not one. ``` # BROKEN — three different people can ask for a change here, all in one class. class BadReport: def compute(self, rows): ... # finance changes the formula def to_pdf(self): ... # design changes the layout def email(self, to): ... # ops changes the mail server ``` ```python from dataclasses import dataclass # FIXED — each class changes for exactly one reason. @dataclass(frozen=True) class SalesReport: total_paise: int rows: int class ReportCalculator: # changes when the business rule changes def compute(self, sales: list[int]) -> SalesReport: return SalesReport(total_paise=sum(sales), rows=len(sales)) class ReportPdfRenderer: # changes when the layout changes def render(self, report: SalesReport) -> bytes: return f"PDF".encode() class ReportMailer: # changes when the way we deliver it changes def __init__(self, transport): self.transport = transport def send(self, to: str, document: bytes) -> None: self.transport.send(to, document) class FakeTransport: def __init__(self): self.outbox = [] def send(self, to, doc): self.outbox.append((to, doc)) report = ReportCalculator().compute([10_000, 25_000, 5_000]) pdf = ReportPdfRenderer().render(report) transport = FakeTransport() ReportMailer(transport).send("cfo@mindforge.test", pdf) assert report.total_paise == 40_000 assert transport.outbox[0][0] == "cfo@mindforge.test" print("report pipeline ok:", pdf.decode()) ``` The real win here isn't tidiness — it's that the calculator can now be tested with no PDF library and no mail server at all, and a layout tweak can never accidentally break the arithmetic. **One trap to watch for: don't overdo this.** Splitting one class into six classes with one tiny method each isn't SRP, it's just thin, scattered design. Group things by *why they'd change*, not by how few lines they have. > **Remember:** the test for SRP isn't "does this do one thing" — it's "could two different teams ask for two different changes here?" ```knowledge-check { "questions": [ { "id": "ip45-lld-03-srp-q1", "type": "mcq", "prompt": "What's the sharpest way to test whether a class breaks the Single Responsibility Principle?", "options": [ {"id":"a","text":"Whether it has more than 200 lines of code"}, {"id":"b","text":"Whether more than one group of people could each independently ask for a change to it — finance changing a formula, design changing a layout, ops changing a mail server means three separate reasons to change"}, {"id":"c","text":"Whether it has more than five methods"}, {"id":"d","text":"Whether it uses more than one interface"} ], "correct": "b", "explanation": "SRP is about who can trigger a change, not about size. A 400-line class that only ever changes for one reason is fine. A 40-line class that three separate teams keep editing is not." } ] } ``` ## O — Open/Closed Principle > Open for extension, closed for modification. Adding a new behaviour should mean **writing new code**, never **editing code that already works**. The warning sign is a growing `if/elif` chain built around a type or a name. ```python # BROKEN — every new payment method means editing this method, risking the ones already there. class BadProcessor: def pay(self, method: str, paise: int) -> str: if method == "card": return f"charged card {paise}" elif method == "upi": return f"charged upi {paise}" # elif "wallet" ... elif "netbanking" ... forever raise ValueError(method) ``` ```python from abc import ABC, abstractmethod class PaymentMethod(ABC): @abstractmethod def pay(self, paise: int) -> str: ... class Card(PaymentMethod): def pay(self, paise: int) -> str: return f"charged card {paise}" class Upi(PaymentMethod): def pay(self, paise: int) -> str: return f"charged upi {paise}" class Wallet(PaymentMethod): # NEW — added, nothing else touched def pay(self, paise: int) -> str: return f"charged wallet {paise}" class Checkout: def pay(self, method: PaymentMethod, paise: int) -> str: return method.pay(paise) # this method never has to change again checkout = Checkout() assert checkout.pay(Card(), 49_900) == "charged card 49900" assert checkout.pay(Wallet(), 1_000) == "charged wallet 1000" print(checkout.pay(Upi(), 25_000)) ``` **How do you know which direction to keep open?** You can't design a class that's open to literally every possible future change — that's just over-engineering with extra steps. Open it along the specific direction the requirements point to: "we'll keep adding new payment methods" means open there. "The tax formula is fixed by law and only changes once a decade" means leave that part concrete. **Where this shows up in real systems**: strategy objects, plugin registries, event listeners, and — the simplest version of all — a plain dictionary lookup replacing an `if/elif` chain. > **Remember:** a growing `if/elif` on a type or a name is the tell. Every new branch is a risk to everything already working. ```knowledge-check { "questions": [ { "id": "ip45-lld-03-ocp-q1", "type": "mcq", "prompt": "Which code smell most reliably points to an Open/Closed violation?", "options": [ {"id":"a","text":"A class with private fields"}, {"id":"b","text":"A growing if/elif chain that switches on a type or a name, where every new variant means editing (and risking) code that already works"}, {"id":"c","text":"A method with two parameters"}, {"id":"d","text":"Using an abstract base class"} ], "correct": "b", "explanation": "The chain is the exact spot that gets edited. Replacing it with polymorphism — or even just a dictionary lookup — turns \"edit and retest this method\" into \"add a class.\"" } ] } ``` ## L — Liskov Substitution Principle > Anywhere code expects the parent type, a child type must work too, without the caller noticing the difference. This principle decides whether inheritance was even the right call, and its violations tend to be sneaky. ```python # BROKEN — the textbook example. A square IS a rectangle in geometry, but not safely in code. class Rectangle: def __init__(self, w, h): self._w, self._h = w, h def set_width(self, w): self._w = w def set_height(self, h): self._h = h def area(self): return self._w * self._h class Square(Rectangle): def __init__(self, side): super().__init__(side, side) def set_width(self, w): self._w = self._h = w # forced to keep both sides equal def set_height(self, h): self._w = self._h = h def client_expects_rectangle_behaviour(r: Rectangle) -> int: r.set_width(5) r.set_height(4) return r.area() # any real Rectangle: 20 assert client_expects_rectangle_behaviour(Rectangle(1, 1)) == 20 assert client_expects_rectangle_behaviour(Square(1)) == 16 # ← this is the broken substitution print("Square breaks the Rectangle contract: 16 != 20") ``` The subclass didn't add anything — it quietly *took away* a promise the parent made ("width and height change independently"). The real fix isn't a clever workaround, it's to stop inheriting altogether: make `Shape` an interface with just `area()`, and let `Square` and `Rectangle` be separate, unchangeable value objects that both implement it. **Four rules a child type actually has to follow:** | Rule | What it means | What breaking it looks like | |---|---|---| | **Never demand more from callers** | The child can't require stricter input than the parent did | Parent accepts any number; child insists on a positive one | | **Never deliver less than promised** | The child must give back at least what the parent guaranteed | Parent promises a sorted list; child hands back an unsorted one | | **Keep the parent's rules intact** | Whatever the parent guaranteed still has to hold | `Square` breaking the "sides move independently" rule above | | **No surprise failures** | Callers shouldn't get an exception they never expected | A subclass throws an error from a method the parent never throws from | That last row is the most common one you'll actually see in real code: a `ReadOnlyList` that inherits `List` and then throws whenever someone calls `add()`. If a subclass has to say "sorry, this doesn't apply to me," the class tree itself is wrong — split the interface instead, which is exactly the next principle. > **Remember:** if a subclass throws on a method its parent promised would work, the class tree is broken — not the caller. ```knowledge-check { "questions": [ { "id": "ip45-lld-03-lsp-q1", "type": "mcq", "prompt": "A `ReadOnlyCollection` extends `Collection` and throws an exception whenever `add()` is called. Which principle does this break, and what's the fix?", "options": [ {"id":"a","text":"Single Responsibility — split the class into two"}, {"id":"b","text":"Liskov Substitution — code holding a plain `Collection` can no longer safely call `add()`. Fix it by splitting the interface: a read-only base and a separate mutable one that extends it"}, {"id":"c","text":"Open/Closed — add a flag instead of throwing"}, {"id":"d","text":"Dependency Inversion — inject the collection instead"} ], "correct": "b", "explanation": "Throwing from a method the parent type promised would work breaks the substitution guarantee. The real fix is usually a narrower interface — LSP problems are very often ISP problems wearing a different name." } ] } ``` ## I — Interface Segregation Principle > Nobody should be forced to depend on a method they'll never use. ```python from abc import ABC, abstractmethod # BROKEN — one wide interface forces a meaningless implementation. class BadWorker(ABC): @abstractmethod def work(self): ... @abstractmethod def eat(self): ... class Robot(BadWorker): def work(self): return "working" def eat(self): raise NotImplementedError("robots don't eat") # ← forced to write this ``` ```python from abc import ABC, abstractmethod # FIXED — small, focused interfaces; each class implements only what it actually is. class Workable(ABC): @abstractmethod def work(self) -> str: ... class Feedable(ABC): @abstractmethod def eat(self) -> str: ... class Human(Workable, Feedable): def work(self) -> str: return "working" def eat(self) -> str: return "eating" class Robot(Workable): # nothing meaningless to implement anymore def work(self) -> str: return "working" def run_shift(workers: list[Workable]) -> list[str]: return [w.work() for w in workers] # only depends on what it actually needs assert run_shift([Human(), Robot()]) == ["working", "working"] assert Human().eat() == "eating" assert not hasattr(Robot, "eat") print("segregated interfaces ok") ``` **The practical tell**: any method body that's just `pass`, `return null`, or an exception saying "not implemented." Every single one of those is proof that the interface asked for more than that class actually is. There's a related idea worth knowing by name: **role interfaces**. Instead of one giant `UserService` with twenty methods, split it into `UserReader`, `UserWriter`, `PasswordResetter`. Each piece of code that uses it only depends on the two methods it actually calls, so a change to password logic can't accidentally break code that only reads users. It also makes your test doubles small — a fake with two methods instead of twenty. > **Remember:** a method body that just throws "not implemented" is proof the interface promised more than that class actually is. ```knowledge-check { "questions": [ { "id": "ip45-lld-03-isp-q1", "type": "mcq", "prompt": "What's the clearest practical sign of an Interface Segregation violation?", "options": [ {"id":"a","text":"An interface with more than three methods"}, {"id":"b","text":"An implementation with an empty body, a `return null`, or a \"not implemented\" exception — proof that the interface demands more than that class actually is"}, {"id":"c","text":"Two classes implementing the same interface"}, {"id":"d","text":"An interface used by only one class"} ], "correct": "b", "explanation": "Method count alone doesn't prove anything — a cohesive interface can have several methods. The real evidence is an implementer that's forced to supply a method that means nothing for it, which also breaks Liskov the moment anyone calls it." } ] } ``` ## D — Dependency Inversion Principle > High-level code shouldn't depend on low-level details. Both should depend on an abstraction — and the abstraction shouldn't depend on the details either. ``` # BROKEN — the business rule is welded directly to MySQL and to SMTP. class BadOrderService: def __init__(self): self.db = "MySQLConnection(...)" # builds its own low-level detail def place(self, order): ... # can't test this without a real database ``` ```python from abc import ABC, abstractmethod # The interface belongs to the HIGH-level module and speaks its language, not the database's. class OrderRepository(ABC): @abstractmethod def save(self, order: dict) -> str: ... class Notifier(ABC): @abstractmethod def notify(self, to: str, message: str) -> None: ... class OrderService: # high level: pure business rules def __init__(self, repo: OrderRepository, notifier: Notifier): self.repo, self.notifier = repo, notifier def place(self, order: dict) -> str: if order["total_paise"] <= 0: raise ValueError("order total must be positive") order_id = self.repo.save(order) self.notifier.notify(order["email"], f"Order {order_id} placed") return order_id # Low level: the details depend on the abstraction, never the other way around. class InMemoryOrderRepository(OrderRepository): def __init__(self): self.saved: dict[str, dict] = {} def save(self, order: dict) -> str: oid = f"ord_{len(self.saved) + 1}" self.saved[oid] = order return oid class RecordingNotifier(Notifier): def __init__(self): self.messages: list[tuple[str, str]] = [] def notify(self, to: str, message: str) -> None: self.messages.append((to, message)) repo, notifier = InMemoryOrderRepository(), RecordingNotifier() order_id = OrderService(repo, notifier).place({"total_paise": 49_900, "email": "a@mindforge.test"}) assert order_id == "ord_1" and repo.saved[order_id]["total_paise"] == 49_900 assert notifier.messages == [("a@mindforge.test", "Order ord_1 placed")] print("business logic tested with zero infrastructure:", order_id) ``` **The subtlety worth stating out loud in an interview**: what actually "inverts" is the *direction* of the dependency. Before: `OrderService → MySQLRepository`. After: both point at `OrderRepository` instead — and critically, that interface belongs to the business layer and is written in business language (`save(order)`), not database language (`executeQuery`). That's what makes swapping Postgres for DynamoDB a change in exactly one file. **You've probably already used this without naming it.** FastAPI's `Depends()` is Dependency Inversion, applied at the framework level: ```python def get_db(): db = SessionLocal() try: yield db finally: db.close() @app.get("/orders/{order_id}") def read_order(order_id: int, db: Session = Depends(get_db)): return db.query(Order).get(order_id) ``` The endpoint function depends on whatever `Depends(get_db)` resolves to — a real database session in production, a test session in your test suite. Swapping one for the other never means touching the endpoint function at all. That's this whole principle, doing its job, and you've likely already relied on it without stopping to name it. This is also the reasoning behind hexagonal ("ports and adapters") architecture, and it's exactly why the test above needed no database, no network call, and no mocking library at all. > **Remember:** the interface belongs to the business layer, written in its language — not to the database layer. ```knowledge-check { "questions": [ { "id": "ip45-lld-03-dip-q1", "type": "mcq", "prompt": "In Dependency Inversion, which side should own and define the `OrderRepository` interface?", "options": [ {"id":"a","text":"The database layer, since it's the one implementing it"}, {"id":"b","text":"The high-level business layer — the interface is written in business language (`save(order)`), and the low-level adapter implements it, which is exactly what inverts the direction of the dependency"}, {"id":"c","text":"A shared utility package that neither layer owns"}, {"id":"d","text":"Whichever layer has fewer classes"} ], "correct": "b", "explanation": "If the persistence layer owns the interface, the business layer still points at persistence, and nothing was actually inverted. The business layer owning it is what lets you swap the adapter without touching a business rule." } ] } ``` ## Quick recap **Principle, warning sign, fix:** | | Principle | Warning sign | Fix | |---|---|---|---| | **S** | One reason to change | A class three different teams keep editing; names like `Manager`/`Util` | Split it up by reason to change | | **O** | Open to add, closed to edit | A growing `if/elif` on a type | Polymorphism, a strategy object, or a registry | | **L** | Children are safely swappable for parents | An override that throws, or quietly weakens a guarantee | Split the class tree; lean on composition instead | | **I** | No forced, unused dependencies | "Not implemented" bodies, empty methods | Small, focused interfaces | | **D** | Depend on abstractions | Building infrastructure directly inside business logic | Inject an interface the business layer owns | - **All five come down to one goal: making change cheap.** When someone asks "why does SOLID even matter," answer with a change, not a definition: "adding a payment method should mean adding a class, not editing a switch statement." - **Present them as fixes, not definitions.** "Here's the broken version, here's what it breaks, here's the fix" is the format that actually scores points. - **They lean on each other.** An LSP break is usually an ISP problem underneath. OCP is usually achieved by applying DIP. SRP is what makes all the others even possible. - **They can absolutely be overdone.** Five one-method classes and an interface for every concrete type isn't SOLID — it's ceremony. Apply each principle where the requirements genuinely say something will change, and be ready to say out loud when you're deliberately choosing *not* to abstract something. That restraint is itself a senior-level signal. 6f:T491e,Every creational pattern answers the same question: **who decides which concrete class gets built, and how?** They all exist for one reason — to stop `new ConcreteThing()` from being scattered through code that has no business knowing `ConcreteThing` even exists. Learn each one as a **problem → pattern → cost** triple. Interviewers ask "when would you reach for this?" far more often than "implement this from scratch," and the trap answer is using a pattern where a plain constructor would have done the job just fine. ## Singleton — exactly one instance **The problem**: something expensive or genuinely one-of-a-kind — a connection pool, a config store, a logger — needs to exist exactly once, shared by everyone. ```python import threading class ConfigRegistry: _instance = None _lock = threading.Lock() def __new__(cls): if cls._instance is None: # fast path, no lock needed most of the time with cls._lock: # double-checked locking if cls._instance is None: # check again, now that we hold the lock obj = super().__new__(cls) obj._values = {} cls._instance = obj return cls._instance def set(self, key: str, value: str) -> None: self._values[key] = value def get(self, key: str) -> str | None: return self._values.get(key) a, b = ConfigRegistry(), ConfigRegistry() assert a is b # truly the same object a.set("region", "ap-south-1") assert b.get("region") == "ap-south-1" print("singleton shared state:", b.get("region")) ``` That double-checked lock isn't decoration — interviewers ask about it directly. Without it, two threads can both pass the first `is None` check before either one finishes building the object, and you end up with two "singletons." Locking on *every* access instead would work, but you'd pay that cost forever, on every single call. Check, lock, check again solves both problems at once. **In Python**, a module is already a singleton by nature — import it twice and you get the same object both times — so a plain module-level variable is usually the natural answer. **In Java**, the safest version is an enum-based singleton (it resists both serialization tricks and reflection) or a static holder class. **Here's the cost, and you should mention it before anyone asks, because "when would you *not* use this?" is always the follow-up:** - It's **shared mutable state**: any code, anywhere, can change it, so bugs in it have no clear owner. - It **hides what a class actually depends on**: a class quietly calling `ConfigRegistry()` internally looks dependency-free from the outside, but isn't. - It makes **testing painful**: state can leak between tests, and there's no way to swap in a fake. - It **fights concurrency**: shared mutable state needs protecting everywhere it's touched. The modern answer: build one instance where your program starts up, and **inject** it into whatever needs it. You keep "exactly one," without the global door that let anything reach in and change it — which was always the harmful half of this pattern anyway. > **Remember:** the useful part of Singleton is "exactly one instance." The harmful part is "reachable from anywhere." Keep the first, inject instead of relying on the second. ```knowledge-check { "questions": [ { "id": "ip45-lld-04-singleton-q1", "type": "mcq", "prompt": "Why does a thread-safe Singleton use double-checked locking instead of just locking on every access?", "options": [ {"id":"a","text":"To make the object immutable"}, {"id":"b","text":"So the lock only ever gets taken during the first, racing construction — the outer check skips locking on every later access, and the inner re-check stops two threads that both passed the outer check from building two instances"}, {"id":"c","text":"To allow multiple instances when needed"}, {"id":"d","text":"Because constructors can't be synchronised"} ], "correct": "b", "explanation": "A single check races. Locking on every access works but costs you forever on a path that's read constantly. Check, lock, check again gets correctness while only paying the synchronisation cost once." } ] } ``` ## Factory Method and Abstract Factory **Factory Method — the problem**: callers shouldn't need to know or name concrete classes, and adding a new type shouldn't mean editing them. ```python from abc import ABC, abstractmethod class Notifier(ABC): @abstractmethod def send(self, to: str, msg: str) -> str: ... class EmailNotifier(Notifier): def send(self, to: str, msg: str) -> str: return f"email->{to}:{msg}" class SmsNotifier(Notifier): def send(self, to: str, msg: str) -> str: return f"sms->{to}:{msg}" class PushNotifier(Notifier): def send(self, to: str, msg: str) -> str: return f"push->{to}:{msg}" class NotifierFactory: """A registry: a new channel just registers itself, nothing here has to change.""" _registry: dict[str, type[Notifier]] = {} @classmethod def register(cls, key: str, impl: type[Notifier]) -> None: cls._registry[key] = impl @classmethod def create(cls, key: str) -> Notifier: try: return cls._registry[key]() except KeyError: raise ValueError(f"unknown channel: {key}") from None for key, impl in (("email", EmailNotifier), ("sms", SmsNotifier), ("push", PushNotifier)): NotifierFactory.register(key, impl) assert NotifierFactory.create("sms").send("+91999", "hi") == "sms->+91999:hi" try: NotifierFactory.create("carrier-pigeon") raise AssertionError("expected failure") except ValueError as e: print("factory rejected:", e) ``` This registry version is worth knowing because it's actually **open/closed**: a plain `if kind == "email"` factory still needs editing for every new channel. This one doesn't — a new channel just registers itself. **Abstract Factory — the problem**: you need whole *families* of related objects that must always be used together, where mixing pieces from different families would be a genuine bug. ```python from abc import ABC, abstractmethod class Button(ABC): @abstractmethod def render(self) -> str: ... class Checkbox(ABC): @abstractmethod def render(self) -> str: ... class DarkButton(Button): def render(self) -> str: return "[dark button]" class DarkCheckbox(Checkbox): def render(self) -> str: return "[dark checkbox]" class LightButton(Button): def render(self) -> str: return "[light button]" class LightCheckbox(Checkbox): def render(self) -> str: return "[light checkbox]" class ThemeFactory(ABC): # the abstract factory @abstractmethod def button(self) -> Button: ... @abstractmethod def checkbox(self) -> Checkbox: ... class DarkTheme(ThemeFactory): def button(self) -> Button: return DarkButton() def checkbox(self) -> Checkbox: return DarkCheckbox() class LightTheme(ThemeFactory): def button(self) -> Button: return LightButton() def checkbox(self) -> Checkbox: return LightCheckbox() def render_form(theme: ThemeFactory) -> str: # There's no way to accidentally end up with a dark button next to a light checkbox. return theme.button().render() + theme.checkbox().render() assert render_form(DarkTheme()) == "[dark button][dark checkbox]" print(render_form(LightTheme())) ``` Here's the one-line difference to remember: **Factory Method builds one product, varying by subclass or a key. Abstract Factory builds a whole matching family at once, and guarantees the pieces actually go together.** > **Remember:** if mixing two "compatible" objects from different sources would be a bug, that's Abstract Factory's job. If you're just building one type of thing, a plain factory is enough. ```knowledge-check { "questions": [ { "id": "ip45-lld-04-factory-q1", "type": "mcq", "prompt": "When is Abstract Factory the better choice over a plain factory?", "options": [ {"id":"a","text":"Whenever more than two concrete classes exist"}, {"id":"b","text":"When several related products have to come from the same matching family, and mixing families would be a bug — like a dark-theme button pairing with a light-theme checkbox"}, {"id":"c","text":"When building the object is expensive"}, {"id":"d","text":"When objects must be unchangeable once built"} ], "correct": "b", "explanation": "Abstract Factory's whole value is guaranteeing consistency across a family. If you only ever build one kind of product, a plain factory method (or even just a registry) is simpler and does the job." } ] } ``` ## Builder — put together a complex object step by step **The problem**: an object has a pile of optional fields, and the constructor has grown into `Pizza(size, cheese, sauce, toppings, crust, extra, discount)`, where half the arguments are usually `None` and nobody remembers what order they go in. This is sometimes called the "telescoping constructor" problem. ```python from dataclasses import dataclass, field @dataclass(frozen=True) class HttpRequest: url: str method: str = "GET" headers: dict[str, str] = field(default_factory=dict) body: str | None = None timeout_ms: int = 5_000 class HttpRequestBuilder: def __init__(self, url: str): self._url, self._method = url, "GET" self._headers: dict[str, str] = {} self._body: str | None = None self._timeout = 5_000 def method(self, m: str) -> "HttpRequestBuilder": self._method = m return self # returning self is what makes chaining work def header(self, k: str, v: str) -> "HttpRequestBuilder": self._headers[k] = v return self def body(self, b: str) -> "HttpRequestBuilder": self._body = b return self def timeout_ms(self, ms: int) -> "HttpRequestBuilder": self._timeout = ms return self def build(self) -> HttpRequest: # Checks live here, so a broken object can never be created in the first place. if self._method in ("POST", "PUT") and self._body is None: raise ValueError(f"{self._method} requires a body") return HttpRequest(self._url, self._method, dict(self._headers), self._body, self._timeout) req = (HttpRequestBuilder("https://api.mindforge.test/orders") .method("POST") .header("Content-Type", "application/json") .body('{"total":49900}') .timeout_ms(2_000) .build()) assert req.method == "POST" and req.timeout_ms == 2_000 try: HttpRequestBuilder("https://x").method("POST").build() raise AssertionError("expected validation failure") except ValueError as e: print("builder validated:", e) ``` Three things make Builder worth the extra typing: **the call site reads like a sentence** ("method POST, header this, body that"), **checks all happen at `build()`**, so a half-finished object is never observable, and **the finished object never changes afterward**, so it's safe to hand to any thread. **When you don't need it**: any language with named arguments and defaults — Python, Kotlin, C# — already solves the readability half of this problem. Reach for a builder there specifically when you need the *validation* and the *unchangeability*, or when the object gets assembled in pieces across different parts of your code. > **Remember:** Builder buys you three things beyond named arguments — validation at one point, an object that never changes, and the ability to build it in stages. ```knowledge-check { "questions": [ { "id": "ip45-lld-04-builder-q1", "type": "mcq", "prompt": "What does Builder solve that named/keyword arguments alone don't?", "options": [ {"id":"a","text":"It makes construction run faster"}, {"id":"b","text":"It centralises cross-field checks at build() and produces an object that never changes afterward, so a half-built or invalid version can never be seen — and it supports assembling the object across separate pieces of code"}, {"id":"c","text":"It allows more than seven parameters"}, {"id":"d","text":"It removes the need for a constructor entirely"} ], "correct": "b", "explanation": "Keyword arguments already fix readability. Builder adds a checkpoint where validation happens, a finished object that's safe to share, and the ability to build up configuration over time before the object exists." } ] } ``` ## Prototype and Object Pool **Prototype — the problem**: building an object from scratch is expensive (a heavy parse, a network fetch, a big computation), and you need lots of near-identical copies. ```python import copy class DocumentTemplate: def __init__(self, sections: list[str], styles: dict[str, str]): self.sections = sections # imagine this took a while to build self.styles = styles def clone(self) -> "DocumentTemplate": return copy.deepcopy(self) # deep, so the copy doesn't secretly share state base = DocumentTemplate(["cover", "body"], {"font": "serif"}) invoice = base.clone() invoice.sections.append("totals") invoice.styles["font"] = "mono" assert base.sections == ["cover", "body"] # the original is untouched assert base.styles["font"] == "serif" print("prototype cloned independently:", invoice.sections, invoice.styles) ``` The whole reason this pattern exists is to warn you about **shallow vs. deep copies**. A shallow copy shares the nested list underneath, so changing the clone silently corrupts the original too. Interviewers ask this directly — know that `copy.copy` is shallow and `copy.deepcopy` is deep in Python, and that Java's `clone()` is shallow by default (most people consider `Cloneable` a design mistake; a copy constructor or a static factory method is usually preferred instead). **Object Pool — the problem**: objects are expensive to both create *and* destroy, and you need a steady supply of them over time — database connections, threads, large buffers. ```python class Connection: def __init__(self, cid: int): self.cid, self.in_use = cid, False def query(self, sql: str) -> str: return f"conn{self.cid}:{sql}" class ConnectionPool: def __init__(self, size: int): self._pool = [Connection(i) for i in range(size)] # all built up front, once def acquire(self) -> Connection: for c in self._pool: if not c.in_use: c.in_use = True return c raise RuntimeError("pool exhausted") # a deliberate limit — this is backpressure def release(self, c: Connection) -> None: c.in_use = False # reset before it's handed to anyone else pool = ConnectionPool(2) a, b = pool.acquire(), pool.acquire() try: pool.acquire() raise AssertionError("pool should be exhausted") except RuntimeError: pass pool.release(a) c = pool.acquire() # 'a' gets reused assert c is a print("pooled:", c.query("SELECT 1")) ``` Two things worth saying about pools in an interview: **the pool has to be bounded** (an unbounded pool is just uncontrolled growth in disguise, and that "pool exhausted" error is doing its job on purpose), and **state must be reset when something is returned**, or the next borrower inherits whatever the last one left behind — an open transaction, a stale timeout, leftover session data. That exact reset bug is the classic production incident this pattern tends to cause. > **Remember:** a pool without a bound isn't a pool, it's just delayed uncontrolled growth. Reset state on release, every time. ```knowledge-check { "questions": [ { "id": "ip45-lld-04-pool-q1", "type": "mcq", "prompt": "What's the most common production bug an object pool introduces?", "options": [ {"id":"a","text":"The pool is too large and wastes memory"}, {"id":"b","text":"Object state isn't reset when it's returned, so the next borrower inherits the previous user's leftovers — an open transaction, a stale session value, old buffer contents"}, {"id":"c","text":"Pooled objects can never be garbage collected"}, {"id":"d","text":"The pool can't be used from more than one thread"} ], "correct": "b", "explanation": "Reuse is the entire point of a pool, and also its danger: anything carried over from the last borrower becomes a leak across requests or a hard-to-spot correctness bug. Resetting on release (or on acquire) isn't optional." } ] } ``` ## Quick recap **Problem, pattern, cost:** | Pattern | Problem it solves | The cost, or when to skip it | |---|---|---| | **Singleton** | Exactly one shared instance of something expensive or unique | Global mutable state, hidden dependencies, hard to test — inject one instance instead | | **Factory Method** | Callers shouldn't name concrete classes; new types shouldn't touch callers | Extra indirection; needs a registry to be truly open/closed | | **Abstract Factory** | A whole *family* of products that must match | Adding a new product type means editing every factory | | **Builder** | Lots of optional fields, checks, and an unchangeable result | Extra typing; keyword arguments already cover the simple case | | **Prototype** | Copying is much cheaper than building from scratch | Shallow-vs-deep copy bugs | | **Object Pool** | Building *and* destroying are both expensive; reuse is safe | Must be bounded; must reset state on release | **How to use all of this in an interview:** - **Say the problem before you say the pattern name.** "Payment methods will keep getting added, so I'll build them through a registry-backed factory" is design. "I'll use the Factory pattern" on its own is just vocabulary. - **Bring up the cost yourself, before anyone asks.** Every pattern above has a well-known downside, and naming it unprompted is what makes you sound like someone who's actually maintained this kind of code, not just read about it. - **The single most common mistake is reaching for Singleton everywhere.** Use it only for things that are genuinely one-of-a-kind, prefer injecting a single instance instead of a global one, and be ready to critique it — that critique is frequently the real question being asked. - **A plain constructor is often the right answer.** Creational patterns earn their place when building something varies, costs a lot, or needs validating — not as a default habit. 70:T47ab,Structural patterns are all about **arranging objects into bigger structures without the arrangement turning into a mess**. Every one of them wraps or combines objects so that whoever's using them sees something simpler than what's actually underneath. These are also the patterns people mix up the most in interviews. Adapter, Decorator, Proxy, and Facade all "wrap something," so each section below starts with the one thing that actually tells them apart — because that difference is usually the whole question. ## Adapter — make a mismatched interface fit **The idea: take an interface you can't change, and make it fit the one your code already expects.** You have a class you're not allowed to touch — a third-party SDK, an old internal module — and your system speaks a different language. ```python from abc import ABC, abstractmethod class PaymentGateway(ABC): # the interface OUR system expects @abstractmethod def charge(self, paise: int, token: str) -> str: ... class LegacyRazorpayClient: # third-party: we cannot touch this def make_payment(self, amount_in_rupees: float, card_token: str) -> dict: return {"status": "captured", "ref": f"rzp_{card_token}_{amount_in_rupees}"} class RazorpayAdapter(PaymentGateway): # the adapter def __init__(self, client: LegacyRazorpayClient): self._client = client def charge(self, paise: int, token: str) -> str: result = self._client.make_payment(paise / 100, token) # convert units... if result["status"] != "captured": # ...and normalise the result raise RuntimeError("payment failed") return result["ref"] gateway: PaymentGateway = RazorpayAdapter(LegacyRazorpayClient()) assert gateway.charge(49_900, "tok_abc") == "rzp_tok_abc_499.0" print("adapted:", gateway.charge(10_000, "tok_xyz")) ``` The adapter is exactly where the **unit conversion** lives (paise to rupees, in this case), where error formats get straightened out, and where the vendor's own quirks stop spreading into the rest of your code. That's its real value in production: switching from Razorpay to Stripe becomes one new adapter, and nothing else in your business code has to change. This is Dependency Inversion, made concrete. **Adapter vs. Facade**: an adapter makes *one* mismatched interface fit an interface that *already exists and is required*. A facade *invents a brand-new, simpler* interface over *many* classes. They can look similar, but the intent is completely different. > **Remember:** if the interface you're fitting into already existed before you got here, that's Adapter. If you're inventing a simpler one from scratch, that's Facade. ```knowledge-check { "questions": [ { "id": "ip45-lld-05-adapter-q1", "type": "mcq", "prompt": "What actually separates Adapter from Facade?", "options": [ {"id":"a","text":"Adapter wraps one object, Facade always wraps at least two"}, {"id":"b","text":"Adapter fits an existing class to an interface the client already needed (that interface already existed); Facade invents a brand-new, simpler interface over a complicated subsystem to reduce what callers need to know"}, {"id":"c","text":"Adapter runs at runtime, Facade at compile time"}, {"id":"d","text":"Adapter adds new behaviour, Facade removes it"} ], "correct": "b", "explanation": "The giveaway is whether the target interface already existed. Adapter fits a square peg into a round hole that was already there; Facade builds a smaller hole on purpose because the real subsystem is unpleasant to use directly." } ] } ``` ## Decorator — add behaviour without subclassing **The idea: attach new responsibilities to an object while it's running, without changing its interface.** The wrapper *is* the thing it wraps, plus a little extra. ```python from abc import ABC, abstractmethod class DataSource(ABC): @abstractmethod def write(self, data: str) -> str: ... class FileDataSource(DataSource): def write(self, data: str) -> str: return f"file({data})" class CompressionDecorator(DataSource): def __init__(self, wrapped: DataSource): self._wrapped = wrapped def write(self, data: str) -> str: return self._wrapped.write(f"zip[{data}]") class EncryptionDecorator(DataSource): def __init__(self, wrapped: DataSource): self._wrapped = wrapped def write(self, data: str) -> str: return self._wrapped.write(f"enc[{data}]") plain: DataSource = FileDataSource() secure: DataSource = EncryptionDecorator(CompressionDecorator(FileDataSource())) assert plain.write("hi") == "file(hi)" assert secure.write("hi") == "file(zip[enc[hi]])" # encrypt, then compress, then write to disk print("decorated:", secure.write("payload")) ``` Here's why this beats subclassing: the features are **independent, and you want to mix and match them**. Doing this with subclasses would force you into `CompressedFile`, `EncryptedFile`, `CompressedEncryptedFile`, `BufferedCompressedEncryptedFile` — the same explosion of classes from the composition-over-inheritance lesson. With decorators, *n* separate features give you 2ⁿ possible combinations from only *n* classes, chosen while your program runs. You've already used this pattern constantly without naming it: HTTP middleware (logging, then auth, then rate limiting, then your actual handler), Java's `BufferedInputStream(new FileInputStream(...))`, Python's function decorators, and React's higher-order components are all this same idea. **Order matters, and it's worth mentioning**: compressing first and then encrypting gives you a much smaller result than the other way around, because encrypted bytes have no repeating structure left to compress. **The cost**: a tall stack of small wrappers can be genuinely hard to debug. A stack trace shows six layers deep, and it's not obvious from the outside what any single object actually does anymore. > **Remember:** decorators pay off exactly when features are independent and combinable. n decorators give you 2ⁿ combinations from n classes. ```knowledge-check { "questions": [ { "id": "ip45-lld-05-decorator-q1", "type": "mcq", "prompt": "Why pick Decorator over subclassing for adding compression, encryption, and buffering to a data source?", "options": [ {"id":"a","text":"Decorators run faster than subclass method calls"}, {"id":"b","text":"The features are independent and combinable: n decorators give 2^n combinations from n classes, chosen while the program runs, while subclassing needs a separate class per combination"}, {"id":"c","text":"Subclasses can't override methods in most languages"}, {"id":"d","text":"Decorators don't need to implement the same interface as what they wrap"} ], "correct": "b", "explanation": "This is the composition-over-inheritance argument at its sharpest. Decorators must implement the exact same interface they wrap — that's precisely what lets them stack and stay transparent to whoever's calling them." } ] } ``` ## Facade, Composite, and Bridge **Facade — the idea: one simple front door over a complicated system behind it.** ```python class VideoFile: def __init__(self, name: str): self.name = name class CodecFactory: def extract(self, f: VideoFile) -> str: return f.name.split(".")[-1] class BitrateReader: def read(self, f: VideoFile, codec: str) -> str: return f"{f.name}|{codec}" class AudioMixer: def fix(self, stream: str) -> str: return f"{stream}|audio-ok" class VideoConverter: # the facade: 1 method standing in front of 4 classes def convert(self, filename: str, target: str) -> str: f = VideoFile(filename) codec = CodecFactory().extract(f) stream = BitrateReader().read(f, codec) return f"{AudioMixer().fix(stream)} -> {target}" assert VideoConverter().convert("clip.mp4", "ogg") == "clip.mp4|mp4|audio-ok -> ogg" print(VideoConverter().convert("movie.avi", "mp4")) ``` A facade doesn't lock anyone out of the classes it sits in front of — it just means most callers never have to reach for them directly. This is, in fact, what a well-built service class usually is: a facade sitting in front of repositories, validators, and outside gateways. **Composite — the idea: treat one object and a whole group of objects through the exact same interface.** Reach for this whenever the domain is naturally a tree: file systems, org charts, UI layouts, nested menus, a bill of materials. ```python from abc import ABC, abstractmethod class FileSystemNode(ABC): @abstractmethod def size(self) -> int: ... class File(FileSystemNode): # a leaf def __init__(self, name: str, bytes_: int): self.name, self._bytes = name, bytes_ def size(self) -> int: return self._bytes class Directory(FileSystemNode): # a composite — a group of the same kind of thing def __init__(self, name: str): self.name, self.children = name, [] def add(self, node: FileSystemNode) -> "Directory": self.children.append(node) return self def size(self) -> int: return sum(child.size() for child in self.children) # same call, works on either kind root = Directory("root").add(File("a.txt", 100)).add( Directory("sub").add(File("b.bin", 250)).add(File("c.bin", 150)) ) assert root.size() == 500 # nothing here ever asks "is this a file or a folder?" print("total bytes:", root.size()) ``` Notice what you *don't* see anywhere in that code: an `if is_directory` check. Adding a new `SymlinkNode` type requires no change at all to how anything gets traversed. **Bridge — the idea: split what something *is* from how it's *implemented*, so both can change independently.** It's the pattern version of the same problem Decorator solves, but for *two* dimensions of variation that need to move independently, rather than stackable features: shapes and rendering engines, message types and delivery channels, remotes and devices. Instead of `VectorCircle`, `RasterCircle`, `VectorSquare`, `RasterSquare`, a `Shape` simply **has a** `Renderer`. In practice, "bridge" is often just composition wearing a name — and saying exactly that in an interview is a perfectly good answer. > **Remember:** if there's no `if is_directory` (or its equivalent) anywhere in your traversal code, Composite is doing its job. ```knowledge-check { "questions": [ { "id": "ip45-lld-05-composite-q1", "type": "mcq", "prompt": "What's the defining payoff of the Composite pattern?", "options": [ {"id":"a","text":"It cuts memory usage for large trees"}, {"id":"b","text":"Callers treat a single leaf and a whole subtree the exact same way through one interface, so traversal code has no \"is this a group?\" branching, and new node types need zero changes anywhere else"}, {"id":"c","text":"It guarantees the tree stays balanced"}, {"id":"d","text":"It lets objects be built lazily"} ], "correct": "b", "explanation": "Treating the part and the whole identically is the whole point. The recursive `size()` above works because a Directory answers the exact same question a File does — that's what removes the branching from any code that walks the tree." } ] } ``` ## Proxy and Flyweight **Proxy — the idea: a stand-in that controls access to the real object**, using the *exact same* interface. There are four standard flavours, and naming them is exactly what interviewers are listening for: | Flavour | What it's for | |---|---| | **Virtual proxy** | Delay building something expensive until it's actually needed | | **Protection proxy** | Check permissions before letting a call through | | **Remote proxy** | A local stand-in for something that actually lives on another machine | | **Caching / smart proxy** | Remember past results, count how often something's called, log calls | ```python from abc import ABC, abstractmethod class Report(ABC): @abstractmethod def data(self) -> str: ... class ExpensiveReport(Report): def __init__(self): print(" [expensive construction happened]") self._data = "quarterly numbers" def data(self) -> str: return self._data class LazyReportProxy(Report): def __init__(self): self._real: Report | None = None def data(self) -> str: if self._real is None: # only built the first time it's actually used self._real = ExpensiveReport() return self._real.data() class AdminOnlyReportProxy(Report): def __init__(self, inner: Report, role: str): self._inner, self._role = inner, role def data(self) -> str: if self._role != "admin": raise PermissionError("admins only") return self._inner.data() proxy = LazyReportProxy() # nothing has been built yet print("proxy created, nothing built") assert proxy.data() == "quarterly numbers" # the real object gets built right here assert proxy.data() == "quarterly numbers" # and never again after that guarded = AdminOnlyReportProxy(LazyReportProxy(), role="viewer") try: guarded.data() raise AssertionError("should have been blocked") except PermissionError as e: print("protection proxy blocked:", e) ``` **Proxy vs. Decorator is the interview question.** Structurally they're nearly identical — both wrap something and implement the same interface — but their intent is completely different: - **Decorator** *adds* new behaviour, and the caller deliberately chooses to stack it. - **Proxy** *controls access* to the same behaviour that's already there, and usually the caller doesn't even know a proxy is involved. **Flyweight — the idea: share the common parts of many similar objects to save memory.** Split an object's data into **intrinsic** state (shared and never changing: a glyph's shape, a tree species' texture, a chess piece's movement rules) and **extrinsic** state (unique per object: position, colour, owner). Keep exactly one shared instance for each distinct value of the intrinsic state. ```python class TreeType: # intrinsic — shared across many trees _cache: dict[tuple[str, str], "TreeType"] = {} def __new__(cls, name: str, texture: str): key = (name, texture) if key not in cls._cache: obj = super().__new__(cls) obj.name, obj.texture = name, texture cls._cache[key] = obj return cls._cache[key] class Tree: # extrinsic — unique per tree def __init__(self, x: int, y: int, kind: TreeType): self.x, self.y, self.kind = x, y, kind forest = [Tree(i, i * 2, TreeType("oak", "oak.png")) for i in range(1_000)] forest += [Tree(i, i, TreeType("pine", "pine.png")) for i in range(1_000)] assert len(forest) == 2_000 assert len(TreeType._cache) == 2 # 2,000 trees, but only 2 shared TreeType objects assert forest[0].kind is forest[5].kind print("trees:", len(forest), "| distinct TreeType objects:", len(TreeType._cache)) ``` Flyweight is purely a memory optimisation, not a clarity one — reach for it only when the sheer *number* of objects is your real problem (text editors, particle systems, game maps, tokenisers). Mentioning that the shared state has to be **unchangeable** is the detail that shows you understand *why* this is safe, not just what it does. > **Remember:** Proxy controls access to behaviour that's already there. Decorator adds behaviour that wasn't there before. Same shape, opposite intent. ```knowledge-check { "questions": [ { "id": "ip45-lld-05-proxy-q1", "type": "mcq", "prompt": "Proxy and Decorator have the same structure — both implement the target's interface and hold a reference to it. What actually tells them apart?", "options": [ {"id":"a","text":"Proxy can only wrap one object, Decorator can wrap several"}, {"id":"b","text":"Intent: Decorator adds new behaviour and the caller deliberately chooses to stack it, while Proxy controls access to the same behaviour (lazy loading, permissions, caching, calling a remote machine) and is usually invisible to the caller"}, {"id":"c","text":"Decorators are built while the program runs, proxies before it starts"}, {"id":"d","text":"Proxies don't implement the same interface as what they wrap"} ], "correct": "b", "explanation": "These patterns are grouped by intent, not by class diagram — several share the same shape. \"Adds behaviour, caller chooses it\" versus \"controls access, invisible to the caller\" is the distinction worth saying out loud." } ] } ``` ## Quick recap **What each one is really for:** | Pattern | The one-line intent | A real example | |---|---|---| | **Adapter** | Make an existing class fit an interface you already need | A payment SDK, wrapped to match your own `PaymentGateway` | | **Decorator** | Add behaviour while running, same interface, stackable | HTTP middleware; `BufferedInputStream` | | **Facade** | One simple front door over a complicated system | A service class sitting in front of repos and validators | | **Composite** | Treat one leaf and a whole group identically | A file system, an org chart, a UI tree | | **Bridge** | Two independent things vary separately | A shape and its renderer | | **Proxy** | Control access to the same underlying behaviour | Lazy loading, permission checks, caching, a remote stand-in | | **Flyweight** | Share unchangeable shared state across many objects | Glyphs, tree types, chess movement rules | - **Lead with intent, not shape.** Adapter, Decorator, Proxy, and Facade all wrap something — intent is the only thing that actually tells them apart, and that's the real question every time. - **Decorator vs. inheritance is the one you'll use the most in practice.** Independent, mixable features point to decorators; almost anything else probably doesn't. - **Composite is the answer whenever the domain is a tree**, and its whole value is the type-checking code you *don't* have to write. - **Flyweight is an optimisation with a precondition.** Say the precondition — shared state has to be unchangeable — not just the pattern's name. 71:T4b53,Behavioral patterns are about **how objects talk to each other, and who's responsible for what**. These five show up in real LLD answers over and over: nearly every problem in this section reaches for Strategy to handle pricing, Observer to handle notifications, and State to handle lifecycles. Get comfortable with these five, and you can design most of the classic interview problems. ## Strategy — swap an algorithm while the program runs **The idea: define a family of interchangeable algorithms, and pick one while the program runs.** It's the direct cure for a growing `if/elif` chain of *behaviours* — as opposed to types, which is what Factory fixes. ```python from abc import ABC, abstractmethod class PricingStrategy(ABC): @abstractmethod def price_paise(self, minutes: int) -> int: ... class FlatRate(PricingStrategy): def price_paise(self, minutes: int) -> int: return 5_000 class PerHour(PricingStrategy): def __init__(self, rate_paise: int): self.rate = rate_paise def price_paise(self, minutes: int) -> int: hours = -(-minutes // 60) # round part-hours up return hours * self.rate class Progressive(PricingStrategy): """Cheap for the first hour, then pricier each hour after — real parking pricing.""" def price_paise(self, minutes: int) -> int: hours, total, rate = -(-minutes // 60), 0, 2_000 for _ in range(hours): total += rate rate += 1_000 return total class ParkingTicket: def __init__(self, strategy: PricingStrategy): self.strategy = strategy # the ticket just HOLDS a strategy def fee(self, minutes: int) -> int: return self.strategy.price_paise(minutes) assert ParkingTicket(FlatRate()).fee(300) == 5_000 assert ParkingTicket(PerHour(3_000)).fee(90) == 6_000 # 1.5 hours billed as 2 assert ParkingTicket(Progressive()).fee(180) == 2_000 + 3_000 + 4_000 ticket = ParkingTicket(FlatRate()) ticket.strategy = Progressive() # swapped while the program is running print("progressive 3h:", ticket.fee(180)) ``` **Where you'll actually use this in the problems ahead**: parking fees, ride surge pricing, seat allocation rules, split algorithms in an expense-sharing app, what gets evicted from a cache, which rate-limiting algorithm to run, sorting or matching rules. **Strategy vs. State — this comes up constantly, and it's really about *who's in charge*:** | | Strategy | State | |---|---|---| | Picked by | Whoever's using it, before or during the call | The states themselves, as the object moves through its life | | Do the options know each other? | No — each algorithm stands alone | Yes — each state knows what it can turn into next | | Represents | *How* to do something | *What* the object currently is | **The lightweight version is worth knowing too**: in Python, a strategy can just be a plain function. `ParkingTicket(lambda m: 5000)` is a perfectly valid strategy, and a dictionary of named functions is often the entire pattern, no classes needed. Saying this — knowing when a class would just be extra ceremony — is itself a senior-level signal. > **Remember:** Strategy is chosen from outside by whoever's using it. State is chosen from inside, by the object as it moves through its own life. ```knowledge-check { "questions": [ { "id": "ip45-lld-06-strategy-q1", "type": "mcq", "prompt": "What's the clearest way to tell Strategy and State apart?", "options": [ {"id":"a","text":"Strategy uses interfaces, State uses enums"}, {"id":"b","text":"With Strategy, whoever is using the object picks which independent algorithm runs; with State, the object's own states drive transitions between each other, modelling a lifecycle rather than an interchangeable algorithm"}, {"id":"c","text":"Strategy is a creational pattern, State is behavioral"}, {"id":"d","text":"State can only ever have two possible alternatives"} ], "correct": "b", "explanation": "Their class diagrams look almost identical, so intent is what actually separates them. Strategies stand alone and are picked from outside; states know their own successors and drive the object through a lifecycle from the inside." } ] } ``` ## Observer — tell everyone interested when something changes **The idea: when one object changes, notify everyone who signed up for it, without that object needing to know who they are.** This is publish-subscribe at the object level, and it's exactly what makes "add a new listener for this event" a zero-edit change. ```python from abc import ABC, abstractmethod class OrderObserver(ABC): @abstractmethod def on_order_placed(self, order_id: str, total_paise: int) -> None: ... class Order: # the thing being watched def __init__(self): self._observers: list[OrderObserver] = [] def subscribe(self, o: OrderObserver) -> None: self._observers.append(o) def unsubscribe(self, o: OrderObserver) -> None: self._observers.remove(o) def place(self, order_id: str, total_paise: int) -> None: # ... save the order somewhere ... for o in list(self._observers): # copy the list: a handler might unsubscribe try: o.on_order_placed(order_id, total_paise) except Exception as exc: # one broken observer must not sink the rest print(f" observer {type(o).__name__} failed: {exc}") class EmailReceipt(OrderObserver): def __init__(self): self.sent: list[str] = [] def on_order_placed(self, order_id, total_paise): self.sent.append(order_id) class InventoryUpdater(OrderObserver): def __init__(self): self.updates = 0 def on_order_placed(self, order_id, total_paise): self.updates += 1 class BrokenAnalytics(OrderObserver): def on_order_placed(self, order_id, total_paise): raise RuntimeError("analytics down") order = Order() email, inventory = EmailReceipt(), InventoryUpdater() for observer in (email, inventory, BrokenAnalytics()): order.subscribe(observer) order.place("ord_1", 49_900) assert email.sent == ["ord_1"] and inventory.updates == 1 # unaffected by the broken one print("observers notified; email queue:", email.sent) ``` Four details that turn a textbook answer into a strong one: 1. **Isolate failures.** One observer throwing an exception must never stop the others, exactly as shown above. 2. **Decide up front: synchronous or asynchronous?** Notifying synchronously means the subject is only as fast as its slowest observer. Pushing to a queue instead is this same pattern applied at the scale of a whole system, and it connects directly to the messaging lesson in HLD. 3. **Unsubscribe, or leak memory.** A subject that keeps strong references to observers forever keeps them alive forever too — this is the classic listener memory leak. Weak references or an explicit teardown step fix it. 4. **Never mutate the observer list while you're looping over it.** Copy it first, exactly as shown above. You've already used this everywhere, whether you called it Observer or not: DOM event listeners, React state subscriptions, Kafka consumer groups, database triggers, and every `on_change` callback you've ever written. > **Remember:** a subject holding onto observers forever is the classic memory leak here. Every subscribe needs a matching unsubscribe somewhere. ```knowledge-check { "questions": [ { "id": "ip45-lld-06-observer-q1", "type": "mcq", "prompt": "What's the most common memory bug in an Observer setup?", "options": [ {"id":"a","text":"The subject stores too many past events"}, {"id":"b","text":"Observers never get unsubscribed, so the subject's strong references keep them alive forever — the classic listener leak, fixed with explicit unsubscribing or weak references"}, {"id":"c","text":"Observers get notified in the wrong order"}, {"id":"d","text":"The interface has too many methods"} ], "correct": "b", "explanation": "A long-lived subject holding references to short-lived observers — closed dialogs, finished requests, unmounted components — stops garbage collection from ever cleaning them up. That's why UI frameworks always pair a subscribe with a teardown." } ] } ``` ## Command — turn a request into an object **The idea: wrap a request up as an object**, so it can be handed around, queued, logged, and — the reason it matters most — **undone**. ```python from abc import ABC, abstractmethod class Command(ABC): @abstractmethod def execute(self) -> None: ... @abstractmethod def undo(self) -> None: ... class Document: def __init__(self): self.text = "" class AppendText(Command): def __init__(self, doc: Document, text: str): self.doc, self.text = doc, text def execute(self) -> None: self.doc.text += self.text def undo(self) -> None: self.doc.text = self.doc.text[: -len(self.text)] class UpperCase(Command): def __init__(self, doc: Document): self.doc, self._before = doc, None def execute(self) -> None: self._before = self.doc.text # remember the old state, to undo later self.doc.text = self.doc.text.upper() def undo(self) -> None: self.doc.text = self._before class Editor: # the thing that runs commands def __init__(self): self.history: list[Command] = [] def run(self, cmd: Command) -> None: cmd.execute() self.history.append(cmd) def undo(self) -> None: if self.history: self.history.pop().undo() doc, editor = Document(), Editor() editor.run(AppendText(doc, "hello ")) editor.run(AppendText(doc, "world")) editor.run(UpperCase(doc)) assert doc.text == "HELLO WORLD" editor.undo(); assert doc.text == "hello world" editor.undo(); assert doc.text == "hello " print("after undos:", repr(doc.text)) ``` Four things Command makes possible, and why it turns up in so many LLD problems: | It gives you | How | Where you'll see it | |---|---|---| | **Undo / redo** | Each command knows how to reverse itself | Text editors, drawing apps, transactions | | **Queueing** | A command is just an object, so it can wait in a list | Job queues, thread pools, schedulers | | **Logging and replay** | Save the stream of commands somewhere | Event sourcing, audit trails, crash recovery | | **Decoupling** | The thing running the command only ever calls `execute()` | Buttons, menu items, keyboard shortcuts, remote controls | Worth knowing: to make undo work, a command either **stores the reverse operation** (append, then undo by truncating) or **snapshots the state from before** (called the Memento pattern, which is what `UpperCase` does above). Snapshots are simpler and always correct; reverse operations use far less memory. Pick based on how big the state actually is. > **Remember:** once a request is an object, everything you can do to objects — store it, queue it, log it, reverse it — becomes available. That's the whole reason Command exists. ```knowledge-check { "questions": [ { "id": "ip45-lld-06-command-q1", "type": "mcq", "prompt": "What's the main reason to wrap an operation as a Command object instead of just calling a method directly?", "options": [ {"id":"a","text":"It runs faster than a plain method call"}, {"id":"b","text":"Once the request is a real object it can be stored, queued, logged, replayed, and — most importantly — undone, none of which a plain method call can do"}, {"id":"c","text":"It removes the need for interfaces"}, {"id":"d","text":"It guarantees the operation will succeed"} ], "correct": "b", "explanation": "Turning a request into an object is the whole point. Once it's an object, everything objects can do — being stored, scheduled, saved, or reversed — becomes available to it." } ] } ``` ## State and Template Method **State — the idea: an object changes how it behaves as its internal state changes, almost as if it swapped its own class.** Reach for this whenever something has a real lifecycle with rules about which transitions are allowed — orders, tickets, documents, vending machines, ATMs, elevators. ```python from abc import ABC, abstractmethod class OrderState(ABC): @abstractmethod def pay(self, order: "Order") -> None: ... @abstractmethod def cancel(self, order: "Order") -> None: ... @abstractmethod def name(self) -> str: ... class Created(OrderState): def name(self) -> str: return "created" def pay(self, order): order.state = Paid() def cancel(self, order): order.state = Cancelled() class Paid(OrderState): def name(self) -> str: return "paid" def pay(self, order): raise ValueError("already paid") def cancel(self, order): order.state = Refunded() # cancelling a paid order = a refund class Cancelled(OrderState): def name(self) -> str: return "cancelled" def pay(self, order): raise ValueError("cannot pay a cancelled order") def cancel(self, order): raise ValueError("already cancelled") class Refunded(OrderState): def name(self) -> str: return "refunded" def pay(self, order): raise ValueError("cannot pay a refunded order") def cancel(self, order): raise ValueError("already refunded") class Order: def __init__(self): self.state: OrderState = Created() def pay(self): self.state.pay(self) def cancel(self): self.state.cancel(self) @property def status(self) -> str: return self.state.name() o = Order(); assert o.status == "created" o.pay(); assert o.status == "paid" o.cancel(); assert o.status == "refunded" bad = Order(); bad.cancel() try: bad.pay() raise AssertionError("illegal transition allowed") except ValueError as e: print("state machine rejected:", e) ``` Compare that to the alternative: `if self.status == "created" and action == "pay": ...`, repeated in every method that touches an order. The State version makes **illegal transitions impossible to write by accident**, keeps each state's own rules in exactly one readable place, and lets you add a brand-new state without touching any of the existing ones. There is a real trade-off worth naming: one class per state means more classes overall, and the full map of transitions is spread across several files instead of sitting in one table. For a small, stable state machine, a plain enum plus a transition table is often clearer — and saying that out loud beats reaching for the pattern on reflex. **Template Method — the idea: a base class fixes the *order* of an algorithm's steps, and subclasses fill in just the steps that actually change.** ```python from abc import ABC, abstractmethod class ReportGenerator(ABC): def generate(self, rows: list[int]) -> str: # the template — the order is fixed here data = self.fetch(rows) body = self.format(data) return self.decorate(body) # a hook, with a default @abstractmethod def fetch(self, rows: list[int]) -> list[int]: ... @abstractmethod def format(self, data: list[int]) -> str: ... def decorate(self, body: str) -> str: return body # optional to override class TotalsReport(ReportGenerator): def fetch(self, rows): return rows def format(self, data): return f"total={sum(data)}" class TopNReport(ReportGenerator): def fetch(self, rows): return sorted(rows, reverse=True)[:2] def format(self, data): return f"top={data}" def decorate(self, body): return f"** {body} **" # chose to override the hook assert TotalsReport().generate([3, 1, 2]) == "total=6" assert TopNReport().generate([3, 1, 2]) == "** top=[3, 2] **" print(TopNReport().generate([9, 4, 7, 1])) ``` **Template Method vs. Strategy** is the last confusion worth clearing up: Template Method uses **inheritance** and fixes the *order* of steps at write-time, only letting subclasses vary individual steps. Strategy uses **composition** and swaps out the *entire* algorithm while the program is running. Reach for Template Method when the sequence genuinely must never change — a build pipeline, a request's lifecycle, a test's setup-run-teardown. Reach for Strategy for basically everything else — and given the "composition over inheritance" habit from earlier, Strategy is the more common answer in practice. > **Remember:** State means "illegal transitions become impossible to write by accident," not just "fewer if-statements." ```knowledge-check { "questions": [ { "id": "ip45-lld-06-state-q1", "type": "mcq", "prompt": "An `Order` moves through created -> paid -> shipped -> delivered, and can only be cancelled before shipping. Why prefer the State pattern over status checks spread across each method?", "options": [ {"id":"a","text":"It uses fewer classes overall"}, {"id":"b","text":"Each state's legal moves live in exactly one class, so illegal transitions become impossible to write by accident, and adding a new status means adding a class instead of editing every method's conditionals"}, {"id":"c","text":"It makes the order object unchangeable"}, {"id":"d","text":"It removes the need to save the status anywhere"} ], "correct": "b", "explanation": "Status checks scattered across methods are an Open/Closed violation, and they drift out of sync as new statuses get added. State keeps the rules in one place per state — at the cost of more classes, which is why a small, stable machine might be clearer as an enum plus a transition table instead." } ] } ``` ## Quick recap | Pattern | Intent | Reach for it when | |---|---|---| | **Strategy** | Interchangeable algorithms, picked at runtime | Pricing, matching, eviction, sorting, split rules — anything with "…policy" in its name | | **Observer** | Notify many listeners when one thing changes | Notifications, cache invalidation, UI updates, "and also do X when Y happens" | | **Command** | A request, turned into an object | Undo/redo, queues, schedulers, audit logs, remote controls | | **State** | Behaviour changes with lifecycle stage | Orders, tickets, vending machines, ATMs, elevators, documents | | **Template Method** | Fixed order, variable steps | Pipelines where the sequence must never change | - **Strategy and Observer show up in nearly every LLD problem in this section.** Pricing is a strategy. "Notify the user, update inventory, log it for analytics" is an observer list. - **State is how you get lifecycle correctness right**, and "illegal transitions become unwritable" is the exact sentence that earns credit. - **Command is the answer to undo**, and knowing the reverse-vs-snapshot trade-off is the natural follow-up question. - **Prefer Strategy over Template Method** unless the *order* of steps genuinely has to stay fixed — composition over inheritance applies to patterns too, not just plain classes. - **Know when a pattern is overkill.** A dictionary of functions is a strategy. A plain list of callbacks is an observer. Saying so out loud is a senior-level signal, not a gap in your knowledge. 72:T4bb9,The remaining behavioral patterns come up less often than Strategy and Observer, but each one is the go-to answer for a specific kind of problem. Chain of Responsibility, especially, is what nearly every piece of middleware, logging library, and approval workflow you've ever used is quietly built from. This lesson finishes the pattern list, then moves on to anti-patterns — because spotting a bad design out loud is worth just as much in an interview as building a good one. ## Chain of Responsibility **The idea: pass a request down a line of handlers until one of them deals with it** (or every handler has had a turn). Each handler in the chain decides whether to act, whether to pass the request further, or both. ```python from abc import ABC, abstractmethod class Handler(ABC): def __init__(self): self._next: "Handler | None" = None def set_next(self, nxt: "Handler") -> "Handler": self._next = nxt return nxt # returns nxt, so chains read left-to-right def handle(self, request: dict) -> str | None: result = self.process(request) if result is not None: return result # this handler dealt with it — stop here return self._next.handle(request) if self._next else None @abstractmethod def process(self, request: dict) -> str | None: ... class AuthHandler(Handler): def process(self, request): return None if request.get("user") else "401 unauthenticated" class RateLimitHandler(Handler): def __init__(self, limit: int): super().__init__() self.limit, self.seen = limit, {} def process(self, request): user = request["user"] self.seen[user] = self.seen.get(user, 0) + 1 return "429 rate limited" if self.seen[user] > self.limit else None class ValidationHandler(Handler): def process(self, request): return None if request.get("body") else "400 missing body" class BusinessHandler(Handler): def process(self, request): return f"200 processed {request['body']} for {request['user']}" chain = AuthHandler() chain.set_next(RateLimitHandler(limit=2)).set_next(ValidationHandler()).set_next(BusinessHandler()) assert chain.handle({}) == "401 unauthenticated" assert chain.handle({"user": "asha", "body": "x"}).startswith("200") assert chain.handle({"user": "asha", "body": "y"}).startswith("200") assert chain.handle({"user": "asha", "body": "z"}) == "429 rate limited" print("chain result:", chain.handle({"user": "ravi"})) ``` **You've already used this everywhere**: HTTP middleware in Express, Django, or Chi, servlet filters, logging libraries (a `DEBUG` handler passes upward until something matches the current level), approval workflows (manager, then director, then VP, depending on amount), and even how a program handles exceptions internally. Two things worth naming: **the chain can be reconfigured while the program runs** — reorder, add, or remove a handler without touching any other one — and **the sender has no idea which handler will actually respond**, which is exactly where the decoupling this pattern buys you comes from. The risk is that a request can reach the end of the chain with nobody having dealt with it, so always design that final fallback on purpose. > **Remember:** always decide on purpose what happens when a request reaches the end of the chain with nobody handling it. ```knowledge-check { "questions": [ { "id": "ip45-lld-07-cor-q1", "type": "mcq", "prompt": "What's the one thing you have to design deliberately in a Chain of Responsibility?", "options": [ {"id":"a","text":"Making sure every handler processes every request"}, {"id":"b","text":"What happens when a request reaches the end of the chain with nobody having handled it — since the sender has no way of knowing in advance which handler, if any, will respond"}, {"id":"c","text":"Making sure the chain has an even number of handlers"}, {"id":"d","text":"Making sure handlers can never be reordered"} ], "correct": "b", "explanation": "The decoupling that makes this pattern useful also means nobody guarantees a handler will actually exist for every request. A default fallback handler (or an explicit \"unhandled\" result) stops requests from silently disappearing." } ] } ``` ## Iterator, Mediator, and Memento **Iterator — the idea: walk through a collection without exposing how it's actually stored inside.** You already use this every time you write a `for` loop. The real design point is that the *code calling it* never has to know whether it's looping over an array, a tree, or a paginated API. ```python class PaginatedFeed: """Looks like a plain sequence to callers; secretly fetches one page at a time.""" def __init__(self, pages: list[list[str]]): self._pages = pages def __iter__(self): for page in self._pages: # imagine each page were a network call for item in page: yield item # a generator basically IS the iterator here feed = PaginatedFeed([["a", "b"], ["c"], ["d", "e"]]) assert list(feed) == ["a", "b", "c", "d", "e"] assert sum(1 for _ in feed) == 5 # can be looped over again print("streamed lazily:", [x for x in feed][:3]) ``` The real value here: swapping the storage from a plain list to a database cursor changes nothing for whoever's calling it. In Python, generators make this pattern nearly invisible — it's worth mentioning that out loud. In Java it's explicit, through `Iterable`/`Iterator`. **Mediator — the idea: put complicated many-to-many communication in one central place, so objects stop talking to each other directly.** Without it, *n* components that all need to talk to each other could need up to *n(n−1)/2* separate connections. With a mediator, every one of them only needs to know about the mediator itself. ```python class ChatRoom: # the mediator def __init__(self): self._members: dict[str, "User"] = {} def join(self, user: "User") -> None: self._members[user.name] = user user.room = self def send(self, sender: str, text: str) -> None: for name, user in self._members.items(): if name != sender: # users never reference each other directly user.receive(sender, text) class User: def __init__(self, name: str): self.name, self.room, self.inbox = name, None, [] def say(self, text: str) -> None: self.room.send(self.name, text) def receive(self, sender: str, text: str) -> None: self.inbox.append((sender, text)) room = ChatRoom() asha, ravi, meera = User("asha"), User("ravi"), User("meera") for u in (asha, ravi, meera): room.join(u) asha.say("hello") assert ravi.inbox == [("asha", "hello")] and meera.inbox == [("asha", "hello")] assert asha.inbox == [] # the sender doesn't get their own message back print("mediated:", ravi.inbox) ``` Worth stating as a warning: **the mediator can turn into a god object all on its own.** It quietly absorbs coordination logic from everywhere and grows without limit. Keep it focused on routing and coordination, and leave the actual domain rules with the participants. Air traffic control, dialog coordination in a UI, and — at a much bigger scale — a message broker are all mediators. **Memento — the idea: capture and later restore an object's state, without exposing what's inside it.** This is the pattern behind undo, checkpoints, and save games, and it fits naturally alongside Command, which stores the memento it needs in order to reverse itself. The key detail: the memento is **opaque to everyone except the object that made it** — whoever's holding it can pass it around, but can't peek inside or change it, which is what keeps encapsulation intact. > **Remember:** a mediator that starts holding domain rules, not just routing, has already become the god object it was meant to prevent. ```knowledge-check { "questions": [ { "id": "ip45-lld-07-mediator-q1", "type": "mcq", "prompt": "What's the main risk of adding a Mediator?", "options": [ {"id":"a","text":"Components become impossible to test"}, {"id":"b","text":"The mediator ends up absorbing coordination logic from every participant and turns into a god object — it should stick to routing and coordination, and leave the actual domain rules with the participants"}, {"id":"c","text":"It increases the number of connections between components"}, {"id":"d","text":"Messages can only reach one recipient at a time"} ], "correct": "b", "explanation": "Mediator trades many-to-many coupling for a single hub, and that hub is exactly where complexity tends to pile up. Keeping it thin is what preserves the benefit in the first place." } ] } ``` ## Visitor and Interpreter **Visitor — the idea: add new operations to a fixed set of types without touching the classes in it.** Here's the problem it solves: you have a fixed set of node types (a syntax tree, a document tree, a set of shapes) and a growing list of operations you want to run over them (render, export, validate, compute a cost). Putting every operation directly on every node class means editing all of them every single time you add one. ```python from abc import ABC, abstractmethod class Node(ABC): @abstractmethod def accept(self, visitor: "Visitor"): ... class Number(Node): def __init__(self, value: int): self.value = value def accept(self, visitor): return visitor.visit_number(self) class Add(Node): def __init__(self, left: Node, right: Node): self.left, self.right = left, right def accept(self, visitor): return visitor.visit_add(self) class Multiply(Node): def __init__(self, left: Node, right: Node): self.left, self.right = left, right def accept(self, visitor): return visitor.visit_multiply(self) class Visitor(ABC): @abstractmethod def visit_number(self, n: Number): ... @abstractmethod def visit_add(self, n: Add): ... @abstractmethod def visit_multiply(self, n: Multiply): ... class Evaluate(Visitor): # operation 1 def visit_number(self, n): return n.value def visit_add(self, n): return n.left.accept(self) + n.right.accept(self) def visit_multiply(self, n): return n.left.accept(self) * n.right.accept(self) class PrettyPrint(Visitor): # operation 2 — not one Node class was touched def visit_number(self, n): return str(n.value) def visit_add(self, n): return f"({n.left.accept(self)} + {n.right.accept(self)})" def visit_multiply(self, n): return f"({n.left.accept(self)} * {n.right.accept(self)})" tree = Multiply(Add(Number(2), Number(3)), Number(4)) # (2 + 3) * 4 assert tree.accept(Evaluate()) == 20 assert tree.accept(PrettyPrint()) == "((2 + 3) * 4)" print(tree.accept(PrettyPrint()), "=", tree.accept(Evaluate())) ``` **The trade-off here runs exactly backwards from normal polymorphism, and that's the insight to state out loud**: adding a new *operation* is free, just write a new visitor. Adding a new *node type* means editing every single existing visitor. So Visitor is the right call when the type hierarchy is stable and operations keep piling up, like in compilers, document processors, and static analysers, and the wrong call when new types show up often. **Interpreter — the idea: represent a grammar as classes, and evaluate sentences written in it.** The `Evaluate` visitor above is really a tiny interpreter for a small arithmetic grammar. In real systems you'll meet this in rule engines, query filters, and search-query languages. For anything bigger than that, a real parser generator beats hand-written interpreter classes — it's enough to recognise "this is a parsing problem, not a pattern problem" and say so. > **Remember:** Visitor flips the usual trade-off — new operations are free, new types are expensive. Know which way your problem actually leans before reaching for it. ```knowledge-check { "questions": [ { "id": "ip45-lld-07-visitor-q1", "type": "mcq", "prompt": "When is the Visitor pattern actually the right choice?", "options": [ {"id":"a","text":"When new node types get added often but the operations rarely change"}, {"id":"b","text":"When the set of node types is stable but the operations on them keep growing — a new operation is just a new visitor class, while a new node type means editing every existing visitor"}, {"id":"c","text":"Whenever there's a tree structure involved at all"}, {"id":"d","text":"When the structure needs to be traversed in parallel"} ], "correct": "b", "explanation": "Visitor flips the usual extensibility direction: cheap new operations, expensive new types. Getting that direction right for your actual domain is the whole decision here." } ] } ``` ## Anti-patterns: recognising bad design out loud Being able to name a smell and its fix live, mid-interview, is worth just as much as building a clean design in the first place — because that's exactly what a real design review sounds like. | Anti-pattern | What it looks like | Why it's a problem | The fix | |---|---|---|---| | **God object** | `OrderManager` with 40 methods and 15 fields | Every change has to touch it; nothing can be tested on its own | Split it up by why each part would change (SRP) | | **Anaemic domain model** | Entities that are just getters and setters; all the real logic lives in `*Service` classes | The data and the rules about that data live apart, so invalid states leak through everywhere | Move behaviour onto the entity that actually owns the data | | **Spaghetti inheritance** | Five-level class trees; subclasses overriding methods just to disable them | Fragile base classes; breaks Liskov Substitution | Composition instead; small, focused interfaces | | **Primitive obsession** | A plain string standing in for money, an id, a phone number, a currency code | The type system can't stop you mixing them up; checks end up scattered everywhere | Value objects: `Money`, `TicketId` | | **Magic strings and numbers** | `if status == 3`, `if role == "adm"` | A typo still compiles fine; the meaning is invisible | Enums and named constants | | **Feature envy** | A method that mostly reads fields from a different class | Coupling to a shape you don't own | Move the method to the class that owns the data | | **Circular dependency** | `Order` imports `Customer`, which imports `Order` | Neither one can be understood or tested alone | Extract an interface, or invert the dependency | | **Leaky abstraction** | A `Repository` that hands back a raw ORM query object | Callers end up depending on the storage technology anyway | Return plain domain objects only | | **Boolean trap** | `save(true, false, true)` | Completely unreadable at the call site | Named arguments, enums, or separate methods | | **Copy-paste inheritance** | Subclassing purely to reuse one method | Ties two unrelated things together permanently | Pull the shared logic into its own collaborator | | **Pattern fever** | An interface, a factory, and a strategy for one concrete class that will never have a second | All the extra layers, none of the payoff | Delete it. Add the abstraction the day a second case actually shows up | That last row deserves special attention, because after a whole pattern catalogue it's tempting to use every one of them: **the single most common mistake after learning these patterns is reaching for one where a plain class would have done fine.** An interface with one implementation and no realistic second one is a cost with no benefit. Often the strongest possible answer is: "I'd keep this concrete for now. If a second pricing rule ever shows up, this is exactly where the strategy would go." That shows you know both the pattern *and* its price. > **Remember:** the entity that owns the data should own the rules about it too. Data and logic living apart is an anaemic domain model, and it's the most common structural mistake in real codebases. ```knowledge-check { "questions": [ { "id": "ip45-lld-07-antipattern-q1", "type": "mcq", "prompt": "A design has `Order` as a bag of getters and setters, with every rule — validation, totals, state transitions — living inside `OrderService`. What's this called, and why is it a problem?", "options": [ {"id":"a","text":"A god object — split the service into smaller services"}, {"id":"b","text":"An anaemic domain model — the data and the rules about that data live in separate places, so nothing stops an invalid Order from existing, and the same checks get re-implemented in every service that touches it"}, {"id":"c","text":"Primitive obsession — introduce value objects"}, {"id":"d","text":"A leaky abstraction — hide the ORM"} ], "correct": "b", "explanation": "Whatever owns the data should own the rules about it — otherwise any caller can build an invalid object, and the same validation ends up copy-pasted into every service that touches it. Behaviour belongs right next to the state it protects." } ] } ``` ## Quick recap **What question triggers which pattern:** | The question you're being asked | The pattern | |---|---| | "How do I add a new type without editing every caller?" | Factory / Strategy | | "How do I add behaviour without subclassing?" | Decorator | | "How do I make several things react to one change?" | Observer | | "How do I support undo?" | Command (plus Memento) | | "How do I stop illegal state transitions?" | State | | "How do I run a request through configurable steps?" | Chain of Responsibility | | "How do I treat one thing and a group of them the same way?" | Composite | | "How do I fit a third-party API to my own interface?" | Adapter | | "How do I hide a messy subsystem?" | Facade | | "How do I control access to an object?" | Proxy | | "How do I add operations to a fixed set of types?" | Visitor | | "How do I cut down n-to-n communication?" | Mediator | | "How do I share state across millions of objects?" | Flyweight | | "How do I safely build a complicated object?" | Builder | | "How do I guarantee exactly one instance exists?" | Singleton (and consider injecting it instead) | - **Chain of Responsibility is the single most valuable pattern in this lesson** — every middleware stack, logging library, and approval workflow is one, and you'll meet it directly in the rate-limiter and logging-framework designs later in this section. - **Visitor's trade-off runs backwards from usual polymorphism**: cheap new operations, expensive new types. Say which way your domain actually leans. - **The anti-pattern table is an interview tool in itself.** When someone asks "what's wrong with this design?", you want names and fixes ready, not just a vague sense that something feels off. - **Know when *not* to reach for a pattern.** After a catalogue this long, restraint is what separates a strong answer from a weak one — abstract exactly where things actually vary, and say out loud when you're deliberately choosing to keep something simple. 73:T4725,"Two users try to book the last seat at the exact same moment — what happens?" That question shows up as a follow-up in almost every LLD interview, and it's where otherwise solid designs quietly fall apart. This lesson gives you the vocabulary, the three tools you'll actually use, and the specific patterns for the problems coming up later in this section. Here's the one idea that keeps you out of trouble: **find the piece of data that's shared and changeable, then either stop sharing it, stop letting it change, or protect access to it.** Every correct answer boils down to one of those three moves. ## Race conditions and shared, changeable data A **race condition** happens whenever the result depends on exactly how two things happening at once get interleaved. The classic shape is **check, then act**: ```python import threading class UnsafeCounter: def __init__(self): self.count = 0 def increment(self): current = self.count # read self.count = current + 1 # write — another thread might have written in between class SafeCounter: def __init__(self): self.count = 0 self._lock = threading.Lock() def increment(self): with self._lock: # read-then-write happens as one atomic step now self.count += 1 def hammer(counter, times=50_000): for _ in range(times): counter.increment() def run(counter): threads = [threading.Thread(target=hammer, args=(counter,)) for _ in range(4)] for t in threads: t.start() for t in threads: t.join() return counter.count safe = run(SafeCounter()) assert safe == 200_000 # always exactly right, every time unsafe = run(UnsafeCounter()) print(f"safe={safe} (always correct), unsafe={unsafe} (may be < 200000)") ``` There are three shapes of race worth being able to name on sight: | Race | What it looks like | Example | |---|---|---| | **Check-then-act** | Test something, then act on it — but it could change in between | `if seat.is_free: seat.book()` | | **Read-modify-write** | Load a value, do some math, save it back | `count = count + 1`, `balance -= amount` | | **Publish-before-init** | Another thread sees an object that's only half built | A naive lazy singleton, with no lock at all | **Two questions to answer out loud in every LLD interview, before anyone even asks:** 1. *What's the shared, changeable data here?* — the set of free spots, the seat map, the inventory count, the account balance. 2. *What's protecting it?* — a lock, an atomic operation, the fact that it never changes, or a database rule. Say both, unprompted, and you've already answered the concurrency follow-up before it lands. > **Remember:** thread-safe pieces don't add up to a thread-safe sequence. The whole check-then-act step needs one lock around it, not two separately-safe halves. ```knowledge-check { "questions": [ { "id": "ip45-lld-08-race-q1", "type": "mcq", "prompt": "`if seat.is_available: seat.book(user)` runs on two threads at the same moment. What kind of race is this, and why doesn't making `is_available` and `book` each individually thread-safe fix it?", "options": [ {"id":"a","text":"Read-modify-write; it's fixed by marking each method synchronized"}, {"id":"b","text":"Check-then-act — both threads can pass the check before either one books the seat. The two steps have to be atomic *together*, so the lock has to cover the whole check-and-act, not each method on its own"}, {"id":"c","text":"Publish-before-initialisation; fixed with a volatile field"}, {"id":"d","text":"There's no race here, since booking just overwrites the same value"} ], "correct": "b", "explanation": "Thread-safe individual methods give you no guarantee about a sequence of them — this is the classic trap where safe pieces don't add up to a safe whole. The section that needs protecting is the entire check-and-act." } ] } ``` ## The three tools **1. Locks — mutual exclusion.** The general-purpose tool: only one thread is allowed inside the protected section at a time. ```python import threading class SeatMap: def __init__(self, seats: list[str]): self._free = set(seats) self._lock = threading.Lock() def book(self, seat: str, user: str) -> bool: with self._lock: # check and act happen as one atomic step if seat not in self._free: return False self._free.remove(seat) return True @property def free_count(self) -> int: with self._lock: return len(self._free) seats = SeatMap([f"A{i}" for i in range(3)]) results = [] threads = [threading.Thread(target=lambda: results.append(seats.book("A1", "u"))) for _ in range(10)] for t in threads: t.start() for t in threads: t.join() assert results.count(True) == 1 # exactly one winner, every single time assert seats.free_count == 2 print("bookings succeeded:", results.count(True), "of", len(results)) ``` Rules for locks, and all of them get asked about: - **Hold the lock for the shortest time possible** — never across a network call, a disk read, or a callback into code you don't control. - **Never call unfamiliar code while holding a lock.** It might call back into your code and deadlock against itself. - **Prefer many small locks over one big one**: one lock per seat, spot, or account, so unrelated operations can run at the same time. - **Use a read-write lock** when reads vastly outnumber writes — many readers can run together, with just one writer at a time. **2. Atomic operations.** For a single value, an atomic compare-and-swap beats a lock outright: no blocking, no possibility of deadlock, less overhead. Java's `AtomicInteger.incrementAndGet()`, Go's `atomic.AddInt64`, and Redis's `INCR` are all this same idea. The limit is that atomics only protect **one** variable — the moment two things need to change together, you're back to needing a lock or a transaction. **3. Making it unchangeable — needs no protection at all.** An object that never changes after it's built is safe to hand to any number of threads, with no lock, no cost, and literally no way for it to go wrong. This is exactly why value objects like `Money`, `TimeSlot`, and `Point` should never change after they're created, and why "just make it unchangeable" is the cheapest concurrency fix you'll ever get to use. When something genuinely has to change, replace the whole object instead of mutating it in place — this is called copy-on-write. > **Remember:** the three tools, from cheapest to most general: make it unchangeable (free), use an atomic operation (one value), or take a lock (anything else, held as briefly as possible). ```knowledge-check { "questions": [ { "id": "ip45-lld-08-mechanisms-q1", "type": "mcq", "prompt": "Why is one lock per parking spot usually better than one single lock for the whole parking lot?", "options": [ {"id":"a","text":"Smaller locks use less memory"}, {"id":"b","text":"Operations on different spots don't compete with each other, so throughput scales with how many things run in parallel — one global lock would force everything in the whole system to happen one at a time"}, {"id":"c","text":"A global lock can never be released"}, {"id":"d","text":"Smaller locks make deadlock impossible"} ], "correct": "b", "explanation": "Lock size is a throughput decision: one big lock is simpler and safer but forces everything to wait its turn. Worth noting: smaller locks actually *raise* the risk of deadlock when one thread needs two of them at once — which is why lock ordering matters, covered next." } ] } ``` ## Deadlock, livelock, and starvation **Deadlock** needs all four of the Coffman conditions to hold at once — break just one of them, and it can't happen: | Condition | What it means | How to break it | |---|---|---| | Mutual exclusion | Something can only be held by one thread at a time | Make it unchangeable, or use a lock-free structure | | Hold and wait | A thread holds one lock while waiting on another | Grab every lock you need at once, or none at all | | No pre-emption | A lock can't be taken away from whoever's holding it | Use timeouts (`tryLock`) | | **Circular wait** | Thread A waits on B, and B waits on A | **A fixed global lock order** — the usual fix | ```python import threading class Account: def __init__(self, aid: int, paise: int): self.id, self.balance = aid, paise self.lock = threading.Lock() def transfer(src: Account, dst: Account, paise: int) -> bool: # ALWAYS lock in a fixed order (by id) — this is exactly what removes the circular wait. first, second = (src, dst) if src.id < dst.id else (dst, src) with first.lock: with second.lock: if src.balance < paise: return False src.balance -= paise dst.balance += paise return True a, b = Account(1, 100_000), Account(2, 50_000) # Concurrent transfers in OPPOSITE directions — the classic setup for a deadlock. t1 = threading.Thread(target=lambda: [transfer(a, b, 100) for _ in range(1_000)]) t2 = threading.Thread(target=lambda: [transfer(b, a, 100) for _ in range(1_000)]) t1.start(); t2.start(); t1.join(); t2.join() assert a.balance + b.balance == 150_000 # the money is all still there, and nothing froze print("balances:", a.balance, b.balance) ``` The bank-transfer deadlock gets asked about by name, and **locking accounts in a fixed order by id** is exactly the answer interviewers are listening for. The fallback, when no stable ordering exists, is `tryLock` with a timeout plus a randomised retry — that breaks the "no pre-emption" condition instead. Mention it as a backup option. Two related problems worth telling apart from deadlock: - **Livelock**: two threads keep reacting to each other and changing state, but neither one ever makes progress — like two people stepping side to side in a hallway, both trying to let the other pass. Fixed with random backoff before retrying. - **Starvation**: one thread never gets its turn because others keep winning first. Fixed with fair locks or a proper queue. > **Remember:** lock accounts (or any pair of things) in a fixed order by id, and the circular-wait condition simply can't happen. ```knowledge-check { "questions": [ { "id": "ip45-lld-08-deadlock-q1", "type": "mcq", "prompt": "Two threads transfer money in opposite directions between accounts A and B, each one locking the source account then the destination. What's the standard fix?", "options": [ {"id":"a","text":"Use one single global lock for every transfer"}, {"id":"b","text":"Lock the two accounts in a fixed global order — by account id, for instance — which breaks the circular-wait condition while still letting unrelated transfers run in parallel"}, {"id":"c","text":"Make the accounts unchangeable"}, {"id":"d","text":"Retry the transfer if it's taking too long"} ], "correct": "b", "explanation": "A single global lock works, but it forces every transfer in the system to wait its turn. Locking in a consistent order removes the cycle with no loss of parallelism; tryLock with a timeout plus randomised retry is the fallback when no stable ordering exists." } ] } ``` ## The patterns you'll actually use **Producer-consumer with a bounded queue.** This is the standard shape whenever requests arrive faster than they can be handled — and the "bounded" part is what gives you backpressure instead of memory growing without limit. ```python import queue, threading def worker(jobs: "queue.Queue", done: list, lock: threading.Lock): while True: job = jobs.get() if job is None: # a signal to shut down cleanly jobs.task_done() return with lock: done.append(job * 2) jobs.task_done() jobs: "queue.Queue" = queue.Queue(maxsize=10) # bounded → producers wait once it's full done, lock = [], threading.Lock() workers = [threading.Thread(target=worker, args=(jobs, done, lock)) for _ in range(3)] for w in workers: w.start() for i in range(20): jobs.put(i) for _ in workers: jobs.put(None) jobs.join() for w in workers: w.join() assert sorted(done) == [i * 2 for i in range(20)] print("processed", len(done), "jobs across", len(workers), "workers") ``` **Optimistic locking (a version check).** No lock held during the operation at all: read a version number, and only allow the write if that version hasn't changed since. This is right for **low contention** — like a user editing their own profile, where clashes are rare. ```python class VersionedRecord: def __init__(self, value: str): self.value, self.version = value, 0 def update(self, new_value: str, expected_version: int) -> bool: if self.version != expected_version: return False # someone else wrote first — caller should retry self.value, self.version = new_value, self.version + 1 return True rec = VersionedRecord("draft") v = rec.version assert rec.update("edited by A", v) is True assert rec.update("edited by B", v) is False # B's outdated write gets rejected assert rec.value == "edited by A" and rec.version == 1 print("optimistic lock rejected the stale write; value =", rec.value) ``` **Pessimistic locking.** Take the lock (or run `SELECT ... FOR UPDATE`) before you even read. This is right for **high contention** — the very last seat of a sold-out show, where optimistic retries would mostly just fail over and over. **Reservation with a TTL.** This is the pattern behind every seat-booking flow you've ever used: hold the resource for a limited time, then either confirm it or let it expire. It avoids holding a database lock for the several minutes a real human spends typing in their card details, and it's exactly why an expiry timestamp beats a plain `is_locked` boolean — a crashed browser tab releases the seat back automatically. **And here's the rule that matters the most in an interview**: in a **multi-process or multi-server** system, an in-process lock protects absolutely nothing. Whatever invariant you need has to be enforced wherever the actual data lives: ``` UPDATE seats SET status = 'booked', booked_by = $1 WHERE seat_id = $2 AND status = 'available'; -- 0 rows affected = someone else already won ``` A conditional `UPDATE`, or a unique constraint, is atomic across every server at once. A `threading.Lock` is atomic across exactly one process, full stop. Saying that sentence out loud is what separates a design that works on your laptop from one that survives production — and it connects directly to the fencing-token discussion in the HLD coordination lesson. > **Remember:** in-process locks are invisible across servers. Only the database — through a conditional write or a unique constraint — actually enforces anything across all of them. ```knowledge-check { "questions": [ { "id": "ip45-lld-08-patterns-q1", "type": "mcq", "prompt": "Your booking service runs on five separate servers. Which mechanism actually stops a seat from being double-booked?", "options": [ {"id":"a","text":"A synchronized method or a threading.Lock in the booking service"}, {"id":"b","text":"A conditional database write — `UPDATE seats SET status='booked' WHERE seat_id=? AND status='available'` — where zero affected rows tells you another server already won. An in-process lock only synchronises threads inside one single process"}, {"id":"c","text":"Making the Seat class unchangeable"}, {"id":"d","text":"Ordering the locks by seat id"} ], "correct": "b", "explanation": "In-process locks simply don't exist from the point of view of a different process. The one thing every server shares is the database, so that's where the invariant has to be enforced — through a conditional write or a unique constraint." } ] } ``` ## Quick recap ``` Find the SHARED, CHANGEABLE data → stop sharing it, stop letting it change, or protect access. Races: check-then-act · read-modify-write · publish-before-init Thread-safe methods do NOT add up: the whole sequence needs one lock, not each half. Tools, cheapest first: Immutability — no protection needed at all. Value objects should never change. Atomic — one variable, no blocking (AtomicInteger, INCR, compare-and-swap) Lock — general purpose; hold briefly, never across I/O or callbacks; small > big Deadlock = all 4 Coffman conditions at once; break circular wait with a GLOBAL LOCK ORDER (by id). Fallback: tryLock + timeout + randomised retry. Livelock → backoff. Starvation → fair locks. Patterns: Producer-consumer with a BOUNDED queue (backpressure) + a shutdown signal Optimistic (version check + retry) → LOW contention Pessimistic (lock / SELECT FOR UPDATE) → HIGH contention Reservation with a TTL → long, human-paced flows (seat holds, checkout) MULTI-PROCESS: an in-process lock protects nothing. Enforce it at the shared resource instead: conditional UPDATE ... WHERE status='available', or a UNIQUE constraint. Zero rows affected means you lost the race. ``` - **Say the concurrency answer before you're asked for it.** Naming the shared, changeable data and how it's protected, unprompted, is one of the highest-value moves in an LLD interview. - **Match your locking strategy to how much contention there really is**: optimistic for rare conflicts, pessimistic for the very last seat, reservations for anything a human takes several minutes to finish. - **Lock ordering is the deadlock answer**, and the bank-transfer example is the one worth having ready. - **The database is the only lock that works across every server.** Every problem later in this section — seat booking, inventory, wallets — comes down to a conditional write or a unique constraint at the storage layer. 74:T53dd,This is the most-asked LLD question there is, and nearly every other problem in this section is really a variation of it. It's popular for a good reason: it's small enough to finish in about 45 minutes, but rich enough to show whether you can model a real domain, pick the right places to leave room for change, and reason about what happens when two things happen at once. This lesson runs the full six-step framework from start to finish. Every problem after this one follows the same shape. ## Step 1 — Requirements and scope **What the system needs to do** (the verbs, coming from the actors: a driver, an attendant, an admin): - Park a vehicle: find a spot that fits, assign it, hand over a ticket. - Unpark: look up the ticket, work out the fee, take payment, free the spot. - Show which spots are free, broken down by vehicle size. - Support several floors, each with many spots. **The clarifying questions that actually change the design**, and the answers this lesson assumes: | Question | Answer used here | What it changes | |---|---|---| | What vehicle types exist? | Motorcycle, car, truck — more may be added later | An enum with a size ordering, not separate subclasses | | Can a small vehicle use a large spot? | Yes, a bigger spot can always take a smaller vehicle | `can_fit` compares sizes by rank, not by exact match | | How's the fee calculated? | Hourly for now, but the scheme will change (flat rate, rising rate, weekend rate) | **Strategy** — this becomes the main place the design can grow | | More than one entrance or exit? | Yes | Separate entry/exit objects, sharing one lot | | Reserved, electric, or accessible spots? | Not yet, but "we might add them" | The spot type has to be easy to extend | | Payment methods? | Cash and card for now, more later | An interface, left unimplemented here | | Kept in memory, or saved somewhere? | In memory, for this interview | Repository interfaces named, but not built | **Say the scope out loud**: "I'll build spot assignment, ticketing, and fee calculation in memory, with pricing that can be swapped out. I'll define a `PaymentProcessor` interface but won't wire up a real payment gateway — I'll show where it would attach." **Worth naming as out of scope**: this is a single lot. A whole chain of lots across a city, with one shared reservation system, is an HLD problem, not this one. > **Remember:** when an interviewer says "this might change later," they're handing you your extension point. Notice it and use it. ```knowledge-check { "questions": [ { "id": "ip45-lld-09-req-q1", "type": "mcq", "prompt": "The interviewer mentions \"the pricing scheme might change — hourly now, maybe progressive or flat later.\" What does that one sentence tell you about the design?", "options": [ {"id":"a","text":"To store the price directly on each spot"}, {"id":"b","text":"Pricing is a place the design needs to vary, so it belongs behind a `PricingStrategy` interface handed into the lot — a new scheme becomes a new class, not an edit to the fee calculation"}, {"id":"c","text":"To make the Ticket class unchangeable"}, {"id":"d","text":"To use a real database instead of memory"} ], "correct": "b", "explanation": "\"This might change\" is the interviewer telling you exactly where to put an extension point. Anything they flag as likely to change should sit behind an interface; anything they call fixed can stay a plain concrete class." } ] } ``` ## Step 2 — Entities and the class diagram Pulling nouns out of the requirements gives: parking lot, floor, spot, vehicle, ticket, payment, pricing, entry and exit panel. Sorting them into the right kind of thing: | Concept | Kind of thing | Why | |---|---|---| | `VehicleType` / `SpotType` | **Enum**, with an ordering | A small, fixed set with a natural ranking | | `Vehicle` | **Entity** | Identified by its plate number | | `ParkingSpot` | **Entity** | Has an identity and a lifecycle — free, then occupied | | `Ticket` | **Entity** | Has an identity, and a lifecycle — issued, then closed | | `Money` | **Value object** | Never changes, has no identity of its own | | `ParkingFloor` | **Entity**, owns its spots | A spot can't exist without a floor | | `SpotAllocationStrategy` | **Interface** | Nearest-first vs. fill-floor-by-floor is likely to change | | `PricingStrategy` | **Interface** | The requirements said this directly | | `ParkingLot` | **Service / facade** | Coordinates everything else | ``` ┌────────────────────┐ │ ParkingLot │ │ + park(vehicle) │◆──────1..*── ParkingFloor │ + unpark(ticket) │ ◆ │ + availability() │ │ 1..* └─────────┬──────────┘ ParkingSpot │ 1 │ ┌─────────────┴──────────────┐ │ 0..1 │ 1 │ 1 ▼ SpotAllocationStrategy PricingStrategy Vehicle △ (interface) △ (interface) △ │ │ │ NearestFirst / FloorByFloor PerHour / Flat / (plate, VehicleType) Progressive Ticket ───> ParkingSpot Ticket ───> Vehicle (associations, not ownership) ``` Two relationship calls worth defending out loud: `ParkingFloor ◆── ParkingSpot` is **composition** — destroy the floor, and its spots have no meaning left. `Ticket ──> Vehicle` is just an **association** — the vehicle existed before the ticket, and still exists after it. > **Remember:** ask "does this part survive the whole being destroyed?" A spot doesn't survive its floor. A vehicle survives its ticket easily. ```knowledge-check { "questions": [ { "id": "ip45-lld-09-entities-q1", "type": "mcq", "prompt": "Why is `ParkingFloor` to `ParkingSpot` composition, while `Ticket` to `Vehicle` is only an association?", "options": [ {"id":"a","text":"Because a floor has more spots than a ticket has vehicles"}, {"id":"b","text":"Lifecycle: a spot means nothing without its floor and is destroyed along with it, while a vehicle exists on its own and keeps existing long after any one ticket closes"}, {"id":"c","text":"Because ParkingSpot is an enum"}, {"id":"d","text":"Because tickets never change once created"} ], "correct": "b", "explanation": "The lifecycle test — \"does the part still make sense if you destroy the whole?\" — is exactly what separates composition (a filled-in diamond) from aggregation or association." } ] } ``` ## Step 3 — The decisions that actually matter here Three decisions carry this whole design. Everything else is just bookkeeping. **1. Whether a spot fits a vehicle is a rank comparison, not an exact match.** `VehicleType` and `SpotType` both carry a rank, and a spot fits a vehicle whenever `spot.rank >= vehicle.rank`. This is exactly what lets a motorcycle park in a car-sized spot, and it means adding an `ELECTRIC` or `ACCESSIBLE` spot type never touches the allocator at all. **2. Which spot to assign is a strategy.** "Which free spot does this vehicle get?" has several reasonable answers — the first one found, the one nearest the entrance, spread evenly across floors, the cheapest one — and that answer is very likely to change. Behind an interface, swapping between them costs nothing. **3. The price is a strategy too.** The requirements said so directly. Notice that pricing only needs *duration and vehicle type*, and returns `Money` — it never touches the spot or the ticket directly, which is exactly what keeps it trivially easy to test on its own. There's a fourth decision here that's really a warning: **don't let `ParkingLot` do everything itself.** The single most common way this design goes wrong is a god class that finds spots, prices tickets, takes payments, and tracks availability, all in one place. `ParkingLot` should coordinate and hand work off — allocation to the strategy, fees to the strategy, and spot state to the spot itself. > **Remember:** a god class is the most common way this exact problem goes wrong. `ParkingLot` coordinates; it should never compute anything itself. ```knowledge-check { "questions": [ { "id": "ip45-lld-09-decisions-q1", "type": "mcq", "prompt": "Why compare spot and vehicle by a numeric rank instead of requiring `spot.type == vehicle.type` exactly?", "options": [ {"id":"a","text":"Comparing integers is faster than comparing enums"}, {"id":"b","text":"It captures the real rule — a bigger spot can always hold a smaller vehicle — in one place, which keeps utilisation higher, and new spot types just slot into the ordering without the allocator needing any changes"}, {"id":"c","text":"Enums can't be compared for equality"}, {"id":"d","text":"It lets a vehicle occupy two spots at once"} ], "correct": "b", "explanation": "Requiring an exact match leaves large spots sitting empty while small vehicles get turned away. The rank comparison expresses the real domain rule once, and the allocation strategy only ever needs to ask `can_fit`." } ] } ``` ## Step 4 — The implementation This is complete and runnable, and it's roughly what you should be able to produce on a whiteboard in about 20 minutes: ```python from abc import ABC, abstractmethod from dataclasses import dataclass from enum import Enum import itertools import threading class VehicleType(Enum): MOTORCYCLE = 1 CAR = 2 TRUCK = 3 class SpotType(Enum): SMALL = 1 MEDIUM = 2 LARGE = 3 @dataclass(frozen=True) class Vehicle: plate: str kind: VehicleType @dataclass(frozen=True) class Money: paise: int def __str__(self) -> str: return f"Rs {self.paise / 100:.2f}" class ParkingSpot: def __init__(self, spot_id: str, kind: SpotType): self.spot_id, self.kind = spot_id, kind self.vehicle: Vehicle | None = None @property def is_free(self) -> bool: return self.vehicle is None def can_fit(self, vehicle: Vehicle) -> bool: return self.is_free and self.kind.value >= vehicle.kind.value def occupy(self, vehicle: Vehicle) -> None: if not self.can_fit(vehicle): raise ValueError(f"{self.spot_id} cannot take {vehicle.plate}") self.vehicle = vehicle def release(self) -> None: self.vehicle = None class ParkingFloor: def __init__(self, number: int, spots: list[ParkingSpot]): self.number, self.spots = number, spots # composition def free_spots(self, vehicle: Vehicle) -> list[ParkingSpot]: return [s for s in self.spots if s.can_fit(vehicle)] @dataclass class Ticket: ticket_id: str vehicle: Vehicle spot: ParkingSpot entry_minute: int exit_minute: int | None = None # ---- extension point 1: where to put the vehicle ---------------------------- class SpotAllocationStrategy(ABC): @abstractmethod def allocate(self, floors: list[ParkingFloor], vehicle: Vehicle) -> ParkingSpot | None: ... class FirstFit(SpotAllocationStrategy): def allocate(self, floors, vehicle): for floor in floors: free = floor.free_spots(vehicle) if free: return free[0] return None class BestFit(SpotAllocationStrategy): """The smallest spot that still fits — keeps large spots free for large vehicles.""" def allocate(self, floors, vehicle): candidates = [s for f in floors for s in f.free_spots(vehicle)] return min(candidates, key=lambda s: s.kind.value, default=None) # ---- extension point 2: what to charge -------------------------------------- class PricingStrategy(ABC): @abstractmethod def price(self, minutes: int, kind: VehicleType) -> Money: ... class PerHourPricing(PricingStrategy): RATES = {VehicleType.MOTORCYCLE: 2_000, VehicleType.CAR: 4_000, VehicleType.TRUCK: 8_000} def price(self, minutes, kind): hours = max(1, -(-minutes // 60)) # round part-hours up, minimum 1 return Money(hours * self.RATES[kind]) class ProgressivePricing(PricingStrategy): """Cheap for the first hour, pricier each hour after — discourages long stays.""" def price(self, minutes, kind): hours, total, rate = max(1, -(-minutes // 60)), 0, 2_000 for _ in range(hours): total += rate rate += 1_000 return Money(total) class ParkingLot: """A facade: coordinates everything, hands every decision off to a collaborator.""" def __init__(self, floors: list[ParkingFloor], allocator: SpotAllocationStrategy, pricing: PricingStrategy): self._floors, self._allocator, self._pricing = floors, allocator, pricing self._tickets: dict[str, Ticket] = {} self._ids = itertools.count(1) self._lock = threading.Lock() # guards allocation + the ticket book def park(self, vehicle: Vehicle, now_minute: int) -> Ticket: with self._lock: # find-and-occupy has to be one atomic step spot = self._allocator.allocate(self._floors, vehicle) if spot is None: raise RuntimeError(f"lot full for {vehicle.kind.name}") spot.occupy(vehicle) ticket = Ticket(f"T{next(self._ids)}", vehicle, spot, now_minute) self._tickets[ticket.ticket_id] = ticket return ticket def unpark(self, ticket_id: str, now_minute: int) -> Money: with self._lock: ticket = self._tickets.get(ticket_id) if ticket is None: raise ValueError("unknown ticket") if ticket.exit_minute is not None: raise ValueError("ticket already closed") # stops charging someone twice ticket.exit_minute = now_minute ticket.spot.release() return self._pricing.price(now_minute - ticket.entry_minute, ticket.vehicle.kind) def availability(self) -> dict[SpotType, int]: with self._lock: counts = {t: 0 for t in SpotType} for floor in self._floors: for spot in floor.spots: if spot.is_free: counts[spot.kind] += 1 return counts def build_lot(allocator=None, pricing=None) -> ParkingLot: floors = [ ParkingFloor(1, [ParkingSpot("1-S1", SpotType.SMALL), ParkingSpot("1-M1", SpotType.MEDIUM), ParkingSpot("1-L1", SpotType.LARGE)]), ParkingFloor(2, [ParkingSpot("2-M1", SpotType.MEDIUM)]), ] return ParkingLot(floors, allocator or BestFit(), pricing or PerHourPricing()) lot = build_lot() bike = Vehicle("KA-01-1234", VehicleType.MOTORCYCLE) car = Vehicle("KA-05-9999", VehicleType.CAR) truck = Vehicle("KA-09-0001", VehicleType.TRUCK) t_bike = lot.park(bike, now_minute=0) assert t_bike.spot.spot_id == "1-S1" # BestFit gives the bike the small spot t_car = lot.park(car, now_minute=0) assert t_car.spot.kind is SpotType.MEDIUM # ...leaving the large spot free for the truck t_truck = lot.park(truck, now_minute=0) assert t_truck.spot.spot_id == "1-L1" assert lot.unpark(t_bike.ticket_id, now_minute=90) == Money(4_000) # 2 hours at Rs 20 try: lot.unpark(t_bike.ticket_id, now_minute=95) raise AssertionError("double exit allowed") except ValueError: pass progressive = build_lot(pricing=ProgressivePricing()) t = progressive.park(car, now_minute=0) assert progressive.unpark(t.ticket_id, now_minute=180) == Money(2_000 + 3_000 + 4_000) print("availability:", {k.name: v for k, v in lot.availability().items()}) print("bike fee:", Money(4_000), "| progressive 3h car:", Money(9_000)) ``` ```knowledge-check { "questions": [ { "id": "ip45-lld-09-impl-q1", "type": "mcq", "prompt": "Why does `park()` hold the lock across BOTH finding a spot and calling `spot.occupy()`?", "options": [ {"id":"a","text":"To keep ticket ids in sequential order"}, {"id":"b","text":"Find-then-occupy is a check-then-act sequence: without one lock spanning both steps, two threads could get handed the exact same free spot, and the second `occupy` call would either fail or double-book it"}, {"id":"c","text":"Because the pricing strategy isn't thread-safe"}, {"id":"d","text":"To stop the availability count from being read while parking happens"} ], "correct": "b", "explanation": "Individually safe operations don't add up to a safe sequence. The lock has to cover the entire find-and-take step — the exact same reason a seat booking has to lock the check and the write together." } ] } ``` ## Steps 5 and 6 — Concurrency and extensions **The shared, changeable data** is the set of free spots. There are three levels of answer here, and you should give whichever one fits how the interviewer framed the problem: | Setting | What protects it | |---|---| | One process, moderate traffic | One lock around find-and-occupy, exactly as built above | | One process, heavy traffic | A lock per floor, or a lock-free free-list per spot type, so different floors don't wait on each other | | Many servers | The database enforces it: `UPDATE spots SET vehicle_id=$1 WHERE id=$2 AND vehicle_id IS NULL` — zero rows affected means someone else already won | That third row is worth saying out loud even if the problem was framed as purely in-memory: an in-process lock protects nothing the moment there are two entry-panel servers running. **Extensions, and how cleanly the design absorbs each one** — walking through one or two of these out loud is a good way to close: | New requirement | What actually changes | |---|---| | Electric vehicles with charging spots | Add `ELECTRIC` to `SpotType`; a `ChargingSpot` subclass adds `start_charging()`. The allocator is untouched — it only ever asks `can_fit` | | Reserved or accessible spots | A `SpotAllocationStrategy` that filters by eligibility — no changes to any entity | | Weekend or festival pricing | A new `PricingStrategy`; nothing else moves | | Monthly pass holders | A `PricingStrategy` that returns `Money(0)` for pass holders, chosen per ticket | | Several entrances with displays | `EntryPanel` / `ExitPanel` objects watching the lot; the display is an **Observer** of changes in availability | | A lost ticket | A `LostTicketPolicy` — a flat penalty — as another pricing path | | Saving data permanently | `SpotRepository` / `TicketRepository` interfaces; `ParkingLot` depends on them, never on raw SQL | Notice what that table actually shows: five of the seven extensions are **brand-new classes, with zero edits anywhere else**. That's exactly the kind of evidence an interviewer is looking for, and pointing it out explicitly is worth doing. > **Remember:** an in-process lock never survives a second server. The database's conditional write is what actually enforces the rule everywhere. ```knowledge-check { "questions": [ { "id": "ip45-lld-09-extend-q1", "type": "mcq", "prompt": "The interviewer adds: \"now support electric vehicles that need charging spots.\" What should your answer be?", "options": [ {"id":"a","text":"Rewrite the allocator to special-case electric vehicles"}, {"id":"b","text":"Add an ELECTRIC spot type and a ChargingSpot subclass with charging behaviour; the allocation strategy stays untouched because it only ever asks `can_fit`, and an eligibility-filtering strategy handles \"EVs only\" if that's needed"}, {"id":"c","text":"Add an `is_electric` boolean to ParkingSpot and check it in every method"}, {"id":"d","text":"Create a whole separate ElectricParkingLot class"} ], "correct": "b", "explanation": "A well-placed extension point means the new requirement is purely additive. Checking a boolean everywhere is exactly the Open/Closed violation this design exists to avoid, and a parallel lot class just duplicates everything." } ] } ``` ## Quick recap - **This problem is the template for the rest of the section.** Requirements, then entities, then relationships, then interfaces, then concurrency, then extensibility — with pricing and allocation as the two strategies. Every other problem coming up is this same shape with different nouns. - **The two extension points are allocation and pricing.** Interviewers tend to add new requirements right along those two axes, which is exactly why they belong behind interfaces before you're even asked. - **Comparing by rank, not by exact match**, is the domain insight that separates a thoughtful model from a purely mechanical one. - **`ParkingLot` coordinates; it doesn't compute.** The god-class version of this answer is the single most common way this problem goes wrong. - **Say the multi-server sentence out loud.** An in-process lock doesn't survive a second server, and the conditional `UPDATE` is what actually enforces the rule. 75:T5426,If the parking lot was about *allocation*, the elevator is about *scheduling*. The hard part isn't the classes — it's that correct behaviour is really an algorithm: which car answers which request, and in what order. Candidates who jump straight into writing classes, without first pinning down that algorithm, end up with a design that can't answer a simple question like "why did car 2 get sent there?" ## Step 1 — Requirements and the two kinds of request **What the system needs to do:** - A person standing on a floor presses **up** or **down** — this is called an *external* or *hall* request. - A person already inside a car presses a **destination floor** — this is an *internal* or *car* request. - Cars move between floors and open their doors at each stop. - A dispatcher decides which car answers each hall request. - There's an emergency stop, manual door controls, and a maintenance mode. **The one distinction that shapes everything else**: an **external request** carries a floor *and a desired direction*, but no destination. An **internal request** carries a destination, but no direction of its own. If you model every request as "just a floor," you can't express something as basic as "this car is already heading up, so it shouldn't grab a down request from floor 8 just yet" — and that idea is really the entire job of elevator scheduling. **The clarifying questions:** | Question | Answer used here | What it changes | |---|---|---| | How many cars? | Several, sharing one bank | A `Dispatcher` becomes its own object | | Which scheduling rule? | Send the nearest suitable car, then sweep inside each car | **Strategy** — this is the extension point | | Can a car skip floors? | Yes — express cars, restricted floors | Each car gets its own `serviceable_floors` | | Is there a capacity limit? | Yes, a weight or headcount limit | A full car refuses new internal requests | | Real hardware, or a simulation? | Simulated with a `step()` tick | Testable, with no real threads needed | **Say the scope**: "I'll model both kinds of requests, how each car moves and holds state, and a pluggable dispatcher, all driven by a discrete `step()` so the behaviour is fully testable. Door timing, the actual motor control, and physical safety interlocks are out of scope." > **Remember:** an external request carries a direction. An internal one carries a destination. Mixing them into one shape loses the exact information the dispatcher needs. ```knowledge-check { "questions": [ { "id": "ip45-lld-10-req-q1", "type": "mcq", "prompt": "Why do external (hall) and internal (car) requests need to be modelled differently?", "options": [ {"id":"a","text":"External requests are simply more urgent"}, {"id":"b","text":"An external request carries a floor plus a desired direction but no destination, while an internal request carries a destination but no direction — that direction is exactly what tells the dispatcher whether a car already heading up should grab this request on the way, or ignore it for now"}, {"id":"c","text":"Internal requests can be cancelled and external ones can't"}, {"id":"d","text":"They're stored in different databases"} ], "correct": "b", "explanation": "Collapsing both into \"just a floor\" makes the whole scheduling rule impossible to express. Direction is the exact field that lets a passing car pick up a hall call instead of turning around for it." } ] } ``` ## Step 2 — Entities and states | Concept | Kind of thing | Notes | |---|---|---| | `Direction` (UP / DOWN / IDLE) | Enum | The car's current direction of travel | | `DoorState` (OPEN / CLOSED) | Enum | | | `ElevatorState` (MOVING / STOPPED / MAINTENANCE) | Enum | Decides which operations are even legal — this is really a small State machine | | `Request` (external) / `Destination` (internal) | Value objects | Never change once created | | `ElevatorCar` | Entity | Owns its own stops, position, direction, and capacity | | `DispatchStrategy` | Interface | Nearest car, least busy, zoned, energy-aware — these will vary | | `ElevatorSystem` | Service / facade | Holds every car, routes hall requests, drives the tick forward | ``` ┌────────────────────┐ │ ElevatorSystem │ │ + request(floor, │◆──1..*── ElevatorCar │ direction) │ - current_floor │ + step() │ - direction: Direction └─────────┬──────────┘ - up_stops / down_stops │ 1 - state: ElevatorState DispatchStrategy + add_stop(floor) △ (interface) + step() │ NearestCar / LeastBusy / Zoned ``` **Why each car keeps two separate ordered sets of stops** (`up_stops`, `down_stops`) instead of one plain queue: a real elevator doesn't serve requests in the order they arrived — it sweeps in one direction, then the other. Keeping "stops I'll hit going up" separate from "stops I'll hit coming down" is what makes that sweep trivial to write and even easier to explain out loud. > **Remember:** an elevator sweeps, it doesn't queue. Two direction-based sets, not one FIFO list. ```knowledge-check { "questions": [ { "id": "ip45-lld-10-entities-q1", "type": "mcq", "prompt": "Why does each car keep separate sorted sets of up-stops and down-stops instead of one plain FIFO queue of requests?", "options": [ {"id":"a","text":"To use less memory"}, {"id":"b","text":"An elevator sweeps rather than serving requests in the order they arrived — the two sets directly express \"floors to stop at going up\" versus \"going down\", so the next stop is just a quick lookup in the current direction"}, {"id":"c","text":"FIFO queues can't store integers"}, {"id":"d","text":"To allow requests to be cancelled"} ], "correct": "b", "explanation": "A plain FIFO order would make an elevator bounce between distant floors pointlessly. The two directional sets encode the sweeping behaviour real elevators use, and turn \"where do I go next?\" into a one-line lookup." } ] } ``` ## Step 3 — The scheduling algorithm This is the real heart of the problem, and there are three named answers worth having ready: | Algorithm | The rule | What it does | |---|---|---| | **FCFS** | Serve requests in the order they arrived | Simple, and genuinely terrible — the car bounces back and forth | | **SCAN** (the "elevator algorithm") | Keep going one direction, stopping at everything along the way, then reverse at the very last floor | What real elevators actually do; wait times stay bounded | | **LOOK** | Like SCAN, but reverse at the last *requested* floor, not the physical top or bottom | SCAN without the wasted travel — this is the practical choice | Inside one car: **LOOK**. Across several cars: a **dispatch strategy** that scores every car against a given hall call. Here's the scoring rule worth stating: ``` For each car: if car is IDLE → cost = |car.floor - request.floor| if car moving TOWARD the request AND same direction → cost = |car.floor - request.floor| otherwise (moving away, or the opposite direction) → cost = |distance| + a large penalty Pick the lowest cost; break ties by fewest pending stops. ``` That single rule captures exactly the behaviour people expect from a real elevator bank: a car already heading your way, passing your floor, picks you up along the way. A car heading the other direction doesn't turn around just for you. **Trade-offs worth mentioning out loud**: optimising purely for *average* wait time can leave one floor at the far end of the building waiting forever, so real systems add a small penalty that grows with how long a request has waited, so it eventually wins regardless of distance. Zoning — assigning cars to specific floor ranges — cuts down travel in tall buildings, at the cost of flexibility whenever there's an unusual rush. > **Remember:** a car already moving toward a request in the same direction costs nothing extra to serve. That's the cheapest case, and it should almost always win. ```knowledge-check { "questions": [ { "id": "ip45-lld-10-algo-q1", "type": "mcq", "prompt": "Car A is at floor 3 moving UP. Car B is idle at floor 8. A hall call arrives at floor 5, wanting to go UP. Which car should be dispatched, and why?", "options": [ {"id":"a","text":"Car B — it's idle, so it's free to respond right away"}, {"id":"b","text":"Car A — it's already heading toward floor 5 in the requested direction, so it serves the call along the way for free, while car B would have to travel all the way down against its current position"}, {"id":"c","text":"Whichever car has served fewer requests so far today"}, {"id":"d","text":"Both, and whichever arrives first wins"} ], "correct": "b", "explanation": "\"Already moving toward the request, same direction\" is the cheapest possible case — the stop is essentially free. Sending the idle car instead adds travel that the passing car would have done anyway, which is exactly why an en-route car should outscore an idle one." } ] } ``` ## Step 4 — The implementation ```python from abc import ABC, abstractmethod from dataclasses import dataclass from enum import Enum class Direction(Enum): UP = 1 DOWN = -1 IDLE = 0 class ElevatorState(Enum): STOPPED = "stopped" MOVING = "moving" MAINTENANCE = "maintenance" @dataclass(frozen=True) class HallRequest: # external: a floor plus the desired direction floor: int direction: Direction class ElevatorCar: def __init__(self, car_id: int, floor: int = 0, capacity: int = 8): self.car_id, self.current_floor, self.capacity = car_id, floor, capacity self.direction = Direction.IDLE self.state = ElevatorState.STOPPED self.occupants = 0 self.up_stops: set[int] = set() # floors to serve while going up self.down_stops: set[int] = set() # floors to serve while going down self.log: list[str] = [] # ---- requests ------------------------------------------------------- def add_stop(self, floor: int) -> None: if self.state is ElevatorState.MAINTENANCE: raise RuntimeError(f"car {self.car_id} is out of service") if floor == self.current_floor and self.direction is Direction.IDLE: return # already here, doors will just open (self.up_stops if floor > self.current_floor else self.down_stops).add(floor) if self.direction is Direction.IDLE: self.direction = Direction.UP if floor > self.current_floor else Direction.DOWN self.state = ElevatorState.MOVING @property def pending(self) -> int: return len(self.up_stops) + len(self.down_stops) def is_full(self) -> bool: return self.occupants >= self.capacity # ---- movement (LOOK) ------------------------------------------------ def _next_stop(self) -> int | None: if self.direction is Direction.UP: ahead = [f for f in self.up_stops if f > self.current_floor] if ahead: return min(ahead) return max(self.down_stops) if self.down_stops else None # time to reverse if self.direction is Direction.DOWN: below = [f for f in self.down_stops if f < self.current_floor] if below: return max(below) return min(self.up_stops) if self.up_stops else None # time to reverse return None def step(self) -> None: """Move one floor, or stop and open the doors if this floor is a stop.""" if self.state is ElevatorState.MAINTENANCE: return target = self._next_stop() if target is None: self.direction, self.state = Direction.IDLE, ElevatorState.STOPPED return if target == self.current_floor: self.up_stops.discard(target) self.down_stops.discard(target) self.log.append(f"car{self.car_id}: doors open at {target}") if self.pending == 0: self.direction, self.state = Direction.IDLE, ElevatorState.STOPPED return step = 1 if target > self.current_floor else -1 self.current_floor += step self.direction = Direction.UP if step == 1 else Direction.DOWN self.state = ElevatorState.MOVING if self.current_floor in self.up_stops or self.current_floor in self.down_stops: self.up_stops.discard(self.current_floor) self.down_stops.discard(self.current_floor) self.log.append(f"car{self.car_id}: doors open at {self.current_floor}") class DispatchStrategy(ABC): @abstractmethod def choose(self, cars: list[ElevatorCar], req: HallRequest) -> ElevatorCar | None: ... class NearestSuitableCar(DispatchStrategy): PENALTY = 1_000 def _cost(self, car: ElevatorCar, req: HallRequest) -> int: distance = abs(car.current_floor - req.floor) if car.direction is Direction.IDLE: return distance moving_toward = ( (car.direction is Direction.UP and req.floor >= car.current_floor) or (car.direction is Direction.DOWN and req.floor <= car.current_floor) ) if moving_toward and car.direction is req.direction: return distance # free: served along the way return distance + self.PENALTY # would need to turn around def choose(self, cars, req): eligible = [c for c in cars if c.state is not ElevatorState.MAINTENANCE and not c.is_full()] if not eligible: return None return min(eligible, key=lambda c: (self._cost(c, req), c.pending, c.car_id)) class ElevatorSystem: def __init__(self, cars: list[ElevatorCar], strategy: DispatchStrategy): self.cars, self.strategy = cars, strategy def hall_request(self, floor: int, direction: Direction) -> ElevatorCar: car = self.strategy.choose(self.cars, HallRequest(floor, direction)) if car is None: raise RuntimeError("no car available") car.add_stop(floor) return car def step(self, ticks: int = 1) -> None: for _ in range(ticks): for car in self.cars: car.step() # --- an en-route car beats an idle one --------------------------------------- a = ElevatorCar(1, floor=3); a.add_stop(10) # car 1: at floor 3, heading UP to 10 b = ElevatorCar(2, floor=8) # car 2: idle at floor 8 system = ElevatorSystem([a, b], NearestSuitableCar()) chosen = system.hall_request(5, Direction.UP) assert chosen is a # picked up on the way, not the idle car # --- the car sweeps: floor 5, then floor 10, never 10 then back -------------- system.step(12) assert "car1: doors open at 5" in a.log assert a.log.index("car1: doors open at 5") < a.log.index("car1: doors open at 10") # --- a car in maintenance is never dispatched --------------------------------- a.state = ElevatorState.MAINTENANCE assert system.hall_request(2, Direction.DOWN) is b print(a.log) print("car2 sent to floor 2:", sorted(b.down_stops)) ``` ```knowledge-check { "questions": [ { "id": "ip45-lld-10-impl-q1", "type": "mcq", "prompt": "In `_next_stop`, a car moving UP with no more stops above it returns `max(down_stops)`. What behaviour is that?", "options": [ {"id":"a","text":"FCFS — serving whichever request arrived first"}, {"id":"b","text":"The LOOK reversal: having run out of stops in the current direction, the car turns around at the highest pending down-stop instead of continuing all the way to the top of the building"}, {"id":"c","text":"An emergency stop"}, {"id":"d","text":"Balancing load between different cars"} ], "correct": "b", "explanation": "Plain SCAN would travel all the way to the physical top floor before turning around. LOOK reverses right at the furthest actual request instead. Returning the highest pending down-stop is exactly that turnaround point." } ] } ``` ## Steps 5 and 6 — Concurrency, edge cases, and extensions **The shared, changeable data**: each car's set of stops, and the dispatcher's view of where every car currently is. Two people pressing buttons at the same instant can both try to change one car's stops at once. | Setting | What protects it | |---|---| | One controller process | A lock per car around `add_stop`/`step` — each car's stops are its own, so no single global lock is needed | | Real hardware | Each car acts as its own independent actor or thread, with a **command queue** — the dispatcher just posts messages, and the car fully owns its own state. This removes shared state entirely, rather than just protecting it | | Dispatcher decisions | Work from a consistent snapshot; a slightly stale position only costs a little efficiency, never correctness | The actor-with-a-queue answer is the stronger one here: **get rid of the sharing, don't just guard it.** **Edge cases worth raising yourself:** | Case | How it's handled | |---|---| | Car is full | Skip it in dispatch (`is_full`), and it won't accept a new hall call either — the passenger presses the button again | | Request for the floor the car is already on | Just open the doors, no new stop needed | | Every car is in maintenance | Dispatch returns nothing; the system should show "no service" instead of silently doing nothing | | Emergency stop | A state transition that clears all pending stops and refuses new ones — a real state change, not a boolean flag | | Power failure or reboot | Cars return to the nearest floor and open their doors | | A far floor keeps getting skipped | Add a term to the cost function that grows with wait time, so waiting eventually beats distance | | Two cars arrive for one call | Cancel the duplicate stop the moment either car opens its doors for that hall request | **Extensions, and how the design absorbs each one:** - **Express elevators, or restricted floors** — a `serviceable_floors` set per car, checked inside `choose`. No new classes needed. - **Zoning** (low-rise and high-rise banks) — a `ZonedDispatch` strategy. One new class. - **Peak-hour behaviour** (morning rush: park idle cars near the lobby) — another strategy, plus a rule for where idle cars wait. - **Energy-aware routing** — a strategy that weights both travel distance and how often doors open and close. - **Displays showing car position** — **Observers** watching each car's floor change. Every single one of those is a new strategy or a new observer — which is exactly the point to make when you wrap up: *the scheduling rule was the thing most likely to change, so it went behind an interface from the start.* > **Remember:** the best concurrency answer here removes the shared state entirely — give each car its own actor and a command queue, instead of guarding a lock. ```knowledge-check { "questions": [ { "id": "ip45-lld-10-concurrency-q1", "type": "mcq", "prompt": "What's the cleanest concurrency model for a real multi-car elevator controller?", "options": [ {"id":"a","text":"One single global lock around the entire elevator system"}, {"id":"b","text":"Each car acts as an independent actor owning its own state, receiving commands through a queue — the dispatcher posts messages instead of directly mutating a car's state, so there's no shared, changeable data left to protect at all"}, {"id":"c","text":"Optimistic locking with version numbers on each car"}, {"id":"d","text":"No synchronisation at all, since each car moves on its own"} ], "correct": "b", "explanation": "The strongest concurrency answer removes the sharing rather than just guarding it. A per-car command queue naturally serialises every change to that car's state, while different cars stay fully independent of each other." } ] } ``` ## Quick recap - **Pin down the algorithm before you write a single class.** The elevator is a scheduling problem, and a design that can't explain *why* a specific car got chosen has missed the actual question. - **There are two kinds of request, not one.** External requests carry a floor plus a direction; internal ones carry a destination — and that direction field is exactly what makes serving a request along the way possible. - **LOOK inside one car, cost-based scoring across cars**, and say the "already moving toward it in the same direction is free" rule out loud. - **Two direction-based sets of stops** make the sweeping behaviour trivial to write, and much easier to defend than a single plain queue. - **Prefer actors with command queues** over locks whenever every piece of state has a natural, single owner — it's the concurrency answer that removes the problem instead of just guarding against it. 76:T57b4,This is the *concurrency* problem of the section. The class model itself is simple — city, cinema, screen, show, seat, booking — and every interviewer moves within about ten minutes to the one question that actually matters: *two people click the same seat at the exact same instant. What happens?* Get that right, and everything else is just bookkeeping. ## Step 1 — Requirements and the booking lifecycle **What the system needs to do:** - Search for shows by city, movie, and date. - Show a show's seat map, with each seat's current availability. - Let a user pick one or more seats and **hold** them while they pay. - Confirm the booking once payment succeeds, or release the hold if it fails or times out. - Cancel a booking, following a refund policy. **The question that shapes the entire design**: *how long can a user hold a seat before actually paying for it?* The answer — "a few minutes" — immediately rules out holding a database lock that whole time, and points straight to the **reservation-with-a-TTL** pattern instead. Say this early. It's really the insight this whole problem is built around. **The other clarifying questions:** | Question | Answer used here | What it changes | |---|---|---| | Does pricing vary? | Yes — by seat class and show time | **Strategy** | | Can a user book multiple seats at once? | Yes — all or nothing | The hold covers a whole *set* of seats | | What if payment fails, or the user just disappears? | The hold expires on its own | An expiry timestamp, not a boolean flag | | Multiple servers? | Yes | The invariant has to live in the database | | Is overbooking ever allowed? | Never | A hard constraint, not a best-effort guess | **The lifecycle is a state machine**, and it's worth thirty seconds to draw it: ``` AVAILABLE ──hold()──▶ HELD ──confirm()──▶ BOOKED ──cancel()──▶ AVAILABLE ▲ │ ▲ └──── expire() ◀────┘ (TTL elapsed, or payment failed) ──────┘ ``` Two things about that diagram are worth points: **HELD is a genuine state, not a boolean**, and **leaving HELD can happen without anyone calling anything at all** — the expiry is driven purely by time, which is exactly why the hold carries a timestamp rather than a flag. > **Remember:** a seat hold needs an expiry timestamp, not a flag — a crashed browser tab has to release the seat automatically, with nobody having to clean up after it. ```knowledge-check { "questions": [ { "id": "ip45-lld-11-req-q1", "type": "mcq", "prompt": "Why does a seat hold need an expiry timestamp rather than a plain `is_locked` boolean?", "options": [ {"id":"a","text":"Timestamps are easier to index"}, {"id":"b","text":"A boolean set by a client that then crashes or just abandons checkout locks the seat forever; an expiry means the hold releases itself, with no cleanup step required for correctness"}, {"id":"c","text":"Booleans can't be stored in a database"}, {"id":"d","text":"So that multiple users could hold the same seat at once"} ], "correct": "b", "explanation": "This is the exact same reasoning behind a TTL on a distributed lock: you can never fully trust the holder to release it themselves. An expiry makes abandonment self-healing, and a sweeper job becomes a nice-to-have instead of a correctness requirement." } ] } ``` ## Step 2 — Entities and relationships | Concept | Kind of thing | Notes | |---|---|---| | `City`, `Cinema`, `Screen` | Entities | `Cinema ◆── Screen` is composition | | `Movie` | Entity | Exists on its own, independent of any specific show | | `Show` | Entity | A movie playing on one screen at one time — this is the unit you actually book | | `Seat` | Entity | Belongs to a screen: a physical row, number, and class | | `ShowSeat` | Entity | **The one people forget**: whether a seat is available *for one specific show* | | `SeatStatus` | Enum | AVAILABLE / HELD / BOOKED | | `Booking` | Entity | A user's set of show-seats, with its own lifecycle | | `PricingStrategy` | Interface | Varies by seat class, show time, day | | `PaymentProcessor` | Interface | Left out of scope to actually implement | ``` City ◇── Cinema ◆── Screen ◆── Seat (the physical layout) │ Show ──> Movie (one screening) ◆ │ 1..* ShowSeat ──> Seat (availability, per show) │ - status: SeatStatus │ - held_until: int|None │ - booking_id: str|None ▲ Booking ◇── 1..* ShowSeat ``` **Splitting `Seat` from `ShowSeat` is the real modelling insight in this problem.** A physical seat exists exactly once and never changes. Its *availability* is a property of the pair (seat, show), not of the seat by itself. If you put `is_booked` directly on `Seat`, you can't express the same seat being booked for the 9pm show while still free for the 6pm one — and being able to say that sentence out loud is worth more here than any pattern name. > **Remember:** availability belongs to the (seat, show) pair — never to the seat alone. ```knowledge-check { "questions": [ { "id": "ip45-lld-11-entities-q1", "type": "mcq", "prompt": "Why separate `Seat` from `ShowSeat` instead of just putting `is_booked` directly on `Seat`?", "options": [ {"id":"a","text":"To cut down the number of database rows"}, {"id":"b","text":"Availability belongs to the (seat, show) pair, not to the physical seat — seat A5 can be booked for the 9pm show and free for the 6pm one, which a single flag on Seat could never express"}, {"id":"c","text":"Because Seat has to be unchangeable for thread safety"}, {"id":"d","text":"Because shows and seats live in different services"} ], "correct": "b", "explanation": "Physical layout and per-screening availability have completely different lifecycles and cardinality. The join entity — ShowSeat — is also exactly where the unique constraint that stops double-booking has to live." } ] } ``` ## Step 3 — The concurrency design This is what the whole interview is actually about. Build the answer up in three layers. **Layer 1 — the hold is one atomic conditional write.** Not "check availability, then separately mark it held." One single statement that both checks and takes at the same time: ```sql UPDATE show_seats SET status = 'HELD', held_by = $1, held_until = now() + interval '5 minutes' WHERE show_id = $2 AND seat_id = ANY($3) AND (status = 'AVAILABLE' OR (status = 'HELD' AND held_until < now())); -- an expired hold can be reclaimed -- affected rows < requested count ⇒ someone else already won ⇒ roll back, tell the user ``` That `AND` clause *is* the entire concurrency mechanism. The database checks the condition and performs the write as one atomic step, so two concurrent attempts genuinely cannot both succeed. Counting the affected rows is how you find out whether you actually won. **Layer 2 — a multi-seat booking is all-or-nothing.** Wrap the update in a transaction, and require the number of affected rows to exactly equal the number of seats requested, or roll everything back. Half a booking is worse than none at all. Two seats grabbed in a different order by two different users is exactly the deadlock case from the concurrency lesson — **sort the seat ids before locking**, so every transaction acquires locks in the same fixed order. **Layer 3 — a unique constraint as the final backstop.** Even with flawless application code, add this: ```sql CREATE UNIQUE INDEX one_booking_per_seat_per_show ON show_seats (show_id, seat_id) WHERE status = 'BOOKED'; ``` Application code can always have bugs. A database constraint cannot be bypassed. Bringing this up yourself is exactly the sign of someone who's actually shipped a booking system before. **Why not just use a Redis lock?** You can, but only as an *optimisation* to cut down contention hitting the database — it can never be the actual guarantee. A garbage-collection pause or a slow network can outlast any TTL, and the lock holder has no way to know it was evicted early. The sentence to say: *"a Redis lock reduces contention; the unique constraint is what actually makes it correct."* **Expiry**: a background sweeper flips expired holds back to AVAILABLE, mostly to keep the seat map tidy — but the `held_until < now()` clause already built into the hold query means correctness never actually depends on that sweeper running at all. > **Remember:** only the database can arbitrate between two different servers. A Redis lock helps with load; the unique constraint is what makes it actually correct. ```knowledge-check { "questions": [ { "id": "ip45-lld-11-concurrency-q1", "type": "mcq", "prompt": "Two users on two different servers both submit a hold on seat A5 at the exact same instant. What actually guarantees only one of them succeeds?", "options": [ {"id":"a","text":"An in-process lock inside the booking service"}, {"id":"b","text":"A conditional UPDATE — `SET status='HELD' WHERE seat_id=$1 AND status='AVAILABLE'` — checked and applied atomically by the database, with the affected-row count telling each server whether it won, backed by a unique index on booked seats"}, {"id":"c","text":"A Redis lock with a 5-minute TTL"}, {"id":"d","text":"Checking availability right before writing"} ], "correct": "b", "explanation": "Only the piece of the system every server actually shares — the database — can arbitrate between them. A Redis lock is a contention optimisation with a TTL that a pause can outlast; check-then-write on its own is the race itself; an in-process lock is simply invisible to the other server." } ] } ``` ## Step 4 — The implementation An in-memory model that reproduces the exact same behaviour, with the conditional-write logic made explicit so it maps directly onto the SQL above: ```python from abc import ABC, abstractmethod from dataclasses import dataclass, field from enum import Enum import itertools import threading class SeatClass(Enum): REGULAR = 1 PREMIUM = 2 RECLINER = 3 class SeatStatus(Enum): AVAILABLE = "available" HELD = "held" BOOKED = "booked" class BookingStatus(Enum): PENDING = "pending" CONFIRMED = "confirmed" CANCELLED = "cancelled" EXPIRED = "expired" @dataclass(frozen=True) class Seat: # physical, never changes seat_id: str row: str number: int seat_class: SeatClass @dataclass class ShowSeat: # availability, specific to one show seat: Seat status: SeatStatus = SeatStatus.AVAILABLE held_until: int | None = None booking_id: str | None = None def is_takeable(self, now: int) -> bool: """AVAILABLE, or a HELD seat whose hold has expired — mirrors the SQL WHERE clause.""" if self.status is SeatStatus.AVAILABLE: return True return self.status is SeatStatus.HELD and self.held_until is not None \ and self.held_until <= now class PricingStrategy(ABC): @abstractmethod def price_paise(self, seat: Seat, show: "Show") -> int: ... class ClassAndTimePricing(PricingStrategy): BASE = {SeatClass.REGULAR: 20_000, SeatClass.PREMIUM: 35_000, SeatClass.RECLINER: 60_000} def price_paise(self, seat, show): price = self.BASE[seat.seat_class] if show.start_hour >= 18: # an evening surcharge price = int(price * 1.2) return price @dataclass class Show: show_id: str movie: str screen_id: str start_hour: int seats: dict[str, ShowSeat] = field(default_factory=dict) @dataclass class Booking: booking_id: str user: str show_id: str seat_ids: list[str] total_paise: int status: BookingStatus = BookingStatus.PENDING class BookingService: HOLD_SECONDS = 300 def __init__(self, pricing: PricingStrategy): self._pricing = pricing self._shows: dict[str, Show] = {} self._bookings: dict[str, Booking] = {} self._ids = itertools.count(1) self._lock = threading.Lock() # stands in for what the database's atomicity gives us def add_show(self, show: Show) -> None: self._shows[show.show_id] = show def available_seats(self, show_id: str, now: int) -> list[str]: show = self._shows[show_id] return sorted(sid for sid, ss in show.seats.items() if ss.is_takeable(now)) def hold(self, show_id: str, seat_ids: list[str], user: str, now: int) -> Booking: show = self._shows[show_id] ordered = sorted(seat_ids) # a fixed order avoids deadlock on multi-seat holds with self._lock: targets = [show.seats[sid] for sid in ordered] if not all(ss.is_takeable(now) for ss in targets): taken = [ss.seat.seat_id for ss in targets if not ss.is_takeable(now)] raise RuntimeError(f"seats no longer available: {taken}") # all or nothing booking = Booking( booking_id=f"B{next(self._ids)}", user=user, show_id=show_id, seat_ids=ordered, total_paise=sum(self._pricing.price_paise(ss.seat, show) for ss in targets), ) for ss in targets: # commit the hold ss.status = SeatStatus.HELD ss.held_until = now + self.HOLD_SECONDS ss.booking_id = booking.booking_id self._bookings[booking.booking_id] = booking return booking def confirm(self, booking_id: str, now: int) -> Booking: with self._lock: booking = self._bookings[booking_id] if booking.status is not BookingStatus.PENDING: raise ValueError(f"booking is {booking.status.value}") show = self._shows[booking.show_id] for sid in booking.seat_ids: ss = show.seats[sid] if ss.booking_id != booking_id or (ss.held_until or 0) <= now: booking.status = BookingStatus.EXPIRED # the hold lapsed before payment raise RuntimeError("hold expired; seats released") for sid in booking.seat_ids: # payment succeeded — make it permanent ss = show.seats[sid] ss.status, ss.held_until = SeatStatus.BOOKED, None booking.status = BookingStatus.CONFIRMED return booking def cancel(self, booking_id: str) -> None: with self._lock: booking = self._bookings[booking_id] show = self._shows[booking.show_id] for sid in booking.seat_ids: ss = show.seats[sid] ss.status, ss.held_until, ss.booking_id = SeatStatus.AVAILABLE, None, None booking.status = BookingStatus.CANCELLED def build_show() -> tuple[BookingService, Show]: seats = {f"A{i}": ShowSeat(Seat(f"A{i}", "A", i, SeatClass.PREMIUM)) for i in range(1, 5)} show = Show("S1", "Dune", "SCR1", start_hour=19, seats=seats) svc = BookingService(ClassAndTimePricing()) svc.add_show(show) return svc, show svc, show = build_show() # --- the happy path: hold, then confirm -------------------------------------- b1 = svc.hold("S1", ["A2", "A1"], user="asha", now=0) assert b1.seat_ids == ["A1", "A2"] # sorted, so ordering is always consistent assert b1.total_paise == 2 * int(35_000 * 1.2) # premium seats, evening surcharge assert svc.available_seats("S1", now=0) == ["A3", "A4"] # --- a second user can't take a seat that's already held --------------------- try: svc.hold("S1", ["A1"], user="ravi", now=10) raise AssertionError("double hold allowed") except RuntimeError as e: print("rejected:", e) svc.confirm(b1.booking_id, now=60) assert show.seats["A1"].status is SeatStatus.BOOKED # --- all-or-nothing: A3 is free but A1 is booked, so the whole request fails -- try: svc.hold("S1", ["A3", "A1"], user="ravi", now=70) raise AssertionError("partial booking allowed") except RuntimeError: pass assert show.seats["A3"].status is SeatStatus.AVAILABLE # A3 was NOT taken either # --- an abandoned hold expires, and the seat becomes takeable again ---------- b2 = svc.hold("S1", ["A3"], user="meera", now=100) assert svc.available_seats("S1", now=200) == ["A4"] # still held assert svc.available_seats("S1", now=100 + 301) == ["A3", "A4"] # the hold lapsed try: svc.confirm(b2.booking_id, now=100 + 301) raise AssertionError("expired hold confirmed") except RuntimeError as e: print("expiry enforced:", e) print("final statuses:", {sid: ss.status.value for sid, ss in show.seats.items()}) ``` ```knowledge-check { "questions": [ { "id": "ip45-lld-11-impl-q1", "type": "mcq", "prompt": "`hold()` sorts the seat ids before taking them. What problem does that actually prevent?", "options": [ {"id":"a","text":"It makes the booking id predictable"}, {"id":"b","text":"Deadlock: with a lock per seat, one user grabbing A1 then A2 while another grabs A2 then A1 forms a circular wait — a fixed global ordering breaks that cycle before it can even start"}, {"id":"c","text":"It stops a seat from being priced twice"}, {"id":"d","text":"It makes the seat map display in order"} ], "correct": "b", "explanation": "This is the exact same bank-transfer deadlock from the concurrency lesson, wearing a different costume. Any time a transaction takes more than one lock, acquiring them in a fixed, consistent order is the standard fix." } ] } ``` ## Steps 5 and 6 — Edge cases and extensions **Edge cases worth raising before anyone asks:** | Case | How it's handled | |---|---| | Payment succeeds, but the hold already expired by then | Never book over someone else's seat. Refund automatically and tell the user. Even better: extend the hold the moment payment starts, and make confirmation idempotent on a payment id | | A user pays twice by double-clicking | An idempotency key on the booking request — the second attempt just returns the first result | | The seat map looks stale in the browser | Show an optimistic update in the UI, but let the server's conditional write make the real decision | | The cinema cancels the show | Bulk-cancel bookings and trigger refunds through an **Observer**, or an event — never a loop inside the show object itself | | A group wants seats next to each other | A `SeatAllocationStrategy` that's aware of adjacency — the exact same extension point the parking lot's allocator used | | Refund amount depends on how early someone cancels | A `CancellationPolicy` strategy that returns the refundable amount | | A hugely popular show, thousands of holds at once | A virtual waiting room plus per-user rate limits; the conditional write is still what guarantees correctness — it just gets rejected more often | **Extensions, and how they fit in:** - **Coupons and offers** → a `DiscountPolicy` combined with pricing (or a decorator layered on top of `PricingStrategy`). - **Food and drink add-ons** → line items on the `Booking`; pricing itself is unchanged. - **Loyalty points** → an observer on `booking.confirmed`. - **Multiplex chains, multiple cities** → new entities added above `Cinema`; the booking core itself doesn't change. - **Rendering the seat map** → a read-only view built from `ShowSeat`, never a second source of truth. The closing line worth having ready: *"The core of this design is a per-show seat table, a hold with an expiry, and one conditional write. Everything else — pricing, discounts, refunds, notifications — hangs off that as either a strategy or an observer."* > **Remember:** never let a lapsed hold win against a correctly-timed one, even when the customer already paid. Refund automatically, and fix the root cause: align the hold window with the payment window. ```knowledge-check { "questions": [ { "id": "ip45-lld-11-edge-q1", "type": "mcq", "prompt": "Payment succeeds, but by then the user's 5-minute hold has already expired and someone else has booked the seat. What's the correct behaviour?", "options": [ {"id":"a","text":"Book it for the first user anyway, since they paid"}, {"id":"b","text":"Never double-book: fail the confirmation, refund automatically, and let the user know — and prevent it happening again by extending the hold the moment payment starts, and making confirmation idempotent on the payment id"}, {"id":"c","text":"Cancel the other user's booking, since the first user paid first"}, {"id":"d","text":"Keep the money and quietly issue a credit note"} ], "correct": "b", "explanation": "Overbooking is a hard constraint, so a lapsed hold has to lose, no matter what. The correct response is an automatic refund plus a clear notification, and the real fix is aligning the hold window with how long payment actually takes, rather than weakening the constraint." } ] } ``` ## Quick recap - **This problem is about concurrency, not classes.** Bring up the seat-contention question yourself, rather than waiting for the interviewer to ask. - **`Seat` vs. `ShowSeat`** is the real modelling insight — availability belongs to the (seat, show) pair. - **A hold with an expiry, not a lock**: a real person takes minutes to pay, and no lock should ever be held that long. The expiry is what makes abandonment heal itself. - **One conditional write is the whole mechanism**, backed up by a unique index. In-process locks and Redis locks are optimisations; the database constraint is the actual guarantee. - **All-or-nothing bookings for multiple seats** need both a transaction and a consistent seat ordering, to avoid deadlock. - **This same skeleton solves every inventory problem you'll ever meet** — flight seats, hotel rooms, event tickets, e-commerce stock, appointment slots. Learn it once, right here. 77:T5435,This is the *money and algorithms* problem of the section. The class model is genuinely small. What interviewers are actually checking is whether you represent money correctly, whether your split rules can be swapped out, and whether you can produce the settlement algorithm — "work out the fewest transactions needed to clear everyone's debts" — the moment they ask. ## Step 1 — Requirements and the money rules **What the system needs to do:** - Add users, and let them form groups. - Add an expense: who paid, how much, who shares it, and how the split is worked out. - Support **equal**, **exact**, and **percentage** splits — and be ready to add more later. - Show each user's balance: who owes whom, and how much. - **Simplify debts**: settle up a whole group in the fewest transactions possible. - Record a settlement payment between two people. **The money rules, stated up front** — say these immediately, because most people skip them entirely: 1. **Never use floating-point numbers for money.** Store whole numbers in the smallest unit — paise, not rupees. In binary floating point, `0.1 + 0.2` doesn't equal `0.3`, and an expense report that's off by one paisa is a real bug report waiting to happen. 2. **A split has to add up exactly to the total.** Splitting ₹100 three ways gives 33.33... rupees each. The standard fix is to hand the leftover remainder to the first few participants, or to the person who paid. Whichever you pick, say it out loud — an unassigned remainder is money that just vanishes. 3. **Balances are worked out on the fly. They're never stored as the actual source of truth.** Keep the list of expenses, unchangeable, and calculate balances from that list whenever you need them. This is the same reasoning behind any accounting ledger, and it means every balance can always be explained, and every calculation can always be redone from scratch. **The clarifying questions:** | Question | Answer used here | What it changes | |---|---|---| | What split types? | Equal, exact, percentage — more coming later | **Strategy** | | Can more than one person pay for one expense? | Yes | `paid_by` is a map, not just a single person | | Multiple currencies? | Out of scope, but worth mentioning | Would need `Money` to carry a currency and a conversion rule | | Do we need a full history? | Yes | Expenses are unchangeable records, never edited after the fact | | Group and non-group expenses? | Both | A group is just a convenience — not required for an expense to exist | > **Remember:** store money as whole paise, never as a float. And every split must be checked to add up exactly to the total — never just assumed. ```knowledge-check { "questions": [ { "id": "ip45-lld-12-money-q1", "type": "mcq", "prompt": "Three friends split ₹100 equally. What does the design need to spell out, and why?", "options": [ {"id":"a","text":"Nothing — 100 divided by 3 is fine with floating-point arithmetic"}, {"id":"b","text":"That amounts are stored as whole paise, and the 1-paisa remainder left over from 10000 divided by 3 is assigned in a clear, repeatable way (say, to the first participants), so the shares always add up to exactly the total"}, {"id":"c","text":"That the total should be rounded up to ₹102 so it divides evenly"}, {"id":"d","text":"That splits always have to be exact amounts, never equal shares"} ], "correct": "b", "explanation": "10000 paise divided by 3 is 3333 with 1 left over. Without a clear rule, that missing paisa either just disappears or gets counted twice, and floating point introduces its own small errors on top. Whole paise plus a clear, repeatable remainder rule is the standard fix." } ] } ``` ## Step 2 — Entities and the split strategies | Concept | Kind of thing | Notes | |---|---|---| | `User` | Entity | id, name | | `Group` | Entity | A named set of users | | `Money` | Value object | Never changes, whole paise | | `Expense` | Entity, **never changes once created** | description, total, `paid_by`, calculated `shares` | | `SplitStrategy` | **Interface** | Equal / exact / percentage / share-units | | `BalanceSheet` | Service | Works out net balances from the expense list | | `SettlementService` | Service | The debt-simplification algorithm | ``` User ◇──── Group ▲ ▲ │ │ └──── Expense ──> SplitStrategy (interface) - total: Money △ - paid_by: {user: paise} │ - shares: {user: paise} Equal / Exact / Percentage │ ▼ BalanceSheet → SettlementService.simplify() ``` **Why `Expense` should never change once created**: editing an expense after the fact would quietly change balances that people already acted on, without any warning. Real accounting systems fix mistakes with a new, offsetting entry — the same idea as a ledger correction. If someone asks for editing support, propose "add a corrected version" rather than mutating the original. **Why `paid_by` is a map, not just one person**: two friends can easily split the bill at the restaurant together. Forcing the payer to be a single person means creating an awkward second expense just to represent that. > **Remember:** an expense once written down should never change. Corrections are new entries, not edits to the old one. ```knowledge-check { "questions": [ { "id": "ip45-lld-12-entities-q1", "type": "mcq", "prompt": "Why calculate balances from the expense list instead of keeping a single changeable `balance` field per user?", "options": [ {"id":"a","text":"Because adding numbers up is faster than reading a field"}, {"id":"b","text":"Unchangeable expenses form a ledger: balances can always be explained and recalculated from scratch, corrections become new entries instead of silent edits, and there's no risk of one update accidentally overwriting another"}, {"id":"c","text":"Because balances change too rarely to bother storing them"}, {"id":"d","text":"Because each user can only ever have one balance"} ], "correct": "b", "explanation": "This is the same reasoning as a double-entry ledger: a calculated balance can always be justified, line by line, and two expenses added at the same time can never quietly overwrite each other's update the way a shared counter could. You can still cache a balance for speed if you need to, but the individual entries stay the actual source of truth." } ] } ``` ## Step 3 — The debt simplification algorithm Here's the question you'll get asked directly: *"n people owe each other various amounts. What's the fewest transactions needed to settle everyone up?"* **Step 1 — reduce it all down to net balances.** All that actually matters, per person, is one single number: total paid, minus total owed. Positive means they should receive money; negative means they should pay. Just this step alone collapses a tangled web of individual debts (A owes B, B owes C, C owes A) into something you can actually settle cleanly. **Step 2 — greedily pair up the biggest creditor with the biggest debtor.** Take whoever is owed the most and whoever owes the most, transfer the smaller of the two amounts between them, and repeat. Every single transaction brings at least one person's balance down to exactly zero, so with *n* people whose balance isn't zero, you'll need at most *n − 1* transactions. ``` Balances: A +60, B −40, C −20 match A(+60) with B(−40) → B pays A 40 → A +20, B 0 match A(+20) with C(−20) → C pays A 20 → all zero 2 transactions for 3 people — the n−1 bound holds ``` **Here's the honest part, and it's the senior half of the answer**: this greedy method is **not guaranteed to be the true minimum**. Finding the actual smallest number of transactions turns out to be an NP-hard problem — it's really about finding every possible group of people whose balances happen to add up to zero, and that search itself is the hard part. Greedy always stays at or under *n − 1* transactions, and it's genuinely what production systems use. Naming this limitation earns you more credit than just presenting greedy as if it were provably optimal. On complexity: sorting or using a heap gives you O(n log n) work per transaction, with at most n − 1 transactions total. > **Remember:** greedy settlement guarantees at most n − 1 transactions. It's not provably the minimum — say that out loud, don't present it as optimal. ```knowledge-check { "questions": [ { "id": "ip45-lld-12-settle-q1", "type": "mcq", "prompt": "How should you correctly describe the greedy \"largest creditor pays largest debtor\" settlement algorithm?", "options": [ {"id":"a","text":"It always produces the provably smallest possible number of transactions"}, {"id":"b","text":"It's guaranteed to need at most n−1 transactions, and it's what production systems actually use, but it isn't provably optimal — finding the true minimum is NP-hard because it means finding every subset of balances that adds up to zero"}, {"id":"c","text":"It requires storing every pairwise debt explicitly"}, {"id":"d","text":"It only works when every balance happens to be equal"} ], "correct": "b", "explanation": "Every greedy step brings at least one person's balance to exactly zero, which bounds it at n−1. Actually proving optimality would mean partitioning the balances into zero-sum groups, and that's the NP-hard part — stating that distinction is the stronger version of this answer." } ] } ``` ## Step 4 — The implementation ```python from abc import ABC, abstractmethod from dataclasses import dataclass from collections import defaultdict import heapq import itertools @dataclass(frozen=True) class Money: paise: int def __str__(self) -> str: return f"Rs {self.paise / 100:.2f}" class SplitStrategy(ABC): """Returns {user: paise}, guaranteed to add up to exactly `total_paise`.""" @abstractmethod def split(self, total_paise: int, participants: list[str], **kwargs) -> dict[str, int]: ... class EqualSplit(SplitStrategy): def split(self, total_paise, participants, **kwargs): n = len(participants) if n == 0: raise ValueError("no participants") base, remainder = divmod(total_paise, n) # A clear, repeatable rule: the first `remainder` people pay 1 extra paisa each. return {u: base + (1 if i < remainder else 0) for i, u in enumerate(participants)} class ExactSplit(SplitStrategy): def split(self, total_paise, participants, *, amounts: dict[str, int], **kwargs): if sum(amounts.values()) != total_paise: raise ValueError(f"exact shares sum to {sum(amounts.values())}, not {total_paise}") if set(amounts) != set(participants): raise ValueError("amounts must cover exactly the participants") return dict(amounts) class PercentageSplit(SplitStrategy): def split(self, total_paise, participants, *, percentages: dict[str, float], **kwargs): if abs(sum(percentages.values()) - 100.0) > 1e-9: raise ValueError("percentages must sum to 100") shares = {u: int(total_paise * percentages[u] / 100) for u in participants} # Rounding down loses a little; give the shortfall to the largest shares, deterministically. shortfall = total_paise - sum(shares.values()) for u in sorted(shares, key=lambda x: (-shares[x], x))[:shortfall]: shares[u] += 1 return shares @dataclass(frozen=True) class Expense: # never changes once created expense_id: str description: str total_paise: int paid_by: tuple[tuple[str, int], ...] # ((user, paise), ...) — supports co-payers shares: tuple[tuple[str, int], ...] # ((user, paise), ...) class ExpenseBook: def __init__(self): self._expenses: list[Expense] = [] self._ids = itertools.count(1) def add(self, description: str, total_paise: int, paid_by: dict[str, int], participants: list[str], strategy: SplitStrategy, **kwargs) -> Expense: if sum(paid_by.values()) != total_paise: raise ValueError("payments must sum to the expense total") shares = strategy.split(total_paise, participants, **kwargs) if sum(shares.values()) != total_paise: # always double-checked, never just assumed raise AssertionError("split does not sum to total") expense = Expense(f"E{next(self._ids)}", description, total_paise, tuple(paid_by.items()), tuple(shares.items())) self._expenses.append(expense) return expense def settle(self, payer: str, payee: str, paise: int) -> Expense: """A settlement is really just an expense the payee owes entirely to the payer.""" return self.add(f"settlement {payer}->{payee}", paise, paid_by={payer: paise}, participants=[payee], strategy=ExactSplit(), amounts={payee: paise}) def balances(self) -> dict[str, int]: """Each user's net position: positive means owed money, negative means owing it.""" net: dict[str, int] = defaultdict(int) for e in self._expenses: for user, paid in e.paid_by: net[user] += paid for user, share in e.shares: net[user] -= share return {u: v for u, v in net.items() if v != 0} def simplify(self) -> list[tuple[str, str, int]]: """Greedy: match the largest creditor with the largest debtor. At most n-1 transfers.""" net = self.balances() # Max-heaps via negated keys; tie-break on name so the output stays predictable. creditors = [(-v, u) for u, v in net.items() if v > 0] debtors = [(v, u) for u, v in net.items() if v < 0] heapq.heapify(creditors) heapq.heapify(debtors) transfers: list[tuple[str, str, int]] = [] while creditors and debtors: credit, creditor = heapq.heappop(creditors) debt, debtor = heapq.heappop(debtors) amount = min(-credit, -debt) transfers.append((debtor, creditor, amount)) # the debtor pays the creditor if -credit - amount > 0: heapq.heappush(creditors, (credit + amount, creditor)) if -debt - amount > 0: heapq.heappush(debtors, (debt + amount, debtor)) return transfers book = ExpenseBook() # Dinner: Asha pays Rs 1000, split equally three ways -> 33333/33333/33334 paise dinner = book.add("dinner", 100_000, {"asha": 100_000}, ["asha", "ravi", "meera"], EqualSplit()) assert sum(dict(dinner.shares).values()) == 100_000 assert sorted(dict(dinner.shares).values()) == [33_333, 33_333, 33_334] # Cab: Ravi and Meera co-pay; exact shares book.add("cab", 60_000, {"ravi": 40_000, "meera": 20_000}, ["asha", "ravi", "meera"], ExactSplit(), amounts={"asha": 30_000, "ravi": 20_000, "meera": 10_000}) # Groceries: a percentage split book.add("groceries", 45_000, {"meera": 45_000}, ["asha", "ravi", "meera"], PercentageSplit(), percentages={"asha": 50, "ravi": 25, "meera": 25}) net = book.balances() assert sum(net.values()) == 0 # the money always balances out to zero transfers = book.simplify() assert len(transfers) <= len(net) - 1 # the n-1 bound assert sum(amount for _, _, amount in transfers) == sum(v for v in net.values() if v > 0) for debtor, creditor, amount in transfers: book.settle(debtor, creditor, amount) assert book.balances() == {} # everything settles down to zero print("net before settling:", {u: str(Money(v)) for u, v in net.items()}) print("transfers:", [(d, c, str(Money(a))) for d, c, a in transfers]) ``` ```knowledge-check { "questions": [ { "id": "ip45-lld-12-impl-q1", "type": "mcq", "prompt": "`EqualSplit` uses `divmod(total, n)` and hands the remainder to the first few participants. Why does that rule need to exist at all, instead of just rounding?", "options": [ {"id":"a","text":"To make the split faster to calculate"}, {"id":"b","text":"Integer division throws away the remainder: without redistributing it, the shares add up to less than the total, and money silently disappears from the ledger — the rule has to be explicit and repeatable so the totals always match"}, {"id":"c","text":"Because participants have to be sorted alphabetically"}, {"id":"d","text":"Because Python doesn't allow floating-point rounding"} ], "correct": "b", "explanation": "10000 divided by 3 gives 3333 each, adding up to 9999 — one paisa short. Any split strategy has to guarantee its shares add up exactly to the total, which is exactly why the implementation checks that invariant right after every single split." } ] } ``` ## Steps 5 and 6 — Concurrency and extensions **The shared, changeable data**: the expense list. Because expenses are **only ever added, never changed**, concurrency here turns out to be unusually easy: | Concern | How it's handled | |---|---| | Two people add expenses at the same moment | Additions are independent of each other; balances are always recalculated from the list. No lock needed beyond the append itself | | Two people settle the same debt at the same moment | Both settlements get recorded; the balance goes negative, which shows up as an overpayment. Fix it with an idempotency key per settlement, or a conditional insert keyed on `(group, payer, payee, amount, client_ref)` | | A slightly stale balance shown on screen | Perfectly acceptable — and worth saying so. This is eventual consistency, with a clear reason behind it | | Caching balances for speed | Treat the cache as something you can always recalculate — recompute it or throw it away on every new expense, and never treat it as the real source of truth | The general lesson worth stating: **unchangeable, append-only data makes concurrency almost free.** That's exactly why every real ledger is designed this way. **Extensions, and how they fit in:** | Requirement | What changes | |---|---| | A new split type (by shares, like "2 shares to Asha, 1 to Ravi") | A new `SplitStrategy` class; nothing else moves | | Multiple currencies | `Money` gains a currency field; a `ConversionPolicy` locks in the exchange rate **at the moment the expense is created**, and stores it — never recalculate old balances using today's rate | | Recurring expenses (rent, subscriptions) | A scheduler that creates new expenses on a timer; the model itself is unchanged | | Attaching receipts to an expense | A field on `Expense`; the actual files live in object storage, not the database | | Simplifying debts per group vs. across everyone | The settlement service just takes a filtered balance map — same algorithm, different input | | Notifying people when someone adds an expense | An **Observer** on `expense.added` | | Editing an expense | Never edit it directly — mark the original as reversed with an offsetting entry, then add the corrected version. History stays intact either way | > **Remember:** if multi-currency ever comes up, the exchange rate gets locked in at the moment of the expense, never recalculated later at today's rate. ```knowledge-check { "questions": [ { "id": "ip45-lld-12-extend-q1", "type": "mcq", "prompt": "The product wants multi-currency support. What's the one decision that matters most here?", "options": [ {"id":"a","text":"Store every amount in US dollars and convert it for display"}, {"id":"b","text":"Record the currency and the exchange rate that applied *at the moment of the expense*, right on the expense itself, so past balances never shift when today's rate moves"}, {"id":"c","text":"Convert every balance to the user's own currency on every single read, using the live rate"}, {"id":"d","text":"Only allow one currency per group"} ], "correct": "b", "explanation": "Recalculating history at today's rate would make a settled debt quietly drift — a balance someone already acted on yesterday would change again today. Locking the rate onto the unchangeable expense record follows exactly the same principle as the append-only ledger: recorded facts stay recorded." } ] } ``` ## Quick recap - **State the money rules first**: whole paise, an explicit rule for leftover remainders, and shares that are checked to add up exactly to the total — never just assumed to. - **Expenses never change; balances are calculated.** This gets you explainability, the ability to redo any calculation from scratch, and concurrency that's nearly free — the same ledger reasoning that shows up in real payment systems. - **The split type is the strategy**, and it's exactly the axis interviewers will ask you to extend. - **The settlement algorithm is net balances, then greedily matching the biggest creditor with the biggest debtor**, bounded at n − 1 transfers — and you should volunteer that greedy isn't provably optimal, since finding the true minimum is NP-hard. - **`paid_by` as a map** handles people co-paying without twisting the model out of shape, and it costs nothing extra to support from the start. 78:T517f,These two problems are really the same problem wearing different clothes: a physical machine with a strict **lifecycle**, where nearly every bug turns out to be an illegal transition — "dispensed without payment," "cash released without a matching debit." They're the textbook use case for the **State pattern**, and each one adds a genuinely interesting algorithm on top — coin change for the vending machine, cash denomination selection for the ATM. ## Step 1 — Requirements and the state machine **Vending machine — what it needs to do:** - Show the products on offer, with their prices and how many are left. - Accept coins or notes one at a time, and show the running total. - Let the customer pick a product: dispense it and hand back the right change, or refuse with a clear reason. - Cancel at any point before dispensing: refund everything that was put in. - Admin actions: restock products, refill change, collect the cash. **Here's the state machine, drawn before writing a single class:** ``` ┌──────── refund / cancel ─────────┐ ▼ │ IDLE ──insert coin──▶ HAS_MONEY ──select──▶ DISPENSING ──▶ IDLE ▲ │ ▲ │ │ └──┘ (more coins) │ └──────────── out of stock / insufficient ───────┘ (stay, with a message) Any state ──admin──▶ OUT_OF_SERVICE ──service done──▶ IDLE ``` Every rule the machine has to follow is either an edge on that diagram, or a deliberately missing one: | Attempted action | Current state | Correct behaviour | |---|---|---| | Select a product | IDLE, with no money in | Refuse: "insert money first" | | Insert a coin | DISPENSING | Refuse: "please wait" | | Cancel | DISPENSING | Refuse: it's already committed | | Select an out-of-stock item | HAS_MONEY | Stay in HAS_MONEY, show a message, keep the money | | Select with not enough credit | HAS_MONEY | Stay, show exactly how much more is needed | | The machine can't make exact change | HAS_MONEY | **Refuse the sale and refund** — never quietly short-change the customer | That last row is the interesting one. "I can sell it to you, but I can't give you your change back" must never mean the machine quietly keeps the difference. The standard fix is to refuse the sale and refund everything, or offer the customer store credit instead. Raising this yourself, unprompted, shows you were thinking about the actual domain, not just the code. > **Remember:** if the machine can't make exact change, it refuses the sale and refunds — it never quietly keeps the difference, and it never dispenses without giving full change. ```knowledge-check { "questions": [ { "id": "ip45-lld-13-states-q1", "type": "mcq", "prompt": "A customer has enough credit and the item is in stock, but the machine can't make exact change. What's the correct behaviour?", "options": [ {"id":"a","text":"Dispense the item and keep the difference"}, {"id":"b","text":"Refuse the sale and refund the money that was inserted (optionally offering store credit instead) — quietly keeping the difference is theft, and dispensing without full change is a guaranteed support ticket"}, {"id":"c","text":"Dispense the item and give back the closest change it can manage"}, {"id":"d","text":"Go straight into OUT_OF_SERVICE"} ], "correct": "b", "explanation": "The change-availability check belongs right alongside the stock and credit checks, before anything commits. This is exactly the kind of domain-level thinking this problem is designed to draw out — and it's also why the coin inventory has to be part of the model at all." } ] } ``` ## Step 2 — The State pattern implementation Each state is its own class implementing the same interface. The machine simply hands off to whatever its current state is, and the states themselves decide what transitions are legal. This is exactly what makes illegal transitions *impossible to write by accident*, instead of merely *checked everywhere*. ```python from abc import ABC, abstractmethod from dataclasses import dataclass @dataclass class Product: code: str name: str price_paise: int stock: int class VendingState(ABC): """Every action has a default: a clear rejection. States only override what's actually legal.""" def insert(self, machine: "VendingMachine", paise: int) -> str: return "cannot insert money right now" def select(self, machine: "VendingMachine", code: str) -> str: return "cannot select right now" def cancel(self, machine: "VendingMachine") -> str: return "nothing to cancel" @abstractmethod def name(self) -> str: ... class IdleState(VendingState): def name(self) -> str: return "IDLE" def insert(self, machine, paise): machine.accept(paise) # held in escrow, not the vault, until the sale commits machine.state = HasMoneyState() return f"credit {machine.credit}" def select(self, machine, code): return "insert money first" class HasMoneyState(VendingState): def name(self) -> str: return "HAS_MONEY" def insert(self, machine, paise): machine.accept(paise) return f"credit {machine.credit}" def select(self, machine, code): product = machine.products.get(code) if product is None: return "unknown product" if product.stock == 0: return "out of stock" # stays in HAS_MONEY, keeps the credit if machine.credit < product.price_paise: return f"need {product.price_paise - machine.credit} more" change_due = machine.credit - product.price_paise coins = machine.plan_change(change_due) if coins is None: # exact change isn't possible refund = machine.refund_all() machine.state = IdleState() return f"cannot make change; refunded {refund}" machine.state = DispensingState() return machine.state.dispense(machine, product, coins, change_due) def cancel(self, machine): refund = machine.refund_all() machine.state = IdleState() return f"refunded {refund}" class DispensingState(VendingState): def name(self) -> str: return "DISPENSING" def dispense(self, machine, product, coins, change_due) -> str: product.stock -= 1 machine.commit_escrow() # the escrowed coins now join the vault for denom, count in coins.items(): # remove exactly the change handed out machine.coin_box[denom] -= count machine.credit = 0 machine.state = IdleState() return f"dispensed {product.name}, change {change_due}" class VendingMachine: def __init__(self, products: list[Product], coins: dict[int, int]): self.products = {p.code: p for p in products} self.coin_box = dict(coins) # the vault: denomination (paise) -> count self.escrow: dict[int, int] = {} # coins inserted but not yet committed to a sale self.credit = 0 self.state: VendingState = IdleState() def accept(self, paise: int) -> None: self.escrow[paise] = self.escrow.get(paise, 0) + 1 self.credit += paise def commit_escrow(self) -> None: for denom, count in self.escrow.items(): self.coin_box[denom] = self.coin_box.get(denom, 0) + count self.escrow.clear() # --- delegation: the machine itself never makes a decision --------------- def insert(self, paise: int) -> str: return self.state.insert(self, paise) def select(self, code: str) -> str: return self.state.select(self, code) def cancel(self) -> str: return self.state.cancel(self) def plan_change(self, amount: int) -> dict[int, int] | None: """Greedy over the coins on hand. Returns None if exact change isn't possible.""" remaining, plan = amount, {} for denom in sorted(self.coin_box, reverse=True): take = min(remaining // denom, self.coin_box[denom]) if take: plan[denom] = take remaining -= denom * take return plan if remaining == 0 else None def refund_all(self) -> int: """Hand back exactly the coins put in — the escrow is why a refund is always possible.""" refund, self.credit = self.credit, 0 self.escrow.clear() return refund machine = VendingMachine( products=[Product("A1", "chips", 3_000, stock=1), Product("A2", "cola", 5_000, stock=0)], coins={1_000: 5, 500: 2, 100: 10}, ) assert machine.select("A1") == "insert money first" # illegal while in IDLE assert machine.state.name() == "IDLE" machine.insert(2_000) assert machine.state.name() == "HAS_MONEY" assert machine.select("A1") == "need 1000 more" # stays in HAS_MONEY assert machine.select("A2") == "out of stock" # the credit is untouched machine.insert(2_000) # credit is now 4000 assert machine.select("A1") == "dispensed chips, change 1000" assert machine.state.name() == "IDLE" and machine.credit == 0 assert machine.products["A1"].stock == 0 machine.insert(1_000) assert machine.cancel() == "refunded 1000" # cancel refunds everything put in assert machine.state.name() == "IDLE" print("final state:", machine.state.name(), "| vault:", machine.coin_box, "| escrow:", machine.escrow) ``` Notice what the pattern buys you: there's **no `if state ==` anywhere** inside `VendingMachine`. Adding a `MAINTENANCE` state means one new class, and not a single existing method has to change. > **Remember:** giving every action a safe default means a new state can never accidentally forget to handle one. Its overrides become a readable list of exactly what's legal. ```knowledge-check { "questions": [ { "id": "ip45-lld-13-state-q1", "type": "mcq", "prompt": "What does the base `VendingState` class gain by defining every action with a default rejection message?", "options": [ {"id":"a","text":"It cuts down the number of classes needed"}, {"id":"b","text":"Every state automatically handles every action — a new state can never accidentally leave one undefined, and each concrete state only has to override the transitions that are actually legal for it"}, {"id":"c","text":"It makes the machine thread-safe"}, {"id":"d","text":"It lets states be compared for equality"} ], "correct": "b", "explanation": "A safe default plus a few selective overrides means the legal transitions are exactly the methods that got overridden — the state class turns into a readable declaration of what's allowed, with no way to accidentally forget a case." } ] } ``` ## Step 3 — The ATM: the same machine, harder money **What it needs to do**: authenticate a card and PIN, check the balance, withdraw cash, deposit, print a receipt, eject the card. **States**: `IDLE → CARD_INSERTED → AUTHENTICATED → TRANSACTION → DISPENSING → IDLE`, plus `OUT_OF_SERVICE`. Three things make the ATM more than just a vending machine wearing a different skin: **1. Authentication is a state with a retry counter built in.** Three wrong PINs in a row has to capture or block the card. That counter lives on the session, not on the card itself, and being blocked is a real state transition — not just a boolean checked in five different places. **2. Dispensing cash is a denomination problem, not just subtraction.** Withdrawing ₹3,700 from a machine holding ₹2,000, ₹500, and ₹100 notes needs an actual plan for which notes to use, and the machine has to **refuse cleanly** whenever it can't make up that amount from what it's holding. Greedy, meaning always take the biggest note first, works fine for the standard Indian note set, and most real currencies in general, but it's **not correct in general**. For denominations {1, 3, 4} and an amount of 6, greedy gives you 4+1+1, three notes, while the actual best answer is 3+3, just two notes. The general answer is a coin-change dynamic program. Say both: greedy for a standard, well-behaved currency, and DP whenever the denomination set is arbitrary or you genuinely need the minimum note count. This single observation is one of the highest-value things you can say in this whole problem, because it ties LLD directly back to the coin-change pattern from the algorithms section. **3. The debit and the dispense can never be allowed to disagree.** The failure that actually matters here: the account gets debited, and then the cash dispenser jams. The correct sequence is **reserve, then dispense, then commit** — with a compensating credit if the dispense fails. This is the saga pattern from the distributed-transactions HLD lesson, in miniature. Bringing this up yourself is the senior move in this whole problem. ```python def plan_notes(amount: int, inventory: dict[int, int]) -> dict[int, int] | None: """Greedy note selection, limited by what the machine actually holds.""" remaining, plan = amount, {} for note in sorted(inventory, reverse=True): take = min(remaining // note, inventory[note]) if take: plan[note] = take remaining -= note * take return plan if remaining == 0 else None def min_notes_dp(amount: int, denominations: list[int]) -> int | None: """Unbounded coin change: the provably minimal note count, for when greedy isn't safe.""" INF = float("inf") best = [0] + [INF] * amount for value in range(1, amount + 1): for d in denominations: if d <= value and best[value - d] + 1 < best[value]: best[value] = best[value - d] + 1 return None if best[amount] == INF else int(best[amount]) inventory = {2_000: 3, 500: 4, 100: 10} assert plan_notes(3_700, inventory) == {2_000: 1, 500: 3, 100: 2} assert plan_notes(50, inventory) is None # smaller than the smallest note assert plan_notes(100_000, inventory) is None # more than the machine even holds # Where greedy gets it wrong, and DP gets it right: assert min_notes_dp(6, [1, 3, 4]) == 2 # 3 + 3 greedy_count = sum(plan_notes(6, {4: 5, 3: 5, 1: 5}).values()) assert greedy_count == 3 # 4 + 1 + 1 print("greedy notes:", greedy_count, "| optimal:", min_notes_dp(6, [1, 3, 4])) ``` > **Remember:** greedy note selection only works because real currencies are built to make it work. For an arbitrary denomination set, only dynamic programming guarantees the minimum. ```knowledge-check { "questions": [ { "id": "ip45-lld-13-atm-q1", "type": "mcq", "prompt": "Why is greedy note selection fine for a real ATM, but not a general solution to \"minimise the number of notes\"?", "options": [ {"id":"a","text":"Greedy runs slower than dynamic programming"}, {"id":"b","text":"Greedy is only optimal for well-designed denomination sets; for an arbitrary set like {1, 3, 4} it gives 4+1+1 for the amount 6, where 3+3 is actually better — a true general minimum needs the coin-change DP"}, {"id":"c","text":"Greedy can't take the machine's actual note inventory into account"}, {"id":"d","text":"Greedy only fails when the amount doesn't divide evenly by the largest note"} ], "correct": "b", "explanation": "Real currencies are designed to make greedy both correct and fast. Stating the caveat, and knowing the DP fallback, is what shows you understand *why* greedy works here rather than that it just happens to." } ] } ``` ## Steps 4 and 5 — Concurrency, edge cases, and extensions **Concurrency.** A single physical vending machine only ever serves one customer at a time, so the interesting version of this question is really about the ATM network as a whole: | Concern | How it's handled | |---|---| | Two ATMs withdrawing from the same account at once | The **account balance is the shared, changeable data**, and it lives in the bank's own database: `UPDATE accounts SET balance = balance - $1 WHERE id = $2 AND balance >= $1` — zero rows affected means insufficient funds, checked and applied atomically | | Cash inventory inside a single machine | A lock (or a single-threaded controller) around planning and dispensing together — this is a check-then-act sequence | | Card session state | Scoped to that one session, with nothing shared | | Debit succeeds but the dispense fails | A compensating credit; the whole transaction is a saga with an explicit `RESERVED` state, and a reconciliation process catches anything the compensation missed | **Edge cases worth raising yourself:** | Case | How it's handled | |---|---| | Power failure mid-dispense | Write down the intent before acting on it. On restart, compare that journal against the physical cash count | | Card left in the machine | A timeout, then the card gets captured and the machine returns to IDLE | | A note gets jammed | Enter OUT_OF_SERVICE and raise an alert — never silently retry | | Daily withdrawal limits | A policy object, checked before the funds are even reserved | | Coin box full, or running low on cash | Admin-configured thresholds and an alert; refuse denominations that would overflow the box | | A product's price changes mid-selection | Read the price once, at the moment of selection, and use that same value for the whole transaction | **Extensions, and how the design absorbs each one:** - **Card payments on the vending machine** → a `PaymentMethod` interface (`CoinPayment`, `CardPayment`, `UpiPayment`); the state machine doesn't change, since every state only cares whether "credit is sufficient," never how that credit arrived. - **Multiple currencies or regions** → a denomination set passed in as configuration, not hardcoded — which is exactly why `plan_change` loops over `self.coin_box` instead of a fixed list. - **Remote telemetry and restocking alerts** → **Observers** on stock levels and cash levels changing. - **A maintenance mode** → one new state class. - **Different dispensing hardware** → an interface sitting behind `DispensingState`. > **Remember:** debit-then-dispense is a saga, not a single transaction. Reserve, act, commit — and have a compensating credit ready for when it fails. ```knowledge-check { "questions": [ { "id": "ip45-lld-13-saga-q1", "type": "mcq", "prompt": "An ATM debits the account, and then the cash dispenser jams. What's the correct design response?", "options": [ {"id":"a","text":"Keep retrying the dispense until it eventually succeeds"}, {"id":"b","text":"Treat it as a saga: reserve the funds first, attempt the dispense, and only commit on success — on failure, run a compensating credit, log the incident, and let a reconciliation process check the physical cash count against the ledger"}, {"id":"c","text":"Roll back the database transaction after the dispense has already failed"}, {"id":"d","text":"Mark the account as disputed and just wait for the customer to call in"} ], "correct": "b", "explanation": "The debit has already gone through and other systems may have already seen it, so it can't be rolled back — and the physical world offers no rollback at all. Reserve, act, commit, with a compensating transaction plus reconciliation, is the standard fix, exactly like in any cross-service workflow." } ] } ``` ## Quick recap - **Draw the state machine before you write a single class.** Both of these problems are lifecycles at heart, and the diagram *is* the design — every rule is either an edge, or a deliberately missing one. - **State pattern with a rejecting base class** means every state handles every action, illegal transitions become impossible to write by accident, and a new state is one new class with zero edits anywhere else. - **The change or note-selection problem is the algorithmic core**: greedy, limited by what's actually on hand, refusing cleanly when exact change isn't possible — plus the honest caveat that greedy is only optimal for well-designed denomination sets. - **Never silently keep the customer's money.** Check whether change is available right alongside stock and credit, before anything actually commits. - **The ATM's debit-then-dispense is a saga.** Reserve, act, commit, compensate, and reconcile — the exact same reasoning as any cross-system workflow, which is why this problem shows up in backend interviews just as often as LLD ones. 79:T5457,These are both "design a library, not an app" problems. That's exactly why they're asked: a library has no UI to hide behind, so the interface itself *is* the design, and how good your abstractions are shows up immediately. Both are also things you genuinely use every day — you've written log statements constantly, and a rate limiter is guarding every API you'll ever build. ## Rate limiter — requirements and the interface **What it needs to do:** - `allow(key) -> bool`: decide, right now, whether this request can go through. - Configurable limits, **per key** — per user, per API key, per IP — and per resource or endpoint. - Support several algorithms: fixed window, sliding window, token bucket. - Report how much budget is left, and when it resets, so clients can behave sensibly. - Work correctly across multiple servers. **Start with the interface.** In a library problem, spend a full minute just on the method signature — most of the actual design lives right there: ``` class RateLimiter(ABC): def try_acquire(self, key: str, now: float, permits: int = 1) -> Decision: ... @dataclass(frozen=True) class Decision: allowed: bool remaining: int retry_after: float # seconds until the next permit; 0 when allowed ``` Three choices here are worth defending out loud: - **Return a `Decision`, not just a plain boolean.** The caller needs a `Retry-After` header and a remaining-budget header — a bare yes/no forces a second call just to get that information. - **Take `now` as a parameter, instead of reading the clock internally.** Injecting time means every algorithm can be tested with exact, predictable numbers, with no actual waiting involved — a small habit that reads as real experience. - **Take `permits`,** so one especially expensive request can cost, say, 10 tokens instead of 1. Weighted limits are a very common follow-up question, and this costs nothing to support from the start. > **Remember:** a rate limiter's return value should carry enough information for the caller to set real HTTP headers, and its clock should be a parameter, not something it reads on its own. ```knowledge-check { "questions": [ { "id": "ip45-lld-14-interface-q1", "type": "mcq", "prompt": "Why should a rate limiter's method return a `Decision` object instead of a plain boolean, and take `now` as a parameter?", "options": [ {"id":"a","text":"To make the API look more object-oriented"}, {"id":"b","text":"The caller needs the remaining budget and a retry-after value to set real response headers, and passing the clock in as a parameter makes every algorithm testable with exact, predictable time values instead of real waiting"}, {"id":"c","text":"Because a plain boolean can't be returned from an abstract method"}, {"id":"d","text":"To allow the limiter to be called asynchronously"} ], "correct": "b", "explanation": "Both choices come from the caller's real needs: HTTP rate-limit headers need more than a plain yes or no, and a component that reads the clock on its own can only be tested by actually waiting or monkey-patching the clock." } ] } ``` ## Rate limiter — the algorithms, behind one interface Each algorithm here is a **Strategy**. The limiter itself is just a thin coordinator sitting over per-key state. ```python from abc import ABC, abstractmethod from collections import deque from dataclasses import dataclass import threading @dataclass(frozen=True) class Decision: allowed: bool remaining: int retry_after: float class RateLimiter(ABC): @abstractmethod def try_acquire(self, key: str, now: float, permits: int = 1) -> Decision: ... class FixedWindowLimiter(RateLimiter): """The cheapest option. Flaw: up to 2x the limit can slip through at a window boundary.""" def __init__(self, limit: int, window_seconds: float): self.limit, self.window = limit, window_seconds self._counts: dict[tuple[str, int], int] = {} self._lock = threading.Lock() def try_acquire(self, key, now, permits=1): bucket = int(now // self.window) with self._lock: used = self._counts.get((key, bucket), 0) if used + permits > self.limit: reset_at = (bucket + 1) * self.window return Decision(False, self.limit - used, reset_at - now) self._counts[(key, bucket)] = used + permits return Decision(True, self.limit - used - permits, 0.0) class SlidingWindowLogLimiter(RateLimiter): """Exact, but memory grows with the request rate — good for low-volume, high-value limits.""" def __init__(self, limit: int, window_seconds: float): self.limit, self.window = limit, window_seconds self._hits: dict[str, deque] = {} self._lock = threading.Lock() def try_acquire(self, key, now, permits=1): with self._lock: hits = self._hits.setdefault(key, deque()) while hits and hits[0] <= now - self.window: hits.popleft() # drop everything outside the window if len(hits) + permits > self.limit: retry = hits[0] + self.window - now return Decision(False, self.limit - len(hits), max(0.0, retry)) for _ in range(permits): hits.append(now) return Decision(True, self.limit - len(hits), 0.0) class TokenBucketLimiter(RateLimiter): """The default choice: enforces an average rate while still allowing a short burst.""" def __init__(self, rate_per_second: float, burst: int): self.rate, self.burst = rate_per_second, burst self._state: dict[str, tuple[float, float]] = {} # key -> (tokens, last_refill) self._lock = threading.Lock() def try_acquire(self, key, now, permits=1): with self._lock: tokens, last = self._state.get(key, (float(self.burst), now)) tokens = min(self.burst, tokens + (now - last) * self.rate) # refill lazily if tokens >= permits: self._state[key] = (tokens - permits, now) return Decision(True, int(tokens - permits), 0.0) self._state[key] = (tokens, now) return Decision(False, int(tokens), (permits - tokens) / self.rate) # --- fixed window: the boundary burst is visible right away ------------------ fw = FixedWindowLimiter(limit=2, window_seconds=60) assert [fw.try_acquire("u1", t).allowed for t in (0, 1, 2)] == [True, True, False] assert fw.try_acquire("u1", 59.9).allowed is False assert fw.try_acquire("u1", 60.0).allowed is True # new window: 2 more, right away assert fw.try_acquire("u2", 0).allowed is True # each key is isolated # --- sliding log: exact, no boundary trick ------------------------------------ sw = SlidingWindowLogLimiter(limit=2, window_seconds=60) assert [sw.try_acquire("u1", t).allowed for t in (0, 1)] == [True, True] assert sw.try_acquire("u1", 59).allowed is False assert sw.try_acquire("u1", 61).allowed is True # the hit at t=0 has aged out # --- token bucket: a burst, then a steady rate -------------------------------- tb = TokenBucketLimiter(rate_per_second=1, burst=3) assert [tb.try_acquire("u1", 0).allowed for _ in range(3)] == [True, True, True] denied = tb.try_acquire("u1", 0) assert denied.allowed is False and abs(denied.retry_after - 1.0) < 1e-9 assert tb.try_acquire("u1", 2).allowed is True # 2 seconds later, 2 tokens refilled assert tb.try_acquire("u1", 2, permits=5).allowed is False # too expensive a request print("token bucket retry_after:", round(denied.retry_after, 2), "seconds") ``` **Distributed rate limiting is the natural follow-up.** Three answers, in increasing order of how good they are: 1. **Per-node limits** — wrong: 10 nodes at 100/minute each means 1000/minute overall, not 100. 2. **One central counter in Redis** (`INCR` plus `EXPIRE`, or a Lua script for the token bucket so refilling and taking a token happen atomically) — correct, but it adds a network round trip to every single request and makes Redis a hard dependency for your front door. 3. **Local buckets, each holding a share of the global budget, rebalanced now and then against a central counter** — approximate, fast, and it gracefully falls back to per-node limits if the central store ever goes down. This is what production API gateways actually do. Also worth one sentence: **rate limit by identity where you can, not by IP address** — mobile carriers and corporate networks can put thousands of real users behind one single IP. > **Remember:** fixed window is cheap but bursty at the boundary. Sliding window is exact but memory-hungry. Token bucket is the default, because it allows a burst without giving up on the average rate. ```knowledge-check { "questions": [ { "id": "ip45-lld-14-algo-q1", "type": "mcq", "prompt": "Under a fixed-window limiter of 2 requests per minute, a client sends 2 requests at t=59s and 2 more at t=61s. How many actually got through in that 2-second span, and what fixes it?", "options": [ {"id":"a","text":"2 — the limiter is working correctly"}, {"id":"b","text":"4 — the window boundary lets up to twice the limit through in an instant; a sliding window (log-based or interpolated) or a token bucket removes this artefact entirely"}, {"id":"c","text":"0 — both windows were already full"}, {"id":"d","text":"3 — the limiter allows one extra request per window"} ], "correct": "b", "explanation": "Each window counts requests entirely on its own, so a burst that straddles the boundary gets both windows' budgets. This is exactly why sliding-window counters and token buckets exist." } ] } ``` ## Logging framework — requirements and the two patterns **What it needs to do:** - Levels: DEBUG, INFO, WARN, ERROR, FATAL, in that order, with a configurable threshold. - Several destinations at once (console, a file, the network), each with its own level and format. - Structured context — a request id, a user id — attached to every message automatically. - Thread-safe, and cheap whenever a message gets filtered out. - Configurable while the program is running, without needing a redeploy. **Two patterns carry this whole design**, and naming both is really the entire point of the problem: - **Chain of Responsibility** for the level hierarchy: each handler checks whether a record meets its own threshold, acts if it does, and passes it on regardless — this is a *broadcast* chain rather than a stop-at-first-match one, so say which kind you mean. - **Strategy** for both formatting (plain text, JSON, key-value pairs) and for the destination itself (an `Appender`/`Sink`), so a brand-new output is just a new class. There's a third, quieter decision here that matters more in production than either pattern: **the level check has to happen before the message string is even built.** `log.debug(f"user {expensive()}")` runs that f-string, and pays its full cost, even when DEBUG is turned off. The fix is either a lazy signature (`log.debug("user %s", user)`, only formatted if it actually passes the check) or an explicit `is_enabled(level)` guard before doing any work. ```python from abc import ABC, abstractmethod from dataclasses import dataclass, field from enum import IntEnum import threading class Level(IntEnum): # an IntEnum, because comparing levels is the whole point DEBUG = 10 INFO = 20 WARN = 30 ERROR = 40 FATAL = 50 @dataclass class LogRecord: level: Level message: str timestamp: float context: dict = field(default_factory=dict) class Formatter(ABC): # strategy: how a record becomes text @abstractmethod def format(self, record: LogRecord) -> str: ... class PlainFormatter(Formatter): def format(self, record): ctx = " ".join(f"{k}={v}" for k, v in sorted(record.context.items())) return f"[{record.level.name}] {record.message}" + (f" {ctx}" if ctx else "") class JsonFormatter(Formatter): def format(self, record): fields = {"level": record.level.name, "msg": record.message, **record.context} body = ", ".join(f'"{k}": "{v}"' for k, v in fields.items()) return "{" + body + "}" class Appender(ABC): # strategy: where the text actually goes def __init__(self, min_level: Level, formatter: Formatter): self.min_level, self.formatter = min_level, formatter self._lock = threading.Lock() def handle(self, record: LogRecord) -> None: if record.level >= self.min_level: # each destination has its own threshold with self._lock: # writes to one sink are serialised self.write(self.formatter.format(record)) @abstractmethod def write(self, line: str) -> None: ... class MemoryAppender(Appender): # a stand-in for console/file/network def __init__(self, min_level, formatter): super().__init__(min_level, formatter) self.lines: list[str] = [] def write(self, line): self.lines.append(line) class Logger: def __init__(self, name: str, min_level: Level = Level.DEBUG): self.name, self.min_level = name, min_level self._appenders: list[Appender] = [] self._context: dict = {} def add_appender(self, appender: Appender) -> "Logger": self._appenders.append(appender) return self def with_context(self, **kwargs) -> "Logger": """A child logger carrying request-scoped fields — no global mutable state involved.""" child = Logger(self.name, self.min_level) child._appenders = self._appenders # shares the same sinks, has its own context child._context = {**self._context, **kwargs} return child def is_enabled(self, level: Level) -> bool: return level >= self.min_level def log(self, level: Level, template: str, *args, now: float = 0.0) -> None: if not self.is_enabled(level): return # a cheap exit BEFORE any formatting message = template % args if args else template record = LogRecord(level, message, now, dict(self._context)) for appender in self._appenders: appender.handle(record) def debug(self, t, *a, now=0.0): self.log(Level.DEBUG, t, *a, now=now) def info(self, t, *a, now=0.0): self.log(Level.INFO, t, *a, now=now) def warn(self, t, *a, now=0.0): self.log(Level.WARN, t, *a, now=now) def error(self, t, *a, now=0.0): self.log(Level.ERROR, t, *a, now=now) console = MemoryAppender(Level.INFO, PlainFormatter()) # for humans: INFO and above audit = MemoryAppender(Level.ERROR, JsonFormatter()) # for alerting: ERROR only log = Logger("app", min_level=Level.DEBUG).add_appender(console).add_appender(audit) request_log = log.with_context(request_id="r-42", user="asha") request_log.debug("cache lookup %s", "user:1") # below the console's own threshold request_log.info("order placed") request_log.error("payment failed: %s", "timeout") assert console.lines == [ "[INFO] order placed request_id=r-42 user=asha", "[ERROR] payment failed: timeout request_id=r-42 user=asha", ] assert len(audit.lines) == 1 and audit.lines[0].startswith('{"level": "ERROR"') assert log.with_context().is_enabled(Level.DEBUG) is True quiet = Logger("app", min_level=Level.WARN).add_appender(console) quiet.info("this line is dropped before any formatting even happens") assert len(console.lines) == 2 # unchanged print("\n".join(console.lines)) print(audit.lines[0]) ``` > **Remember:** the level check has to happen before the message string is built, never after. Otherwise, a disabled log call still pays the cost of an enabled one. ```knowledge-check { "questions": [ { "id": "ip45-lld-14-logger-q1", "type": "mcq", "prompt": "Why does `log(...)` check `is_enabled(level)` before it ever builds the message string?", "options": [ {"id":"a","text":"To keep the method shorter"}, {"id":"b","text":"Building the message is often the expensive part — `log.debug(f\"...{expensive()}\")` pays that full cost even with DEBUG turned off, so the level check has to come first, and formatting has to be deferred (%s-style arguments, not an eager f-string)"}, {"id":"c","text":"Because appenders can't handle empty messages"}, {"id":"d","text":"To make the logger thread-safe"} ], "correct": "b", "explanation": "A disabled log call should cost exactly one integer comparison. Building the string eagerly at the call site defeats that entirely — which is exactly why real logging libraries take a template plus separate arguments, not a pre-built string." } ] } ``` ## Concurrency, performance, and extensions **Rate limiter:** | Concern | How it's handled | |---|---| | Several `try_acquire` calls for one key at once | A lock per key (or a striped array of locks), never one single global lock | | Memory growing from keys nobody uses anymore | Evict with an LRU cache or a TTL — an unbounded per-key map is really just a slow memory leak | | Correctness across servers | A Lua script in Redis makes refilling and taking a token one atomic step; local buckets against a shared global budget when latency matters more than being perfectly exact | | Fail open, or fail closed? | **Decide this ahead of time, and say so out loud.** If Redis goes down, do you let all traffic through (available, but unprotected) or block everything (protected, but an outage)? Usually fail-open for ordinary user traffic, fail-closed for anything expensive or dangerous | That last row is exactly the question interviewers use to separate strong candidates from weaker ones — the right answer isn't a fixed value, it's "it depends on what this endpoint actually costs, and here's my default." **Logger:** | Concern | How it's handled | |---|---| | Several threads writing to one shared sink | A lock per appender (as built above), or an asynchronous appender with a bounded queue | | A slow sink (the network) blocking the request | An **asynchronous appender**: put the message on a queue, and let a background thread drain it | | The queue fills up | Drop the oldest entry, drop by level, or block — but as an explicit, configured policy, never as an unbounded queue that just grows forever | | Losing logs if the process crashes | Flush on shutdown; accept a small, known window of possible loss for async sinks, and say exactly what that window is | | Request-scoped context | A child logger, or a context-local variable — never a single global mutable dictionary | **Extensions for both:** - A new rate-limiting algorithm → a new `RateLimiter` class; the gateway itself is unchanged. - Per-endpoint limits → a config map from route to limiter; a composite tries each one and denies if any of them denies. - A new log destination (Kafka, S3, OpenTelemetry) → a new `Appender`. - Sampling ("only log 1% of DEBUG messages in production") → a filter placed before the appenders in the chain. - Redacting sensitive data → a formatter decorator wrapping the real formatter. > **Remember:** fail-open or fail-closed is a deliberate, per-endpoint decision — never a blanket default applied everywhere. ```knowledge-check { "questions": [ { "id": "ip45-lld-14-failmode-q1", "type": "mcq", "prompt": "Your distributed rate limiter's Redis backend goes down. What's the right design response?", "options": [ {"id":"a","text":"Always deny requests — safety comes first"}, {"id":"b","text":"It's a deliberate, per-endpoint policy: fail-open (allow, unprotected) for ordinary user traffic so an infrastructure blip doesn't take the whole product down, and fail-closed for expensive or dangerous endpoints — either way, backed by a local in-process fallback limit"}, {"id":"c","text":"Always allow requests — availability comes first"}, {"id":"d","text":"Just keep retrying Redis until it responds again"} ], "correct": "b", "explanation": "Neither blanket answer is right in every situation. The strong response names the trade-off directly, sets a sensible default, and adds a degraded local limit so the failure stays bounded instead of becoming an all-or-nothing outcome." } ] } ``` ## Quick recap - **In a library problem, the interface *is* the design.** Spend a full minute on the method signature: return a rich result, inject the clock, and allow weighted permits. - **Rate limiter = a Strategy over per-key state.** Fixed window is cheap but bursty at the boundary; sliding log is exact but memory-hungry; **token bucket is the default** because it enforces an average rate while still letting through a short burst. - **Distributed limiting is the natural follow-up**, and "local buckets against a shared budget" is the production answer — with the fail-open or fail-closed decision stated out loud. - **Logger = Chain of Responsibility for levels, plus Strategy for the formatter and the appender**, plus the one performance detail people forget: check the level *before* building the message. - **Bounded, with eviction, everywhere.** An unbounded per-key map and an unbounded async log queue are the two memory leaks these two designs quietly invite if you're not careful. 7a:T6724,Two more library-shaped problems, picked because between the two of them they touch nearly every pattern in this section. The notification service is the classic example of Observer, Strategy, and Chain of Responsibility working together. The cache is the classic "combine two data structures to hit an exact complexity target" problem, and it's the single most-asked design question in coding interviews, full stop. ## Notification service — requirements and structure **What it needs to do:** - Send a notification to a user over one or more channels: email, SMS, push, in-app. - Respect **the user's own preferences**: which channels they want, and which categories they've muted. - Templates, with variables filled in, that render differently per channel. - Retry failures that are likely temporary; never retry ones that clearly aren't. - Rate limit per user, so one runaway event can't flood someone's inbox. - Priority: a security alert should never sit in a queue behind a marketing email. **The patterns, and exactly what each one is doing here:** | Pattern | Its job in this design | |---|---| | **Strategy** | One class per delivery channel, all behind a `NotificationChannel` interface | | **Observer** | Domain events like `order.placed` trigger notifications, with the order code never knowing they exist | | **Chain of Responsibility** | The send pipeline: preferences, then rate limiting, then quiet hours, then dedupe, then actual delivery | | **Template Method / Strategy** | Rendering the message per channel (SMS gets 160 characters; email gets full HTML) | | **Factory** | Turning a channel name into the right implementation | | **Decorator** | Wrapping a channel with retry logic and circuit-breaking, without touching the channel's own code | **The key modelling decision here**: a `Notification` is a **request** — recipient, category, template, data, priority — not a finished message. Rendering only happens per channel, at the moment of sending, because the exact same request turns into a completely different piece of text on SMS versus in an email. If you put a plain `body: str` directly on the notification, you can't express that at all. > **Remember:** a Notification is a request, not a rendered message. Rendering happens per channel, at send time — never before. ```knowledge-check { "questions": [ { "id": "ip45-lld-15-notif-model-q1", "type": "mcq", "prompt": "Why should a `Notification` carry a template id plus data, rather than a rendered `body` string?", "options": [ {"id":"a","text":"Strings use more memory than template ids"}, {"id":"b","text":"The same logical notification renders differently per channel — a 160-character SMS, an HTML email, a short push title — so rendering has to happen per channel at send time, and this same choice makes localisation and template edits possible without touching the caller"}, {"id":"c","text":"Because templates are easier to store in a database"}, {"id":"d","text":"Because rendered strings can't be retried"} ], "correct": "b", "explanation": "Rendering is a channel-specific concern. Baking a fixed body directly into the request forces the caller to already know about every channel's constraints, and makes both localisation and template edits into code changes." } ] } ``` ## Notification service — implementation ```python from abc import ABC, abstractmethod from dataclasses import dataclass, field from enum import Enum class Channel(Enum): EMAIL = "email" SMS = "sms" PUSH = "push" class Priority(Enum): LOW = 1 NORMAL = 2 URGENT = 3 @dataclass(frozen=True) class Notification: user_id: str category: str # "security" | "marketing" | "transactional" template: str data: dict priority: Priority = Priority.NORMAL @dataclass class UserPreferences: channels: set[Channel] muted_categories: set[str] = field(default_factory=set) contact: dict[Channel, str] = field(default_factory=dict) # ---- Strategy: one class per delivery channel ------------------------------- class NotificationChannel(ABC): @abstractmethod def render(self, n: Notification) -> str: ... @abstractmethod def deliver(self, to: str, body: str) -> None: ... class EmailChannel(NotificationChannel): def __init__(self): self.sent: list[tuple[str, str]] = [] def render(self, n): return f"{n.template}: {n.data}" def deliver(self, to, body): self.sent.append((to, body)) class SmsChannel(NotificationChannel): LIMIT = 160 def __init__(self, fail_times: int = 0): self.sent: list[tuple[str, str]] = [] self._fail_times = fail_times def render(self, n): return f"{n.template}: {n.data.get('order_id', '')}"[: self.LIMIT] def deliver(self, to, body): if self._fail_times > 0: # simulating a temporary outage self._fail_times -= 1 raise ConnectionError("sms gateway timeout") self.sent.append((to, body)) # ---- Decorator: retry logic without touching the channel itself ------------- class RetryingChannel(NotificationChannel): def __init__(self, inner: NotificationChannel, attempts: int = 3): self._inner, self._attempts = inner, attempts self.failures = 0 def render(self, n): return self._inner.render(n) def deliver(self, to, body): last: Exception | None = None for _ in range(self._attempts): try: return self._inner.deliver(to, body) except ConnectionError as exc: # likely temporary → retry it self.failures += 1 last = exc except ValueError: # permanent — a bad address — give up raise raise last # out of attempts → send to a dead-letter queue # ---- Chain of Responsibility: the send pipeline ----------------------------- class Filter(ABC): def __init__(self): self._next: "Filter | None" = None def then(self, nxt: "Filter") -> "Filter": self._next = nxt return nxt def handle(self, n: Notification, prefs: UserPreferences) -> str | None: blocked = self.check(n, prefs) if blocked is not None: return blocked # stop here: the notification gets dropped return self._next.handle(n, prefs) if self._next else None @abstractmethod def check(self, n: Notification, prefs: UserPreferences) -> str | None: ... class MutedCategoryFilter(Filter): def check(self, n, prefs): if n.category in prefs.muted_categories and n.priority is not Priority.URGENT: return f"muted category {n.category}" # urgent alerts bypass mute — a real rule return None class PerUserRateLimitFilter(Filter): def __init__(self, limit: int): super().__init__() self.limit, self._counts = limit, {} def check(self, n, prefs): if n.priority is Priority.URGENT: return None # never rate limit security alerts self._counts[n.user_id] = self._counts.get(n.user_id, 0) + 1 if self._counts[n.user_id] > self.limit: return "rate limited" return None class DedupeFilter(Filter): def __init__(self): super().__init__() self._seen: set[tuple] = set() def check(self, n, prefs): key = (n.user_id, n.template, tuple(sorted(n.data.items()))) if key in self._seen: return "duplicate" self._seen.add(key) return None class NotificationService: def __init__(self, channels: dict[Channel, NotificationChannel], pipeline: Filter): self._channels, self._pipeline = channels, pipeline self.dead_letter: list[tuple[Notification, Channel, str]] = [] def send(self, n: Notification, prefs: UserPreferences) -> list[str]: blocked = self._pipeline.handle(n, prefs) if blocked is not None: return [f"dropped: {blocked}"] results = [] for channel in prefs.channels: impl = self._channels.get(channel) if impl is None: continue try: impl.deliver(prefs.contact[channel], impl.render(n)) results.append(f"{channel.value}: sent") except Exception as exc: # one failing channel can't sink the rest self.dead_letter.append((n, channel, str(exc))) results.append(f"{channel.value}: failed") return results email = EmailChannel() sms_inner = SmsChannel(fail_times=2) # fails twice, then succeeds sms = RetryingChannel(sms_inner, attempts=3) pipeline = DedupeFilter() pipeline.then(MutedCategoryFilter()).then(PerUserRateLimitFilter(limit=2)) service = NotificationService({Channel.EMAIL: email, Channel.SMS: sms}, pipeline) prefs = UserPreferences( channels={Channel.EMAIL, Channel.SMS}, muted_categories={"marketing"}, contact={Channel.EMAIL: "asha@mindforge.test", Channel.SMS: "+91999"}, ) order = Notification("u1", "transactional", "order_shipped", {"order_id": "ord_1"}) assert sorted(service.send(order, prefs)) == ["email: sent", "sms: sent"] assert sms.failures == 2 # two temporary failures, then success assert service.dead_letter == [] assert service.send(order, prefs) == ["dropped: duplicate"] # the same payload gets deduped promo = Notification("u1", "marketing", "sale", {"pct": 20}) assert service.send(promo, prefs) == ["dropped: muted category marketing"] alert = Notification("u1", "marketing", "breach", {"ip": "1.2.3.4"}, Priority.URGENT) assert "email: sent" in service.send(alert, prefs) # urgent bypasses the mute print("email outbox:", len(email.sent), "| sms outbox:", len(sms_inner.sent)) ``` > **Remember:** cross-cutting behaviour like retry belongs in a wrapper, never copy-pasted into every channel. That single decision makes retry, metrics, and circuit-breaking free for every channel you add later. ```knowledge-check { "questions": [ { "id": "ip45-lld-15-notif-impl-q1", "type": "mcq", "prompt": "Retry logic lives in `RetryingChannel`, wrapping a channel, rather than being built into each channel separately. What does that actually buy you?", "options": [ {"id":"a","text":"It makes retries happen faster"}, {"id":"b","text":"Retry becomes an independent, reusable concern: every channel gets it with no duplicated code, it can be configured per channel, and a circuit breaker or a metrics wrapper can stack the exact same way — this is Decorator applied to cross-cutting behaviour"}, {"id":"c","text":"It stops permanent failures from happening in the first place"}, {"id":"d","text":"It removes the need for a dead-letter queue"} ], "correct": "b", "explanation": "Retry, circuit breaking, metrics, and logging are all cross-cutting concerns. Building them into every channel duplicates code and drifts out of sync over time; wrapping keeps every channel focused purely on its own protocol." } ] } ``` ## How a hash map actually works underneath Before building a cache, it's worth seeing what a hash map does under the hood — this is also a common coding-round question on its own, sometimes phrased as "implement a hash map without using your language's built-in one." **The idea**: pick a fixed number of "buckets." To store a key, hash it down to a bucket index, then just append the (key, value) pair to whatever's already in that bucket's list. Two different keys landing in the same bucket is called a **collision**, and it's handled by simply keeping a short list per bucket — this is called **chaining**. ```python class MyHashMap: def __init__(self, bucket_count: int = 1000): self.bucket_count = bucket_count self.buckets: list[list[tuple[int, int]]] = [[] for _ in range(bucket_count)] def _hash(self, key: int) -> int: return key % self.bucket_count def put(self, key: int, value: int) -> None: bucket = self.buckets[self._hash(key)] for i, (k, v) in enumerate(bucket): if k == key: bucket[i] = (key, value) # an existing key: overwrite, don't duplicate return bucket.append((key, value)) def get(self, key: int) -> int: bucket = self.buckets[self._hash(key)] for k, v in bucket: if k == key: return v return -1 def remove(self, key: int) -> None: bucket = self.buckets[self._hash(key)] for i, (k, v) in enumerate(bucket): if k == key: bucket.pop(i) return m = MyHashMap(bucket_count=4) m.put(1, 100) m.put(5, 500) # 1 % 4 == 1 and 5 % 4 == 1 — a deliberate collision assert m.get(1) == 100 and m.get(5) == 500 # chaining keeps both, side by side m.put(1, 999) # overwrites, doesn't create a second entry for key 1 assert m.get(1) == 999 and len(m.buckets[1]) == 2 m.remove(5) assert m.get(5) == -1 print("bucket 1 holds:", m.buckets[1]) ``` **Time complexity: average O(1) per operation, as long as chains stay short.** That "as long as" is the entire catch. With a fixed bucket count and a growing number of keys, chains get longer and longer, and performance quietly degrades toward O(n): one giant bucket with everything crammed inside it. A real hash map fixes this by tracking its **load factor** (roughly: keys stored, divided by bucket count) and **resizing**, doubling the bucket count and re-hashing everything, once that load factor crosses a threshold, typically around 0.75. **The two mistakes worth watching for**: forgetting that `put` on a key that already exists should overwrite it, not silently add a duplicate entry to the bucket, and picking a bucket count so small that chains turn long and every operation quietly becomes O(n) in practice. > **Remember:** a hash map is just an array of buckets, each holding a small list. Its O(1) average case relies entirely on keeping those chains short through resizing. ```knowledge-check { "questions": [ { "id": "ip45-lld-15-hashmap-q1", "type": "mcq", "prompt": "Why does a hand-rolled hash map with a fixed bucket count eventually slow down as more keys get added?", "options": [ {"id":"a","text":"Because Python dictionaries are always faster"}, {"id":"b","text":"Every extra key increases the average chain length inside each bucket, since the bucket count never grows — that pushes lookups from O(1) toward O(n), which is exactly why real hash maps resize once their load factor crosses a threshold"}, {"id":"c","text":"Because hashing itself gets slower for larger numbers"}, {"id":"d","text":"Because Python lists can't hold tuples"} ], "correct": "b", "explanation": "A fixed number of buckets with a growing number of keys means longer and longer chains inside each bucket — a bucket with a long chain degrades toward a plain linear scan. Resizing (doubling the bucket count and re-hashing everything) is what keeps the average case at O(1)." } ] } ``` ## In-memory cache — the LRU design **Requirements**: `get` and `put` both in **O(1)**, a fixed capacity, evict the least-recently-used entry once it's full, an optional TTL per entry, and a pluggable eviction policy. **Here's the reasoning worth saying out loud, because it really is the whole answer**: a plain hash map gives you O(1) lookup, but no sense of ordering at all. A plain linked list gives you O(1) reordering, but O(n) lookup. Combine the two — **a hash map from key to node, and a doubly linked list to track recency** — and both operations land at O(1). Sentinel head and tail nodes get rid of every null check at the edges of the list. ```python class Node: __slots__ = ("key", "value", "expires_at", "prev", "next") def __init__(self, key=None, value=None, expires_at=None): self.key, self.value, self.expires_at = key, value, expires_at self.prev = self.next = None class LRUCache: """O(1) get and put. A hash map for lookup, a doubly linked list for recency order.""" def __init__(self, capacity: int): if capacity <= 0: raise ValueError("capacity must be positive") self.capacity = capacity self._map: dict[object, Node] = {} self._head = Node() # sentinel: the most-recently-used side self._tail = Node() # sentinel: the least-recently-used side self._head.next, self._tail.prev = self._tail, self._head self.hits = self.misses = self.evictions = 0 # ---- moving nodes around ---------------------------------------------- def _unlink(self, node: Node) -> None: node.prev.next, node.next.prev = node.next, node.prev def _push_front(self, node: Node) -> None: node.next, node.prev = self._head.next, self._head self._head.next.prev = node self._head.next = node # ---- public API ----------------------------------------------------- def get(self, key, now: float = 0.0): node = self._map.get(key) if node is None: self.misses += 1 return None if node.expires_at is not None and node.expires_at <= now: self._evict(node) # expire it lazily — cheaper than a sweeper thread self.misses += 1 return None self._unlink(node) self._push_front(node) # touching an entry makes it the most recent self.hits += 1 return node.value def put(self, key, value, now: float = 0.0, ttl: float | None = None) -> None: expires_at = None if ttl is None else now + ttl node = self._map.get(key) if node is not None: node.value, node.expires_at = value, expires_at self._unlink(node) self._push_front(node) return node = Node(key, value, expires_at) self._map[key] = node self._push_front(node) if len(self._map) > self.capacity: self._evict(self._tail.prev) # the node just before the tail sentinel self.evictions += 1 def _evict(self, node: Node) -> None: self._unlink(node) del self._map[node.key] def keys_mru_first(self) -> list: out, node = [], self._head.next while node is not self._tail: out.append(node.key) node = node.next return out def __len__(self) -> int: return len(self._map) cache = LRUCache(capacity=3) cache.put("a", 1); cache.put("b", 2); cache.put("c", 3) assert cache.keys_mru_first() == ["c", "b", "a"] assert cache.get("a") == 1 # touching 'a' makes it the most recently used assert cache.keys_mru_first() == ["a", "c", "b"] cache.put("d", 4) # over capacity → evict the LRU entry, which is 'b' assert cache.get("b") is None and cache.evictions == 1 assert sorted(cache.keys_mru_first()) == ["a", "c", "d"] cache.put("e", 5, now=0, ttl=10) # an entry with a TTL assert cache.get("e", now=5) == 5 assert cache.get("e", now=11) is None # expired lazily, right when it was read assert cache.hits == 2 and cache.misses == 2 print("keys (MRU first):", cache.keys_mru_first(), "| hits/misses/evictions:", cache.hits, cache.misses, cache.evictions) ``` **The follow-up questions you'll get, along with their answers:** | Follow-up | Answer | |---|---| | "Make it thread-safe" | One lock around `get` and `put` (both of them mutate the list). For higher throughput, a sharded cache — N independent chunks, each keyed by `hash(key) % N`, each with its own lock | | "Make the eviction policy pluggable" | An `EvictionPolicy` interface — LRU, LFU, FIFO, random — that owns the ordering structure. LFU needs a frequency count plus a pointer to the current minimum frequency to stay O(1) | | "What about a big scan flushing out the hot data?" | LFU, or a segmented LRU (a probation area and a protected area), or an algorithm like W-TinyLFU, which is what the real Caffeine cache library uses | | "Why not just use `OrderedDict`?" | It genuinely works, using `move_to_end` and `popitem(last=False)`, but interviewers want to see the underlying mechanism — know both, and be ready to say why | | "Evict by memory used, not entry count" | Track an approximate size per entry, and evict until you're back under budget | | "What about a distributed cache?" | That's really the HLD caching lesson at this point: consistent hashing across nodes, cache-aside, jittered TTLs, stampede protection | > **Remember:** a hash map gives O(1) lookup with no ordering. A doubly linked list gives O(1) reordering with no lookup. LRU exists because combining them fills in exactly what the other one is missing. ```knowledge-check { "questions": [ { "id": "ip45-lld-15-cache-q1", "type": "mcq", "prompt": "Why does an O(1) LRU cache need both a hash map and a doubly linked list?", "options": [ {"id":"a","text":"The list stores the values and the map stores the keys"}, {"id":"b","text":"The map gives O(1) key lookup but no sense of ordering; the doubly linked list gives O(1) removal and re-insertion — so updating recency is constant time — but only O(n) search on its own. Each one supplies exactly what the other is missing"}, {"id":"c","text":"The list is only there for iteration"}, {"id":"d","text":"A singly linked list would work exactly as well"} ], "correct": "b", "explanation": "The map holds key to node, so you can find any node instantly. The doubly linked structure lets you unlink that node in O(1) — something a singly linked list can't do, since it has no way to reach back to the node before it." } ] } ``` ## Concurrency and extensions **Notification service:** | Concern | How it's handled | |---|---| | One slow channel blocking all the others | Deliver to each channel independently — ideally asynchronously, or at minimum catching failures per channel, as built above | | Duplicate sends after a retry | Deliveries have to be idempotent: a `(notification_id, channel)` dedupe key, exactly like in the messaging lesson in HLD | | Priority | Separate queues per priority level, drained by weight — never a single FIFO queue where a security alert sits behind a marketing digest | | Permanent failures | Send to a dead-letter queue with the error and the attempt count, plus an alert if that queue's depth grows too large | | A whole channel provider going down | A circuit-breaker decorator wrapping the channel, so you stop hammering a dead provider and can fall back to a different channel instead | **Cache:** | Concern | How it's handled | |---|---| | A concurrent `get` mutating the recency list | `get` is really a *writer* in an LRU cache — a plain read-write lock isn't enough here; use a full lock, or approximate recency the way Caffeine does, by recording accesses in a buffer and reordering in batches | | Lock contention under heavy load | Shard the cache — each shard is its own independent `LRUCache` with its own lock | | Expiry | Lazy, checked on read (as built above), plus an optional background sweeper purely to reclaim memory sooner | | A stampede on one very hot key | Single-flight: the very first miss populates the cache while everyone else waits — the exact fix from the HLD caching lesson, applied here | The detail worth volunteering about the cache: **`get` mutates state**, so the instinctive answer "reads can share a lock, only writes need an exclusive one" is actually wrong for LRU specifically. Saying this unprompted is a strong signal. > **Remember:** `get` mutates the recency list in an LRU cache, so it's really a writer. A read-write lock alone isn't enough — you need a full lock, or approximate recency in batches. ```knowledge-check { "questions": [ { "id": "ip45-lld-15-concurrency-q1", "type": "mcq", "prompt": "Why isn't a read-write lock (many readers, one writer) enough for a standard LRU cache?", "options": [ {"id":"a","text":"Read-write locks are slower than plain mutexes"}, {"id":"b","text":"`get` isn't actually a read — it moves the accessed node to the front of the recency list, so concurrent \"readers\" would corrupt that list. The real options are a full mutex, sharding, or recording accesses in a buffer and reordering them in batches"}, {"id":"c","text":"Because the hash map itself isn't thread-safe"}, {"id":"d","text":"Because TTL expiry always requires a background thread"} ], "correct": "b", "explanation": "Tracking recency turns every single read into a mutation. Real high-throughput caches like Caffeine solve this by buffering access records and applying them asynchronously, which restores true parallel reads at the cost of slightly approximate ordering." } ] } ``` ## Quick recap - **The notification service is a showcase of patterns working together**: Strategy per channel, Chain for the filter pipeline, Decorator for retry and circuit-breaking, Observer to trigger it from domain events, Factory to resolve a channel by name. Naming each one alongside its exact role is the whole answer. - **A notification is a request, not a message.** Rendering happens per channel, at send time. - **Cross-cutting behaviour goes in a wrapper**, never copy-pasted into every implementation — that one decision makes retry, metrics, and circuit-breaking free for every channel you add later. - **A hash map is buckets plus chaining, with resizing to keep chains short** — worth knowing on its own, and it's exactly the first half of what makes LRU work. - **LRU = a hash map plus a doubly linked list plus sentinels.** Be able to write it from memory — it's asked more often than any other design problem out there. - **`get` mutates an LRU cache**, so the right concurrency answer is a full lock or sharding, never a read-write lock. Saying that unprompted is the single strongest sentence you can offer in this problem. 7b:T5e0e,Games get asked because they pack a lot of design into a small space: a board, players, turns, rules, and a way to decide who's won. These three, taken in increasing order of difficulty, cover the whole range — Tic-Tac-Toe checks whether you can spot the O(1) win check, Snake & Ladder checks whether you can model turns and edge cases cleanly, and Chess checks whether you can build a truly extensible, polymorphic set of rules. Here's the shared skeleton behind every board game, worth stating before writing a single class: ``` Game owns the board, the turn order, whose turn it is, and the overall status Board owns the cells and the geometry (is this position even valid?) Player an identity, plus a strategy for choosing a move (human or bot) Move a value object: what was actually attempted Rules validate a move, and detect when the game is over GameStatus IN_PROGRESS | WON | DRAW | ABANDONED ``` ## Tic-Tac-Toe — the O(1) win check **The real design point here isn't the classes — it's how you detect a win.** Re-scanning the whole board after every single move is O(n²). Instead, keep a running total per row, per column, and for both diagonals: player 1 adds +1, player 2 adds −1, and the moment any single counter reaches ±n, that's a win. Every move only ever touches one row, one column, and possibly both diagonals — so the check is O(1). ```python class TicTacToe: """O(1) per move: running counters, instead of rescanning the whole board.""" def __init__(self, n: int = 3): self.n = n self._rows = [0] * n self._cols = [0] * n self._diag = 0 self._anti = 0 self._board = [[0] * n for _ in range(n)] self._moves = 0 def move(self, row: int, col: int, player: int) -> str: if not (0 <= row < self.n and 0 <= col < self.n): raise ValueError("off the board") if self._board[row][col] != 0: raise ValueError("cell already taken") if player not in (1, 2): raise ValueError("unknown player") delta = 1 if player == 1 else -1 self._board[row][col] = player self._moves += 1 self._rows[row] += delta self._cols[col] += delta if row == col: self._diag += delta if row + col == self.n - 1: # NOT elif: the centre of an odd board is on both self._anti += delta if self.n in (abs(self._rows[row]), abs(self._cols[col]), abs(self._diag), abs(self._anti)): return f"player {player} wins" return "draw" if self._moves == self.n * self.n else "in progress" game = TicTacToe(3) assert game.move(0, 0, 1) == "in progress" assert game.move(1, 1, 2) == "in progress" assert game.move(0, 1, 1) == "in progress" assert game.move(2, 2, 2) == "in progress" assert game.move(0, 2, 1) == "player 1 wins" # the top row is complete try: game.move(0, 0, 2) raise AssertionError("re-using a cell was allowed") except ValueError as e: print("rejected:", e) # X O X # X O O -- no line is ever complete, so a full board is a draw # O X X draw = TicTacToe(3) for r, c, p in [(0,0,1),(0,1,2),(0,2,1),(1,1,2),(1,0,1),(1,2,2),(2,1,1),(2,0,2),(2,2,1)]: result = draw.move(r, c, p) assert result == "draw" print("full board result:", result) ``` Two details that come up whenever this problem is probed further: the diagonal updates use two separate `if` statements, **not** `if`/`elif`, because on an odd-sized board the exact centre cell sits on both diagonals at once. And a draw gets detected by simply counting moves, never by scanning the board for empty cells. > **Remember:** the centre cell of an odd-sized board sits on both diagonals. Use two separate `if`s, not `if`/`elif`, or you'll miss a real win. ```knowledge-check { "questions": [ { "id": "ip45-lld-16-ttt-q1", "type": "mcq", "prompt": "Why do the two diagonal counter updates use separate `if` statements instead of `if`/`elif`?", "options": [ {"id":"a","text":"Because `elif` runs more slowly"}, {"id":"b","text":"On an odd-sized board, the exact centre cell satisfies both `row == col` and `row + col == n-1` at once, so it sits on both diagonals and needs to update both counters"}, {"id":"c","text":"Because the anti-diagonal counter always has to be updated regardless"}, {"id":"d","text":"Because the board might not be square"} ], "correct": "b", "explanation": "For n=3, the centre cell (1,1) sits on both diagonals at once. `elif` would skip updating the anti-diagonal there, which would make a diagonal win running through the centre completely undetectable." } ] } ``` ## Snake & Ladder — clean turn and state modelling There's no clever algorithm hiding here. This problem gets asked purely to see whether you model **turns, rules, and how the game ends** cleanly, and whether you actually handle the edge cases. | Rule question | Typical answer | Where it lives | |---|---|---| | What if a roll overshoots the final square? | Stay put (or bounce back) — this is a deliberate rule, not an accident | `MovementRule` | | What happens on rolling a six? | Roll again | The turn loop | | Three sixes in a row? | The turn is forfeited | The turn loop | | Do you need to land exactly on square 100? | Yes | `MovementRule` | | Can a snake's head also be a ladder's bottom? | No — check this when the board is built | A `Board` invariant | | How many dice? | Configurable — one or two | A `Dice` strategy | Modelling both snakes and ladders as one single `jumps: {start: end}` map is the simplification worth saying out loud: a snake is just a jump to a lower square, and a ladder a jump to a higher one, so a single lookup handles both, and checking "no square is both a start and an end" becomes trivially easy. ```python from abc import ABC, abstractmethod from dataclasses import dataclass, field from enum import Enum class Status(Enum): IN_PROGRESS = "in_progress" WON = "won" class Dice(ABC): @abstractmethod def roll(self) -> int: ... class ScriptedDice(Dice): """Deterministic dice — the same seam a real design would use for a RandomDice.""" def __init__(self, values: list[int]): self._values, self._i = values, 0 def roll(self) -> int: value = self._values[self._i % len(self._values)] self._i += 1 return value @dataclass class Board: size: int jumps: dict[int, int] = field(default_factory=dict) # a snake OR a ladder — same shape def __post_init__(self): for start, end in self.jumps.items(): if not (1 <= start <= self.size and 1 <= end <= self.size): raise ValueError(f"jump {start}->{end} is off the board") if end in self.jumps: # this rules out chained jumps raise ValueError(f"square {end} is both a destination and a jump start") if self.size in self.jumps: raise ValueError("the final square cannot start a jump") def destination(self, square: int) -> int: return self.jumps.get(square, square) @dataclass class Player: name: str position: int = 0 class Game: MAX_SIXES = 3 def __init__(self, board: Board, players: list[Player], dice: Dice): if len(players) < 2: raise ValueError("need at least two players") self.board, self.players, self.dice = board, players, dice self.turn = 0 self.status = Status.IN_PROGRESS self.winner: Player | None = None self.log: list[str] = [] def current_player(self) -> Player: return self.players[self.turn % len(self.players)] def play_turn(self) -> str: if self.status is Status.WON: raise RuntimeError("game is over") player = self.current_player() sixes = 0 while True: roll = self.dice.roll() if roll == 6: sixes += 1 if sixes == self.MAX_SIXES: self.log.append(f"{player.name}: three sixes, turn forfeited") break target = player.position + roll if target > self.board.size: self.log.append(f"{player.name}: rolled {roll}, overshoot, stays at {player.position}") break # you must land exactly on the last square landed = self.board.destination(target) kind = "" if landed == target else (" ladder" if landed > target else " snake") player.position = landed self.log.append(f"{player.name}: rolled {roll} -> {landed}{kind}") if landed == self.board.size: self.status, self.winner = Status.WON, player self.turn += 1 return f"{player.name} wins" if roll != 6: break # a six earns another roll self.turn += 1 return "in progress" board = Board(size=20, jumps={3: 15, 17: 5}) # a ladder 3->15, a snake 17->5 alice, bob = Player("alice"), Player("bob") # alice: 3 (up the ladder to 15) ... bob: 5 ... alice: 6, then 6 again -> overshoot handling game = Game(board, [alice, bob], ScriptedDice([3, 5, 2, 4, 3, 6, 4, 1])) assert game.play_turn() == "in progress" assert alice.position == 15 # took the ladder game.play_turn(); assert bob.position == 5 # rolled a 5 game.play_turn() # alice: 15 + 2 = 17, down the snake to 5 assert alice.position == 5 and game.log[-1].endswith("snake") # Landing exactly on the final square wins. sprint = Game(Board(size=10), [Player("a"), Player("b")], ScriptedDice([5, 1, 5])) sprint.play_turn() # a -> 5 sprint.play_turn() # b -> 1 assert sprint.play_turn() == "a wins" # a: 5 + 5 = 10, exactly assert sprint.status is Status.WON and sprint.winner.name == "a" print("\n".join(game.log)) print("sprint winner:", sprint.winner.name) ``` > **Remember:** a snake and a ladder are the same mechanic — a jump to a different square. One map, one lookup, and validation becomes a single check. ```knowledge-check { "questions": [ { "id": "ip45-lld-16-snl-q1", "type": "mcq", "prompt": "Why model snakes and ladders as one single `jumps: {start: end}` map instead of two separate collections?", "options": [ {"id":"a","text":"It uses less memory overall"}, {"id":"b","text":"They're really the same mechanic — a jump to a different square — differing only in direction, so one lookup handles both, and board validation (no square is both a jump's start and its destination) becomes a single check"}, {"id":"c","text":"Because ladders have to be processed before snakes"}, {"id":"d","text":"Because a player can only ever use each ladder once"} ], "correct": "b", "explanation": "Recognising that two named ideas actually share one mechanic is the real modelling insight here. Direction can always be worked out from the map itself (`end > start` means a ladder), so it doesn't need its own separate field." } ] } ``` ## Chess — polymorphic rules and extensibility Chess is the hard one here, and nobody expects you to build a full working game in 45 minutes. What actually gets expected is the **shape**: a piece hierarchy that's genuinely easy to extend, move validation kept separate from actually making the move, and a clear plan for handling the special rules. **The core decision: every piece owns its own movement rule.** This is polymorphism doing exactly the job it exists for — adding a whole new piece type (a fairy-chess variant, a custom rule set) means writing one new class, and editing nothing else at all. ```python from abc import ABC, abstractmethod from dataclasses import dataclass from enum import Enum class Colour(Enum): WHITE = "w" BLACK = "b" @dataclass(frozen=True) class Square: # a value object row: int col: int def valid(self) -> bool: return 0 <= self.row < 8 and 0 <= self.col < 8 class Piece(ABC): def __init__(self, colour: Colour): self.colour, self.has_moved = colour, False @abstractmethod def symbol(self) -> str: ... @abstractmethod def can_move(self, src: Square, dst: Square, board: "Board") -> bool: """Geometry only. Whether the path is clear, and whether it's legal, is the board's job.""" def path_clear(self, src: Square, dst: Square, board: "Board") -> bool: step_r = (dst.row > src.row) - (dst.row < src.row) # a sign: -1, 0, or 1 step_c = (dst.col > src.col) - (dst.col < src.col) r, c = src.row + step_r, src.col + step_c while (r, c) != (dst.row, dst.col): if board.at(Square(r, c)) is not None: return False r, c = r + step_r, c + step_c return True class Rook(Piece): def symbol(self): return "R" def can_move(self, src, dst, board): if src.row != dst.row and src.col != dst.col: return False return self.path_clear(src, dst, board) class Bishop(Piece): def symbol(self): return "B" def can_move(self, src, dst, board): if abs(src.row - dst.row) != abs(src.col - dst.col): return False return self.path_clear(src, dst, board) class Queen(Piece): def symbol(self): return "Q" def can_move(self, src, dst, board): straight = src.row == dst.row or src.col == dst.col diagonal = abs(src.row - dst.row) == abs(src.col - dst.col) return (straight or diagonal) and self.path_clear(src, dst, board) class Knight(Piece): def symbol(self): return "N" def can_move(self, src, dst, board): # a jump — it never has to check the path return {abs(src.row - dst.row), abs(src.col - dst.col)} == {1, 2} class King(Piece): def symbol(self): return "K" def can_move(self, src, dst, board): return max(abs(src.row - dst.row), abs(src.col - dst.col)) == 1 class Pawn(Piece): def symbol(self): return "P" def can_move(self, src, dst, board): direction = -1 if self.colour is Colour.WHITE else 1 # white moves up the array forward = dst.row - src.row sideways = abs(dst.col - src.col) target = board.at(dst) if sideways == 0 and target is None: # a straight push if forward == direction: return True return (forward == 2 * direction and not self.has_moved and board.at(Square(src.row + direction, src.col)) is None) if sideways == 1 and forward == direction: # a diagonal capture only return target is not None and target.colour is not self.colour return False class Board: def __init__(self): self._grid: dict[tuple[int, int], Piece] = {} def place(self, piece: Piece, square: Square) -> None: self._grid[(square.row, square.col)] = piece def at(self, square: Square) -> Piece | None: return self._grid.get((square.row, square.col)) def move(self, src: Square, dst: Square, turn: Colour) -> str: """The check order matters: ownership, then geometry, then the destination.""" if not (src.valid() and dst.valid()) or src == dst: raise ValueError("invalid squares") piece = self.at(src) if piece is None: raise ValueError("no piece there") if piece.colour is not turn: raise ValueError("not your piece") target = self.at(dst) if target is not None and target.colour is piece.colour: raise ValueError("cannot capture your own piece") if not piece.can_move(src, dst, self): raise ValueError(f"{piece.symbol()} cannot move like that") captured = self._grid.pop((dst.row, dst.col), None) self._grid[(dst.row, dst.col)] = self._grid.pop((src.row, src.col)) piece.has_moved = True # A real engine would now check whether the mover's own king is left in check, and undo if so. return "capture" if captured else "move" board = Board() board.place(Rook(Colour.WHITE), Square(7, 0)) board.place(Knight(Colour.WHITE), Square(7, 1)) board.place(Pawn(Colour.BLACK), Square(4, 0)) assert board.move(Square(7, 1), Square(5, 2), Colour.WHITE) == "move" # a knight's L-shape try: board.move(Square(7, 0), Square(6, 2), Colour.WHITE) # a rook can't move diagonally raise AssertionError("illegal rook move allowed") except ValueError as e: print("rejected:", e) assert board.move(Square(7, 0), Square(4, 0), Colour.WHITE) == "capture" # the rook takes the pawn try: board.move(Square(4, 0), Square(3, 1), Colour.WHITE) # still no diagonal rook moves raise AssertionError("illegal diagonal rook move allowed") except ValueError: pass print("rook now at (4,0):", board.at(Square(4, 0)).symbol()) ``` **The special rules, and exactly where each one belongs** — say this rather than trying to actually implement all of it: | Rule | Where it lives | Why not directly on the piece | |---|---|---| | **Castling** | The board or game level | It involves two pieces, whether either has moved before, and whether the squares crossed are under attack | | **En passant** | The game level | It depends on the *previous* move, which a piece has no way to see on its own | | **Promotion** | The game level, right after the move | It replaces a piece entirely — that's a board mutation, not a movement | | **Check and checkmate** | The board level | "Would this move leave my own king under attack?" is a whole-board question | | **Stalemate, the 50-move rule, repetition** | The game level | These all need the game's history, not just the current board state | The general rule worth stating: **a piece knows only its own geometry; the board knows the current position; the game knows the full history.** Any rule that needs history — en passant, castling rights, repeated positions — simply can't live on the piece, and putting it there anyway is the single most common structural mistake in this exact problem. **Detecting check is worth one sentence of algorithm**: after making a move on a copy of the board (or making it and then undoing it), ask whether any enemy piece's `can_move` reaches the king's square. Checkmate is "in check, with no legal move available." Stalemate is "not in check, with no legal move available" — the exact same move generator, just checked against a different condition. > **Remember:** a piece only knows its geometry. The board knows the current position. The game knows the history. Any rule needing history belongs at the game level. ```knowledge-check { "questions": [ { "id": "ip45-lld-16-chess-q1", "type": "mcq", "prompt": "Why can't en passant be implemented directly inside `Pawn.can_move`?", "options": [ {"id":"a","text":"Because pawns can't capture diagonally at all"}, {"id":"b","text":"Its legality depends entirely on the opponent's immediately preceding move — information the piece has no way to see. Rules that need game history belong at the game level; the piece only owns its own geometry"}, {"id":"c","text":"Because it involves two pieces of the same colour"}, {"id":"d","text":"Because it changes the size of the board"} ], "correct": "b", "explanation": "This problem's layering rule: a piece owns geometry, the board owns the current position, and the game owns history. En passant, castling rights, repeated positions, and the 50-move rule are all history-dependent, and so all of them belong at the game level." } ] } ``` ## Turn management, players, and extensions This next part applies to all three games, and it makes for a good closing section in any game-design interview. **Turn management** is just a rotating index into the player list, plus a couple of extra rules: extra turns (rolling a six) and skipped turns (three sixes, a forfeit). Keeping all of that inside one `next_turn()` method, rather than scattering `turn += 1` statements everywhere, is exactly what stops off-by-one bugs the moment those extra rules show up. **Players and bots**: give `Player` a `MoveStrategy` — `HumanInput`, `RandomBot`, `MinimaxBot`. The game loop never has to branch on "is this a bot?" at all, and adding an AI just means adding a new strategy class. This is the exact same use of Strategy as pricing was in the parking lot, just applied to a decision instead of to money. **Undo** is the **Command** pattern: every move becomes an object that knows how to both apply and reverse itself, and the game just holds a stack of them. In chess specifically, reversing a move has to restore the captured piece, the `has_moved` flags, and the en-passant square — which is exactly why storing that context on a `Move` object beats trying to recompute it afterward. **Saving and replaying a game**: store the list of moves, not the board itself. The board can always be rebuilt by replaying those moves from the starting position, which gives you undo, replay, and analysis essentially for free — this is the same event-sourcing idea from the HLD lessons, at a much smaller scale. **Multiplayer over a network** turns this into an HLD problem: a server that's the final authority on the game state, every move validated on the server (never trust the client), with the board pushed out over a WebSocket to anyone watching. > **Remember:** move selection is a Strategy, and moves themselves are Commands. That one pair gives you bots, undo, replay, and saving — all from the exact same model. ```knowledge-check { "questions": [ { "id": "ip45-lld-16-turns-q1", "type": "mcq", "prompt": "How should a game support both human players and AI bots, without any branching in the game loop itself?", "options": [ {"id":"a","text":"Subclass Game into HumanGame and BotGame"}, {"id":"b","text":"Give each Player a `MoveStrategy` (human input, a random bot, a minimax bot); the loop always just calls `player.strategy.choose_move(state)`, so adding an AI is a new strategy class with zero changes to the loop"}, {"id":"c","text":"Check `player.is_bot` before every single move"}, {"id":"d","text":"Run every bot in a separate process"} ], "correct": "b", "explanation": "Move selection is the part that actually varies, so it belongs behind an interface on the player. An `is_bot` flag is exactly the Open/Closed violation this design is meant to avoid, and subclassing the whole game duplicates everything just to vary one single decision." } ] } ``` ## Quick recap - **The board-game skeleton is reusable everywhere**: Game (turns, status), Board (geometry, cells), Player (identity plus a move strategy), Move (a value object), Rules (validation plus deciding when it's over). - **Tic-Tac-Toe is really an algorithm question wearing a game's clothes.** Running counters give you O(1) win detection; the two separate `if`s for the diagonals, and detecting a draw by move count, are exactly the details that get probed further. - **Snake & Ladder is really an edge-case question.** One `jumps` map, an explicit overshoot rule, landing exactly, an extra turn for a six, and board validation right when it's built. - **Chess is really a layering question.** Piece equals geometry, board equals position, game equals history — and every single special rule sorts cleanly into exactly one of those three. - **Move selection is a Strategy; moves themselves are Commands.** That pair gives you bots, undo, replay, and saving from the same model, and it's the strongest thing you can offer when asked "how would you extend this?" 7c:T5368,A database design interview tests a completely different muscle than an algorithms one. It's about modelling relationships correctly, knowing when spreading data across tables actually helps versus when it just gets in the way, and writing joins and subqueries fluently while someone watches. This lesson covers entity-relationship modelling, the normal forms, when it makes sense to deliberately break them, and hands-on schema and query practice using a blog as the running example. ## ER diagrams An **entity-relationship diagram** models the real things a system needs to track — entities — and how they connect to each other. In an actual interview, you'll rarely draw a real diagram. You'll describe the entities, their fields, and how they relate, either out loud or directly as a schema. **An entity is just a table** — `users`, `posts`, `comments`. **How two entities relate — their cardinality — is the single decision that shapes your whole schema:** | Cardinality | Example | What it means for the schema | |---|---|---| | One-to-one | `users` and `user_profiles` | A foreign key on either side works — usually the "detail" table holds it | | One-to-many | `users` to `posts` | The foreign key lives on the "many" side (`posts.user_id`) | | Many-to-many | `posts` and `tags` | You need a separate junction table (`post_tags`) holding both foreign keys | ```sql -- One-to-many: a user has many posts CREATE TABLE users ( id SERIAL PRIMARY KEY, username VARCHAR(50) UNIQUE NOT NULL ); CREATE TABLE posts ( id SERIAL PRIMARY KEY, user_id INTEGER NOT NULL REFERENCES users(id), title VARCHAR(255) NOT NULL, created_at TIMESTAMP DEFAULT NOW() ); -- Many-to-many: a post has many tags, and a tag applies to many posts CREATE TABLE tags ( id SERIAL PRIMARY KEY, name VARCHAR(50) UNIQUE NOT NULL ); CREATE TABLE post_tags ( post_id INTEGER NOT NULL REFERENCES posts(id), tag_id INTEGER NOT NULL REFERENCES tags(id), PRIMARY KEY (post_id, tag_id) ); ``` **Here's the tell interviewers watch for**: the moment you hear "many-to-many," you need a junction table. Trying to model it with a foreign key sitting directly on either side — say, a `tag_ids` array column — is the classic beginner mistake, and it also breaks the first normal form covered next. > **Remember:** "many-to-many" always means a junction table with two foreign keys. There's no way around it. ```knowledge-check { "questions": [ { "id": "ip45-lld-17-er-q1", "type": "mcq", "prompt": "You're modelling posts and tags, where a post can have many tags and a tag can apply to many posts. What's the right schema shape?", "options": [ {"id":"a","text":"A `tag_ids` array column directly on the `posts` table"}, {"id":"b","text":"A separate junction table, `post_tags`, holding a `post_id` and a `tag_id` together as its primary key"}, {"id":"c","text":"A `post_id` column added directly onto the `tags` table"}, {"id":"d","text":"Duplicate the tag's data into every post row that uses it"} ], "correct": "b", "explanation": "Any true many-to-many relationship needs a junction table with a foreign key pointing each way. An array column on one side is the classic beginner shortcut, and it breaks first normal form on top of everything else." } ] } ``` ## Normalization: 1NF, 2NF, 3NF Normalization is about removing repeated data by splitting it across related tables, with each normal form building directly on the one before it. **1NF (first normal form): every column holds one single, plain value.** No repeating groups, and no comma-separated lists crammed into a single cell. ```sql -- Breaks 1NF: tags crammed into one column -- posts(id, title, tags) -- tags = "tech,python,backend" -- Follows 1NF: tags broken out into their own rows, through a junction table -- posts(id, title) -- tags(id, name) -- post_tags(post_id, tag_id) ``` **2NF (second normal form): on top of 1NF, every non-key column has to depend on the *whole* primary key, not just part of it.** This one only matters when the primary key is made of more than one column. ```sql -- Breaks 2NF: order_date really only depends on order_id, not on the full (order_id, product_id) key -- order_items(order_id, product_id, quantity, order_date) -- Follows 2NF: order_date moves to a table keyed only by order_id -- orders(order_id, order_date) -- order_items(order_id, product_id, quantity) ``` **3NF (third normal form): on top of 2NF, no non-key column should depend on another non-key column.** This is called a "transitive" dependency. ```sql -- Breaks 3NF: city and zip_code depend on each other, not directly on user_id -- users(id, name, zip_code, city) -- city can be worked out from zip_code alone -- Follows 3NF: city moves to its own table, keyed by zip_code -- users(id, name, zip_code) -- zip_codes(zip_code, city) ``` | Form | The rule | What it fixes | |---|---|---| | 1NF | Plain columns, no repeating groups | Comma-separated lists, arrays used as columns | | 2NF | Non-key columns depend on the *whole* composite key | A column that only depends on part of the key | | 3NF | Non-key columns depend only on the key, never on each other | A column that's derivable from another non-key column | **In practice**: you don't have to say "this breaks 2NF" out loud every time, but you do need to design a schema that avoids these problems instinctively, and be ready to explain why a given schema is properly normalized if someone asks. > **Remember:** 1NF is atomic columns. 2NF is depending on the whole key. 3NF is not depending on another non-key column. Each one builds on the last. ```knowledge-check { "questions": [ { "id": "ip45-lld-17-normalization-q1", "type": "mcq", "prompt": "A `users` table has columns `id, name, zip_code, city`, where `city` can always be worked out from `zip_code`. Which normal form does this break?", "options": [ {"id":"a","text":"1NF, because zip_code isn't atomic"}, {"id":"b","text":"3NF — city depends on zip_code, which is itself a non-key column, rather than depending directly on the primary key. Moving city into its own table keyed by zip_code fixes it"}, {"id":"c","text":"2NF, because the primary key isn't composite here"}, {"id":"d","text":"Nothing — this is a perfectly normal design"} ], "correct": "b", "explanation": "This is exactly a transitive dependency: city depends on zip_code, and zip_code depends on the actual key (id), rather than city depending on id directly. 3NF is the rule that specifically rules this out." } ] } ``` ## Denormalization trade-offs Normalization optimizes for **correct writes and efficient storage** — update one place, with nothing duplicated anywhere. Denormalization deliberately brings some duplication back, in order to optimize for **read speed** instead, at the cost of more complicated writes and some risk of things drifting out of sync. | | Normalized | Denormalized | |---|---|---| | Writes | Simple — one single source of truth | More complex — duplicated copies have to be kept in sync | | Reads | Might need several joins | Fewer or no joins, faster on the hot read path | | Storage | Minimal duplication | Some duplication, trading space for speed | | Risk | None, from duplication at least | Data can quietly drift apart if an update misses a copy | **When it's worth denormalizing**: a read-heavy path where the cost of a join is a real, measured bottleneck. For example, storing `comment_count` directly on the `posts` table, kept up to date by a trigger or in application code whenever a comment is added or removed, instead of running `COUNT(*)` against `comments` on every single page load. This is a normal, well-understood pattern in real systems, not a mistake. It's a deliberate trade-off, and the strongest answer names exactly *why* you're accepting the extra write-side complexity, for a specific, named read-side win — rather than denormalizing out of habit. > **Remember:** denormalize only for a specific, named hot read path — and always say how you'll keep the duplicated copy in sync. ```knowledge-check { "questions": [ { "id": "ip45-lld-17-denorm-q1", "type": "mcq", "prompt": "A blog stores `comment_count` directly on the `posts` table instead of always running `COUNT(*)` on `comments`. What's the correct way to think about this?", "options": [ {"id":"a","text":"It's always a mistake, since it breaks normalization"}, {"id":"b","text":"It's a deliberate trade-off: a specific hot read path (rendering the post list) gets faster, in exchange for having to keep the duplicated count in sync on every insert or delete — and it should be named as such, not applied by default"}, {"id":"c","text":"It's required by 3NF"}, {"id":"d","text":"It only matters for tables with more than a million rows"} ], "correct": "b", "explanation": "Denormalization is a genuine engineering trade-off, not an error. The strongest answer names exactly which read path it speeds up and exactly how the duplicated value gets kept in sync — rather than treating it as either always wrong or a free lunch." } ] } ``` ## Designing a SQL schema **The interview format is usually "design a schema for X"** — a blog, an e-commerce site, a ride-sharing app. The process is the same every time: list out the entities, decide on cardinalities, normalize to 3NF as your starting point, then call out any denormalization you're deliberately choosing for a known hot path. **A worked example — a blog:** ```sql CREATE TABLE users ( id SERIAL PRIMARY KEY, username VARCHAR(50) UNIQUE NOT NULL, email VARCHAR(255) UNIQUE NOT NULL, created_at TIMESTAMP DEFAULT NOW() ); CREATE TABLE posts ( id SERIAL PRIMARY KEY, author_id INTEGER NOT NULL REFERENCES users(id), title VARCHAR(255) NOT NULL, body TEXT NOT NULL, published_at TIMESTAMP, created_at TIMESTAMP DEFAULT NOW() ); CREATE TABLE comments ( id SERIAL PRIMARY KEY, post_id INTEGER NOT NULL REFERENCES posts(id), author_id INTEGER NOT NULL REFERENCES users(id), body TEXT NOT NULL, created_at TIMESTAMP DEFAULT NOW() ); CREATE TABLE tags ( id SERIAL PRIMARY KEY, name VARCHAR(50) UNIQUE NOT NULL ); CREATE TABLE post_tags ( post_id INTEGER NOT NULL REFERENCES posts(id), tag_id INTEGER NOT NULL REFERENCES tags(id), PRIMARY KEY (post_id, tag_id) ); -- indexes for the access patterns you'll actually run CREATE INDEX idx_posts_author ON posts(author_id); CREATE INDEX idx_comments_post ON comments(post_id); ``` **Common mistakes to avoid**: forgetting foreign key constraints (`REFERENCES`), which lets orphaned rows pile up quietly; skipping indexes on foreign key columns, which turns a join on `posts.author_id` or `comments.post_id` into a full table scan; and not explicitly deciding cardinality before writing a single `CREATE TABLE` statement. Users to posts is one-to-many. Posts to tags is many-to-many. Get that settled first, and the actual table definitions follow directly from it. > **Remember:** decide every relationship's cardinality before you write a single `CREATE TABLE` statement — the tables follow directly from that decision. ```knowledge-check { "questions": [ { "id": "ip45-lld-17-schema-q1", "type": "mcq", "prompt": "You create `posts.author_id REFERENCES users(id)` but forget to add an index on `posts.author_id`. What actually happens?", "options": [ {"id":"a","text":"Nothing — foreign keys are automatically indexed by every database"}, {"id":"b","text":"A join or filter on `posts.author_id` degrades into a full table scan, since there's no index to look the value up quickly — foreign key columns need their own explicit index"}, {"id":"c","text":"The foreign key constraint itself will simply fail to be created"}, {"id":"d","text":"Inserts into `posts` become impossible"} ], "correct": "b", "explanation": "A `REFERENCES` clause enforces the relationship, but it doesn't automatically create an index for looking things up by that column. Without one, any query filtering or joining on `author_id` has to scan every single row in the table." } ] } ``` ## Writing SQL queries **Beyond just designing the schema**, you're expected to write correct, efficient queries against it. Aggregation, filtering, and ranking come up the most often. ```sql -- Posts per user, most active authors first SELECT u.username, COUNT(p.id) AS post_count FROM users u JOIN posts p ON p.author_id = u.id GROUP BY u.username ORDER BY post_count DESC; -- Users who have never posted (a LEFT JOIN plus a NULL check) SELECT u.username FROM users u LEFT JOIN posts p ON p.author_id = u.id WHERE p.id IS NULL; -- Posts with more than 5 comments SELECT p.title, COUNT(c.id) AS comment_count FROM posts p JOIN comments c ON c.post_id = p.id GROUP BY p.id, p.title HAVING COUNT(c.id) > 5; ``` **Common mistakes**: using `WHERE` when you actually mean `HAVING` to filter on an aggregate. `WHERE` filters rows *before* they're grouped; `HAVING` filters groups *after* aggregation, and the two are not interchangeable. Also worth watching: in strict SQL modes, every non-aggregated column you select has to also appear in `GROUP BY` — `p.id, p.title` above, not just `p.title` on its own. > **Remember:** `WHERE` filters rows before grouping happens. `HAVING` filters the groups afterward. They are never interchangeable. ```knowledge-check { "questions": [ { "id": "ip45-lld-17-queries-q1", "type": "mcq", "prompt": "You want posts with more than 5 comments. Why does `WHERE COUNT(c.id) > 5` fail, while `HAVING COUNT(c.id) > 5` works?", "options": [ {"id":"a","text":"`WHERE` and `HAVING` are actually interchangeable, and either one should work fine"}, {"id":"b","text":"`WHERE` filters individual rows before any grouping happens, so the aggregate `COUNT(c.id)` doesn't exist yet at that point; `HAVING` filters the groups after aggregation, once the count is available"}, {"id":"c","text":"`WHERE` only works on string columns"}, {"id":"d","text":"`COUNT` can never appear inside a `WHERE` clause for any reason"} ], "correct": "b", "explanation": "This is the single most common SQL interview slip. Aggregates like COUNT only exist after GROUP BY has run, so filtering on them has to happen in HAVING, which runs after grouping — never in WHERE, which runs before it." } ] } ``` ## Join exercises **Four join types answer four different questions about how two tables relate.** Picking the wrong one is probably the most common SQL mistake in interviews. | Join type | What it returns | Use it when | |---|---|---| | `INNER JOIN` | Only rows that have a match on both sides | You only care about pairs that exist in both tables | | `LEFT JOIN` | Every row from the left table, matched or not (`NULL` on the right if there's no match) | "Show me everything, with related data attached where it exists" | | `RIGHT JOIN` | Every row from the right table, matched or not | Rare in practice — usually just rewritten as a `LEFT JOIN` with the tables swapped | | `FULL OUTER JOIN` | Every row from both tables, matched wherever possible | You need the unmatched rows from *both* sides at once | ```sql -- INNER JOIN: only posts that actually have an author record SELECT p.title, u.username FROM posts p INNER JOIN users u ON p.author_id = u.id; -- LEFT JOIN: every post, with tag names where they exist (posts with no tags still show up) SELECT p.title, t.name FROM posts p LEFT JOIN post_tags pt ON pt.post_id = p.id LEFT JOIN tags t ON t.id = pt.tag_id; ``` **Common mistakes**: reaching for `LEFT JOIN` by default "just to be safe" when the question actually calls for an `INNER JOIN`. This quietly returns extra `NULL`-padded rows, which can silently break aggregation logic downstream — `COUNT(c.id)` will happily count a `NULL` from an unmatched `LEFT JOIN` if you forget an `IS NOT NULL` guard. Also watch for chaining several joins without checking whether each one might multiply your row count unexpectedly: joining `posts` to both `comments` and `post_tags` in the same query multiplies rows against each other, which is a classic, quiet bug. > **Remember:** an `INNER JOIN` says "only pairs that exist on both sides." A `LEFT JOIN` says "everything on the left, matched or not." Picking the wrong one silently changes your results. ```knowledge-check { "questions": [ { "id": "ip45-lld-17-joins-q1", "type": "mcq", "prompt": "You join `posts` to both `comments` and `post_tags` in one query to count comments per post. Why might the comment count come out wrong?", "options": [ {"id":"a","text":"You can never join more than two tables in one query"}, {"id":"b","text":"Joining to two separate one-to-many tables at once multiplies rows against each other — a post with 3 comments and 2 tags produces 6 joined rows, not 3, which silently inflates any COUNT you run on comments"}, {"id":"c","text":"`post_tags` has to come before `comments` in the FROM clause"}, {"id":"d","text":"LEFT JOIN can only be used once per query"} ], "correct": "b", "explanation": "Chaining joins against two independent one-to-many relationships multiplies row counts together — this is called a fan-out. It's a quiet, common bug, usually fixed by aggregating each relationship separately before combining them, or using a subquery for one side." } ] } ``` ## Subqueries **Subqueries let you filter or compute a result using another, smaller query's result set.** Sometimes it's the cleanest way to express "compare this against an aggregate." Other times, a join does the same job faster. ```sql -- Posts by the single most prolific author (a subquery inside WHERE) SELECT title FROM posts WHERE author_id = ( SELECT author_id FROM posts GROUP BY author_id ORDER BY COUNT(*) DESC LIMIT 1 ); -- Users whose post count is above the overall average SELECT u.username FROM users u WHERE ( SELECT COUNT(*) FROM posts p WHERE p.author_id = u.id ) > ( SELECT AVG(post_count) FROM ( SELECT COUNT(*) AS post_count FROM posts GROUP BY author_id ) counts ); -- The same result, written as a CTE — often easier to read than nested subqueries WITH post_counts AS ( SELECT author_id, COUNT(*) AS post_count FROM posts GROUP BY author_id ) SELECT u.username FROM users u JOIN post_counts pc ON pc.author_id = u.id WHERE pc.post_count > (SELECT AVG(post_count) FROM post_counts); ``` **Common mistakes**: writing a **correlated subquery** — one that references a value from the outer query, so it re-runs once per outer row — when an uncorrelated subquery or a plain join would do the exact same job. Correlated subqueries can genuinely become a serious performance problem on a large table, since they run over and over. It's also worth reaching for a CTE (`WITH ... AS`) whenever nested subqueries start getting hard to read, especially if the same subquery result is needed more than once in the same outer query. > **Remember:** a correlated subquery re-runs once for every single outer row. On a large table, that's a real performance problem, not just a style preference. ```knowledge-check { "questions": [ { "id": "ip45-lld-17-subquery-q1", "type": "mcq", "prompt": "Why can a correlated subquery become a serious performance problem on a large table?", "options": [ {"id":"a","text":"Correlated subqueries always return the wrong result"}, {"id":"b","text":"A correlated subquery references a value from the outer query, so the database has to re-run it once for every single outer row — on a large table that adds up fast, whereas an uncorrelated subquery or a join runs only once"}, {"id":"c","text":"Correlated subqueries can't use aggregate functions"}, {"id":"d","text":"Correlated subqueries only work inside a WHERE clause"} ], "correct": "b", "explanation": "The defining trait of a correlated subquery is that it depends on the outer row, so it has to be re-evaluated for every single one of them. An uncorrelated subquery, or an equivalent join, is computed just once and reused, which is usually far faster on a large table." } ] } ``` ## Quick recap - Relationship cardinality decides your schema's shape before you write a single line of DDL. Many-to-many always needs a junction table, and 1NF, 2NF, and 3NF build directly on each other: atomic columns first, then full-key dependency, then no dependency between two non-key columns. - Denormalization is a deliberate trade-off for a specific, named read-heavy path — never a default. Always name exactly which reads you're speeding up, and exactly how you'll keep the duplicated data in sync. - The two most common SQL slips in interviews are mixing up `WHERE` (filters rows before grouping) with `HAVING` (filters groups after aggregation), and reaching for `LEFT JOIN` "just to be safe" when an `INNER JOIN` is what the question actually calls for — which quietly changes the result and can corrupt an aggregate count. 7d:T38d5,Seventeen lessons of object modelling, principles, patterns, and worked problems only actually pay off if you can pull them back out of your head in 45 minutes, with someone watching. This lesson is the retrieval layer: the framework, tables that map a requirement straight to a design move, the exact phrases that earn points, and a drill worth running regularly until every answer feels automatic. ## The one-page map ``` FRAMEWORK (Lesson 1) Requirements → Entities → Relationships → Interfaces → Concurrency → Extensibility 45 min: 5 / 8 / 8 / 10 / 7 / 5 MODELLING (1,2) nouns → classes · verbs → methods · closed sets → ENUMS varying behaviour → INTERFACE · values → unchangeable value objects COMPOSITION over inheritance · low coupling, high cohesion the lifecycle test: composition (◆) vs aggregation (◇) PRINCIPLES (3) S one reason to change · O add classes, don't edit L subtypes must be substitutable · I no forced methods D depend on abstractions the DOMAIN owns PATTERNS (4–7) Creational : Singleton · Factory · Abstract Factory · Builder · Prototype · Object Pool Structural : Adapter · Decorator · Facade · Composite · Bridge · Proxy · Flyweight Behavioral : Strategy · Observer · Command · State · Template Method · Chain · Iterator · Mediator · Memento · Visitor CONCURRENCY (8) find the SHARED, CHANGEABLE data → stop sharing it / stop letting it change / protect access to it lock · atomic · immutable · lock ORDER for deadlock optimistic (low contention) vs pessimistic (high) vs a TTL reservation MULTI-PROCESS ⇒ the DATABASE enforces it, never an in-process lock PROBLEMS (9–17) parking lot · elevator · ticket booking · splitwise · vending machine/ATM · rate limiter/logger · notifications/cache/hashmap · games · database design ``` ```knowledge-check { "questions": [ { "id": "ip45-lld-19-map-q1", "type": "mcq", "prompt": "Which step of the LLD framework do people skip most often, and what does skipping it actually cost them?", "options": [ {"id":"a","text":"Drawing the class diagram — without it, the interviewer can't follow along"}, {"id":"b","text":"Concurrency — most candidates present a single-threaded design and then have nothing to say when asked what happens if two users act at the exact same time, which is the follow-up in nearly every LLD round"}, {"id":"c","text":"Requirements — most candidates spend far too long there"}, {"id":"d","text":"Naming the classes"} ], "correct": "b", "explanation": "Concurrency is both the step people skip the most and the follow-up interviewers ask the most reliably. Volunteering \"the shared, changeable data here is X, and it's protected by Y\" before anyone even asks is one of the cheapest ways to stand out." } ] } ``` ## Requirement → design move Run this table in your head while the interviewer is still talking. | What you hear | What it actually means | |---|---| | "...and we might add more types later" | An enum plus polymorphism, or a registry-backed factory | | "...the pricing or rules might change" | A **Strategy** interface | | "...when X happens, also do Y and Z" | **Observer** | | "...it can be in one of these states" | The **State** pattern, or just an enum plus a transition table | | "...support undo" | **Command** (plus Memento for snapshots) | | "...run the request through these steps" | **Chain of Responsibility** | | "...it's a tree, or has nested groups" | **Composite** | | "...integrate with this third-party API" | **Adapter** (plus **Decorator** for retry) | | "...this is expensive to build" | A lazy **Proxy**, an **Object Pool**, or **Flyweight** | | "...lots of optional parameters" | **Builder** | | "...exactly one of these should ever exist" | One instance, **injected** — not a global Singleton | | "...two users do this at the same moment" | Name the shared data; a lock, an atomic operation, or a conditional database write | | "...the user takes minutes to finish this" | A **reservation with a TTL**, never a held lock | | "...this involves money" | Whole minor units, unchangeable ledger entries, calculated balances | | "...we run on several servers" | A unique constraint or a conditional `UPDATE` — in-process locks are useless here | | "...we need history or an audit trail" | Unchangeable records; corrections are new entries, never edits | ```knowledge-check { "questions": [ { "id": "ip45-lld-19-mapping-q1", "type": "mcq", "prompt": "The interviewer says: \"a user selects seats, then has five minutes to pay.\" What's the design move here?", "options": [ {"id":"a","text":"Hold a database row lock for the whole five minutes"}, {"id":"b","text":"A reservation with an expiry timestamp — the seat moves into a HELD state with a `held_until` field, so an abandoned checkout releases itself automatically, and no lock is held across a delay that long"}, {"id":"c","text":"An optimistic version check, done only at payment time"}, {"id":"d","text":"A distributed Redis lock with a five-minute TTL"} ], "correct": "b", "explanation": "Delays measured in human time rule out held locks — they'd serialise the whole system and leak whenever someone abandons checkout. The expiry makes abandonment self-healing, and the actual anti-double-booking guarantee still comes from the conditional write plus the unique constraint." } ] } ``` ## The phrases that earn points Rehearse these until they're automatic — under pressure, you tend to say whatever you've already practiced saying. 1. "Before I model anything — what varies here, and what's fixed?" 2. "I'll scope to X and Y. I'll define an interface for Z, but I won't implement it." 3. "That's a closed set, so it's an enum — and specifically an enum instead of a boolean, because a third state is coming." 4. "These two things vary independently, so composition instead of inheritance — otherwise I'd need a class per combination." 5. "This is composition, not aggregation: destroy the floor, and the spots stop meaning anything." 6. "I'm putting pricing behind an interface, because you said the scheme is going to change." 7. "The shared, changeable data here is the free-seat set, and it's protected by a conditional write." 8. "An in-process lock won't survive a second server — the invariant has to live in the database." 9. "Illegal transitions become impossible to write by accident, because each state class only defines the moves it actually allows." 10. "That's a cross-cutting concern, so a decorator around the channel, rather than code copy-pasted into every channel." 11. "Money is stored as whole paise, and the split has an explicit rule for leftover remainders, so the shares always add up exactly to the total." 12. "If we add a new type, that's one new class with zero edits — here's the walkthrough." **And the anti-patterns worth catching yourself doing**: naming a pattern before naming the actual problem, a `Manager`/`Helper` god class, getters and setters standing in for real behaviour, inheritance used purely for code reuse, booleans where an enum belongs, an interface with one implementation and no realistic second one, and going silent while you think instead of narrating out loud. ```knowledge-check { "questions": [ { "id": "ip45-lld-19-phrases-q1", "type": "mcq", "prompt": "Which of these statements would most likely count against you in an interview?", "options": [ {"id":"a","text":"\"I'll keep this concrete for now — if a second pricing rule shows up, this is exactly where the strategy would go.\""}, {"id":"b","text":"\"I'll add an interface, an abstract factory, and a strategy for this one concrete class, just to keep the design flexible.\""}, {"id":"c","text":"\"The shared, changeable data here is the inventory count, and it's protected by a conditional UPDATE.\""}, {"id":"d","text":"\"This is aggregation, not composition — the songs outlive the playlist.\""} ], "correct": "b", "explanation": "Adding abstraction with no real axis of variation is the most common mistake people make right after learning these patterns. Deliberately staying concrete while naming exactly where the extension point would go, like option (a), is the stronger, more senior answer." } ] } ``` ## The weekly recall drill Answer these out loud, from memory, in under five seconds each. The number in brackets is the lesson to check yourself against. **Round 1 — framework and modelling** 1. The six steps of an LLD interview, and roughly how many minutes each gets. [1] 2. The four things a noun can turn into. [1] 3. The lifecycle test for telling composition from aggregation. [1] 4. Why prefer an enum over a boolean flag. [1] 5. Encapsulation versus abstraction, in one sentence each. [2] 6. Two reasons composition beats inheritance. [2] 7. Name three design smells and their fixes. [2] 8. Interface versus abstract class — when to use each. [2] **Round 2 — principles** 9. Each SOLID letter, plus the warning sign that reveals its violation. [3] 10. Why does `Square extends Rectangle` break Liskov Substitution? [3] 11. The practical tell for an Interface Segregation violation. [3] 12. Which layer should own the repository interface, and why? [3] **Round 3 — patterns** 13. Adapter versus Facade. [5] 14. Decorator versus Proxy. [5] 15. Strategy versus State. [6] 16. Strategy versus Template Method. [6] 17. When is Visitor the right call, and what does it cost you? [7] 18. Two things Command makes possible, besides undo. [6] 19. Why does Singleton get criticised, and what's preferred instead? [4] 20. What has to be true for Flyweight to actually be safe? [5] **Round 4 — concurrency** 21. The three shapes a race condition can take. [8] 22. Why thread-safe methods don't add up to a thread-safe sequence. [8] 23. The four Coffman conditions, and which one you actually break in practice. [8] 24. Optimistic versus pessimistic locking — decided by what? [8] 25. What actually prevents double-booking across five servers? [8] **Round 5 — problems** 26. Parking lot: the two extension points. [9] 27. Elevator: why two direction-based sets of stops, and what LOOK does. [10] 28. Booking: why `Seat` and `ShowSeat` are separate classes. [11] 29. Splitwise: the three money rules, and the bound on the settlement algorithm. [12] 30. Vending machine: what happens when exact change isn't possible. [13] 31. ATM: when is greedy note selection actually wrong? [13] 32. Rate limiter: the four algorithms, and which one is the default. [14] 33. Logger: why check the level before formatting the message? [14] 34. LRU: which two data structures, and why each one is needed. [15] 35. Chess: which layer owns en passant, and why? [16] **Round 6 — apply it.** Pick a problem you haven't designed before — food delivery, a car rental system, a library system, a hotel booking system, a coffee machine, an online judge, a chat app, a URL shortener at the class level — and give yourself **fifteen minutes**: requirements and scope, entities with their kind, a class diagram, real method signatures on the core classes, the shared changeable data and how it's protected, and one extension walked through out loud. No notes. Do one of these a week. Every single one of those is really just a recombination of what's already in this section: an allocator (the parking lot), a lifecycle (the vending machine), a reservation (booking), a pricing strategy, a notification observer, and a repository interface. ```knowledge-check { "questions": [ { "id": "ip45-lld-19-drill-q1", "type": "mcq", "prompt": "You're asked to design a food-delivery system's classes, and you've never specifically prepared for that exact problem. What's the most reliable way to approach it?", "options": [ {"id":"a","text":"Recall the closest problem you've memorised and just reuse its classes"}, {"id":"b","text":"Run the six-step framework and recombine building blocks you already know: an order lifecycle (State), rider assignment (an allocation Strategy), surge pricing (Strategy), status updates (Observer), inventory holds (a reservation with a TTL), and persistence behind repository interfaces"}, {"id":"c","text":"Start by listing every design pattern that might possibly apply"}, {"id":"d","text":"Ask the interviewer to switch to a problem you've already prepared"} ], "correct": "b", "explanation": "Every new LLD problem is really a recombination of the same handful of building blocks. The framework guarantees you cover requirements, entities, relationships, interfaces, concurrency, and extensibility no matter what the domain is — which is exactly why the procedure beats memorising specific answers." } ] } ``` ## Quick recap - **Procedure beats memorisation.** The six steps, and the requirement-to-design-move table, are exactly what let you handle a problem you've genuinely never seen before. - **Every design decision comes with a cost — say it out loud.** "Composition here, because these two things vary independently — the cost is one more object to wire together" is what a real design review actually sounds like. - **Concurrency is the step people skip the most, and the one asked about the most.** Name the shared, changeable data and how it's protected before anyone asks, and remember that only the database enforces anything across separate servers. - **Restraint is itself a senior-level signal.** After going through a whole pattern catalogue, deliberately staying concrete and naming exactly where the extension point *would* go beats abstracting everything on reflex. - **Practice out loud, on a timer, every week.** Fifteen minutes on an unfamiliar problem, using nothing but the framework and the building blocks from lessons 9 through 16. 7e:T2bd2,You write `x = []` and never call `malloc` or `free`. Something behind the scenes is deciding when that list's memory gets handed back. This lesson is about that something: how Python creates objects, how it knows when to destroy them, and why a plain loop that "should" be fast sometimes still copies a million numbers it never needed. ## Reference counting: the main way objects get freed Picture a library book with a card in the back listing everyone who's currently borrowing it. As long as one name is on that card, the book stays on someone's shelf. The moment the last name is crossed off, the book goes back to the library immediately, no waiting for a scheduled cleanup. Every Python object carries that card: a counter called `ob_refcnt`. Every time a variable, a list, or a dict holds a reference to the object, the counter goes up by one. Every time a reference goes away, it goes down by one. The instant it hits zero, Python frees the object right then, not on some later pass. ```python import sys x = [] sys.getrefcount(x) # 2: your variable x, plus the temporary argument to getrefcount itself del x # refcount drops to 0 -> freed immediately ``` This is why Python memory management feels instant most of the time: no separate "garbage collector thread" has to run before that empty list's memory comes back. > **Remember:** an object is freed the instant its reference count hits zero. That is deterministic, not scheduled. ```knowledge-check { "questions": [ { "id": "backend-python-how-python-runs-refcount-q1", "type": "mcq", "prompt": "When is an object's memory freed under Python's reference counting?", "options": [ {"id":"a","text":"On a fixed schedule, every few seconds"}, {"id":"b","text":"The instant its reference count reaches zero"}, {"id":"c","text":"Only when the program exits"}, {"id":"d","text":"Only when you call gc.collect()"} ], "correct": "b", "explanation": "Reference counting frees an object immediately once nothing points to it anymore. There is no wait for a scheduled pass." } ] } ``` ## Reference cycles: the case counting alone can't catch Now picture two people who each hold the only key to the other's storage unit. Neither unit can ever be opened by anyone else, and neither key-holder will ever give up their key, since each is waiting on the other. Both units sit locked forever, useless, even though no one outside actually needs them. ```python a = {} b = {} a["ref"] = b b["ref"] = a del a del b # Both dicts still have refcount 1: they point at each other. # Neither is reachable from your code anymore, but neither ever hits 0. ``` After both `del` lines run, the names `a` and `b` are gone, but the two dict objects still hold a reference to each other. Reference counting alone would leak this pair forever. That's exactly the gap Python's second mechanism, the cyclic garbage collector, exists to close. The cyclic collector tracks every container object (dicts, lists, class instances, anything that could form a cycle) and, from time to time, asks a sharper question than plain refcounting can: for each tracked object, subtract one reference for every link that comes from *another tracked object in the group*. What's left is the count of references reaching it from outside the group. In the `a`/`b` example, both real refcounts are 1, and subtracting the one internal link each holds on the other brings both down to 0. Nothing outside the pair references either dict, so the collector frees both. > **Remember:** reference counting alone never frees a cycle. The cyclic collector runs separately to catch exactly that case. ```knowledge-check { "questions": [ { "id": "backend-python-how-python-runs-cycles-q1", "type": "mcq", "prompt": "Two dicts reference each other and nothing else references either one. What happens under plain reference counting alone?", "options": [ {"id":"a","text":"Both are freed immediately, since del was called on both"}, {"id":"b","text":"Neither is freed: each still has a refcount of 1 from the other, so counting alone leaks the pair"}, {"id":"c","text":"Python raises an error"}, {"id":"d","text":"Only the first one deleted is freed"} ], "correct": "b", "explanation": "Each dict's refcount never reaches zero because the other dict still points to it. This is exactly the case the cyclic garbage collector exists to detect and clean up." } ] } ``` ## Generational collection: why scanning can stay cheap Most objects in a running program are short-lived: a loop counter, a temporary list built inside one function call, a string used once and thrown away. Python leans on this pattern instead of fighting it. Every new object starts in "generation 0." If a GC pass finds it still alive, it's promoted to generation 1, checked less often. Survive another pass, and it moves to generation 2, the long-lived bucket, checked rarely. ```python import gc print(gc.get_threshold()) # (700, 10, 10) # Gen 0 is checked after about 700 net allocations # Gen 1 is checked after Gen 0 has run 10 times # Gen 2 is checked after Gen 1 has run 10 times ``` Since the vast majority of objects die in generation 0, checking that small, fast-turnover bucket often catches most garbage cheaply. Long-lived objects, like a cache built once at startup, get scanned rarely once they earn their way into generation 2, so the collector never pays to re-check them on every pass. > **Remember:** most objects die young, so Python checks new objects often and old objects rarely. That's the whole idea behind generations. ```knowledge-check { "questions": [ { "id": "backend-python-how-python-runs-generations-q1", "type": "mcq", "prompt": "Why does Python's garbage collector check generation 0 far more often than generation 2?", "options": [ {"id":"a","text":"Generation 0 objects are bigger and need closer watching"}, {"id":"b","text":"Most objects die young, so checking new objects often catches most garbage cheaply, while rarely re-scanning objects that have already proven long-lived saves work"}, {"id":"c","text":"Generation 2 is checked more often, not less"}, {"id":"d","text":"The generations are checked in a fixed round-robin with no difference in frequency"} ], "correct": "b", "explanation": "This is the weak generational hypothesis: most allocations are short-lived. Scanning the young generation frequently is cheap and catches most garbage; scanning survivors rarely avoids wasted work." } ] } ``` ## PyMalloc and the GIL For small objects, 512 bytes or less, Python doesn't call the operating system's allocator every time. It keeps its own pool of pre-reserved memory (arenas, split into pools, split into blocks) and hands pieces out from there. That's why Python sometimes seems to hold onto memory even after you've deleted a lot of objects: it's keeping that space ready for the next small object instead of giving it back to the OS immediately, trading "give memory back right away" for "avoid a slow system call on every tiny allocation." The Global Interpreter Lock (GIL) exists mainly to protect that `ob_refcnt` counter from every object. If two threads could both decrement the same object's refcount at the same instant, both might see it drop to zero and both might try to free it, a double-free that corrupts memory. The GIL makes sure only one thread touches Python objects at a time, which is also the mechanical reason CPU-heavy work needs `multiprocessing` (separate processes, each with its own interpreter and its own GIL) instead of `threading` to actually run in parallel. | Question | Answer | |---|---| | How do you find a memory leak? | `tracemalloc` (built in) or `objgraph` (shows you the reference graph) | | How do you force cleanup? | `del` drops your reference; `gc.collect()` forces an extra cyclic-GC pass | | What's a weak reference? | `weakref` holds a pointer to an object without bumping its refcount, so it doesn't keep the object alive. Used for caches that shouldn't block cleanup | > **Remember:** the GIL's core job is keeping refcount updates thread-safe. That's why CPU-bound work needs separate processes, not just separate threads, to use more than one core. ```knowledge-check { "questions": [ { "id": "backend-python-how-python-runs-gil-q1", "type": "mcq", "prompt": "Why does CPython need the GIL to keep only one thread running Python bytecode at a time?", "options": [ {"id":"a","text":"Because Python is an interpreted language, and interpreted languages can never run in parallel"}, {"id":"b","text":"To keep every object's reference count update thread-safe; without it, two threads could race to decrement the same counter to zero and both try to free the object"}, {"id":"c","text":"To make single-threaded programs run faster"}, {"id":"d","text":"It's only a historical artifact with no real technical reason today"} ], "correct": "b", "explanation": "Two threads racing on the same ob_refcnt could both read 1, both decrement to 0, and both free the same object: a double-free. The GIL prevents that race, at the cost of true parallel execution of Python bytecode." } ] } ``` ## range vs xrange: a warm-up question Python 2 had two ways to loop over numbers. `range()` built the entire list up front: `range(1000000)` allocated a million integers before the loop even started. `xrange()` produced one number at a time, on demand, so memory stayed flat no matter how big the range was. ``` for i in range(1000000): pass # Python 2: builds a full list of a million ints first for i in xrange(1000000): pass # Python 2: never holds more than one int at a time ``` Python 3 removed `xrange` because it made `range()` itself lazy: it now returns a `range` object that produces values on demand, exactly like Python 2's `xrange` did. Calling `list(range(...))` still builds the eager list, when you actually want one. | | Python 2 `range()` | Python 2 `xrange()` | Python 3 `range()` | |---|---|---|---| | Returns | Full list | Lazy generator-like object | Lazy range object | | Memory | High | Low | Low | > **Remember:** Python 3 made `range` lazy, which is exactly what `xrange` used to be for, so `xrange` had nothing left to do and was removed. ```knowledge-check { "questions": [ { "id": "backend-python-how-python-runs-range-q1", "type": "mcq", "prompt": "Why doesn't Python 3 have xrange anymore?", "options": [ {"id":"a","text":"xrange was removed for being too slow"}, {"id":"b","text":"Python 3's range() itself became lazy, doing exactly what xrange used to do, so a separate function was no longer needed"}, {"id":"c","text":"Lists were removed from Python 3 entirely"}, {"id":"d","text":"xrange still exists in Python 3 under a new name, list()"} ], "correct": "b", "explanation": "Python 2's range() built a full list eagerly; xrange() was the lazy alternative. Python 3 made range() lazy by default, so xrange became redundant and was dropped." } ] } ``` 7f:T2ec7,Four things almost every Python interview opens with, because each one is quick to ask and quick to spot a gap in: closures, context managers, generators, and how Python decides which variable you mean when a name could refer to several. ## Closures: a function that remembers where it came from Picture a locker that comes pre-loaded with a note only that locker can read, even after the person who wrote the note has gone home. A closure is that: an inner function that keeps a live link to a variable from the function that created it, even after that outer function has already finished running. ```python def make_multiplier(factor): def multiply(x): return x * factor # 'factor' is remembered, not copied return multiply double = make_multiplier(2) triple = make_multiplier(3) double(5) # 10 triple(5) # 15 ``` `make_multiplier(2)` runs once, creates a little box (a "cell") holding `2`, and hands back `multiply` with that box attached. Every later call to `double(x)` reads from that same box. It never re-reads anything from `make_multiplier`'s call, which already ended. That's why `double` and `triple` behave differently even though they're built from the exact same code. The classic trap: a closure captures the *variable*, not its value at the moment the closure was made. ```python funcs = [lambda: i for i in range(3)] [f() for f in funcs] # [2, 2, 2] -- all three lambdas share the same 'i' box funcs = [lambda i=i: i for i in range(3)] # fix: copy the current value into a default argument [f() for f in funcs] # [0, 1, 2] ``` All three lambdas in the broken version share one `i` box, and by the time any of them runs, the loop is over and `i` is stuck at `2`. The fix works because default argument values are copied in at function-definition time, once per lambda, so `i=i` freezes that loop's current value instead of leaving it as a shared, still-changing variable. > **Remember:** a closure keeps a live link to a variable, not a snapshot of its value. A loop variable in a closure needs a default argument to freeze it. **Common mistake:** building a list of callbacks inside a loop and expecting each one to remember "its" iteration's value without the `i=i` fix. ```knowledge-check { "questions": [ { "id": "backend-python-functions-closures-q1", "type": "mcq", "prompt": "Three lambdas are built inside `for i in range(3): funcs.append(lambda: i)`. Calling all three afterward prints what?", "options": [ {"id":"a","text":"0, 1, 2 -- each remembers its own iteration"}, {"id":"b","text":"2, 2, 2 -- all three share the same variable, which ends at 2"}, {"id":"c","text":"A crash, since i no longer exists after the loop"}, {"id":"d","text":"0, 0, 0"} ], "correct": "b", "explanation": "A closure captures the variable itself, not a frozen value. All three lambdas share one 'i' cell, which holds 2 by the time the loop finishes and any lambda is called." } ] } ``` ## Context managers: guaranteed setup and cleanup A context manager is an object that sets something up before your code runs and tears it down afterward, no matter what, even if your code raises an exception halfway through. ```python with open("file.txt") as f: data = f.read() # file is closed here even if .read() raised ``` You can write your own two ways. Class-based, with `__enter__`/`__exit__`: ```python class Timer: def __enter__(self): self.start = time.time() return self def __exit__(self, exc_type, exc_val, exc_tb): print(f"Elapsed: {time.time() - self.start:.3f}s") return False # False/None re-raises any exception; True would swallow it with Timer(): do_work() ``` Or function-based, with `@contextmanager`, which is usually less code for a one-off: ```python from contextlib import contextmanager @contextmanager def timer(): start = time.time() yield # the code inside the `with` block runs here print(f"Elapsed: {time.time() - start:.3f}s") with timer(): do_work() ``` Everything before `yield` plays the role of `__enter__`; everything after plays `__exit__`. Entering `with timer():` runs `timer()` up to `yield`, then `do_work()` runs as the body, then execution resumes right after `yield` to print the elapsed time. Common real uses: `open()` for files, `threading.Lock()` for acquiring and releasing a lock, a database connection for connect and disconnect, `unittest.mock.patch` for patching and restoring. Watch the `__exit__` return value: `True` silently swallows any exception raised inside the block, which is rarely what you want. > **Remember:** everything before `yield` in a `@contextmanager` function is setup; everything after is cleanup, and cleanup still needs a `try/finally` around the `yield` if it must run even on error. ```knowledge-check { "questions": [ { "id": "backend-python-functions-contextmanagers-q1", "type": "mcq", "prompt": "A class's __exit__ method returns True. What effect does that have?", "options": [ {"id":"a","text":"It has no effect on exception handling"}, {"id":"b","text":"It swallows any exception raised inside the with block, so it never propagates"}, {"id":"c","text":"It forces the exception to re-raise with extra detail"}, {"id":"d","text":"It restarts the with block from the beginning"} ], "correct": "b", "explanation": "Returning True from __exit__ tells Python the exception was handled and should not propagate further. Returning False or None lets it re-raise normally, which is what you want unless you deliberately mean to suppress it." } ] } ``` ## Generators: values produced one at a time A generator is a function that hands out a lazy sequence of values with `yield`, instead of building and returning the whole list up front. Nothing runs until the caller actually asks for the next value. ```python def squares(n): for i in range(n): yield i * i gen = squares(5) next(gen) # 0 -- nothing beyond this has run yet next(gen) # 1 total = sum(x * x for x in range(10_000_000)) # generator expression: no full list ever built ``` Calling `squares(5)` doesn't run the function body at all, it just creates a generator object. The first `next(gen)` runs up to the first `yield`, producing `0`, then pauses exactly there. The second `next(gen)` resumes right after that `yield` and continues the loop to `i = 1`. The payoff is memory, not raw speed: `sum(x*x for x in range(10_000_000))` never holds ten million values at once, unlike the equivalent list comprehension. > **Remember:** a generator computes the next value only when asked. Use one whenever you'd otherwise build a huge list just to loop over it once. ```knowledge-check { "questions": [ { "id": "backend-python-functions-generators-q1", "type": "mcq", "prompt": "What is the main reason to use a generator expression instead of a list comprehension for summing ten million squared numbers?", "options": [ {"id":"a","text":"Generators always compute faster than list comprehensions"}, {"id":"b","text":"A generator never holds all ten million values in memory at once; it produces and consumes one at a time"}, {"id":"c","text":"Generators can hold more precision than lists"}, {"id":"d","text":"There is no real difference between the two"} ], "correct": "b", "explanation": "A list comprehension builds the full list before summing it. A generator expression produces one value at a time, so peak memory use stays flat regardless of how many values there are." } ] } ``` ## LEGB: how Python finds a name When your code uses a name, Python checks four scopes, in this order: **L**ocal (inside the current function), **E**nclosing (any function this one is nested inside), **G**lobal (the module level), **B**uilt-in (Python's own names like `len`). The first scope where the name exists wins. ```python x = "global" def outer(): x = "enclosing" def inner(): x = "local" print(x) # "local" -- found immediately in Local scope inner() outer() ``` Writing to an outer scope, rather than just reading it, needs an explicit declaration. This is the part people forget under pressure: ```python count = 0 def increment(): global count # without this, 'count += 1' raises UnboundLocalError count += 1 ``` Without `global count`, Python sees the assignment `count += 1` anywhere in the function body and decides, before the function even runs, that `count` is a local variable for the whole function. That makes the *read* half of `count += 1` fail, since the local `count` was never assigned before that line runs. `nonlocal` does the same job one level up: it lets a nested function write to its *enclosing* function's variable, not the global one. > **Remember:** Python looks up a name Local, then Enclosing, then Global, then Built-in. Writing to an outer scope needs `global` or `nonlocal`; reading it does not. ```knowledge-check { "questions": [ { "id": "backend-python-functions-legb-q1", "type": "mcq", "prompt": "A function does `count += 1` on a variable defined outside it, without declaring `global count`. What happens?", "options": [ {"id":"a","text":"It silently updates the outer count"}, {"id":"b","text":"UnboundLocalError, because the assignment makes Python treat count as local for the whole function, and that local was never assigned before the read"}, {"id":"c","text":"It creates a second global variable with the same name"}, {"id":"d","text":"Nothing happens; the line is skipped"} ], "correct": "b", "explanation": "Any assignment to a name inside a function marks that name local for the entire function body, decided before the function runs. That breaks the read half of count += 1 unless global count says otherwise." } ] } ``` ## The mutable default argument trap ```python def add_item(item, cart=[]): # the list is created ONCE, when the function is defined cart.append(item) return cart add_item("apple") # ['apple'] add_item("banana") # ['apple', 'banana'] -- the SAME list from before ``` Default argument values are evaluated once, when the `def` line runs, not once per call. So `[]` here is a single list object, shared and mutated by every call that doesn't pass its own `cart`. ```python def add_item(item, cart=None): # sentinel default; a fresh list is built inside the call if cart is None: cart = [] cart.append(item) return cart ``` `None` is a safe, immutable default. Inside the function, a brand-new list is created on every call that didn't supply its own, so callers stop unknowingly sharing state. > **Remember:** a mutable default argument is created once at definition time and shared across every call. Use `None` as the default and build the real value inside the function. ```knowledge-check { "questions": [ { "id": "backend-python-functions-mutabledefault-q1", "type": "mcq", "prompt": "Why does `def add_item(item, cart=[]):` cause items from earlier, unrelated calls to show up in a later call's result?", "options": [ {"id":"a","text":"Lists in Python are always shared between all functions"}, {"id":"b","text":"The empty list is created once when the function is defined, and every call that skips the cart argument reuses and mutates that same list"}, {"id":"c","text":"Python resets all default arguments after every call, so this should never happen"}, {"id":"d","text":"append() copies the list before adding to it"} ], "correct": "b", "explanation": "Default values are evaluated exactly once, at def time. A mutable default like [] becomes one shared object across every call that relies on the default, which is why state leaks between unrelated calls." } ] } ``` 80:T236c,A class interview usually opens with "explain the three kinds of methods," moves to "what happens when two parents share a grandparent," and sometimes ends with "what is a metaclass, and have you ever needed one." All three build on the same idea: a class is just an object too, with its own rules for how names are looked up. ## Instance, class, and static methods ```python class Pizza: total_made = 0 def __init__(self, toppings): self.toppings = toppings Pizza.total_made += 1 def describe(self): # instance method: needs self return f"Pizza with {', '.join(self.toppings)}" @classmethod def margherita(cls): # classmethod: needs cls, not an instance return cls(["tomato", "mozzarella"]) # cls() so subclasses get the right type @staticmethod def is_valid_topping(name): # staticmethod: needs neither return name in {"tomato", "mozzarella", "basil", "pepperoni"} ``` An **instance method** takes `self` and works on one object's own data. It's the default, called as `instance.method()`. A **classmethod** takes `cls` and works on the class as a whole, not one particular object. The textbook use is an alternate constructor: `Pizza.margherita()` builds a pizza without the caller needing to know the topping list. Using `cls(...)` instead of hardcoding `Pizza(...)` matters for inheritance: if a `Margherita` subclass calls `Margherita.margherita()`, `cls` is bound to `Margherita`, so `cls(...)` correctly builds a `Margherita`. Had the method hardcoded `Pizza(...)`, every subclass calling this constructor would quietly get back a plain `Pizza` instead. A **staticmethod** takes neither. It's a plain function that happens to live inside the class because it's related, like `is_valid_topping` above. It's a label for readers, not a mechanism with special binding. > **Remember:** if the method needs one object's data, it's an instance method. If it needs the class but not one object (an alternate constructor), it's a classmethod. If it needs neither, it's a staticmethod, or arguably just a module-level function. ```knowledge-check { "questions": [ { "id": "backend-python-classes-methodtypes-q1", "type": "mcq", "prompt": "A classmethod alternate constructor uses cls(...) instead of hardcoding the class name. Why does that matter?", "options": [ {"id":"a","text":"It doesn't matter; both are always identical"}, {"id":"b","text":"When a subclass calls the inherited classmethod, cls is bound to the subclass, so cls(...) builds an instance of the subclass instead of always building the parent"}, {"id":"c","text":"cls() runs faster than calling the class name directly"}, {"id":"d","text":"Hardcoding the class name is required for classmethods to work at all"} ], "correct": "b", "explanation": "cls is bound to whichever class the method was actually called through. Using cls(...) lets an inherited alternate constructor correctly build the subclass, not silently fall back to the parent class." } ] } ``` ## Method Resolution Order (MRO) When a class inherits from two parents that share a common ancestor, Python needs one deterministic rule for which parent's method wins when you call `super()`. That rule is called C3 linearization, and the order it produces is the class's MRO. ```python class Base: def greet(self): return "Base" class Left(Base): def greet(self): return f"Left -> {super().greet()}" class Right(Base): def greet(self): return f"Right -> {super().greet()}" class Diamond(Left, Right): def greet(self): return f"Diamond -> {super().greet()}" d = Diamond() print(d.greet()) # Diamond -> Left -> Right -> Base print(Diamond.__mro__) # (Diamond, Left, Right, Base, object) ``` Tracing `d.greet()`: `Diamond.greet` calls `super().greet()`, which does not mean "my direct parent," it means "the next class after `Diamond` in the MRO," which is `Left`. `Left.greet` runs and calls `super().greet()` again, landing on `Right` (the next class after `Left`). `Right.greet` calls `super().greet()` once more, landing on `Base`, which returns `"Base"` with no further `super()` call. The calls unwind back up to build the full string. Notice `Base.greet` runs exactly once, even though both `Left` and `Right` inherit from it: C3 linearization visits each class only once, which is exactly what solves the diamond problem. A naive "check my parents in order, depth-first" search would call `Base.greet` twice. Two guarantees make the MRO predictable instead of arbitrary: a class always comes before its own parents, and parents are checked in the order they're listed (`Left` before `Right`, since `class Diamond(Left, Right)` lists them that way). If Python can't compute a consistent order, for example one base requires `A` before `B` while another requires the opposite, it raises `TypeError: Cannot create a consistent method resolution order` at class-definition time, rather than silently guessing. > **Remember:** `super()` means "the next class in the MRO," not "my direct parent." That's what lets every class call `super()` and still visit each ancestor exactly once. ```knowledge-check { "questions": [ { "id": "backend-python-classes-mro-q1", "type": "mcq", "prompt": "class Diamond(Left, Right) where both Left and Right inherit from Base. How many times does Base's method run when Diamond calls it through a chain of super() calls?", "options": [ {"id":"a","text":"Twice, once through each parent"}, {"id":"b","text":"Exactly once, because C3 linearization visits each class in the MRO only one time"}, {"id":"c","text":"Zero times, because Diamond overrides it"}, {"id":"d","text":"It depends on the order Left and Right are listed"} ], "correct": "b", "explanation": "The whole point of C3 linearization is producing one order where each ancestor appears exactly once, which is what actually solves the diamond problem: a naive depth-first search would call Base's method twice." } ] } ``` ## Metaclasses: a blueprint for classes A class is a blueprint for objects. A metaclass is a blueprint for classes. In Python, classes are themselves objects: every class is an instance of some metaclass, and by default that metaclass is `type`. ```python class Dog: pass print(type(Dog)) # print(type(42)) # ``` `Dog` is an instance of `type`, the same way `42` is an instance of `int`. Writing `class Dog: ...` internally calls `type` to build the class object. You can write a custom metaclass by subclassing `type` and overriding `__new__`, which runs when the class itself is being created: ```python class UpperMeta(type): def __new__(mcs, name, bases, attrs): name = name.upper() return super().__new__(mcs, name, bases, attrs) class dog(metaclass=UpperMeta): pass print(dog.__name__) # DOG ``` This explains framework "magic" you'll run into constantly: Django's ORM `Model` class uses a metaclass to scan its own class attributes (`CharField`, `IntegerField`, and so on) at class-definition time and register them as table columns. Pydantic (which FastAPI uses) does something similar to build validation and schema generation from annotated fields. The most practical everyday use is `abc.ABCMeta`, for enforcing an interface: ```python from abc import ABC, abstractmethod class PaymentGateway(ABC): @abstractmethod def charge(self, amount: float): pass class StripeGateway(PaymentGateway): def charge(self, amount: float): print(f"Charging {amount} via Stripe") # Forgetting to implement charge() raises TypeError at instantiation, # not at some unrelated point at runtime. ``` You'll rarely write one in application code. If a decorator or `__init_subclass__` (a simpler hook that runs when a class is subclassed, without the full metaclass machinery) solves the problem, prefer that instead. Recognizing a metaclass explains a lot of "how does this framework know about my fields" moments, even if you never write your own. > **Remember:** every class is an instance of `type` unless told otherwise. A metaclass controls how the class object itself gets built, which is exactly how Django and Pydantic turn plain class bodies into working schemas. ```knowledge-check { "questions": [ { "id": "backend-python-classes-metaclass-q1", "type": "mcq", "prompt": "What is the default metaclass for every class in Python that doesn't specify one?", "options": [ {"id":"a","text":"object"}, {"id":"b","text":"type"}, {"id":"c","text":"ABCMeta"}, {"id":"d","text":"There is no default; a metaclass must always be specified"} ], "correct": "b", "explanation": "Every class, unless you say otherwise, is an instance of type. Writing class Dog: ... internally calls type to actually construct the Dog class object." } ] } ``` 81:T2b76,A senior Python developer doesn't ask "does the standard library have this," they already know which module to reach for. This lesson is a reference to build that reflex, plus a close look at one specific module, `pickle`, that comes with a real security trap. ## Data structures and iteration you should reach for by name **`collections`** - `defaultdict`: a dict that supplies a default value for a missing key instead of raising `KeyError`, so you skip the explicit "does this key exist yet" check before appending or incrementing. - `Counter`: a dict built for frequency counting. Any time an interview problem asks "how many times does each element appear," this is the tool. - `deque`: a double-ended queue with instant append and pop from both ends. Used for queues, and for the sliding-window pattern where you need to drop elements off the front cheaply. - `namedtuple`: a lightweight, immutable record type, tuple performance with named field access. **`heapq`** - A binary min-heap built directly on a plain list. Use it for priority queues, and for `nlargest`/`nsmallest` when you need the top few elements without a full sort. - Also the standard tool for merging several already-sorted lists into one sorted output, the "merge K sorted lists" pattern. **`bisect`** - Binary search on a sorted list (`bisect_left`/`bisect_right`), and inserting while keeping order (`insort`) instead of appending and re-sorting every time. **`itertools`** - `chain`: flattens several iterables into one, without building an extra list. - `product`/`combinations`/`permutations`: generate combinatorial outputs directly. These show up in backtracking-style problems, though a hand-rolled recursive function is usually what an interviewer wants to see instead of a one-line call. - `groupby`: groups consecutive equal elements, useful right after sorting by the same key. - `islice`: slices an iterator lazily, without materializing the whole thing. - `accumulate`: a running (prefix) sum, or a running reduction with a custom function. **`functools`** - `lru_cache`/`cache`: memoizes a function's return values by its arguments. This is the standard way to turn a slow exponential recursive solution into a fast dynamic-programming one, by caching each subproblem's answer the first time it's computed. - `partial`: pre-fills some arguments and returns a new callable. - `reduce`: folds an iterable down to one value with a two-argument function. - `cached_property`: like `lru_cache`, but for one instance attribute, computed once per instance. > **Remember:** reaching for `Counter` or `bisect` instead of hand-rolling the same logic is exactly what "knowing the standard library" means in an interview. ```knowledge-check { "questions": [ { "id": "backend-python-stdlib-datastructures-q1", "type": "mcq", "prompt": "You need the running count of how many times each word appears in a list. Which stdlib tool is built exactly for this?", "options": [ {"id":"a","text":"collections.Counter"}, {"id":"b","text":"itertools.chain"}, {"id":"c","text":"bisect.insort"}, {"id":"d","text":"functools.partial"} ], "correct": "a", "explanation": "Counter is a dict subclass built specifically for frequency counting: pass it any iterable and it tallies occurrences of each element automatically." } ] } ``` ## Files, concurrency, and text - **`pathlib`**: the modern, object-oriented way to work with filesystem paths. Prefer it over `os.path` for new code; it supports globbing (`rglob`) and has built-in read/write helpers. - **`json`**: serializes and deserializes JSON, with custom encoders for types it doesn't know by default (dates, `Decimal`, custom classes). - **`csv`**: `DictReader`/`DictWriter` give header-based row access instead of raw positional lists. Concurrency has three tools for three different jobs: - **`threading`**: for I/O-bound work, where threads mostly wait on network or disk. Provides `Lock`/`Semaphore`/`Event` for coordinating between threads. - **`multiprocessing`**: for CPU-bound parallelism that needs to bypass the GIL, since each process gets its own interpreter. - **`asyncio`**: async I/O built on coroutines, with `gather` for running things concurrently. This is the foundation under any async web framework, including FastAPI, and under async pipelines built with tools like Celery. - **`concurrent.futures`**: a simpler, managed-pool interface sitting on top of both `threading` and `multiprocessing`. Prefer this unless you need finer-grained control. Other reliable reflexes: `datetime`/`zoneinfo` for timezone-aware date math (`zoneinfo`, 3.9+, replaced the third-party `pytz`); `decimal` for money, never `float`, since floating-point rounding error accumulates across repeated arithmetic; `re.compile` to pre-compile a pattern reused across many calls instead of recompiling it every time; `dataclasses` to auto-generate `__init__`/`__repr__`/`__eq__` for a plain data-holding class, instead of hand-writing that boilerplate or reaching for a validation library you don't actually need; `logging` instead of `print()` in production code, since a logger can be filtered, routed, and leveled in a way `print` never can. > **Remember:** `concurrent.futures` is the simple, managed front door to both threading and multiprocessing. Reach for the raw modules only when you need control it doesn't give you. ```knowledge-check { "questions": [ { "id": "backend-python-stdlib-concurrency-q1", "type": "mcq", "prompt": "Which module gives CPU-bound work its own separate interpreter per worker, actually bypassing the GIL for parallel execution?", "options": [ {"id":"a","text":"threading"}, {"id":"b","text":"multiprocessing"}, {"id":"c","text":"asyncio"}, {"id":"d","text":"itertools"} ], "correct": "b", "explanation": "Each process spawned by multiprocessing gets its own Python interpreter and its own GIL, so CPU-heavy work genuinely runs in parallel across cores, unlike threading, which is limited by one shared GIL." } ] } ``` ## Security-relevant modules - **`hashlib`**: file integrity hashes, and an input to password hashing (combined with `hmac`/`secrets`). Never hash passwords with plain `hashlib` alone; use a purpose-built password hashing scheme instead. - **`hmac`**: message authentication codes. Use `hmac.compare_digest` for a timing-safe comparison of secrets, never a plain `==`, which can leak information through how long the comparison takes. - **`secrets`**: cryptographically secure random tokens and passwords. Never use the `random` module for anything security-sensitive; its output isn't cryptographically secure and can be predicted. - **`ast.literal_eval`**: the safe alternative to `eval()` for parsing literal Python values (numbers, strings, lists, dicts) out of a string. > **Remember:** `random` is for games and sampling. `secrets` is for anything security-sensitive, tokens, passwords, session IDs. ```knowledge-check { "questions": [ { "id": "backend-python-stdlib-security-q1", "type": "mcq", "prompt": "Why should you use hmac.compare_digest instead of == to compare a secret token against an expected value?", "options": [ {"id":"a","text":"compare_digest is shorter to type"}, {"id":"b","text":"A plain == can return faster or slower depending on how many leading characters match, leaking information through timing; compare_digest takes constant time regardless"}, {"id":"c","text":"== does not work on strings in Python"}, {"id":"d","text":"compare_digest is required for comparing numbers, not strings"} ], "correct": "b", "explanation": "A naive == comparison can exit early on the first mismatched character, and an attacker measuring response times can use that to guess a secret one character at a time. compare_digest always takes the same amount of time." } ] } ``` ## Pickle: Python's own serialization format `pickle` turns Python objects into bytes (pickling) and back into objects (unpickling), working with almost anything: lists, dicts, custom class instances, even functions by reference. ```python import pickle data = {"name": "Alice", "scores": [95, 87, 92]} # Pickling: to a file or to bytes with open("data.pkl", "wb") as f: pickle.dump(data, f) byte_data = pickle.dumps(data) # Unpickling: from a file or from bytes with open("data.pkl", "rb") as f: loaded = pickle.load(f) loaded = pickle.loads(byte_data) ``` `pickle.dump(data, f)` walks the dict, converts each piece into pickle's own binary format, and writes the bytes straight to the open file. `pickle.dumps(data)` does the same conversion but returns the bytes directly, which is what you'd use to store the result in Redis or a database column. `pickle.load(f)` and `pickle.loads(byte_data)` reverse the process, rebuilding an equivalent object in memory. **Never unpickle data from an untrusted source.** Unlike `json`, unpickling can run arbitrary code: a crafted pickle payload can execute anything during deserialization, by defining a `__reduce__` method that returns a callable and arguments, which `pickle.load` will call automatically while rebuilding the object. This is the standard interview follow-up: "why not always use pickle instead of JSON?" Pickle trades safety for capability. It's Python-only, not cross-language, and unsafe on untrusted input. `json` (and `msgpack`) are safe to parse from anywhere but can't represent arbitrary objects, like custom classes or functions, without writing a custom encoder. Pickle is a good fit for caching computed Python objects between runs, such as a trained model or an in-memory index, where both ends of the exchange are your own trusted code. It's the wrong tool for anything crossing a network boundary from an external client, and the wrong tool for cross-language interchange, since only Python can read the format back. > **Remember:** pickle can run arbitrary code on load. Only unpickle data your own trusted code produced, never anything from an external client. ```knowledge-check { "questions": [ { "id": "backend-python-stdlib-pickle-q1", "type": "mcq", "prompt": "Why is it dangerous to call pickle.load() on data received from an untrusted external client?", "options": [ {"id":"a","text":"It will always raise an exception on malformed data"}, {"id":"b","text":"A crafted pickle payload can execute arbitrary code during deserialization, since pickle.load automatically calls whatever the payload's __reduce__ tells it to"}, {"id":"c","text":"Pickle files are always too large to transmit safely"}, {"id":"d","text":"Pickle cannot represent dictionaries, only lists"} ], "correct": "b", "explanation": "Pickle's format supports rebuilding an object by calling arbitrary functions with arbitrary arguments. An attacker controlling the bytes controls what code runs when you unpickle them. JSON has no equivalent mechanism, which is why it's the safe default for untrusted input." } ] } ``` 82:T2e3b,"Walk me through what happens when a request hits your Django app" is one of the most common backend warm-up questions there is. It isn't really about Django. It's checking whether you understand the framework underneath your code, or only know how to call its APIs. This lesson traces a request end to end, then has you build the two pieces of middleware almost every interviewer expects a backend candidate to have written from scratch. ## The request lifecycle, end to end Picture a request as a letter passed hand to hand through a line of clerks before it reaches the person who can actually answer it, and then passed back through the same line, in reverse, on its way out. Each clerk in Django's chain gets a look at the letter going in, and another look at the reply going out. A request to a Django app running behind Gunicorn or uWSGI goes through these stages: 1. **WSGI server** (Gunicorn) accepts the TCP connection and parses the raw HTTP request into a WSGI environ dict. 2. **`WSGIHandler`** (`django.core.handlers.wsgi`) wraps that environ in an `HttpRequest` object. 3. **Middleware chain, request phase:** each middleware's code *before* it calls `get_response(request)` runs top to bottom, in the order listed in `MIDDLEWARE`. 4. **URL resolver:** Django walks `ROOT_URLCONF`, matches the path against `urlpatterns`, and resolves it to a view function plus any captured URL arguments. A failed match becomes a 404 response before any view code runs. 5. **View:** the matched view runs. This is where your business logic, database calls, and response-building happen. It returns an `HttpResponse`. 6. **Middleware chain, response phase:** each middleware's code *after* `get_response(request)` runs bottom to top, the reverse of step 3, letting each one add headers, compress the body, or set cookies on the way out. 7. **WSGI server** turns the `HttpResponse` back into raw HTTP bytes and writes them to the socket. The detail interviewers actually probe for: **middleware is a chain of closures, not a list Django loops through.** Each middleware wraps the next one. `MIDDLEWARE = [A, B, C]` builds `A(B(C(view)))`. That's why `A`'s request-phase code runs before `B`'s, while `A`'s response-phase code runs *after* `B`'s: you're unwinding the exact call stack you built going in. ```python # Simplified mental model of what Django builds from MIDDLEWARE def build_chain(view, middlewares): handler = view for mw_class in reversed(middlewares): handler = mw_class(handler) # each middleware wraps the previous handler return handler ``` > **Remember:** `MIDDLEWARE = [A, B, C]` builds `A(B(C(view)))`. Request-phase code runs A, B, C in order; response-phase code unwinds C, B, A. ```knowledge-check { "questions": [ { "id": "backend-django-request-lifecycle-order-q1", "type": "mcq", "prompt": "MIDDLEWARE = [A, B, C]. In what order does each middleware's response-phase code (the part after get_response) run?", "options": [ {"id":"a","text":"A, then B, then C -- the same order as request phase"}, {"id":"b","text":"C, then B, then A -- the reverse of request phase, since each middleware wraps the next"}, {"id":"c","text":"All three run at exactly the same time"}, {"id":"d","text":"Only the last middleware's response-phase code runs"} ], "correct": "b", "explanation": "MIDDLEWARE = [A, B, C] builds A(B(C(view))). Going in, A's code runs first, then B's, then C's. Coming back out, you unwind the same stack: C's response code runs first, then B's, then A's." } ] } ``` ## Writing middleware Modern Django (1.10 and later) writes middleware as a class with one `__call__` entry point, not the older `process_request`/`process_response` hook pair (those still work through `MiddlewareMixin`, but they're the legacy style). ```python # middleware.py import time import uuid import logging logger = logging.getLogger("request_timing") class RequestTimingMiddleware: """Logs method, path, status code, and duration for every request.""" def __init__(self, get_response): # Called once, at server startup -- expensive setup goes here, not in __call__. self.get_response = get_response def __call__(self, request): start = time.monotonic() response = self.get_response(request) # <-- everything downstream runs here duration_ms = (time.monotonic() - start) * 1000 logger.info( "%s %s -> %s in %.2fms", request.method, request.path, response.status_code, duration_ms, ) return response class RequestIDMiddleware: """Attaches a unique ID to every request and echoes it back as a response header.""" def __init__(self, get_response): self.get_response = get_response def __call__(self, request): request_id = request.headers.get("X-Request-ID", str(uuid.uuid4())) request.request_id = request_id # available to views/logging via request.request_id response = self.get_response(request) response["X-Request-ID"] = request_id return response ``` Register both in `settings.py`. Order matters here too: put `RequestIDMiddleware` early, so the ID is already set before anything downstream, including exception logging, might want it. ```python MIDDLEWARE = [ "django.middleware.security.SecurityMiddleware", "myapp.middleware.RequestIDMiddleware", "myapp.middleware.RequestTimingMiddleware", "django.contrib.sessions.middleware.SessionMiddleware", "django.middleware.common.CommonMiddleware", # ... "django.middleware.clickjacking.XFrameOptionsMiddleware", ] ``` One trade-off worth saying out loud in an interview: middleware runs on *every* request, including static files and health checks if they're routed through Django. Expensive middleware, a database lookup, an external call, belongs in a view decorator or the view itself, scoped to the routes that actually need it, not applied globally where it slows down everything. > **Remember:** put cheap, universal middleware (request ID, timing) early in the list, and keep expensive checks (a DB lookup, an external call) out of middleware entirely; scope them to the views that need them instead. ```knowledge-check { "questions": [ { "id": "backend-django-request-lifecycle-middleware-q1", "type": "mcq", "prompt": "Why is it a bad idea to put an expensive database lookup inside a globally registered middleware?", "options": [ {"id":"a","text":"Middleware cannot access the database at all"}, {"id":"b","text":"Middleware runs on every request, including static files and health checks, so the cost lands on requests that never needed it"}, {"id":"c","text":"Django caches middleware output automatically, so this is never actually a problem"}, {"id":"d","text":"Database lookups are faster inside middleware than inside a view"} ], "correct": "b", "explanation": "A globally registered middleware runs before every single request that reaches Django. An expensive check belongs in a view or decorator, scoped only to the routes that genuinely need it." } ] } ``` ## A timing decorator for a single function Middleware times a whole request. Sometimes you need to time one function instead: a slow database call, a serializer, a background task's body. ```python import time import functools import logging logger = logging.getLogger(__name__) def timed(func): """Decorator that logs how long the wrapped function took to run.""" @functools.wraps(func) # preserves __name__/__doc__ -- without this, introspection and Django's URL naming break def wrapper(*args, **kwargs): start = time.perf_counter() try: return func(*args, **kwargs) finally: elapsed = time.perf_counter() - start logger.info("%s took %.4fs", func.__qualname__, elapsed) return wrapper @timed def generate_report(user_id: int) -> dict: ... ``` `functools.wraps` is the detail interviewers probe for here. Without it, `generate_report.__name__` becomes `"wrapper"`, which quietly breaks anything relying on introspection: admin registration, some testing frameworks, chained `@method_decorator` calls. > **Remember:** always add `@functools.wraps(func)` inside a decorator's inner function. Skipping it silently renames every function the decorator wraps. ```knowledge-check { "questions": [ { "id": "backend-django-request-lifecycle-wraps-q1", "type": "mcq", "prompt": "A decorator's inner wrapper function forgets @functools.wraps(func). What breaks?", "options": [ {"id":"a","text":"Nothing; wraps is purely cosmetic"}, {"id":"b","text":"The wrapped function's __name__ and __doc__ get replaced by the wrapper's own, breaking anything that relies on introspection, like admin registration or method_decorator chains"}, {"id":"c","text":"The decorated function stops running entirely"}, {"id":"d","text":"Python raises a SyntaxError at import time"} ], "correct": "b", "explanation": "Without functools.wraps, the wrapped function's identity (name, docstring) is replaced by the generic wrapper's. Code that inspects a function by name, including Django's own tooling, sees 'wrapper' instead of the real name." } ] } ``` ## What happens on a POST request specifically This is the most-asked variant of the lifecycle question. 1. Same middleware and URL resolution as above. 2. If the view is a DRF `APIView`, **content negotiation** picks a parser (`JSONParser`, `MultiPartParser`, and so on) based on the request's `Content-Type`. 3. **CSRF check:** `CsrfViewMiddleware` validates the CSRF token for session-authenticated requests. This is skipped for API clients using token or JWT auth that don't rely on cookies. 4. The parser turns the body into `request.data` (DRF), or you read `request.POST`/`request.body` directly in plain Django. 5. Validation runs: a `Form.is_valid()` call, or a DRF `Serializer.is_valid()` call. 6. The view executes the write, typically inside a transaction if it touches more than one table. 7. Response serialization and the middleware unwind happen exactly as before. A common follow-up: **"Where would you put a database transaction?"** Wrap the write in `django.db.transaction.atomic()` inside the view or a service function, not in middleware. Middleware has no idea where your table-level boundaries are, and wrapping every single request in a transaction wastes a database connection on read-only GET requests that never needed one. > **Remember:** a transaction belongs around the actual write, in the view or a service function. Middleware doesn't know your table boundaries, and wrapping GETs in a transaction wastes connections for nothing. ```knowledge-check { "questions": [ { "id": "backend-django-request-lifecycle-transaction-q1", "type": "mcq", "prompt": "Where should a multi-table database write be wrapped in transaction.atomic()?", "options": [ {"id":"a","text":"In a middleware, so every request is automatically protected"}, {"id":"b","text":"In the view or a service function, around the actual write, since middleware doesn't know your table-level boundaries"}, {"id":"c","text":"In the WSGI server configuration"}, {"id":"d","text":"It doesn't matter where, as long as it happens somewhere in the process"} ], "correct": "b", "explanation": "A transaction needs to know exactly where a unit of work starts and ends. Middleware runs for every request regardless of whether it touches the database at all, so wrapping every request in a transaction wastes connections on plain reads." } ] } ``` 83:T4556,The Django ORM hides SQL from you, right up until the moment it doesn't. Almost every Django interview question lives at that seam: what `QuerySet.filter()` actually does, why it waits before running anything, how to read the SQL it builds, and how to kill the N+1 queries that show up in nearly every backend code review. ## Querysets are lazy: nothing runs until you ask for the data Think of a queryset as a recipe card, not a cooked meal. Writing the recipe down and even editing it doesn't put food on the table. Only when someone actually asks to eat does the cooking happen. ```python qs = Book.objects.filter(published=True) # no query yet -- just a recipe qs = qs.filter(author__country="US") # still no query -- refines the same recipe qs = qs.order_by("-created_at") # still no query for book in qs: # <-- THIS triggers the query print(book.title) ``` Each `.filter()`/`.order_by()` call returns a *new* queryset rather than mutating one in place, so chaining them just keeps building up the same underlying description. The database is only actually hit when the queryset gets evaluated: on iteration (`for`, `list(qs)`), on slicing with a step, on `len()` or `bool()`/`if qs:`, on `repr()` (which is why a queryset printed in a shell "looks like it ran"), and on terminal methods like `.get()`, `.count()`, `.exists()`, `.first()`, each of which builds and runs its own SQL rather than reusing a previous query. Two traps worth knowing cold: - `if qs:` and `len(qs)` both trigger a full query and pull every row into memory just to check truthiness or count. For an existence check, call `.exists()` directly instead: it becomes a cheap `SELECT 1 ... LIMIT 1`. - Once a queryset is evaluated, it **caches its results**, so looping over it twice only queries once. But calling `.filter(...)` on an already-evaluated queryset builds a brand-new, uncached queryset. Re-filtering instead of reusing the existing result is a common source of accidental duplicate queries. Because building a queryset never touches the database, you can also assemble one conditionally across several `if` branches, adding a `.filter(...)` in each, and the database still only gets hit once, at the very end, when something finally consumes the result. > **Remember:** a queryset is a description of a query, not the result. It only runs when you iterate it, count it, check truthiness, or call a terminal method. ```knowledge-check { "questions": [ { "id": "backend-django-orm-lazy-q1", "type": "mcq", "prompt": "Why does `if my_queryset:` still hit the database even though you only wanted to check truthiness?", "options": [ {"id":"a","text":"It doesn't; checking a queryset's truthiness never touches the database"}, {"id":"b","text":"bool(queryset) forces full evaluation, pulling every matching row into memory just to check if the list is non-empty; .exists() is the cheap alternative"}, {"id":"c","text":"Django caches the result from the last query and reuses it"}, {"id":"d","text":"Only slicing triggers evaluation, not truthiness checks"} ], "correct": "b", "explanation": "A queryset's __bool__ calls _fetch_all() internally, which runs the full query. .exists() is the version built to answer this specific question cheaply, as a SELECT 1 LIMIT 1." } ] } ``` ## Reading the generated SQL, and dropping to raw SQL when you need to ```python qs = Order.objects.filter(status="paid", total__gt=100).select_related("customer") print(qs.query) ``` ```sql -- Roughly what Django generates SELECT "orders_order"."id", "orders_order"."status", "orders_order"."total", "orders_customer"."id", "orders_customer"."name" FROM "orders_order" INNER JOIN "orders_customer" ON ("orders_order"."customer_id" = "orders_customer"."id") WHERE ("orders_order"."status" = 'paid' AND "orders_order"."total" > 100) ``` For anything the ORM can't express cleanly, window functions, complex CTEs, vendor-specific hints, drop to raw SQL, but stay inside the ORM's own connection and transaction management instead of opening a separate connection: ```python from django.db import connection def top_customers_by_spend(limit=10): with connection.cursor() as cursor: cursor.execute( """ SELECT customer_id, SUM(total) AS spend FROM orders_order WHERE status = %s GROUP BY customer_id ORDER BY spend DESC LIMIT %s """, ["paid", limit], ) columns = [col[0] for col in cursor.description] return [dict(zip(columns, row)) for row in cursor.fetchall()] ``` Always pass values through parameterized placeholders (`%s`), never build the query with an f-string. An f-string here is a straight SQL-injection finding in any code review. To see how Postgres actually plans a query, run it through the ORM's own explain: ```python qs = Order.objects.filter(status="paid").select_related("customer") print(qs.explain(analyze=True)) ``` This runs `EXPLAIN ANALYZE` against the real generated SQL. Watch for a `Seq Scan` on a large table (usually a missing index), a `Nested Loop` whose estimated row count is far off from the actual count (stale table statistics), or which join strategy Postgres picked for your `select_related` join. > **Remember:** `qs.query` shows you the SQL a queryset will run; `qs.explain(analyze=True)` shows you how the database actually plans to run it. ```knowledge-check { "questions": [ { "id": "backend-django-orm-rawsql-q1", "type": "mcq", "prompt": "Why is `cursor.execute(sql, [param])` safe while building the same query with an f-string is not?", "options": [ {"id":"a","text":"There is no real difference; both are equally safe"}, {"id":"b","text":"Parameterized placeholders send the value separately from the query structure, so a malicious value can't change what SQL actually runs; an f-string pastes the value directly into the query text"}, {"id":"c","text":"f-strings are simply slower to execute"}, {"id":"d","text":"cursor.execute() automatically escapes every character in the entire query"} ], "correct": "b", "explanation": "Parameterized queries keep user-controlled data out of the SQL text itself, which is what actually prevents SQL injection. An f-string mixes untrusted data into the query structure, letting crafted input change the query's meaning." } ] } ``` ## select_related vs prefetch_related: the N+1 fix This pair is asked in nearly every Django interview, and the difference comes down to the join strategy. | | `select_related` | `prefetch_related` | |---|---|---| | Works on | Forward `ForeignKey`/`OneToOne` | `ManyToMany`, reverse `ForeignKey`, anything multi-valued | | Mechanism | One SQL `JOIN` | A separate query per relation, stitched together in Python | | Query count | 1 | 2 or more, one per prefetched relation | | Use when | "One row has one related row" | "One row has many related rows" | ```python # N+1 problem: 1 query for orders, then 1 query PER order to fetch its customer orders = Order.objects.filter(status="paid") for order in orders: print(order.customer.name) # <-- hits the database every iteration # Fixed with select_related: a single JOIN query, customer is already loaded orders = Order.objects.filter(status="paid").select_related("customer") for order in orders: print(order.customer.name) # no extra query # Reverse/M2M relation: prefetch_related runs a second query and stitches in Python orders = Order.objects.prefetch_related("line_items") for order in orders: for item in order.line_items.all(): # no extra query -- already fetched print(item.sku) ``` The reason `select_related` can't be used for a "many" relation is structural, not a missing feature: you can't `JOIN` a one-to-many relation into a single row per parent without duplicating the parent's own columns once per child. `prefetch_related` avoids that by running a flat, separate query and matching things up afterward in Python. You can combine and nest both in one call: `Book.objects.select_related("author").prefetch_related("tags", "reviews__reviewer")`, where the double underscore prefetches a relation of a relation. > **Remember:** in one sentence, N+1 is "one query for the list, plus one more query per row for something related to it." `select_related` collapses that into one JOIN for single-valued relations; `prefetch_related` collapses it into a fixed, small number of queries for multi-valued relations. ```knowledge-check { "questions": [ { "id": "backend-django-orm-nplus1-q1", "type": "mcq", "prompt": "A loop over orders reads order.customer.name, and customer is a ForeignKey. Which fix collapses this into a single query?", "options": [ {"id":"a","text":".prefetch_related(\"customer\")"}, {"id":"b","text":".select_related(\"customer\"), which JOINs the customer row into the same query"}, {"id":"c","text":"Calling .exists() before the loop"}, {"id":"d","text":"There is no way to avoid one query per order for a ForeignKey"} ], "correct": "b", "explanation": "customer is a forward, single-valued relation (ForeignKey), which is exactly what select_related is for: one JOIN, one query total, instead of one extra query per row." } ] } ``` ## Custom queryset methods and managers Encapsulate a reusable filter as a queryset method instead of scattering the same `.filter(status="published", deleted_at__isnull=True)` across the codebase every time you need it. ```python from django.db import models class BookQuerySet(models.QuerySet): def published(self): return self.filter(status="published", deleted_at__isnull=True) def by_author(self, author): return self.filter(author=author) def with_review_stats(self): return self.annotate( avg_rating=models.Avg("reviews__rating"), review_count=models.Count("reviews"), ) class BookManager(models.Manager.from_queryset(BookQuerySet)): def get_queryset(self): # applied to every query through this manager, including .filter()/.all() return super().get_queryset().select_related("author") class Book(models.Model): title = models.CharField(max_length=255) status = models.CharField(max_length=20, default="draft") deleted_at = models.DateTimeField(null=True, blank=True) author = models.ForeignKey("Author", on_delete=models.CASCADE) objects = BookManager() ``` `Manager.from_queryset(BookQuerySet)` is the idiomatic way to make custom queryset methods usable both directly on the manager (`Book.objects.published()`) and chained after any other queryset method (`Book.objects.by_author(a).published()`). Writing the methods straight on a `Manager` subclass instead loses that chainability, since a manager method returns whatever type it explicitly returns, not automatically another manager you can keep chaining off of. > **Remember:** put reusable filters on a custom `QuerySet`, wired up via `Manager.from_queryset(...)`. That keeps them chainable everywhere, instead of copy-pasting the same filter across the codebase. ```knowledge-check { "questions": [ { "id": "backend-django-orm-manager-q1", "type": "mcq", "prompt": "Why use Manager.from_queryset(BookQuerySet) instead of defining published() directly as a method on a plain Manager subclass?", "options": [ {"id":"a","text":"It's required; a plain Manager cannot have any custom methods at all"}, {"id":"b","text":"It keeps the method chainable both on the manager and after any other queryset method, since a plain Manager method loses that chaining"}, {"id":"c","text":"It runs the query faster"}, {"id":"d","text":"It automatically adds caching to every query"} ], "correct": "b", "explanation": "from_queryset makes the custom methods available on the resulting QuerySet type itself, so you can chain Book.objects.by_author(a).published(). A method defined only on the Manager can't be chained after another queryset method that way." } ] } ``` ## bulk_create and its limits `bulk_create` builds one, or a few batched, `INSERT` statements for many model instances instead of issuing one `INSERT` per `.save()`. ```python Book.objects.bulk_create([ Book(title="Clean Code", author=author, status="published"), Book(title="Refactoring", author=author, status="published"), Book(title="DDIA", author=author, status="published"), ], batch_size=500) ``` What interviewers expect you to know about its edges: - **`save()` is never called.** No `pre_save`/`post_save` signals fire, and any custom `save()` override is skipped entirely. - **`pk` isn't always populated back on the instances you passed in**, on databases that don't support returning generated IDs from a bulk insert. Postgres and modern SQLite do populate `pk` since Django 4.0. - **`batch_size` matters.** Without it, Django sends one `INSERT` covering every row, which can hit a database's parameter limit or just become one huge statement; batching splits the work into chunks. - **It doesn't handle conflicts by default.** A duplicate key aborts the whole batch (or the batch containing it), unless you pass `update_conflicts=True` with `unique_fields`/`update_fields` (Django 4.1+) to turn it into an upsert. > **Remember:** `bulk_create` skips `save()` entirely, so any logic living in a custom `save()` override or a `post_save` signal never runs for those rows. ```knowledge-check { "questions": [ { "id": "backend-django-orm-bulkcreate-q1", "type": "mcq", "prompt": "A model has a post_save signal that sends a welcome email. You create 500 users with bulk_create. What happens to the emails?", "options": [ {"id":"a","text":"All 500 emails are sent, exactly as if .save() had been called 500 times"}, {"id":"b","text":"None are sent, because bulk_create never calls save() and so never fires post_save signals"}, {"id":"c","text":"Only the first email in the batch is sent"}, {"id":"d","text":"bulk_create raises an error whenever a post_save signal exists"} ], "correct": "b", "explanation": "bulk_create builds INSERT statements directly, bypassing save() and every signal that hangs off of it. Any logic that must run per row needs to run explicitly, not rely on save()-triggered signals." } ] } ``` ## Finding and fixing an N+1 query in practice The bug, as it typically shows up in a codebase or an interview snippet: ```python # N+1: 1 query for books, then 1 additional query PER book for its author def book_list_view(request): books = Book.objects.filter(status="published") return render(request, "books.html", { "books": [{"title": b.title, "author": b.author.name} for b in books] # b.author triggers a query every iteration -- that's the +N }) ``` Diagnose it before guessing at a fix, using Django Debug Toolbar's SQL panel in development, or `CaptureQueriesContext` in a shell or test: ```python from django.test.utils import CaptureQueriesContext from django.db import connection with CaptureQueriesContext(connection) as ctx: orders = list(Order.objects.filter(status="paid")) for o in orders: _ = o.customer.name print(len(ctx.captured_queries)) # roughly 1 + N with CaptureQueriesContext(connection) as ctx: orders = list(Order.objects.filter(status="paid").select_related("customer")) for o in orders: _ = o.customer.name print(len(ctx.captured_queries)) # 1 ``` The fix mirrors the diagnosis: ```python def book_list_view(request): books = Book.objects.filter(status="published").select_related("author") return render(request, "books.html", { "books": [{"title": b.title, "author": b.author.name} for b in books] # b.author now reads from the already-joined row -- 1 query total }) ``` If the view also needs each book's tags (`ManyToMany`), add `.prefetch_related("tags")`: that turns "1 plus N" (books) into 2 total queries (books, and all tags for all books in one `IN (...)` query), instead of "1 plus N plus M". The fastest way to prove a fix actually worked, and to catch a regression before it ships, is `CaptureQueriesContext` paired with Django's `assertNumQueries` in a test: assert the exact query count for the view or function, and any future change that reintroduces an N+1 fails the test immediately, instead of only showing up as a slow endpoint in production weeks later. > **Remember:** count queries before declaring a fix works, and pin that count with `assertNumQueries` in a test. Eyeballing the code and assuming it's fixed is how N+1 regressions slip back in. ```knowledge-check { "questions": [ { "id": "backend-django-orm-testnplus1-q1", "type": "mcq", "prompt": "What is the most reliable way to catch an N+1 regression in CI before it ships?", "options": [ {"id":"a","text":"Manually reviewing the diff for any .filter() calls"}, {"id":"b","text":"A test using assertNumQueries (or CaptureQueriesContext) that pins the exact expected query count for the code path"}, {"id":"c","text":"Running the app locally once and checking it feels fast"}, {"id":"d","text":"Relying on production monitoring to catch it after deploy"} ], "correct": "b", "explanation": "A query-count assertion in a test fails immediately if a future change removes a select_related/prefetch_related and reintroduces N+1, catching it in CI instead of as a slow endpoint discovered later in production." } ] } ``` 84:T2c17,Redis itself, as a general-purpose tool you talk to directly from Python (data structures, cache-aside, invalidation, thundering-herd stampedes), belongs to its own lesson. This lesson is about the layer Django builds on top of that: its own `CACHES` framework, meaning the pluggable backend system, the four levels of granularity you can cache at, and how Django wires caching into views, templates, and HTTP headers. ## Configuration and backends ```python CACHES = { "default": { "BACKEND": "django_redis.cache.RedisCache", "LOCATION": "redis://127.0.0.1:6379/1", "OPTIONS": {"CLIENT_CLASS": "django_redis.client.DefaultClient"}, "TIMEOUT": 300, # seconds; None = never expires "KEY_PREFIX": "myapp", # namespacing across apps sharing one backend } } ``` Django doesn't hardcode Redis. `CACHES` names a backend class, and swapping it changes where cached data actually lives without touching any of your call sites. | Backend | Persistent | Distributed | Notes | |---|---|---|---| | `LocMemCache` (default) | No, process memory | No | Zero setup; dev only, never shared across processes | | `django_redis.cache.RedisCache` | Yes | Yes | The production default; a plain Redis instance wired into Django's cache API | | `PyMemcacheCache` | No | Yes | Fast, distributed, no complex data types | | `DatabaseCache` | Yes | Yes | Uses a real table (`manage.py createcachetable`); slower, but needs no new infrastructure | | `FileBasedCache` | Yes | No | Dev or low-traffic only | | `DummyCache` | N/A | N/A | Accepts every call and does nothing; swaps caching off in a test or staging environment without touching a single call site | > **Remember:** `CACHES["BACKEND"]` is the one setting that decides where cached data actually lives. Everything else in this lesson works the same regardless of which backend is plugged in. ```knowledge-check { "questions": [ { "id": "backend-django-cache-backends-q1", "type": "mcq", "prompt": "You want to disable caching entirely for a staging environment, without changing any code that calls cache.get()/cache.set(). What's the cleanest way?", "options": [ {"id":"a","text":"Delete every cache.get()/cache.set() call from the codebase for that environment"}, {"id":"b","text":"Swap CACHES[\"default\"][\"BACKEND\"] to DummyCache for that environment; it accepts every call and does nothing"}, {"id":"c","text":"Set TIMEOUT to 0 seconds everywhere"}, {"id":"d","text":"Django cannot disable caching without code changes"} ], "correct": "b", "explanation": "DummyCache implements the same interface as every other backend but never actually stores anything, so every existing cache.get()/cache.set() call keeps working without a single call-site change." } ] } ``` ## Four levels of granularity ``` Per-site -> Per-view -> Template fragment -> Low-level (manual) (all) (one view) (part of a page) (any Python object) ``` **Per-view** is the one you'll reach for most: ```python from django.views.decorators.cache import cache_page, never_cache @cache_page(60 * 15) def article_list(request): ... @never_cache def user_dashboard(request): # personalized -- never cache ... ``` **Template fragment** caches part of a page rather than the whole response: ```django {% load cache %} {% cache 500 sidebar %} {% for item in sidebar_items %}

{% endfor %} {% endcache %} {# vary per-user by passing an extra key #} {% cache 500 user_sidebar request.user.id %}...{% endcache %} ``` **The low-level API** caches any Python object manually, and it's the one that maps most directly onto the general cache-aside pattern: check the cache, fall back to computing the value on a miss, then write it back. ```python from django.core.cache import cache cache.set("key", value, timeout=300) value = cache.get("key", default=None) cache.delete("key") cache.get_or_set("key", expensive_fn, 300) # cache-aside in one call cache.add("key", value, timeout=10) # sets only if NOT already present, atomic, used for locks ``` > **Remember:** per-view is the everyday default. Reach for template fragments when only part of a page is expensive, and the low-level API when you're caching something that isn't a whole HTTP response at all. ```knowledge-check { "questions": [ { "id": "backend-django-cache-granularity-q1", "type": "mcq", "prompt": "A page is mostly cheap to render, except for one expensive sidebar widget shared by every visitor. Which caching level fits best?", "options": [ {"id":"a","text":"Per-site caching"}, {"id":"b","text":"Template fragment caching, wrapping just the sidebar block"}, {"id":"c","text":"@never_cache on the whole view"}, {"id":"d","text":"The low-level API, manually caching the entire rendered HTML page"} ], "correct": "b", "explanation": "Template fragment caching lets you cache just the expensive part of a page while the rest renders normally on every request, which is exactly the granularity this situation calls for." } ] } ``` ## Invalidation: signals are Django's specific hook The general cache-aside invalidation rule is delete-on-write: whenever the underlying data changes, delete the cached copy so the next read recomputes it. Django's specific mechanism for that is model signals, so invalidation fires automatically wherever a model is saved, not just from the one write path you remembered to update by hand. ```python from django.db.models.signals import post_save, post_delete from django.dispatch import receiver @receiver(post_save, sender=Article) def invalidate_article_cache(sender, instance, **kwargs): cache.delete(f"article:detail:{instance.pk}") @receiver(post_delete, sender=Article) def invalidate_on_delete(sender, instance, **kwargs): cache.delete(f"article:detail:{instance.pk}") ``` This is stronger than invalidating by hand inside a view or serializer's save path. A signal fires no matter which code path triggered the save, the admin, a shell session, a management command, or a bulk operation calling `.save()` on each object individually, so there's no forgotten call site quietly leaving a stale cache entry behind. > **Remember:** a model signal invalidates the cache no matter which code path saved the model. A manual cache.delete() inside one view only protects that one path. ```knowledge-check { "questions": [ { "id": "backend-django-cache-signals-q1", "type": "mcq", "prompt": "Why is a post_save signal a stronger place to invalidate a cache than a cache.delete() call inside one specific view?", "options": [ {"id":"a","text":"Signals run faster than a direct function call"}, {"id":"b","text":"A signal fires no matter which code path saved the model (admin, shell, management command), so there's no forgotten call site that leaves stale data cached"}, {"id":"c","text":"Signals are the only way to call cache.delete() in Django"}, {"id":"d","text":"There is no real difference between the two approaches"} ], "correct": "b", "explanation": "A cache.delete() placed in one view only protects that one write path. A post_save signal fires for every save of that model, from any code path, closing the gap where a forgotten call site leaves stale data behind." } ] } ``` ## Caching a queryset: the gotcha specific to Django ```python def get_published_articles(): key = "articles:published" articles = cache.get(key) if articles is None: articles = list( # must evaluate -- a lazy queryset doesn't serialize Article.objects.filter(status="published").select_related("author") ) cache.set(key, articles, 600) return articles ``` Django querysets are lazy, and that laziness has a specific consequence for caching: caching an unevaluated queryset either fails to serialize outright, or, worse, silently re-runs the underlying query every time the "cached" value is read back, which defeats the cache entirely while looking like it's working. Always call `list()` on the queryset before handing it to `cache.set`, exactly as above, so what's actually stored is the materialized rows, not a lazy description of how to fetch them. > **Remember:** call `list()` on a queryset before caching it. Caching the lazy queryset itself, not its evaluated rows, silently re-runs the query on every read. ```knowledge-check { "questions": [ { "id": "backend-django-cache-lazyqueryset-q1", "type": "mcq", "prompt": "What goes wrong if you cache.set() an unevaluated Django queryset instead of list(queryset)?", "options": [ {"id":"a","text":"Nothing; querysets serialize identically to lists"}, {"id":"b","text":"It can fail to serialize, or silently re-run the underlying query every time the cached value is read, defeating the cache while appearing to work"}, {"id":"c","text":"Django raises a clear error immediately at cache.set() time"}, {"id":"d","text":"The queryset caches correctly but loses its ordering"} ], "correct": "b", "explanation": "A queryset is a lazy description, not data. Caching it as-is either breaks serialization or, depending on the backend, re-triggers the real query on every read back, which looks like caching but provides none of the benefit." } ] } ``` ## HTTP cache headers ```python from django.views.decorators.cache import cache_control from django.views.decorators.vary import vary_on_cookie @cache_control(max_age=3600, public=True) # browsers/CDN may cache def public_page(request): ... @cache_control(private=True, max_age=0) # never cache in a shared proxy/CDN def user_profile(request): ... @vary_on_cookie # separate cached copy per session @cache_page(600) def my_view(request): ... ``` These decorators control caching in the browser and in any CDN sitting in front of Django, a separate layer from everything above. `@cache_control` and `@vary_on_cookie` never touch Django's own server-side cache backend; they only set response headers that other HTTP caches read and obey. > **Remember:** `@cache_control`/`@vary_on_cookie` are instructions for caches outside Django (browser, CDN). They don't store anything in Django's own `CACHES` backend. ```knowledge-check { "questions": [ { "id": "backend-django-cache-httpheaders-q1", "type": "mcq", "prompt": "Does @cache_control(max_age=3600, public=True) store anything in Django's own CACHES backend?", "options": [ {"id":"a","text":"Yes, it writes an entry into whatever backend CACHES[\"default\"] points to"}, {"id":"b","text":"No, it only sets a response header that tells the browser and any CDN in front of Django how long they may cache the response"}, {"id":"c","text":"Yes, but only when LocMemCache is configured"}, {"id":"d","text":"It replaces the need for CACHES entirely"} ], "correct": "b", "explanation": "cache_control is purely an HTTP-header instruction for caches outside Django. Django's own server-side cache, the CACHES setting, is a completely separate layer that this decorator never touches." } ] } ``` 85:T1167,Backend interviews increasingly include a debugging round: you are handed a slow endpoint, a wrong number or a flaky test in an unfamiliar codebase and asked to find out why, out loud. The questions in this section so far test what you know about Django. This lesson points you at the place where you practice what you do when something is broken. ## What a debugging round actually scores Interviewers rarely care whether you find the bug in the first minute. They watch the process: do you reproduce the problem before touching the code, do you form a hypothesis and test it with a measurement, do you fix the cause instead of the symptom, and can you explain what you changed and how you know it works. A candidate who says "the query count grows with the number of rows, so I will look at where the page evaluates related objects" is already ahead of one who starts adding caches. ```knowledge-check { "questions": [ { "id": "backend-django-debugging-labs-process-q1", "type": "mcq", "prompt": "In a debugging interview you are told a page is slow for some users. What do interviewers most want to see first?", "options": [ {"id":"a","text":"An immediate fix, whatever it is"}, {"id":"b","text":"You reproduce it with realistic data and measure it (for example count the queries) before changing code"}, {"id":"c","text":"You rewrite the page from scratch"}, {"id":"d","text":"You blame the database"} ], "correct": "b", "explanation": "The process is what is scored: reproduce, measure, form a hypothesis, fix the cause, verify. Jumping to a fix is the classic red flag." } ] } ``` ## Practice on realistic, broken systems The **Production Debugging** course gives you exactly that practice. Every lab is a small e-commerce Django app in a browser IDE with a real git history, a database, logs and a ticket written the way support or an on-call engineer would write it. A hidden test suite and behavioral checks grade your fix, and you finish with a short incident write-up. Start with these three, chosen to match what Django interviews probe most: - **The order list page is slow for repeat customers** (easy): an N+1 query pattern. Practice counting queries and using `select_related` and `prefetch_related`. - **Evening orders land on tomorrow's report** (medium): time zones and where the conversion from UTC happens. - **The last unit is sold twice** (hard): a lost update under concurrent checkouts, fixed atomically in the database. Browse them in the [debug lab catalog](/labs/catalog?kind=debug&stack=django), or open the Production Debugging course from the course list. ```knowledge-check { "questions": [ { "id": "backend-django-debugging-labs-practice-q1", "type": "mcq", "prompt": "Which lab skill maps to the interview question \"why does this page get slower as the customer has more orders?\"", "options": [ {"id":"a","text":"Counting queries and finding the N+1 pattern in the queryset"}, {"id":"b","text":"Changing the server timezone"}, {"id":"c","text":"Adding a lock around the view"}, {"id":"d","text":"Rewriting the template engine"} ], "correct": "a", "explanation": "Cost that grows with the number of rows is the signature of per-row work, most often an N+1 query pattern that select_related and prefetch_related remove." } ] } ``` ## How to use the labs for interview prep Do each lab twice. The first time, solve it. The second time, narrate: say what you are measuring and why, as if an interviewer were watching, and write the `INCIDENT.md` in five sentences you could say out loud. The write-up (symptom, how you reproduced it, root cause, fix, prevention) is exactly the structure of a strong debugging answer. ```knowledge-check { "questions": [ { "id": "backend-django-debugging-labs-narrate-q1", "type": "mcq", "prompt": "What should a good incident write-up or spoken debugging answer contain?", "options": [ {"id":"a","text":"Only the final diff"}, {"id":"b","text":"Symptom, how you reproduced it, the root cause and mechanism, the fix, and how to prevent it coming back"}, {"id":"c","text":"A list of every command you ran"}, {"id":"d","text":"An apology"} ], "correct": "b", "explanation": "The structure shows you understand the mechanism and the prevention, not just the patch." } ] } ``` 86:T31e0,FastAPI's whole pitch is async performance, and an interviewer will push on whether you actually understand what "async" buys you, or you're just decorating functions with `async def` out of habit. This lesson covers WSGI vs ASGI, what `await` really does, running several I/O calls at once with `asyncio.gather`, and where FastAPI fits against Django and Flask. ## WSGI vs ASGI Picture a restaurant with one waiter per table: the waiter stands at that table until the whole meal is served, unavailable to anyone else the entire time. That's WSGI. Now picture one waiter who takes an order, drops it at the kitchen window, and immediately goes to take the next table's order while the first meal cooks, coming back to each table exactly when its food is ready. That's ASGI. **WSGI** (Web Server Gateway Interface) is synchronous, one request per thread: the server hands your app a request, your app blocks until it produces a response, and that thread is unavailable to anyone else in the meantime. Concurrency comes from running more worker processes or threads. **ASGI** (Asynchronous Server Gateway Interface) lets one worker handle many connections at once, by cooperatively pausing whenever it's waiting on something. When your code hits `await` on a database call or an HTTP request, the event loop parks that piece of work and runs something else until the wait is over. | | WSGI (Django default, Flask) | ASGI (FastAPI) | |---|---|---| | Concurrency model | OS threads/processes | One event loop plus coroutines | | Scales by | Adding more workers | Handling more concurrent I/O-bound requests per worker | | Best for | CPU-bound, simple synchronous code | I/O-bound: lots of concurrent database/HTTP calls | | A blocking call inside it | Blocks one worker | Blocks the *entire event loop* | That last row is the trap interviewers probe for: calling a blocking, synchronous function (`requests.get()`, `time.sleep()`, a sync database driver) inside an `async def` route freezes the whole event loop. Every other concurrent request on that worker stalls. FastAPI protects a plain `def` route automatically by running it in a thread pool, but the moment you write `async def` and then call blocking code inside it, you own the bug. ```python # WRONG -- blocks the entire event loop for every concurrent request @app.get("/bad") async def bad_endpoint(): time.sleep(2) # blocking call inside an async route return {"ok": True} # RIGHT -- either don't mark it async, or use the async-native equivalent @app.get("/good") def sync_endpoint(): time.sleep(2) # FastAPI runs def routes in a thread pool, so this doesn't block the loop return {"ok": True} @app.get("/also-good") async def async_sleep(): await asyncio.sleep(2) # yields control back to the event loop return {"ok": True} ``` > **Remember:** `async def` is a promise you'll only await non-blocking things. Break that promise once and every concurrent request on that worker pays for it. ```knowledge-check { "questions": [ { "id": "backend-fastapi-asgi-blocking-q1", "type": "mcq", "prompt": "Why does calling time.sleep(2) inside an async def route freeze every other concurrent request on that worker?", "options": [ {"id":"a","text":"It doesn't; each request gets its own thread automatically"}, {"id":"b","text":"A single-threaded event loop is running that coroutine; a blocking call never yields control back, so nothing else on that worker can run until it returns"}, {"id":"c","text":"time.sleep() is disabled inside FastAPI routes"}, {"id":"d","text":"Only the calling request is affected, never other requests"} ], "correct": "b", "explanation": "ASGI's concurrency comes from one event loop juggling many coroutines by yielding at await points. A blocking call never yields, so it holds the entire loop hostage until it finishes, stalling every other request that worker was serving." } ] } ``` ## async / await, precisely `async def` defines a **coroutine function**. Calling it returns a coroutine object immediately; it does not run the function body. `await` is what actually drives the coroutine forward, and it's also the point where control can be handed back to the event loop if the awaited thing isn't ready yet. ```python async def fetch_user(user_id: int) -> dict: ... coro = fetch_user(1) # nothing has run yet -- this is just a coroutine object result = await coro # NOW the body runs, yielding control at any internal await ``` The one-line interview answer: **`await` doesn't block a thread. It suspends the current coroutine and lets the event loop run something else until the awaited operation is ready, then resumes exactly where it left off.** > **Remember:** calling an `async def` function does nothing by itself. The body only runs once you `await` it. ```knowledge-check { "questions": [ { "id": "backend-fastapi-asgi-await-q1", "type": "mcq", "prompt": "What does `coro = fetch_user(1)` do, on its own, without an await?", "options": [ {"id":"a","text":"Runs fetch_user's body to completion and stores the result in coro"}, {"id":"b","text":"Creates a coroutine object without running any of the function body yet"}, {"id":"c","text":"Raises a SyntaxError, since async functions must always be awaited immediately"}, {"id":"d","text":"Blocks until fetch_user finishes"} ], "correct": "b", "explanation": "Calling a coroutine function just builds a coroutine object. Nothing inside it runs until that object is awaited (or otherwise scheduled on the event loop)." } ] } ``` ## Running several I/O calls at once with asyncio.gather This is the entire point of async in a web backend: fire off several independent I/O calls and wait for all of them concurrently, instead of one after another. ```python import asyncio import httpx from fastapi import FastAPI, HTTPException app = FastAPI() async def fetch_json(client: httpx.AsyncClient, url: str) -> dict: response = await client.get(url, timeout=5.0) response.raise_for_status() return response.json() @app.get("/aggregate") async def aggregate_endpoint(): urls = [ "https://api.mindforge.test/users", "https://api.mindforge.test/orders", "https://api.mindforge.test/inventory", ] async with httpx.AsyncClient() as client: try: users, orders, inventory = await asyncio.gather( *(fetch_json(client, url) for url in urls), return_exceptions=False, ) except httpx.HTTPStatusError as exc: raise HTTPException( status_code=502, detail=f"Upstream call failed: {exc.request.url}", ) from exc except httpx.TimeoutException as exc: raise HTTPException(status_code=504, detail="Upstream timeout") from exc return {"users": users, "orders": orders, "inventory": inventory} ``` Say the numbers out loud in an interview: three calls at 200 ms each, run sequentially, take 600 ms total. Run through `asyncio.gather`, all three are in flight at once, so the total is close to `max(latency)`, about 200 ms plus a little overhead, not `sum(latency)`. **`return_exceptions` changes the failure behavior.** By default (`False`), the first exception raised by any task propagates right away, but the other tasks are not automatically canceled; they keep running in the background unless you handle cancellation yourself. Setting `return_exceptions=True` instead collects every exception as a result rather than raising, so you can inspect which calls failed without aborting the whole batch: ```python results = await asyncio.gather(*tasks, return_exceptions=True) succeeded = [r for r in results if not isinstance(r, Exception)] failed = [r for r in results if isinstance(r, Exception)] ``` > **Remember:** sequential awaits sum their latencies; `asyncio.gather` takes the max. Three 200 ms calls become 600 ms sequentially, or about 200 ms concurrently. ```knowledge-check { "questions": [ { "id": "backend-fastapi-asgi-gather-q1", "type": "mcq", "prompt": "Three independent upstream calls each take 200 ms. Roughly how long does asyncio.gather over all three take, compared to awaiting them one at a time?", "options": [ {"id":"a","text":"About 600 ms either way -- gather doesn't change total latency"}, {"id":"b","text":"About 200 ms with gather (the max of the three), versus about 600 ms awaiting them sequentially (the sum)"}, {"id":"c","text":"gather always takes longer, since it has scheduling overhead"}, {"id":"d","text":"About 66 ms with gather, since it splits the work three ways"} ], "correct": "b", "explanation": "Sequential awaits pay for each call's latency in turn: 200+200+200=600ms. Gather starts all three at once, so total time tracks the slowest single call, about 200ms, plus a little overhead." } ] } ``` ## Django vs FastAPI vs Flask: picking the right one The three-way comparison an interviewer asks for when the question is "which framework would you pick for X," rather than "how does FastAPI's dependency injection work." | | Django | Flask | FastAPI | |---|---|---|---| | Type | Full, batteries-included framework | Minimal micro-framework | Modern, async-first micro-framework | | Concurrency | WSGI (sync) by default | WSGI (sync) | ASGI (async), natively | | Validation | Forms / DRF serializers, manual | Manual, or an add-on | Pydantic, automatic from type hints | | ORM | Built in | Bring your own (usually SQLAlchemy) | Bring your own (usually SQLAlchemy) | | Admin panel | Built in, auto-generated | None | None | | API docs | Manual, or DRF's browsable API | Manual, or an add-on | Automatic OpenAPI/Swagger, generated from type hints | | Best for | Content-heavy sites, admin-driven CRUD, teams that want strong conventions | Small services, prototypes, full control over every piece | High-concurrency APIs, I/O-heavy services, type safety end to end | **Pick Django** when the project needs an admin interface out of the box, a batteries-included ORM with migrations, and you're building a traditional web app, server-rendered templates, forms, sessions, rather than a pure API. **Pick FastAPI** when the project is API-first, I/O-bound (many concurrent database or HTTP calls, exactly what ASGI's concurrency model is built for), and you want request and response validation plus OpenAPI docs generated automatically from Python type hints. FastAPI has no opinion on ORM or admin; you assemble those yourself, typically SQLAlchemy plus Alembic. **Flask still wins** for a small, mostly synchronous service where you want minimal magic and full control over every piece, or an existing Flask codebase where a rewrite isn't worth it. FastAPI's advantages, async concurrency, automatic validation and docs, compound as the API surface and concurrent-request volume grow; for a handful of simple synchronous endpoints, Flask's simplicity is often the pragmatic choice. The honest framing: Django gives you more for free but is heavier and synchronous by default. FastAPI gives you async concurrency and automatic validation and docs but requires assembling the rest of the stack yourself. Neither is unconditionally better; the decision hinges on whether you're building a full web application or a high-throughput API service. > **Remember:** Django for a full web app with an admin and an ORM built in. FastAPI for an API-first, I/O-heavy service that wants type-hint-driven validation and docs. Flask when you want minimal magic and are happy assembling everything yourself. ```knowledge-check { "questions": [ { "id": "backend-fastapi-asgi-framework-choice-q1", "type": "mcq", "prompt": "A team is building an I/O-heavy API service with many concurrent calls to other services, and wants request validation and API docs generated automatically from type hints. Which framework fits best?", "options": [ {"id":"a","text":"Django, for its built-in admin panel"}, {"id":"b","text":"FastAPI, since ASGI concurrency suits I/O-bound work and Pydantic generates validation and OpenAPI docs from type hints automatically"}, {"id":"c","text":"Flask, since it has the shallowest learning curve"}, {"id":"d","text":"Any of the three would be identical for this use case"} ], "correct": "b", "explanation": "FastAPI's ASGI concurrency model is built exactly for many concurrent I/O-bound calls, and its Pydantic integration gives automatic validation and OpenAPI docs from type hints, which is the specific pair of requirements described here." } ] } ``` 87:T3171,A candidate who has only used `@app.get` decorators gets tripped up the moment they're asked to share authentication logic, database sessions, or caching across endpoints cleanly. This is exactly what FastAPI's dependency system is for, and it's what makes FastAPI feel different from Flask in an interview. ## How FastAPI resolves dependencies A dependency is just a callable, a function, or a class with `__call__`, that FastAPI calls for you before your endpoint runs, injecting its return value as an argument. Dependencies can themselves depend on other dependencies, and FastAPI resolves the whole graph on every request. ```python from fastapi import FastAPI, Depends app = FastAPI() def get_query_params(q: str | None = None, limit: int = 20): return {"q": q, "limit": limit} @app.get("/items") def list_items(params: dict = Depends(get_query_params)): return {"params": params} ``` Under the hood, FastAPI inspects the endpoint's signature at route-registration time, finds every parameter with a `Depends(...)` default, and builds a dependency graph from that. On each request, it walks the graph, resolving sub-dependencies first, then passes each return value into your endpoint as a regular argument. This is dependency injection through plain function signatures: no decorators to configure and no container or registry to set up, which is the design detail worth naming if you're comparing it to something like Spring's `@Autowired`. > **Remember:** `Depends()` isn't a function that runs anything by itself. It's a marker telling FastAPI "resolve this parameter by calling the given callable instead of parsing it from the request." ```knowledge-check { "questions": [ { "id": "backend-fastapi-di-howitworks-q1", "type": "mcq", "prompt": "When does FastAPI actually call a function passed to Depends()?", "options": [ {"id":"a","text":"Once, when the app first starts up"}, {"id":"b","text":"On each request, when resolving the dependency graph for that endpoint's signature"}, {"id":"c","text":"Only when the endpoint explicitly calls it by name"}, {"id":"d","text":"Never automatically; the developer must call it manually inside the route"} ], "correct": "b", "explanation": "FastAPI inspects the endpoint's signature at route-registration time to find Depends() parameters, then walks and resolves that dependency graph fresh on every incoming request." } ] } ``` ## What Depends() accepts ```python class Pagination: def __init__(self, skip: int = 0, limit: int = 20): self.skip = skip self.limit = limit @app.get("/users") def list_users(pagination: Pagination = Depends()): return {"skip": pagination.skip, "limit": pagination.limit} ``` `Depends()` accepts a plain function, called fresh for each place it's used (subject to caching, covered next); a class, where FastAPI calls `SomeClass(...)`, so `__init__`'s parameters become sub-dependencies and the instance itself is what gets injected; or nothing at all, which infers the callable from the parameter's own annotated type, as in `Pagination` above. > **Remember:** passing a class to `Depends()` makes its `__init__` parameters into sub-dependencies automatically. The injected value is the constructed instance. ```knowledge-check { "questions": [ { "id": "backend-fastapi-di-classdepends-q1", "type": "mcq", "prompt": "`pagination: Pagination = Depends()` where Pagination.__init__ takes skip and limit. What gets injected into the endpoint?", "options": [ {"id":"a","text":"The Pagination class itself, not an instance"}, {"id":"b","text":"An instance of Pagination, built by FastAPI calling Pagination(...) with skip/limit resolved as sub-dependencies from the request"}, {"id":"c","text":"Nothing; Depends() with no argument is invalid"}, {"id":"d","text":"A dictionary with keys skip and limit"} ], "correct": "b", "explanation": "FastAPI calls the class like any other dependency, so __init__'s own parameters (skip, limit) become sub-dependencies read from the request, and the constructed Pagination instance is what's injected." } ] } ``` ## Caching a dependency's result By default, FastAPI **caches a dependency's result for the duration of one request**. If two different dependencies both depend on `get_db` within the same request, `get_db` runs once and both receive the same returned value, not two separate calls. This is `use_cache=True`, the default. ```python from fastapi import Depends def get_settings(): print("loading settings") # only prints once per request, even if used twice below return load_app_settings() def get_feature_flags(settings=Depends(get_settings)): return settings.feature_flags def get_rate_limits(settings=Depends(get_settings)): # same get_settings call, cached return settings.rate_limits @app.get("/config") def config_endpoint( flags=Depends(get_feature_flags), limits=Depends(get_rate_limits), ): return {"flags": flags, "limits": limits} ``` For caching *across* requests, not just within one, don't rely on FastAPI's per-request cache. Use `functools.lru_cache` on the dependency itself, the standard pattern for expensive, request-independent setup like loading settings from environment variables once per process: ```python from functools import lru_cache @lru_cache def get_settings(): return Settings() # e.g. a pydantic-settings model reading env vars, loaded once and reused forever @app.get("/health") def health(settings: Settings = Depends(get_settings)): return {"env": settings.environment} ``` `Depends(..., use_cache=False)` is the opposite override: it forces a dependency to re-run even if it was already resolved earlier in the same request, useful for a dependency with a deliberate side effect you want repeated. > **Remember:** FastAPI's built-in cache only lasts one request. For a value that should persist across requests, like settings loaded once per process, wrap the dependency in `functools.lru_cache` instead. ```knowledge-check { "questions": [ { "id": "backend-fastapi-di-caching-q1", "type": "mcq", "prompt": "Two endpoints in the same app both use `Depends(get_settings)`. Without @lru_cache, how many times does get_settings run across two separate requests?", "options": [ {"id":"a","text":"Once total, shared across both requests"}, {"id":"b","text":"Once per request: FastAPI's per-request cache means it won't re-run within one request, but it does run again for each new request"}, {"id":"c","text":"Never; it only runs at app startup"}, {"id":"d","text":"Twice per request, once for each endpoint"} ], "correct": "b", "explanation": "FastAPI's dependency cache is scoped to a single request, not the whole process. Without @lru_cache (or another process-level cache), a dependency re-runs fresh on every new request even if it produced the same result last time." } ] } ``` ## Request-scoped setup and teardown with yield A FastAPI dependency that uses `yield` instead of `return` gets request-scoped setup and teardown. The code after `yield` runs after the response is sent, which is the standard pattern for anything needing cleanup: database sessions, file handles, locks. ```python from sqlalchemy.orm import Session from fastapi import Depends def get_db() -> Session: db = SessionLocal() try: yield db # this Session is what gets injected finally: db.close() # runs after the endpoint (and response) completes @app.get("/orders/{order_id}") def get_order(order_id: int, db: Session = Depends(get_db)): return db.query(Order).get(order_id) ``` "Request-scoped" here means a fresh `Session` per request, never shared across concurrent requests (which would corrupt transactional state), but reused across every dependency and endpoint code within that one request, via the same per-request caching from the previous section. Compare that with a global module-level `Session` (wrong: shared mutable state across concurrent requests) or building a brand-new session in every function that touches the database (wrong: loses the "one unit of work per request" boundary and duplicates setup and teardown). > **Remember:** a `yield`-based dependency splits into setup (before `yield`) and teardown (after it), with the teardown guaranteed to run once the response is done, wrapped in `try/finally` for anything that must clean up even on error. ```knowledge-check { "questions": [ { "id": "backend-fastapi-di-yield-q1", "type": "mcq", "prompt": "In a `yield`-based dependency like get_db above, when does the code after yield (db.close()) actually run?", "options": [ {"id":"a","text":"Immediately, before the endpoint body even executes"}, {"id":"b","text":"After the endpoint has finished and the response has been sent"}, {"id":"c","text":"It never runs automatically; you must call it manually"}, {"id":"d","text":"Only if the endpoint raises an exception"} ], "correct": "b", "explanation": "Everything before yield is setup, injected as the dependency's value. Everything after yield is teardown, which FastAPI runs once the request/response cycle for that endpoint is complete." } ] } ``` ## Building an authentication dependency ```python from fastapi import Depends, HTTPException, status from fastapi.security import OAuth2PasswordBearer from jose import jwt, JWTError oauth2_scheme = OAuth2PasswordBearer(tokenUrl="token") SECRET_KEY = settings.jwt_secret # from env, never hardcoded ALGORITHM = "HS256" def get_current_user(token: str = Depends(oauth2_scheme)) -> "User": credentials_exception = HTTPException( status_code=status.HTTP_401_UNAUTHORIZED, detail="Could not validate credentials", headers={"WWW-Authenticate": "Bearer"}, ) try: payload = jwt.decode(token, SECRET_KEY, algorithms=[ALGORITHM]) user_id: str = payload.get("sub") if user_id is None: raise credentials_exception except JWTError: raise credentials_exception user = get_user_by_id(user_id) if user is None: raise credentials_exception return user def get_current_active_user(user: "User" = Depends(get_current_user)) -> "User": if not user.is_active: raise HTTPException(status_code=400, detail="Inactive user") return user @app.get("/me") def read_own_profile(current_user: "User" = Depends(get_current_active_user)): return {"id": current_user.id, "email": current_user.email} ``` Two points worth naming explicitly. `OAuth2PasswordBearer` doesn't perform authentication itself: it's a dependency that extracts the `Authorization: Bearer ` header, raising a 401 automatically if it's missing, and documents the security scheme in the OpenAPI schema so `/docs` shows an "Authorize" button. The actual token *validation* is your own code in `get_current_user`. And layering `get_current_user` into `get_current_active_user` lets different endpoints require different strictness: a "verify email" endpoint might accept an inactive user through `get_current_user` directly, while most endpoints require the stricter `get_current_active_user`. This composability, small dependencies building into stricter ones, is the payoff of FastAPI's dependency system over one monolithic auth check. > **Remember:** `OAuth2PasswordBearer` only extracts the token; it doesn't validate it. Layer small dependencies (`get_current_user` -> `get_current_active_user`) instead of writing one big auth check. ```knowledge-check { "questions": [ { "id": "backend-fastapi-di-auth-q1", "type": "mcq", "prompt": "Does OAuth2PasswordBearer(tokenUrl=\"token\") validate the JWT's signature and claims?", "options": [ {"id":"a","text":"Yes, it fully validates the token before injecting it"}, {"id":"b","text":"No, it only extracts the Authorization: Bearer token from the header (and 401s if missing); actual validation is separate code, like get_current_user"}, {"id":"c","text":"It validates the signature but not the expiry"}, {"id":"d","text":"It only works with session cookies, not bearer tokens"} ], "correct": "b", "explanation": "OAuth2PasswordBearer's job is extracting the raw token string from the request and documenting the security scheme for OpenAPI. Decoding and validating that token is separate application code, layered on top via another dependency." } ] } ``` 88:T2cc8,The ASGI and Async lesson introduced `BackgroundTasks` in passing. This lesson goes deep on when it's the right tool versus when you actually need a real task queue like Celery, and builds the pattern every "process this upload and show progress" interview question is really testing: offloading work and giving the client a way to poll for status. ## BackgroundTasks vs a real task queue This distinction is a direct, frequent interview question. | | `BackgroundTasks` | Celery / RQ / durable queue | |---|---|---| | Runs where | Same process, after the response is sent | Separate worker process(es), possibly separate machines | | Survives a crash | No -- in-memory, lost if the process dies | Yes -- the task sits in the broker until a worker picks it up | | Scales independently of the web tier | No | Yes -- add workers without touching web servers | | Retry / scheduling | None built in | Built in | | Best for | Fire-and-forget, sub-second, non-critical work (a log line, a metric, warming a cache) | Anything that must complete, is slow, or needs retry/scheduling | The interview trap is using `BackgroundTasks` for something that must not be lost: sending a password-reset email, charging a card, processing an uploaded file a user is actively waiting on. If the worker process restarts, a deploy, a crash, an autoscaler killing an instance, mid-task, that work simply disappears with no error surfaced anywhere. `BackgroundTasks` is appropriate for genuinely disposable work only. > **Remember:** `BackgroundTasks` runs in the same process and vanishes if that process dies. If the work must not be lost, it belongs in a durable queue, not `BackgroundTasks`. ```knowledge-check { "questions": [ { "id": "backend-fastapi-bgtasks-tradeoff-q1", "type": "mcq", "prompt": "A route uses BackgroundTasks to send a password-reset email. The server crashes 2 seconds after responding, before the task ran. What happens to the email?", "options": [ {"id":"a","text":"It's queued and will send once the server restarts"}, {"id":"b","text":"It's lost entirely, since BackgroundTasks holds the task only in memory in that same process"}, {"id":"c","text":"FastAPI automatically retries it on the next request"}, {"id":"d","text":"It was already sent before the crash, since BackgroundTasks runs before the response"} ], "correct": "b", "explanation": "BackgroundTasks runs in-process, after the response is sent. Nothing persists it anywhere else, so a crash before it runs means the work is gone with no record it was ever attempted." } ] } ``` ## Offloading heavy computation, with a status endpoint ```python from fastapi import FastAPI, BackgroundTasks, UploadFile, HTTPException import uuid app = FastAPI() # In-memory here for illustration; use Redis in any real deployment so state # survives a worker restart and is visible across multiple app instances. job_store: dict[str, dict] = {} def process_file(job_id: str, contents: bytes) -> None: job_store[job_id]["status"] = "processing" try: total_lines = contents.count(b"\n") processed = 0 for _ in range(total_lines): # simulate per-line work processed += 1 if processed % 100 == 0: job_store[job_id]["progress"] = processed / total_lines job_store[job_id]["status"] = "completed" job_store[job_id]["result"] = {"lines_processed": processed} except Exception as exc: job_store[job_id]["status"] = "failed" job_store[job_id]["error"] = str(exc) @app.post("/files/process") async def start_processing(file: UploadFile, background_tasks: BackgroundTasks): contents = await file.read() job_id = str(uuid.uuid4()) job_store[job_id] = {"status": "queued", "progress": 0.0} background_tasks.add_task(process_file, job_id, contents) return {"job_id": job_id, "status_url": f"/files/process/{job_id}"} @app.get("/files/process/{job_id}") async def get_job_status(job_id: str): job = job_store.get(job_id) if job is None: raise HTTPException(status_code=404, detail="Job not found") return job ``` The shape here, return a job ID right away and let the client poll a status endpoint, is the standard answer for any "long-running work behind an HTTP API" question, independent of whether the actual execution is `BackgroundTasks`, Celery, or a cloud job service. Interviewers care more about this shape than the specific execution mechanism. > **Remember:** return a job ID immediately and let the client poll a status endpoint. That shape is what interviewers are checking for, regardless of what actually runs the work behind it. ```knowledge-check { "questions": [ { "id": "backend-fastapi-bgtasks-shape-q1", "type": "mcq", "prompt": "What is the standard response shape for a 'start this long-running job' endpoint?", "options": [ {"id":"a","text":"Block the request until the job finishes, then return the full result"}, {"id":"b","text":"Return a job ID and a status URL immediately, and let the client poll that URL for progress"}, {"id":"c","text":"Return a 202 with no body and no way to check progress"}, {"id":"d","text":"Redirect the client to a separate job-tracking service"} ], "correct": "b", "explanation": "Returning a job id immediately and exposing a status endpoint to poll is the standard pattern for long-running work behind an HTTP API, regardless of whether BackgroundTasks, Celery, or something else actually does the work." } ] } ``` ## Making job state durable with Redis The in-memory `job_store` above breaks the moment you run more than one app instance, a status check can land on a different instance than the one processing the job, or the process restarts. Redis fixes both: ```python import json import redis r = redis.Redis(host="localhost", port=6379, decode_responses=True) def set_job(job_id: str, data: dict) -> None: r.set(f"job:{job_id}", json.dumps(data), ex=3600) # expire stale job records after an hour def get_job(job_id: str) -> dict | None: raw = r.get(f"job:{job_id}") return json.loads(raw) if raw else None def process_file_durable(job_id: str, contents: bytes) -> None: set_job(job_id, {"status": "processing", "progress": 0.0}) try: total_lines = contents.count(b"\n") or 1 processed = 0 for _ in range(total_lines): processed += 1 if processed % 100 == 0: set_job(job_id, {"status": "processing", "progress": processed / total_lines}) set_job(job_id, {"status": "completed", "progress": 1.0, "result": {"lines_processed": processed}}) except Exception as exc: set_job(job_id, {"status": "failed", "error": str(exc)}) ``` This still runs in-process via `BackgroundTasks`, so it's still lost entirely if the process dies mid-task. The fix for *that* is routing `process_file_durable`'s work through a real task queue instead, the natural next step once "must survive a crash" becomes a real requirement. Keep both layers straight: Redis fixes the *state visibility* problem (any instance can answer the status check), a durable queue fixes the *durability* problem (the work itself survives a crash), and in practice they're often used together, a queued task writes progress into Redis, and the API reads that progress back for the status endpoint. > **Remember:** Redis fixes state *visibility* across instances. A durable queue fixes work *surviving a crash*. They solve different problems and are often used together. ```knowledge-check { "questions": [ { "id": "backend-fastapi-bgtasks-redis-q1", "type": "mcq", "prompt": "Job state is moved from an in-process dict to Redis, but the actual work still runs via BackgroundTasks. Is the durability problem (surviving a crash mid-task) now solved?", "options": [ {"id":"a","text":"Yes, Redis makes the whole job durable"}, {"id":"b","text":"No, the job's progress is now visible across instances, but the work itself still runs in-process and is lost if that process crashes mid-task"}, {"id":"c","text":"Yes, but only for jobs under a certain size"}, {"id":"d","text":"No, Redis actually makes things worse here"} ], "correct": "b", "explanation": "Redis solves visibility: any instance can now read a job's current status. It does nothing for durability of the work itself, since BackgroundTasks still executes in-process and has no way to resume or replay a task lost to a crash." } ] } ``` ## The durable version: progress tracking with a real task queue ```python from celery_app import app as celery_app from celery import states @celery_app.task(bind=True) def process_file_task(self, contents_b64: str): contents = base64.b64decode(contents_b64) total_lines = contents.count(b"\n") or 1 processed = 0 for _ in range(total_lines): processed += 1 if processed % 100 == 0: self.update_state(state="PROGRESS", meta={"progress": processed / total_lines}) return {"lines_processed": processed} ``` ```python @app.post("/files/process-durable") async def start_processing_durable(file: UploadFile): contents = await file.read() task = process_file_task.delay(base64.b64encode(contents).decode()) return {"job_id": task.id, "status_url": f"/files/process-durable/{task.id}"} @app.get("/files/process-durable/{job_id}") async def get_durable_job_status(job_id: str): result = celery_app.AsyncResult(job_id) if result.state == "PROGRESS": return {"status": "processing", "progress": result.info.get("progress")} if result.state == "SUCCESS": return {"status": "completed", "result": result.result} if result.state == "FAILURE": return {"status": "failed", "error": str(result.info)} return {"status": result.state.lower()} ``` `self.update_state` with a custom `"PROGRESS"` state is a task queue's built-in mechanism for exactly this. There's no need to hand-roll a Redis progress key once you're already on a real queue, since its own result backend gives you this for free. > **Remember:** once a job genuinely must survive a crash, route it through a real task queue instead of BackgroundTasks. The queue's own result backend already tracks progress; you don't need to hand-roll it. ```knowledge-check { "questions": [ { "id": "backend-fastapi-bgtasks-celery-q1", "type": "mcq", "prompt": "Why doesn't the Celery version above need a separate Redis progress key like the BackgroundTasks version did?", "options": [ {"id":"a","text":"Celery tasks run instantly, so progress tracking isn't needed"}, {"id":"b","text":"self.update_state writes progress into the task's own result backend, which the status endpoint reads back through AsyncResult, so a hand-rolled Redis key would be redundant"}, {"id":"c","text":"Celery cannot report progress at all"}, {"id":"d","text":"Redis is required by Celery internally, so it's already being written to anyway"} ], "correct": "b", "explanation": "update_state with a custom PROGRESS state is Celery's built-in progress-reporting mechanism, backed by its own result backend. The status endpoint reads that back via AsyncResult, so a separate hand-rolled progress key is unnecessary." } ] } ``` 89:T2946,Picture a phone book with a million names in random order. Finding "Smith" means checking every single page. Now picture the same names sorted alphabetically: you jump straight to the S section. An index is that sorted shortcut, built for a database table instead of a phone book. Nearly every backend interview asks some version of "how would you speed up this slow query," and the answer they want is "add an index," followed immediately by "which kind, and why not just index every column." This lesson builds that full answer. ## How a database index finds a row fast Without an index, Postgres does a **sequential scan**: it reads every page of the table and checks every row against your `WHERE` clause. On a small table that's fast enough. On a big one, it's the phone-book-in-random-order problem. Postgres's default index type is a **B-tree**, a balanced tree of sorted keys. Each key points to the exact physical location of its row (called a tuple ID). A lookup walks down the tree comparing against a handful of boundaries instead of reading the whole table. ``` [50] / \ [20,35] [70,90] / | \ / | \ [..] [..] [..] [..] [..] [..] ``` A search for `id = 42` starts at the root, sees 42 is less than 50, goes left, sees it's between 35 and 50, and so on, in a handful of steps instead of scanning the whole table. ```sql CREATE TABLE orders ( id SERIAL PRIMARY KEY, customer_id INT NOT NULL, status VARCHAR(20) NOT NULL, total NUMERIC(10, 2) NOT NULL, created_at TIMESTAMP NOT NULL DEFAULT now() ); ``` ```sql EXPLAIN ANALYZE SELECT * FROM orders WHERE customer_id = 42; -- Seq Scan on orders, checking all 100,000 rows for ~20 matches CREATE INDEX idx_orders_customer_id ON orders (customer_id); EXPLAIN ANALYZE SELECT * FROM orders WHERE customer_id = 42; -- Index Scan using idx_orders_customer_id (cost=0.29..8.31 rows=20 width=32) ``` Same table, same query, two orders of magnitude cheaper once the index exists. > **Remember:** an index is a sorted shortcut to a row's location, built as a B-tree. It turns "check every row" into "check a handful of boundaries." ```knowledge-check { "questions": [ { "id": "backend-databases-indexing-btree-q1", "type": "mcq", "prompt": "Why is a B-tree index faster than a sequential scan for finding one matching row in a big table?", "options": [ {"id":"a","text":"It walks a tree of sorted keys and skips most of the table, instead of checking every row one by one"}, {"id":"b","text":"It stores a second full copy of the table in memory"}, {"id":"c","text":"It compresses the table so it takes up less disk space"}, {"id":"d","text":"It only works on tables smaller than 1,000 rows"} ], "correct": "a", "explanation": "A B-tree narrows the search at every level, comparing against a handful of boundary values instead of reading every row. That is what turns a full scan into a small number of page reads." } ] } ``` ## Selectivity: why an index does not always help Not every column is worth indexing. Try the same trick on a column with only a few possible values: ```sql CREATE INDEX idx_orders_status ON orders (status); EXPLAIN ANALYZE SELECT * FROM orders WHERE status = 'paid'; -- Still a Seq Scan! About a quarter of all rows match "paid", so scanning -- straight through is cheaper than jumping around the index for that many rows. ``` **Selectivity** is distinct values divided by total rows. `customer_id` has 5,000 distinct values across 100,000 rows: high selectivity, a great index candidate, because each lookup skips almost the entire table. `status` has 4 values across those same 100,000 rows: low selectivity, a poor index candidate alone, because a lookup still has to fetch a huge slice of the table. ```sql SELECT count(DISTINCT status)::float / count(*) AS status_selectivity, -- ~0.00004 count(DISTINCT customer_id)::float / count(*) AS customer_selectivity -- ~0.05 FROM orders; ``` Rule of thumb: an index pays off when a query returns a small slice of the table, roughly under 10-15%. Above that, Postgres knows a straight scan beats jumping around an index, and it will quietly ignore your index. That's the planner doing its job, not a bug. This same idea explains every case where an index is a bad idea: | Situation | Why the index does not help | |---|---| | Low-selectivity column alone (a boolean, a small enum) | A lookup still touches most of the table | | A small table | The whole table already fits in a few pages; the index adds overhead for nothing | | A column written far more than it's read | Every write has to update every index on that column too | | A wide text column, indexed whole | The index itself becomes huge; index only a prefix or use a trigram index instead | > **Remember:** an index only pays for itself when it lets Postgres skip most of the table on a read. A column with only a few possible values usually fails that test on its own. ```knowledge-check { "questions": [ { "id": "backend-databases-indexing-selectivity-q1", "type": "mcq", "prompt": "A boolean column is filtered on its own in a WHERE clause. Why is a plain index on that column usually a weak choice?", "options": [ {"id":"a","text":"Postgres cannot build an index on a boolean type at all"}, {"id":"b","text":"With only two possible values, a lookup still has to fetch a large fraction of the table, so a sequential scan is often cheaper"}, {"id":"c","text":"Boolean indexes take up more disk space than any other type"}, {"id":"d","text":"Indexes only work on numeric columns"} ], "correct": "b", "explanation": "Selectivity is distinct values over total rows. A boolean has only two distinct values, so roughly half the table matches either one, which is far above the point where a scan beats an index." } ] } ``` ## Reading EXPLAIN ANALYZE `EXPLAIN ANALYZE` shows you exactly what Postgres did and how long it took. This is the tool you reach for before touching an index at all. ```sql EXPLAIN ANALYZE SELECT * FROM orders WHERE customer_id = 42 AND status = 'paid'; ``` ``` Index Scan using idx_orders_customer_id on orders (cost=0.29..8.45 rows=5 width=32) (actual time=0.018..0.052 rows=5 loops=1) Index Cond: (customer_id = 42) Filter: (status = 'paid'::text) Rows Removed by Filter: 15 Planning Time: 0.112 ms Execution Time: 0.071 ms ``` Read it in this order: - **`cost=A..B`**: the planner's own estimate, in arbitrary units, not milliseconds. - **`actual time=A..B`**: real measured milliseconds. Only appears with `ANALYZE`, which actually runs the query, so run it inside a transaction you roll back before trying it on a production `DELETE` or `UPDATE`. - **`rows` estimated vs actual**: a big gap between them means Postgres's statistics are stale. Fix with `ANALYZE orders;`. - **`Index Cond` vs `Filter`**: `Index Cond` is checked by the index itself, cheap. `Filter` is checked after fetching the row, more expensive. Here, `customer_id` narrows things down through the index, but `status` still has to be checked row by row afterward, because there's no single index covering both. - **`Rows Removed by Filter`**: rows the index fetched and then threw away. A high number here is a sign a better index would help. A composite index fixes exactly that last problem: ```sql CREATE INDEX idx_orders_customer_status ON orders (customer_id, status); -- now both conditions become Index Cond, and zero rows get removed by the filter ``` > **Remember:** `Index Cond` is cheap (checked by the index); `Filter` is expensive (checked after fetching the row). A high "rows removed by filter" number is your signal to widen the index. ```knowledge-check { "questions": [ { "id": "backend-databases-indexing-explain-q1", "type": "mcq", "prompt": "In EXPLAIN ANALYZE output, the estimated row count is 25,000 but the actual row count is 5. What does this gap usually mean?", "options": [ {"id":"a","text":"The query has a syntax error"}, {"id":"b","text":"The table's statistics are stale, so the planner's guess is off; running ANALYZE on the table refreshes them"}, {"id":"c","text":"The index is corrupted and needs to be rebuilt"}, {"id":"d","text":"This gap is normal and never worth investigating"} ], "correct": "b", "explanation": "The planner picks a plan based on statistics gathered by ANALYZE. When those statistics are old, its row estimates drift from reality, and it can pick a worse plan than the one actually available." } ] } ``` ## Composite indexes and the leftmost prefix rule A composite index is one index built over more than one column, in a fixed order. That order is not cosmetic: it decides which queries can use the index at all. `CREATE INDEX ON orders (customer_id, status)` supports: - A query filtering on `customer_id` alone. - A query filtering on `customer_id` and `status` together. It does **not** support a query filtering on `status` alone, because the index is sorted first by `customer_id`. Skipping straight to a given `status` value would mean jumping all over the index, not scanning a contiguous range, so Postgres can't use it that way. This is the **leftmost prefix rule**: a composite index only helps a query that filters starting from its leftmost column. Think of it like a phone book sorted by last name, then first name. You can jump straight to "Smith," or to "Smith, John." You cannot jump straight to everyone named "John," because the book isn't sorted by first name at all. > **Remember:** a composite index `(a, b)` serves queries on `a` alone or `a` and `b` together, never `b` alone. Column order is part of the index's design, not a detail you can swap freely. ```knowledge-check { "questions": [ { "id": "backend-databases-indexing-composite-q1", "type": "mcq", "prompt": "An index exists on (customer_id, status). Which query can it actually speed up?", "options": [ {"id":"a","text":"WHERE status = 'paid'"}, {"id":"b","text":"WHERE customer_id = 42"}, {"id":"c","text":"Neither query can use this index"}, {"id":"d","text":"Both queries equally"} ], "correct": "b", "explanation": "The leftmost prefix rule: a composite index on (customer_id, status) is sorted by customer_id first, so only a query that filters on customer_id (alone, or with status added) can use it." } ] } ``` 8a:T24cc,An index only helps if the query around it is written well. This lesson covers what Postgres does with your SQL before it ever touches an index: how it picks a join strategy, the WHERE-vs-HAVING trap, and the N+1 pattern that shows up in nearly every backend interview. ## How the query planner picks a plan Postgres never runs your SQL as written. It parses it into a tree, then its **planner** looks at several possible ways to execute that tree (which index to use, which join order, which join algorithm) and picks the one it estimates is cheapest, based on statistics gathered by `ANALYZE`: row counts, common values, and a histogram of how values are spread out. Three join algorithms come up constantly in interviews: | Algorithm | How it works | Good fit | |---|---|---| | **Nested loop** | For each row on one side, scan (or index-lookup) the other side for matches | The outer side is small, or the inner side has a good index | | **Hash join** | Build an in-memory hash table from the smaller side, then probe it once per row on the larger side | Large, unindexed, unsorted inputs, given enough working memory | | **Merge join** | Both sides are already sorted (or get sorted), then merged in one pass | Both inputs are already sorted, often via an index | Stale statistics are why the planner sometimes picks a worse plan even when a better one is available: it's reasoning about row counts that no longer match reality. > **Remember:** the planner picks a plan from row-count estimates, not from your SQL's shape. Stale statistics (an old `ANALYZE`) are the classic reason it picks the wrong one. ```knowledge-check { "questions": [ { "id": "backend-databases-optimization-planner-q1", "type": "mcq", "prompt": "A hash join is generally the right choice when...", "options": [ {"id":"a","text":"Both inputs are already sorted on the join key"}, {"id":"b","text":"The inputs are large, unsorted, and unindexed, and there's enough working memory to build a hash table from the smaller side"}, {"id":"c","text":"The outer table has only one row"}, {"id":"d","text":"The join has no matching rows at all"} ], "correct": "b", "explanation": "A hash join builds an in-memory hash table from the smaller side and probes it once per row on the larger side, which works well precisely when there's no existing sort or index to exploit." } ] } ``` ## WHERE filters rows, HAVING filters groups `WHERE` runs **before** rows are grouped. `HAVING` runs **after** aggregation. This ordering, not the keywords themselves, is what nearly every SQL interview question about the two is really testing. ```sql SELECT customer_id, SUM(total) AS spend FROM orders WHERE status = 'paid' -- per-row, before grouping GROUP BY customer_id HAVING SUM(total) > 1000; -- per-group, after aggregation ``` `WHERE SUM(total) > 1000` is an error, because at the point `WHERE` runs, rows have not been grouped yet, so there is nothing to sum. `HAVING status = 'paid'` fails too in Postgres, because `status` is not in the `GROUP BY`. Even if you add it to the `GROUP BY`, it's wasteful: the database groups every row, including the ones you'll throw away. Always put a per-row filter in `WHERE`. The same rule explains a classic `GROUP BY` error. After grouping, each output row stands for many input rows. So every column you select must either be in the `GROUP BY` list or be wrapped in an aggregate like `COUNT`, `SUM` or `AVG`. Postgres rejects the query otherwise. Older MySQL (non-strict mode) runs it and quietly returns a value from some random row in the group, which is worse. > **Remember:** `WHERE` runs before grouping and can't see an aggregate; `HAVING` runs after grouping and filters the groups themselves. Put per-row filters in `WHERE`. ```knowledge-check { "questions": [ { "id": "backend-databases-optimization-having-q1", "type": "mcq", "prompt": "Why does WHERE SUM(total) > 1000 fail with a syntax error?", "options": [ {"id":"a","text":"SUM is spelled wrong in Postgres"}, {"id":"b","text":"WHERE runs before rows are grouped, so there is nothing yet to sum at that point"}, {"id":"c","text":"Aggregate functions can never be used in SQL"}, {"id":"d","text":"WHERE only accepts text comparisons"} ], "correct": "b", "explanation": "WHERE filters individual rows before GROUP BY runs. An aggregate like SUM only makes sense once rows are grouped, which is why that check belongs in HAVING instead." } ] } ``` ## Join types, and finding "customers with no orders" ```sql -- INNER JOIN: only rows that match on both sides SELECT o.id, c.name FROM orders o INNER JOIN customers c ON o.customer_id = c.id; -- LEFT JOIN: every row from orders, NULL for customers with no match SELECT o.id, c.name FROM orders o LEFT JOIN customers c ON o.customer_id = c.id; -- FULL OUTER JOIN: every row from both sides, NULL wherever there's no match SELECT o.id, c.name FROM orders o FULL OUTER JOIN customers c ON o.customer_id = c.id; ``` `RIGHT JOIN` exists too, but it's rare in practice: it's almost always rewritten as a `LEFT JOIN` with the tables swapped, which reads more naturally. A classic follow-up, "find every customer with zero orders," is the standard **anti-join** pattern: left join, then filter for the side that came back empty. ```sql SELECT c.id, c.name FROM customers c LEFT JOIN orders o ON o.customer_id = c.id WHERE o.id IS NULL; ``` > **Remember:** "rows with no match" is a LEFT JOIN plus `WHERE right_side.id IS NULL`. That pattern, not a subquery, is the standard anti-join. ```knowledge-check { "questions": [ { "id": "backend-databases-optimization-join-q1", "type": "mcq", "prompt": "What is the standard way to find every customer who has placed zero orders?", "options": [ {"id":"a","text":"INNER JOIN customers to orders, then count"}, {"id":"b","text":"LEFT JOIN customers to orders, then filter WHERE the order side's key IS NULL"}, {"id":"c","text":"RIGHT JOIN orders to customers with no filter"}, {"id":"d","text":"There is no way to express this in SQL"} ], "correct": "b", "explanation": "A LEFT JOIN keeps every customer row even without a matching order, filling the order columns with NULL. Filtering for that NULL isolates exactly the customers with no match: the anti-join pattern." } ] } ``` ## N+1 queries: the same disease with or without an ORM An N+1 pattern is one query to fetch a list, then one more query per item in that list. It happens in raw SQL just as easily as through an ORM. ```python # N+1: one query for customers, then one MORE query per customer customers = db.execute("SELECT id, name FROM customers WHERE active = true").fetchall() for c in customers: orders = db.execute("SELECT * FROM orders WHERE customer_id = %s", [c["id"]]).fetchall() ``` The fix is a single JOIN, with the grouping done afterward in application code: ```python rows = db.execute( """ SELECT c.id AS customer_id, c.name, o.id AS order_id, o.total FROM customers c LEFT JOIN orders o ON o.customer_id = c.id WHERE c.active = true """ ).fetchall() from collections import defaultdict by_customer = defaultdict(lambda: {"name": None, "orders": []}) for row in rows: entry = by_customer[row["customer_id"]] entry["name"] = row["name"] if row["order_id"] is not None: entry["orders"].append({"id": row["order_id"], "total": row["total"]}) ``` This trades 500 round trips for exactly one, at the cost of some duplicated data over the wire (each order row repeats its customer's name) and a small grouping step in Python. For most read paths that's a clear win, but measure rather than assume: a join that fans out into millions of duplicated rows can end up worse than two well-indexed queries. The number that actually matters here is not query *execution* time, it's round trips. 500 queries at 0.5ms execution but 2ms of network latency each adds up to over a second of wall-clock time. One JOIN query, even if its own execution cost is higher than any single N+1 query, finishes in single-digit milliseconds because it pays that network cost exactly once. > **Remember:** N+1 is one query, then one more per row of the result. The fix is a single JOIN; the win comes from cutting round trips, not from making any one query faster. ```knowledge-check { "questions": [ { "id": "backend-databases-optimization-n1-q1", "type": "mcq", "prompt": "500 customers are fetched, then one extra query runs per customer to get their orders. What is the real cost of this pattern?", "options": [ {"id":"a","text":"The per-query execution time, which is usually the dominant cost"}, {"id":"b","text":"The network round trip repeated 500 times, which usually dwarfs each query's own execution time"}, {"id":"c","text":"Nothing; databases handle this pattern efficiently on their own"}, {"id":"d","text":"The extra disk space used by 500 separate queries"} ], "correct": "b", "explanation": "Each query might execute in under a millisecond, but the round trip to the database is paid 500 times. A single JOIN pays that round-trip cost once, which is why it wins even when its own execution is more expensive than any individual N+1 query." } ] } ``` 8b:T3645,Transactions are the second most-asked backend database topic, right after indexes. Every interviewer wants to know you understand ACID as more than an acronym, and can say exactly what breaks when two requests touch the same row at once. This lesson reproduces the classic bugs yourself, then writes a bank transfer that survives a crash mid-flight. ## ACID, and which letter Postgres actually tunes - **Atomicity**: a transaction is all-or-nothing. If one statement fails, every earlier statement in that transaction rolls back too. - **Consistency**: a transaction moves the database from one valid state to another. Constraints (foreign keys, checks, uniqueness) are never violated at commit. - **Isolation**: concurrent transactions behave as if they ran one after another, to a degree you control. This is the part interviewers actually probe, covered below. - **Durability**: once a transaction commits, it survives a crash. Postgres guarantees this with a write-ahead log (WAL), flushed to disk before the commit returns to you. Here's the trap: candidates recite ACID but can't say which letter is actually adjustable. Atomicity and durability are unconditional. Consistency comes from your constraints. Isolation is the only one with a dial you can turn. > **Remember:** atomicity and durability are unconditional guarantees. Isolation is the one knob Postgres actually lets you tune. ```knowledge-check { "questions": [ { "id": "backend-databases-transactions-acid-q1", "type": "mcq", "prompt": "Which ACID property is Postgres's isolation level actually controlling?", "options": [ {"id":"a","text":"Isolation, since atomicity and durability are unconditional and consistency comes from your own constraints"}, {"id":"b","text":"Atomicity"}, {"id":"c","text":"Durability"}, {"id":"d","text":"All four equally"} ], "correct": "a", "explanation": "Postgres always guarantees atomicity and durability, and consistency is whatever your constraints define. Isolation level is the one setting you actively choose, trading strictness for concurrency." } ] } ``` ## Isolation levels and the bugs each one allows Postgres has four isolation level names but only three distinct behaviors (`READ UNCOMMITTED` behaves exactly like `READ COMMITTED`). | Level | Dirty read | Non-repeatable read | Phantom read | Serialization anomaly | |---|---|---|---|---| | Read Committed (default) | No | Yes | Yes | Yes | | Repeatable Read | No | No | No | Yes | | Serializable | No | No | No | No | - **Dirty read**: reading a row another transaction wrote but hasn't committed yet. Postgres never allows this, at any level. - **Non-repeatable read**: you read the same row twice in one transaction and get two different values, because something else committed a change in between. - **Phantom read**: you re-run the same `WHERE` query and get a different *set* of rows, because another transaction inserted or deleted matching rows in between. - **Serialization anomaly**: the combined effect of several committed transactions could not have come from *any* one-at-a-time ordering of them, even though none of the three bugs above happened individually. Reproduce a non-repeatable read across two `psql` sessions: ```sql -- Session A BEGIN ISOLATION LEVEL READ COMMITTED; SELECT balance FROM accounts WHERE id = 1; -- returns 100 -- Session B, commits in between BEGIN; UPDATE accounts SET balance = 50 WHERE id = 1; COMMIT; -- Session A, same transaction, same query SELECT balance FROM accounts WHERE id = 1; -- now returns 50 COMMIT; ``` Switch session A to `REPEATABLE READ` and rerun: the second `SELECT` still returns `100`. Repeatable Read takes one consistent snapshot at the start of the transaction and reads from it for the whole transaction. Postgres does this with MVCC (multi-version concurrency control): every row keeps multiple versions, each tagged with the transaction that created it, and a reader only ever sees versions that were committed before its own snapshot began. An uncommitted version is invisible to everyone except the transaction that wrote it, which is exactly why a dirty read is structurally impossible in Postgres. > **Remember:** Postgres never allows a dirty read at any level, because MVCC keeps an uncommitted row version invisible to everyone but its own writer. Repeatable Read fixes non-repeatable reads by freezing a snapshot at the start of the transaction. ```knowledge-check { "questions": [ { "id": "backend-databases-transactions-isolation-q1", "type": "mcq", "prompt": "Why can Postgres skip READ UNCOMMITTED entirely and just treat it as READ COMMITTED?", "options": [ {"id":"a","text":"Because MVCC makes an uncommitted row version invisible to every transaction except the one that wrote it, so there is no cheap 'read whatever is there' mode to offer"}, {"id":"b","text":"Because dirty reads are actually allowed at every level in Postgres"}, {"id":"c","text":"Because Postgres does not support multiple isolation levels"}, {"id":"d","text":"Because READ UNCOMMITTED is faster and Postgres always picks the fastest option"} ], "correct": "a", "explanation": "MVCC keeps every uncommitted row version hidden from other transactions. There is no lower mode that could expose it, so READ UNCOMMITTED has nothing extra to offer and simply behaves like READ COMMITTED." } ] } ``` ## Savepoints: undoing part of a transaction A savepoint marks a point inside a transaction you can roll back to, without throwing away the whole transaction. ```sql BEGIN; INSERT INTO orders (id, customer_id, total) VALUES (501, 7, 250.00); SAVEPOINT before_discount; UPDATE promotions SET uses_remaining = uses_remaining - 1 WHERE code = 'SAVE10' AND uses_remaining > 0; -- if 0 rows updated, the promo was already exhausted: undo just that part ROLLBACK TO SAVEPOINT before_discount; -- the order insert is still intact COMMIT; ``` Django's nested `atomic()` blocks are built on savepoints: ```python from django.db import transaction, IntegrityError def place_order(customer_id, items, promo_code=None): with transaction.atomic(): # outer transaction order = Order.objects.create(customer_id=customer_id, total=0) for item in items: OrderLine.objects.create(order=order, **item) if promo_code: try: with transaction.atomic(): # this becomes a SAVEPOINT apply_promo(order, promo_code) except IntegrityError: pass # rolls back to the savepoint; the order still commits order.total = order.compute_total() order.save() return order ``` The inner `atomic()` is a savepoint, not a second real transaction. Django only opens one actual `BEGIN`/`COMMIT` pair, at the outermost `atomic()` block. > **Remember:** a nested `atomic()` in Django is a savepoint, not a new transaction. Only the outermost block opens the real `BEGIN`/`COMMIT`. ```knowledge-check { "questions": [ { "id": "backend-databases-transactions-savepoint-q1", "type": "mcq", "prompt": "An inner transaction.atomic() block in Django raises IntegrityError, which is caught. What happens to the outer transaction?", "options": [ {"id":"a","text":"The whole outer transaction rolls back, including work done before the inner block"}, {"id":"b","text":"Only the inner block's work rolls back, since it was a savepoint; the outer transaction continues and can still commit"}, {"id":"c","text":"Django raises a second exception and crashes"}, {"id":"d","text":"Nothing rolls back; the failed inner block's changes are kept anyway"} ], "correct": "b", "explanation": "A nested atomic() maps to a SAVEPOINT. Catching the exception and letting execution continue rolls back only to that savepoint, leaving everything before it in the outer transaction intact." } ] } ``` ## A bank transfer that survives a crash The textbook transaction example, and interviewers push on the failure modes: what if the process dies between the debit and the credit? What if two transfers race on the same account? ```python from django.db import transaction from django.db.models import F from decimal import Decimal class InsufficientFundsError(Exception): pass @transaction.atomic def transfer_funds(from_account_id: int, to_account_id: int, amount: Decimal): if amount <= 0: raise ValueError("amount must be positive") # lock both accounts in a fixed order (sorted by id) so two transfers # going in opposite directions can never deadlock on each other ids = sorted([from_account_id, to_account_id]) accounts = { a.id: a for a in Account.objects.select_for_update().filter(id__in=ids) } from_account = accounts[from_account_id] to_account = accounts[to_account_id] if from_account.balance < amount: raise InsufficientFundsError( f"account {from_account_id} has {from_account.balance}, needs {amount}" ) # F() pushes the arithmetic into the SQL UPDATE itself, so there's no # read-modify-write race even without the explicit lock above Account.objects.filter(id=from_account_id).update(balance=F("balance") - amount) Account.objects.filter(id=to_account_id).update(balance=F("balance") + amount) Transfer.objects.create( from_account_id=from_account_id, to_account_id=to_account_id, amount=amount, status="completed", ) ``` Four things make this crash-safe: 1. **`@transaction.atomic`** wraps everything in one `BEGIN`/`COMMIT`. If the process dies after the debit but before the credit, Postgres rolls the whole thing back on connection loss. Nothing is left half-done. 2. **`select_for_update()`** takes row-level locks on both accounts, so a concurrent transfer touching either one waits until this transaction commits or rolls back. 3. **Sorting the account IDs before locking** guarantees every transaction acquires locks in the same order. A transfer A to B and a transfer B to A both lock the lower ID first, so neither one ever holds a lock the other one needs while waiting for the one it holds, which is exactly how a deadlock forms. 4. **`F("balance") - amount`** pushes the read-and-write into one atomic SQL statement, immune to a lost update even for code that skips the explicit lock. > **Remember:** sort the IDs before locking. A fixed lock order across all transactions is what actually prevents deadlocks between transfers going in opposite directions. ```knowledge-check { "questions": [ { "id": "backend-databases-transactions-transfer-q1", "type": "mcq", "prompt": "Two concurrent transfers run: A pays B, and B pays A, at the same time. Why does sorting the account IDs before calling select_for_update() prevent a deadlock?", "options": [ {"id":"a","text":"It makes the transfers run one after another automatically"}, {"id":"b","text":"Every transaction locks accounts in the same fixed order, so neither transaction can be left holding one lock while waiting forever on a lock the other transaction already holds"}, {"id":"c","text":"Sorting has no effect on deadlocks; only serializable isolation prevents them"}, {"id":"d","text":"It only matters for accounts with the same balance"} ], "correct": "b", "explanation": "A deadlock needs two transactions each waiting on a lock the other holds. If every transaction locks the lower ID first, that circular wait can never form, because both transactions compete for the same first lock instead of each grabbing a different one." } ] } ``` ## Read Committed vs Serializable, in one interview answer Read Committed re-takes its snapshot before every statement, so within one transaction it can see other transactions' commits happen in between statements: that's where non-repeatable reads and phantoms come from. Serializable takes one snapshot at the start and also tracks read/write dependencies between concurrently running transactions. If committing would produce a result no one-at-a-time ordering could have produced, Postgres aborts one of the transactions with a serialization failure (error code `40001`), and the application has to retry it. Read Committed is Postgres's default because it never blocks on other readers and almost never aborts. Serializable trades some of that throughput, plus added retry logic in your application, for the strongest guarantee Postgres offers. > **Remember:** Read Committed never aborts you but allows more anomalies. Serializable allows none, at the cost of occasionally aborting a transaction that your code then has to retry. ```knowledge-check { "questions": [ { "id": "backend-databases-transactions-serializable-q1", "type": "mcq", "prompt": "What must application code do that plain Read Committed code does not need to do, when using Serializable isolation?", "options": [ {"id":"a","text":"Nothing different; Serializable is a drop-in replacement with no other changes needed"}, {"id":"b","text":"Catch a serialization failure (error 40001) and retry the transaction, since Postgres can abort one of two conflicting transactions rather than let an anomaly through"}, {"id":"c","text":"Manually call select_for_update on every table"}, {"id":"d","text":"Disable foreign key constraints"} ], "correct": "b", "explanation": "Serializable's guarantee comes from aborting a transaction when committing it would create an anomaly no serial ordering could produce. The application must be ready to catch that error and retry, which Read Committed code never has to do." } ] } ``` 8c:T39bd,Every backend engineer eventually ships a migration that locks a table in production. Interviewers ask about migrations to find out whether you've already learned that lesson, or you're about to learn it the hard way on their system. This lesson covers how Django migrations actually work, which schema changes are dangerous on a big table, and how to change a live table without an outage. ## How Django migrations actually work `makemigrations` compares your models against the last known state, tracked through migration files rather than the live database, and writes a Python file describing the difference. `migrate` applies pending migration files in dependency order and records which ones ran, in a `django_migrations` table. ```python # migrations/0007_add_phone_number.py from django.db import migrations, models class Migration(migrations.Migration): dependencies = [("accounts", "0006_alter_user_email")] operations = [ migrations.AddField( model_name="user", name="phone_number", field=models.CharField(max_length=20, blank=True, default=""), ), ] ``` Four habits interviewers expect you to name: - **One logical change per migration.** Don't bundle an unrelated index add with a column rename. A rollback should undo one thing, not three. - **Never edit a migration that has already run anywhere** (staging, a teammate's machine, production). Treat migration files as an append-only log. Editing an already-applied one desyncs `django_migrations`'s record from what actually happened. Write a new migration to fix a mistake instead. - **Keep migrations reversible when you can.** Implement `reverse_code` for a `RunPython` operation, so `migrate app 0006` actually works instead of throwing `IrreversibleError`. - **Read the generated SQL before running it in production**, with `python manage.py sqlmigrate accounts 0007`. This one habit turns "I think this is safe" into "I checked exactly what lock this takes." ```bash python manage.py makemigrations accounts python manage.py sqlmigrate accounts 0007 python manage.py migrate accounts ``` > **Remember:** run `sqlmigrate` before every production deploy. It's the difference between guessing a migration is safe and knowing exactly what lock it takes. ```knowledge-check { "questions": [ { "id": "backend-databases-migrations-workflow-q1", "type": "mcq", "prompt": "A migration was already applied on staging, and it turns out to be wrong. What should you do?", "options": [ {"id":"a","text":"Edit that migration file directly and re-run migrate everywhere"}, {"id":"b","text":"Write a new migration that fixes the problem, and leave the applied one untouched"}, {"id":"c","text":"Delete the migration file and hope Django regenerates it correctly"}, {"id":"d","text":"Manually edit rows in the django_migrations table instead"} ], "correct": "b", "explanation": "An applied migration is part of an append-only history. Editing it after the fact desyncs django_migrations's record from what environments actually ran. A new migration is the safe fix." } ] } ``` ## Why some migrations lock the whole table Changing a table's structure needs a lock. The real question to ask is not "will this work," it's "which lock does it take, and for how long." | Operation | Lock in Postgres | Danger on a large table | |---|---|---| | `ADD COLUMN`, nullable, no default | Metadata-only, near-instant (Postgres 11+) | Safe | | `ADD COLUMN` with a non-null default | Metadata-only on Postgres 11+ | Safe on 11+; check your version | | `ADD COLUMN` with a **volatile** default (like `uuid.uuid4`) | Full table rewrite | Dangerous: locks the whole table for the rewrite | | `ALTER COLUMN TYPE` | Full rewrite, exclusive lock | Dangerous on a large table | | `CREATE INDEX` (plain) | Blocks writes for the duration | Dangerous: use `CREATE INDEX CONCURRENTLY` instead | | `ADD CONSTRAINT NOT NULL` | Full scan to validate, holds a lock | Dangerous: split into `NOT VALID` plus a separate `VALIDATE CONSTRAINT` | | `ADD FOREIGN KEY` | Scans both tables to validate | Same fix: `NOT VALID`, then validate separately | The dangerous rows all take an `ACCESS EXCLUSIVE` lock, which blocks both writes *and* reads from every other connection while it's held. On a table with 50 million rows, a full rewrite can take minutes. During that window, your app effectively has an outage on anything touching that table. > **Remember:** the danger question is never "will this migration work," it's "what lock does it take, and for how long." `ACCESS EXCLUSIVE` blocks reads too, not just writes. ```knowledge-check { "questions": [ { "id": "backend-databases-migrations-locks-q1", "type": "mcq", "prompt": "Why is ADD COLUMN with a volatile default like uuid.uuid4 dangerous on a huge table, when a plain non-null default is safe on modern Postgres?", "options": [ {"id":"a","text":"There is no real difference; both are equally safe"}, {"id":"b","text":"A volatile default produces a different value per row, so Postgres must actually rewrite the whole table rather than making a fast, metadata-only change"}, {"id":"c","text":"UUIDs are always slower to compute than other data types"}, {"id":"d","text":"Volatile defaults are rejected by Postgres and never actually run"} ], "correct": "b", "explanation": "A constant default lets Postgres record the value once, as metadata. A volatile default must be computed separately for every existing row, which forces a full table rewrite under an ACCESS EXCLUSIVE lock." } ] } ``` ## Adding a required column to a huge table, safely Take the worst case: adding a `NOT NULL` column with a default to a huge, high-traffic table, without an outage. The trick is splitting one risky operation into several small, non-blocking ones, deployed one at a time. **Step 1: add the column, nullable, no default.** Fast, metadata-only. ```python migrations.AddField( model_name="order", name="status", field=models.CharField(max_length=20, null=True, blank=True), ) ``` **Step 2: backfill in small batches**, off the request path, never as one giant transaction. ```python def backfill_status(apps, schema_editor): Order = apps.get_model("orders", "Order") batch_size = 5000 last_id = 0 while True: batch = list( Order.objects.filter(id__gt=last_id, status__isnull=True) .order_by("id").values_list("id", flat=True)[:batch_size] ) if not batch: break Order.objects.filter(id__in=batch).update(status="pending") last_id = batch[-1] ``` Batching matters for two reasons. One giant `UPDATE` on 50 million rows holds row locks and generates a mountain of write-ahead log in a single transaction. And it's all-or-nothing: if it dies at row 40 million, you redo all 40 million. Batches of a few thousand commit independently and pick up from `last_id` if interrupted. **Step 3: add the `NOT NULL` constraint in two phases**, so the full-table scan does not block anything. ```sql -- Instant: doesn't scan existing rows, only enforces the rule on new writes ALTER TABLE orders ADD CONSTRAINT orders_status_not_null CHECK (status IS NOT NULL) NOT VALID; -- Scans the table but takes a lighter lock that never blocks reads or writes ALTER TABLE orders VALIDATE CONSTRAINT orders_status_not_null; ``` **Step 4: once confident**, backfill complete and the constraint validated, update the Django model to match. ```python migrations.AlterField( model_name="order", name="status", field=models.CharField(max_length=20, default="pending"), ) ``` Four small migrations, each either instant or non-blocking, instead of one migration that locks the whole table. Say this in an interview and name the sequence: "add nullable, backfill in batches so I never hold a long transaction or lock the whole table, then tighten to `NOT NULL` in a follow-up deploy once the backfill is confirmed complete." That sequencing, not any single line of code, is the actual thing being tested. > **Remember:** a required column on a huge table is four small migrations: add nullable, backfill in batches, add the constraint `NOT VALID`, then validate it. Never one big blocking migration. ```knowledge-check { "questions": [ { "id": "backend-databases-migrations-backfill-q1", "type": "mcq", "prompt": "Why split a NOT NULL constraint into ADD CONSTRAINT ... NOT VALID followed by a separate VALIDATE CONSTRAINT, instead of adding it directly?", "options": [ {"id":"a","text":"NOT VALID is only a syntax preference with no real effect"}, {"id":"b","text":"Adding it directly requires a full-table scan under a blocking lock; NOT VALID applies instantly and only enforces the rule going forward, while VALIDATE CONSTRAINT scans under a much lighter, non-blocking lock"}, {"id":"c","text":"VALIDATE CONSTRAINT is faster because it skips checking any rows"}, {"id":"d","text":"NOT VALID constraints are never actually enforced"} ], "correct": "b", "explanation": "Adding a validated constraint directly requires scanning the whole table while holding a blocking lock. Splitting it lets the instant NOT VALID step enforce new writes immediately, while the scan for existing rows happens later under a lock that doesn't block reads or writes." } ] } ``` ## Data migrations and the historical model trap A data migration transforms existing rows rather than the schema. Always fetch models through `apps.get_model`, never by importing the real model class directly: the historical model reflects the schema at that exact point in migration history, which matters once the real model gains fields or methods the migration was never written to expect. ```python def split_full_name(apps, schema_editor): User = apps.get_model("accounts", "User") for user in User.objects.filter(first_name="", last_name="").iterator(): parts = user.full_name.split(" ", 1) user.first_name = parts[0] user.last_name = parts[1] if len(parts) > 1 else "" user.save(update_fields=["first_name", "last_name"]) ``` `iterator()` avoids loading the whole queryset into memory at once, which matters once "existing data" means millions of rows. For very large tables, batch this the same way as the backfill above, rather than one unbounded `iterator()` pass inside a single migration transaction. > **Remember:** always fetch models through `apps.get_model` inside a data migration. It gives you the schema as it existed at that point in history, not whatever the real model currently looks like. ```knowledge-check { "questions": [ { "id": "backend-databases-migrations-datamigration-q1", "type": "mcq", "prompt": "Why does a data migration use apps.get_model('accounts', 'User') instead of importing the real User model directly?", "options": [ {"id":"a","text":"apps.get_model is faster to import"}, {"id":"b","text":"It returns a historical version of the model matching the schema at that point in migration history, which stays correct even after the real model gains new fields or methods later"}, {"id":"c","text":"Importing the real model is not allowed anywhere in Django"}, {"id":"d","text":"There is no difference between the two"} ], "correct": "b", "explanation": "A data migration might run long after it was written, against a codebase whose real model has since changed. apps.get_model gives back the model as it looked at that historical point, so the migration keeps working." } ] } ``` ## Zero-downtime migrations: expand, migrate, contract During a rolling deploy, old and new application code run against the *same* database at the same time, for as long as it takes instances to cycle through. A migration is zero-downtime only if both versions of the code work correctly against the schema at every point in that window. That rules out any single step that both adds and immediately requires a column. The standard technique is **expand/contract**: 1. **Expand**: add the new column or table, purely additive. Old code ignores it; nothing breaks. 2. **Migrate and dual-write**: deploy code that writes to both the old and new columns (or reads the new one with a fallback to the old), and backfill existing rows. 3. **Contract**: once every instance runs the new code and the backfill is done, remove the old column and the compatibility code. A column rename (`username` to `handle`) can never be a single `RENAME COLUMN` in a zero-downtime deploy, because old code would break the instant the old column disappeared: ```python # Expand: add handle, keep username migrations.AddField(model_name="user", name="handle", field=models.CharField(max_length=50, null=True)) # App code deployed after this: write to both def save_username(user, value): user.username = value user.handle = value user.save() # Backfill handle from username for existing rows (batched, as above) # Contract, only once every instance has stopped reading username: migrations.RemoveField(model_name="user", name="username") ``` The interview answer, said plainly: "Zero-downtime means both old and new code work against the schema during a rolling deploy. Expand adds new structure additively, dual-write and backfill keep both paths working while they coexist, and contract removes the old structure only once every instance is on the new code." Naming "expand/contract" is what signals you've actually done this, not just read about it once. > **Remember:** expand adds, contract removes. Never combine them into one step, or old code breaks the instant new code deploys. ```knowledge-check { "questions": [ { "id": "backend-databases-migrations-zerodowntime-q1", "type": "mcq", "prompt": "Why can't a column rename be done as a single RENAME COLUMN during a zero-downtime rolling deploy?", "options": [ {"id":"a","text":"RENAME COLUMN does not exist in Postgres"}, {"id":"b","text":"During the rollout window, old app code instances still expect the original column name, and it would already be gone"}, {"id":"c","text":"Renaming a column always requires downtime, regardless of deploy strategy"}, {"id":"d","text":"Django does not support RenameField as a migration operation"} ], "correct": "b", "explanation": "A rolling deploy runs old and new code side by side for a while. A single rename removes the old name immediately, breaking every old-code instance still reading it. Expand/contract keeps both names valid until every instance is on the new code." } ] } ``` 8d:T3d81,A category tree, an org chart, a threaded comment section: these are all the same shape, a hierarchy, and a database table with a flat list of rows is not naturally built for it. This lesson covers `ltree`, Postgres's own extension for tree-shaped data, then a set of concurrency-safety decisions that show up the moment you combine a tree with role-based permissions and real, simultaneous writers. This is the kind of "how did you actually handle X" follow-up that separates someone who has read about a topic from someone who has shipped it. ## Storing a tree: ltree and the alternatives `ltree` is a Postgres extension: a data type for tree-shaped data stored as dot-separated label paths, with real index support so you don't need a recursive query to walk it. ```sql CREATE EXTENSION ltree; CREATE TABLE categories ( id SERIAL PRIMARY KEY, path ltree ); INSERT INTO categories (path) VALUES ('Top'), ('Top.Science'), ('Top.Science.Biology'), ('Top.Science.Physics'), ('Top.Arts'), ('Top.Arts.Music'); ``` | Operator | Meaning | Example | |---|---|---| | `@>` | is ancestor of | `'Top' @> 'Top.Science'` is true | | `<@` | is descendant of | `'Top.Science' <@ 'Top'` is true | | `~` | matches a pattern | `path ~ 'Top.Science.*'` | ```sql -- every descendant of Top.Science SELECT path FROM categories WHERE path <@ 'Top.Science'; -- direct children only, exactly one level down SELECT path FROM categories WHERE path ~ 'Top.Science.*{1}'; ``` Read that first query as: "is this row's path a descendant of `Top.Science`?" Postgres checks each stored path and keeps only the ones nested somewhere underneath it. An index type called GiST supports every one of these tree operators, while a plain B-tree index only helps with equality and sorting, not "is this an ancestor of that": ```sql CREATE INDEX idx_path_gist ON categories USING GIST (path); ``` `ltree` is Postgres-only. Without it, three other approaches exist, each with a different trade-off: | Approach | Read | Write | Notes | |---|---|---|---| | Adjacency list (`parent_id` on each row) | Slow, needs a recursive query | Easy | Simple to write, but re-walks the tree from scratch on every read | | Materialized path (`'1.4.10'` as plain text, `LIKE '1.4.%'`) | Medium | Manual upkeep | Same idea as `ltree`, without an index built for it | | Nested sets (`lft`/`rgt` bounds per node) | Fast, a simple range query | Costly | Every insert or move has to renumber the affected subtree | The interview answer: `ltree` stores label-based tree paths and gives fast ancestor/descendant queries through a GiST index, avoiding a hand-written recursive query. Without it, you're choosing between recursion cost (adjacency list) and write cost (nested sets), so the right pick depends on your read/write ratio. > **Remember:** `ltree` is a Postgres extension for tree paths with GiST-indexed ancestor/descendant queries. An adjacency list is easy to write but slow to read deep; nested sets are fast to read but expensive to write. ```knowledge-check { "questions": [ { "id": "backend-databases-hierarchical-ltree-q1", "type": "mcq", "prompt": "Why does a plain B-tree index on an ltree column fail to speed up an 'is this a descendant of X' query?", "options": [ {"id":"a","text":"A B-tree only supports equality and sorting; it doesn't understand tree-relationship operators like <@ and @>, which need a GiST index instead"}, {"id":"b","text":"ltree columns cannot be indexed at all"}, {"id":"c","text":"B-tree indexes are always slower than GiST for every kind of query"}, {"id":"d","text":"Descendant queries do not use indexes in Postgres under any circumstances"} ], "correct": "a", "explanation": "A B-tree is built for equality and ordering comparisons. Ancestor/descendant checks are structural relationships that need GiST, which is why ltree columns are indexed with USING GIST, not a default B-tree." } ] } ``` ## Advisory checks vs authoritative triggers This is the pattern that repeats through everything else in this lesson: **application-level validation is advisory. A database constraint that runs inside the same transaction as the write is authoritative.** Python code cannot make a check-then-write sequence safe under concurrency without external locking, because two requests can both pass the check before either one commits. ```python # Advisory only — a race window exists between this check and the actual save() def clean(self): if self._would_create_cycle(): raise ValidationError("cycle detected") ``` ```sql -- Authoritative — runs inside the same transaction as the INSERT/UPDATE, no race window CREATE OR REPLACE FUNCTION check_no_cycle() RETURNS TRIGGER AS $$ BEGIN IF NEW.hierarchy_path <@ (SELECT parent_path FROM org_units WHERE id = NEW.parent_id) THEN RAISE EXCEPTION 'cycle detected: % would become an ancestor of itself', NEW.id; END IF; RETURN NEW; END; $$ LANGUAGE plpgsql; ``` Here's the race the Python-only version misses: two concurrent requests can each call `clean()`, each find no cycle because neither has committed yet, and both proceed to save. Together they create a cycle that neither individual check ever saw. A Postgres trigger runs inside the same transaction as the write itself, so it's the only place this check is actually race-free. Keep the Python check anyway. It gives a fast, friendly error in the common case, while the trigger is the backstop for the case where two requests land at nearly the same instant. The same split shows up anywhere you need a guarantee that holds no matter what wrote the data. Blocking `UPDATE`/`DELETE` inside a model's `save()`/`delete()` methods only works if every write goes through the ORM; a raw SQL client bypasses it completely. An audit log that must truly never change needs a Postgres trigger that rejects any `UPDATE`/`DELETE` outright, on top of the Django-layer guard: ```sql CREATE OR REPLACE FUNCTION prevent_audit_mutation() RETURNS TRIGGER AS $$ BEGIN RAISE EXCEPTION 'audit_log rows are immutable'; END; $$ LANGUAGE plpgsql; CREATE TRIGGER trg_audit_immutable_update BEFORE UPDATE ON audit_log FOR EACH ROW EXECUTE FUNCTION prevent_audit_mutation(); ``` > **Remember:** an app-level check and a database trigger are not doing the same job. The check is a fast, friendly error for the common case; the trigger is the only thing that's actually race-free. ```knowledge-check { "questions": [ { "id": "backend-databases-hierarchical-triggers-q1", "type": "mcq", "prompt": "Two concurrent requests each call a Python clean() method that checks for a cycle before saving. Why can a cycle still get created?", "options": [ {"id":"a","text":"Python's clean() method always has a bug"}, {"id":"b","text":"Both requests can run their check before either one commits, so each sees no cycle, and then both save, together creating one that neither check individually saw"}, {"id":"c","text":"Django does not support cycle detection"}, {"id":"d","text":"This can never actually happen in practice"} ], "correct": "b", "explanation": "An application-level check-then-write has a race window unless something serializes the two requests. A database trigger closes that window because it runs inside the same transaction as the write itself." } ] } ``` ## Scoped roles over a hierarchy: additive, not precedence When a role can be granted at any node of a tree, for example a role at `/company/sales` and a different role at `/company/sales/india`, you have to decide: do overlapping grants combine, or does the more specific one win? **Decision: additive (union) semantics, no precedence.** A user with a role at `/company/sales` and a different role at `/company/sales/india` gets the union of both roles' permissions inside `/company/sales/india`. This is simpler to reason about and to audit: "why can this user do X" is always "some ancestor scope granted it," never "which of two conflicting grants wins." Precedence can be added later through a priority field without breaking any existing grant, so leaving it out now is a safe thing to defer, not a corner you're cutting. > **Remember:** overlapping scoped roles add up; they don't override each other. That keeps "why can this user do X" answerable with one sentence instead of a precedence table. ```knowledge-check { "questions": [ { "id": "backend-databases-hierarchical-scoped-q1", "type": "mcq", "prompt": "A user has one role granted at /company/sales and a different role granted at /company/sales/india. Under additive scoped-role semantics, what permissions do they have inside /company/sales/india?", "options": [ {"id":"a","text":"Only the permissions from the more specific /company/sales/india role"}, {"id":"b","text":"The union of both roles' permissions, since ancestor and descendant scopes combine rather than override each other"}, {"id":"c","text":"Only the permissions from the /company/sales role"}, {"id":"d","text":"Neither role applies because they conflict"} ], "correct": "b", "explanation": "Additive semantics mean every scope that covers a given node contributes its permissions. There's no precedence to resolve, so the answer is always the union of every applicable grant." } ] } ``` ## Locking a subtree: lock the root, not every row Moving or soft-deleting a subtree needs to stop two concurrent operations from touching the same subtree at once. Locking the *entire descendant set* with `select_for_update()` can hold thousands of row locks for the whole transaction, blocking unrelated reads on nodes that were never actually in conflict. The fix: **lock only the subtree root.** The bulk `UPDATE` that follows acquires its own row locks as it goes, which is all it needs, since you don't have to pre-lock what the update will lock anyway. ```python def move_subtree(self, new_parent): with transaction.atomic(): # .exists() forces the query to actually run — a lazy queryset locks nothing OrgUnit.objects.select_for_update().filter(id=self.id).exists() ... ``` Two concrete bugs hide in that one line if you're not careful. First, a `select_for_update()` queryset that's never evaluated, never iterated or checked with `.exists()`, sends no lock request to Postgres at all: the lock silently does nothing. Second, locking every descendant instead of just the root is far more expensive than it needs to be for the same correctness. > **Remember:** lock the subtree root, not every descendant. A `select_for_update()` queryset does nothing until something forces it to actually run, like `.exists()`. ```knowledge-check { "questions": [ { "id": "backend-databases-hierarchical-locking-q1", "type": "mcq", "prompt": "Why is calling OrgUnit.objects.select_for_update().filter(id=self.id) alone, without .exists() or iterating it, a silent bug?", "options": [ {"id":"a","text":"It raises an exception immediately"}, {"id":"b","text":"A queryset is lazy: it sends no query to Postgres, and therefore requests no lock, until something forces it to evaluate"}, {"id":"c","text":"select_for_update() only works inside Celery tasks"}, {"id":"d","text":"It locks every row in the entire table instead of just one"} ], "correct": "b", "explanation": "Django querysets don't hit the database until evaluated. A select_for_update() call that's never iterated or checked never actually runs, so no lock is ever taken, and the code silently isn't safe under concurrency." } ] } ``` ## Soft delete, expiring grants, and the partial index Postgres won't let you write A naive "currently active" query on a scoped role filters only `deleted_at IS NULL`. But a role assignment with a past `expires_at` looks soft-deleted in every way that matters, without actually being soft-deleted, and it still passes that filter, silently granting access that should have lapsed. The fix is one canonical queryset method that every permission check goes through, instead of trusting every call site to remember both conditions: ```python class ScopedRoleAssignmentQuerySet(models.QuerySet): def currently_active(self): return self.filter( models.Q(expires_at__isnull=True) | models.Q(expires_at__gt=timezone.now()) ) ``` This is the same "one blessed path, not a convention every caller has to remember" principle as a shared response helper or a single auth-check function. A permission leak from a forgotten `.filter()` is a security bug, not a style nit. A related trap: `ActiveManager.get_queryset()` returning a plain `models.QuerySet` looks fine until someone chains `.filter(...).delete()`. The *type* of the returned queryset decides whether that `.delete()` does a soft delete or a real SQL `DELETE`. Building the manager from a custom queryset subclass keeps soft-delete semantics all the way down any chain: ```python class SoftDeleteQuerySet(models.QuerySet): def delete(self): return self.update(deleted_at=timezone.now(), updated_at=timezone.now()) def hard_delete(self): return super().delete() ActiveManager = models.Manager.from_queryset(SoftDeleteQuerySet) ``` Django's `auto_now=True` only fires on `.save()`. A bulk `.update()`, which any queryset-level soft delete has to use, silently skips it. Any custom `.delete()` override on a queryset has to set `updated_at` explicitly, or every soft-deleted row ends up with a stale timestamp. Now the indexing question: a composite index on `(user_id, deleted_at)` still leaves `expires_at` as a check done after the index scan. The instinct is a partial index with `WHERE expires_at > now()`. Postgres rejects this, because a partial index's condition is evaluated once, at the moment the index is defined, and `now()` changes every time it's called, so it can never be an immutable condition. The workable partial index instead targets the *permanent* grants, which have no time-based condition at all: ```sql CREATE INDEX scoped_role_user_permanent_active_idx ON scoped_role_assignment (user_id) WHERE deleted_at IS NULL AND expires_at IS NULL; ``` Grants that do expire fall back to the regular composite index. Being able to explain *why* they can't get the same partial-index treatment is the actually interview-worthy part of this answer, not just knowing partial indexes exist. > **Remember:** a partial index's `WHERE` clause must be immutable. `expires_at > now()` fails that test, since `now()` changes every call; only a condition on fixed columns like `expires_at IS NULL` works. ```knowledge-check { "questions": [ { "id": "backend-databases-hierarchical-partialindex-q1", "type": "mcq", "prompt": "Why does Postgres reject a partial index with the condition WHERE expires_at > now()?", "options": [ {"id":"a","text":"Partial indexes cannot use comparison operators"}, {"id":"b","text":"A partial index's condition is fixed once, at definition time, but now() returns a different value on every call, so it can never be a stable, immutable condition"}, {"id":"c","text":"expires_at is not allowed to be indexed at all"}, {"id":"d","text":"Postgres actually allows this; the example is describing a nonexistent restriction"} ], "correct": "b", "explanation": "A partial index needs a condition that's true or false forever once the index is built. now() is not immutable, so Postgres can't evaluate it once and rely on that answer staying correct. A condition on fixed columns, like expires_at IS NULL, works fine." } ] } ``` 8e:T31c3,Redis shows up in nearly every backend system design interview as "put a cache in front of the database." The follow-up questions, invalidation, stampedes, eviction, are where most candidates fall apart. This lesson covers the data structures that actually matter, a real cache-aside implementation, a Redis-backed rate limiter, and what happens when Redis itself runs out of memory. ## Redis data structures and when to use each | Type | Use it for | |---|---| | **String** | A simple cached value, a counter (`INCR`), a feature flag | | **Hash** | Object-like data, a user profile, where you want to read or update one field without touching the rest | | **List** | A queue, or a capped recent-activity feed (`LPUSH` plus `LTRIM`) | | **Set** | Unique membership checks: "has this user already done X" | | **Sorted Set (ZSET)** | Anything ranked by a number: leaderboards, rate-limit windows | | **Stream** | An append-only event log with consumer groups, a lightweight Kafka | ```python import redis r = redis.Redis(host="localhost", port=6379, decode_responses=True) r.set("user:42:name", "Ada", ex=300) # string, expires in 300s r.hset("user:42", mapping={"name": "Ada", "plan": "pro"}) # hash: update one field, leave the rest r.zadd("leaderboard", {"user:42": 1500}) # sorted set: O(log n) insert, ranked reads r.zrevrange("leaderboard", 0, 9, withscores=True) # top 10 ``` > **Remember:** pick the Redis type that matches the *access pattern* you need, not just "can this data fit in a string." A leaderboard is a sorted set because you need ranked reads, not just storage. ```knowledge-check { "questions": [ { "id": "backend-systems-rediscaching-types-q1", "type": "mcq", "prompt": "Why store a user's profile fields in a Redis hash instead of one JSON string?", "options": [ {"id":"a","text":"Hashes are always faster to read than strings, regardless of access pattern"}, {"id":"b","text":"A hash lets you read or update one field directly, without deserializing and re-serializing the entire object for every small change"}, {"id":"c","text":"Strings cannot hold more than 100 characters in Redis"}, {"id":"d","text":"Hashes automatically expire after one hour"} ], "correct": "b", "explanation": "A hash exposes per-field access (HSET/HGET on one field). A JSON string forces you to load and re-parse the whole blob even to change a single field." } ] } ``` ## Cache-aside: the default pattern The application checks the cache first, falls back to the source of truth on a miss, and fills the cache for next time. ```python CACHE_TTL_SECONDS = 300 def get_user(user_id: int, db) -> dict: cache_key = f"user:{user_id}" cached = r.get(cache_key) if cached is not None: return json.loads(cached) # hit — no DB round trip user = db.query_one("SELECT id, name, email FROM users WHERE id = %s", [user_id]) if user is None: return None r.set(cache_key, json.dumps(user), ex=CACHE_TTL_SECONDS) return user def update_user(user_id: int, fields: dict, db) -> None: db.execute("UPDATE users SET name = %s WHERE id = %s", [fields["name"], user_id]) r.delete(f"user:{user_id}") # invalidate — don't rewrite in place ``` **Why delete on write, instead of updating the cache in place?** Updating the cache to match a write means every single write path must remember to keep the cache in sync. One forgotten spot leaves stale data forever. Deleting is simpler and self-healing: the very next read repopulates the cache from the real source of truth. **Cache stampede** is the other classic failure. If one hot key expires and a thousand requests all miss at the same instant, all thousand hit the database at once to refill it. Mitigate with a short lock around the refill, jittered TTLs so keys don't all expire in the same second, or serving the stale value while one request refreshes it in the background. > **Remember:** on write, delete the cache key, don't overwrite it. The next read repopulates from the real source of truth, which is simpler than keeping two copies in sync forever. ```knowledge-check { "questions": [ { "id": "backend-systems-rediscaching-aside-q1", "type": "mcq", "prompt": "Why does update_user() delete the cache key instead of writing the new value into the cache directly?", "options": [ {"id":"a","text":"Deleting is always faster than a SET call"}, {"id":"b","text":"Overwriting the cache requires every write path to correctly mirror the write logic; a forgotten path leaves stale data forever, while deleting is simple and self-healing on the next read"}, {"id":"c","text":"Redis does not allow overwriting an existing key"}, {"id":"d","text":"Deleting uses less memory than any SET call"} ], "correct": "b", "explanation": "Delete-on-write means the next read always goes back to the real source of truth. Update-in-place requires every write path to remember to keep the cache correct, which is easy to get wrong in one forgotten corner of the codebase." } ] } ``` ## Eviction policies: what happens when Redis runs out of memory Once Redis hits its configured `maxmemory`, it has to free space for a new write. Which key it throws away is the eviction policy. | Policy | Behavior | |---|---| | `noeviction` | Reject the write with an error instead of evicting anything | | `allkeys-lru` / `allkeys-lfu` | Evict least-recently / least-frequently used, across every key | | `volatile-lru` / `volatile-lfu` / `volatile-ttl` | Same idea, but only considers keys that already have a TTL set | | `allkeys-random` | Evict a random key | The choice depends on what Redis is holding. If Redis is a pure cache, everything in it is disposable and can be rebuilt from the database, so an `allkeys-*` policy is safe. If Redis mixes disposable cache data with data you actually need to keep, like session state or queue contents, use a `volatile-*` policy instead: only the keys you deliberately gave a TTL become eligible for eviction, and anything without one is never silently dropped under memory pressure. > **Remember:** if Redis only holds a cache, `allkeys-*` is safe. If it also holds data you can't afford to lose, use `volatile-*` so only your TTL'd cache keys are ever evicted. ```knowledge-check { "questions": [ { "id": "backend-systems-rediscaching-eviction-q1", "type": "mcq", "prompt": "A Redis instance holds both disposable cache entries (with a TTL) and session data (no TTL) that must never be silently dropped. Which eviction policy fits?", "options": [ {"id":"a","text":"allkeys-lru, since it evicts across every key regardless of TTL"}, {"id":"b","text":"volatile-lru, since it only considers keys that already have a TTL set, leaving the untimed session data alone"}, {"id":"c","text":"noeviction, so nothing is ever evicted under any circumstances"}, {"id":"d","text":"allkeys-random, since randomness is fair to every key"} ], "correct": "b", "explanation": "A volatile-* policy only evicts keys that were given an explicit TTL. Mixing cache data (TTL'd) with data you must keep (no TTL) is exactly the case this policy is built for." } ] } ``` ## A distributed lock, and its real problems `SET key value NX PX ttl` sets a key only if it doesn't already exist (`NX`), with an expiry in milliseconds (`PX`) so a crashed holder doesn't lock everyone out forever. ```python import uuid def acquire_lock(r: redis.Redis, lock_name: str, ttl_ms: int = 5000) -> str | None: token = str(uuid.uuid4()) # unique per attempt, needed to release safely acquired = r.set(f"lock:{lock_name}", token, nx=True, px=ttl_ms) return token if acquired else None # Release must be one atomic check-and-delete — a plain GET then DEL from Python has a race window RELEASE_LOCK_SCRIPT = """ if redis.call("GET", KEYS[1]) == ARGV[1] then return redis.call("DEL", KEYS[1]) else return 0 end """ def release_lock(r: redis.Redis, lock_name: str, token: str) -> bool: return r.eval(RELEASE_LOCK_SCRIPT, 1, f"lock:{lock_name}", token) == 1 ``` Here's why the token matters: without it, process A acquires the lock, runs longer than the TTL, and the lock expires while A is still working. Process B then acquires it. When A finally finishes, a plain `DEL` would release a lock A no longer owns, letting a third process C grab it while B still believes it's the only holder. Checking the token before deleting closes that window. What interviewers actually want you to say: a single Redis instance's lock is **not** safe across a failover. If the primary crashes right after granting a lock, before replicating it to a replica, and that replica gets promoted, a second client can acquire the "same" lock, because the new primary never saw it. Treat this as a best-effort optimization, not a correctness guarantee, unless you specifically implement and understand a multi-instance quorum protocol like Redlock. > **Remember:** release a lock with a token-checked script, never a plain `DEL`. A single Redis instance's lock is best-effort, not safe across a failover. ```knowledge-check { "questions": [ { "id": "backend-systems-rediscaching-lock-q1", "type": "mcq", "prompt": "Why must releasing a Redis lock be a Lua script that checks the token, rather than a plain DEL?", "options": [ {"id":"a","text":"A plain DEL is slower than a Lua script"}, {"id":"b","text":"A slow holder's lock can expire and be re-acquired by another process; a plain DEL would then release the new holder's lock instead of just its own"}, {"id":"c","text":"Redis does not support DEL on keys with a TTL"}, {"id":"d","text":"Lua scripts are required for every Redis command"} ], "correct": "b", "explanation": "If the original holder's TTL expires before it finishes, another client can acquire the same key. A plain DEL then releases whatever is currently there, not necessarily your own lock. Checking the token first makes the release conditional on still being the true owner." } ] } ``` ## A sliding-window rate limiter A fixed-window counter (`INCR` plus `EXPIRE`) is cheap but allows a burst of up to twice the limit across a window boundary: once right before the window resets, once right after. ```python def is_rate_limited_sliding(r: redis.Redis, user_id: int, limit: int = 100, window_seconds: int = 60) -> bool: key = f"ratelimit:sliding:{user_id}" now = time.time() pipe = r.pipeline() pipe.zremrangebyscore(key, 0, now - window_seconds) # drop entries older than the window pipe.zadd(key, {str(uuid.uuid4()): now}) # record this request pipe.zcard(key) # count requests in the window pipe.expire(key, window_seconds) _, _, count, _ = pipe.execute() return count > limit ``` `r.pipeline()` batches these four commands into a single round trip. That's worth naming as a general Redis technique beyond rate limiting: fewer round trips, and Redis runs a pipeline's commands without another client's commands interleaved in between, though it is not a single atomic step the way a Lua script is. For true atomicity under heavy concurrent access to the same key, move this logic into a Redis Lua script so the whole read-check-write happens as one atomic step on the server. > **Remember:** a fixed-window counter allows a 2x burst at the window boundary. A sorted set that prunes old entries before counting fixes that at the cost of more memory per key. ```knowledge-check { "questions": [ { "id": "backend-systems-rediscaching-ratelimit-q1", "type": "mcq", "prompt": "What is the specific weakness of a fixed-window rate limiter (INCR plus EXPIRE) that a sliding-window sorted set fixes?", "options": [ {"id":"a","text":"Fixed windows cannot be implemented in Redis at all"}, {"id":"b","text":"A client can send up to double the limit by bursting right before a window resets and again right after, since the two windows are counted independently"}, {"id":"c","text":"INCR is not atomic, so counts can be lost"}, {"id":"d","text":"Fixed windows use more memory than sorted sets"} ], "correct": "b", "explanation": "A fixed window resets its count to zero at a clock boundary, with no memory of requests just before it. A burst at the very end of one window plus a burst at the very start of the next can total nearly double the limit in a short span." } ] } ``` 8f:T1e6e,Redis interviews rarely stop at "it's a key-value store." Interviewers want to see you pick the right data structure for a real feature, a leaderboard, a live feed, a rate limiter, and reason about what happens when Redis restarts or dies mid-write. This lesson covers sorted sets, streams, pub/sub, and the two persistence mechanisms behind Redis's durability story. ## Sorted sets: the leaderboard data structure A sorted set (`ZSET`) stores unique members, each with a floating-point score, always kept in score order, with fast inserts and fast range reads. That is exactly a leaderboard's access pattern: update a score, read the top N, look up one person's rank. ```python r.zadd("leaderboard:weekly", {"user:42": 1500}) # insert or overwrite a score r.zincrby("leaderboard:weekly", 250, "user:42") # += 250, atomically top10 = r.zrevrange("leaderboard:weekly", 0, 9, withscores=True) rank = r.zrevrank("leaderboard:weekly", "user:42") # 0-indexed, descending score = r.zscore("leaderboard:weekly", "user:42") ``` Under the hood, a sorted set is a skip list plus a hash table. The hash table gives a fast lookup by member name; the skip list gives fast ordered range scans. That combination is why adding a score, reading a score, and reading a range are all fast. Asking "how would you build a leaderboard without Redis" is really asking whether you see this trade-off: a plain SQL table with `ORDER BY score` needs an index scan and effectively re-sorts on every write-heavy update, while a skip list keeps its order incrementally as scores change. > **Remember:** a sorted set is a skip list plus a hash table. The hash table gives fast lookups by name; the skip list gives fast ordered ranges. That's why it fits a leaderboard so well. ```knowledge-check { "questions": [ { "id": "backend-systems-redisadvanced-zset-q1", "type": "mcq", "prompt": "Why does a Redis sorted set fit a leaderboard better than a SQL table with ORDER BY on a score column?", "options": [ {"id":"a","text":"SQL cannot sort by a numeric column"}, {"id":"b","text":"A sorted set's skip list keeps its order incrementally as scores change, instead of re-sorting the whole result on every read the way a plain ORDER BY effectively does under heavy writes"}, {"id":"c","text":"Sorted sets can only hold up to 100 members"}, {"id":"d","text":"SQL tables cannot store floating-point scores"} ], "correct": "b", "explanation": "The skip list structure underneath a sorted set maintains order as data changes, giving fast ranked reads without a fresh sort each time. A SQL index scan with ORDER BY has to redo more work as the underlying data changes frequently." } ] } ``` ## Streams: durable, replayable logs `XADD` appends an immutable entry to a stream. Unlike pub/sub, entries persist and can be replayed. Consumer groups let several workers split a stream's entries without duplicating work, and each entry is acknowledged only once it's actually processed, giving at-least-once delivery with retry on crash. ```python r.xadd("events:orders", {"order_id": "501", "status": "created"}) # producer r.xgroup_create("events:orders", "order-processors", id="0", mkstream=True) # once while True: resp = r.xreadgroup( "order-processors", "worker-1", {"events:orders": ">"}, count=10, block=5000, ) for stream, entries in resp or []: for entry_id, fields in entries: process(fields) r.xack("events:orders", "order-processors", entry_id) # confirm processed ``` If `worker-1` crashes after reading an entry but before acking it, that entry sits in the group's Pending Entries List. `XCLAIM`/`XAUTOCLAIM` let another worker take over stale pending entries after a timeout. This mechanism is exactly what an interviewer is checking for with "how do you not lose messages if a consumer dies." The critical distinction from pub/sub: **pub/sub has no persistence and no replay.** A message published while a subscriber is disconnected is gone the instant it's sent, since Redis never buffers it. Use pub/sub for ephemeral broadcast, typing indicators, live cursors. Use streams when a consumer must never miss an event. > **Remember:** streams persist and can be replayed, with a pending-entries list to recover a crashed consumer's work. Pub/sub delivers only to whoever is listening right now, and drops everything else. ```knowledge-check { "questions": [ { "id": "backend-systems-redisadvanced-streams-q1", "type": "mcq", "prompt": "A subscriber is disconnected for 10 seconds while messages are published. What happens to those messages under pub/sub versus a stream with a consumer group?", "options": [ {"id":"a","text":"Both pub/sub and streams deliver the missed messages once the subscriber reconnects"}, {"id":"b","text":"Pub/sub loses those messages permanently; a stream keeps them, so the consumer can read them once it reconnects and catches up"}, {"id":"c","text":"Streams lose the messages, but pub/sub keeps them"}, {"id":"d","text":"Neither mechanism can recover from a disconnect of any length"} ], "correct": "b", "explanation": "Pub/sub is fire-and-forget with no buffering: a message sent while nobody is listening is gone. A stream persists every entry, so a reconnecting consumer group member can pick up exactly where it left off." } ] } ``` ## Redis persistence: RDB and AOF Two mechanisms, often combined: - **RDB (snapshotting)**: a periodic point-in-time dump of the whole dataset to disk. Fast to restart from and compact to back up, but any writes since the last snapshot are lost on a crash. - **AOF (append-only file)**: every write command is logged, and replayed on restart. The default, `appendfsync everysec`, fsyncs once a second, so at most one second of writes is lost on a hard crash; `always` fsyncs every single write, durable but much slower. The interview answer for "what is Redis persistence": RDB trades durability for fast restarts and small backups. AOF trades some write throughput for a small, bounded data-loss window. Production setups commonly run both: RDB for fast full recovery, AOF for minimizing loss between snapshots. For failure recovery beyond a single instance, run Redis Sentinel or Redis Cluster: Sentinel monitors a primary and its replicas and promotes a replica if the original stops responding, notifying clients over pub/sub. The broader rule: never treat Redis as the source of truth for data you can't afford to lose. A cache miss should always be able to fall back to Postgres; anything Redis alone holds, session state, rate-limit counters, should tolerate being reset. > **Remember:** RDB is fast restarts with a bigger loss window; AOF is a small loss window with more write overhead. Production systems commonly run both together. ```knowledge-check { "questions": [ { "id": "backend-systems-redisadvanced-persistence-q1", "type": "mcq", "prompt": "A Redis instance uses RDB snapshots only, taken every 15 minutes, and then crashes. How much data can be lost?", "options": [ {"id":"a","text":"None; RDB never loses data"}, {"id":"b","text":"Up to everything written since the last snapshot, since RDB only captures the dataset at fixed points in time"}, {"id":"c","text":"Exactly one second of writes"}, {"id":"d","text":"Only writes made in the final millisecond before the crash"} ], "correct": "b", "explanation": "RDB is a point-in-time dump. Anything written after the last snapshot exists only in memory, so a crash before the next snapshot loses that entire window, in this case up to 15 minutes' worth of writes." } ] } ``` 90:T55f2,Picture a waiter who takes your order, then stands at your table while the kitchen cooks it, blocking every other customer from being served. That is a web server that does slow work inside the request itself: sending an email, generating a report, running a model. Once one request takes 10 seconds, everything behind it queues up too. A background worker is the fix: the waiter drops your order in the kitchen and immediately moves to the next table. Celery is the standard Python answer to this problem, and interviews push past "I used `@shared_task`" into the two things that actually break in production: a task running twice, and a worker dying mid-task. This lesson builds both answers with real mechanisms, then covers routing, chains, and how Celery compares to a couple of common alternatives. ## Celery's moving pieces Celery has three parts: - **Broker** (Redis or RabbitMQ): a message queue holding tasks waiting to run. Your app pushes a task message here; it never runs the task itself. - **Worker(s)**: separate processes that pull messages off the broker and execute the task function. You can run many workers, on many machines, all consuming from the same queue. - **Result backend** (optional: Redis, a database): stores a task's return value and state, if something later needs to check on it. ```python from celery import Celery app = Celery( "myproject", broker="redis://localhost:6379/0", backend="redis://localhost:6379/1", # a separate Redis DB index from the broker ) ``` The web app never talks to a worker directly. It serializes the task's name and arguments into a message and publishes it to the broker. Some worker, possibly on a different machine, picks it up whenever it's free. That decoupling is the entire point: the request returns immediately, and the real work scales independently of your web tier. > **Remember:** the broker holds pending work, the worker runs it, and the result backend (if configured) remembers what happened. The web app only ever talks to the broker. ```knowledge-check { "questions": [ { "id": "backend-systems-celery-architecture-q1", "type": "mcq", "prompt": "In a Celery setup, what does the web application actually do when it calls a task?", "options": [ {"id":"a","text":"It runs the task function directly in the request thread"}, {"id":"b","text":"It serializes the task name and arguments into a message and publishes it to the broker, then returns immediately without waiting for the work to finish"}, {"id":"c","text":"It opens a direct network connection to a specific worker process"}, {"id":"d","text":"It writes the task's code to disk for a worker to compile later"} ], "correct": "b", "explanation": "The web app is decoupled from execution entirely. It hands a message to the broker and moves on; whichever worker is free picks the message up later." } ] } ``` ## Retry with backoff, and why jitter matters ```python @app.task( bind=True, max_retries=5, autoretry_for=(requests.RequestException,), retry_backoff=True, # 1s, 2s, 4s, 8s... retry_backoff_max=60, retry_jitter=True, # randomize so many failed tasks don't retry in lockstep ) def send_webhook(self, url: str, payload: dict): response = requests.post(url, json=payload, timeout=5) response.raise_for_status() return response.status_code ``` `retry_jitter` is the detail interviewers listen for. Without it, if 1,000 tasks fail at the same moment, say a downstream service blips, they all retry at exactly the same backed-off intervals, producing a synchronized retry storm that can re-crash the very service they're retrying against. Jitter spreads that storm out over time instead. For cases needing custom logic instead of `autoretry_for`: ```python @app.task(bind=True, max_retries=5) def process_payment(self, payment_id: int): try: _charge_provider(payment_id) except TransientProviderError as exc: raise self.retry(exc=exc, countdown=2 ** self.request.retries) except PermanentProviderError: raise # this will never succeed no matter how many times you retry — fail loudly ``` > **Remember:** add jitter to every backoff. Without it, a thousand tasks failing together retry together, turning a blip into a second, synchronized outage. ```knowledge-check { "questions": [ { "id": "backend-systems-celery-retry-q1", "type": "mcq", "prompt": "1,000 Celery tasks fail at the same instant because a downstream service is briefly overloaded. Why does retry_jitter matter here?", "options": [ {"id":"a","text":"Without jitter, all 1,000 tasks retry at the exact same backed-off intervals, creating a synchronized retry storm that can re-crash the recovering service"}, {"id":"b","text":"Jitter makes each individual retry succeed"}, {"id":"c","text":"Jitter is only relevant for tasks that never fail"}, {"id":"d","text":"Without jitter, Celery refuses to retry at all"} ], "correct": "a", "explanation": "Backoff alone spaces out one task's own retries, but if every task computes the same delay from the same failure moment, all of them still retry together. Jitter breaks that synchronization." } ] } ``` ## Idempotency: the number one Celery interview question The premise behind "how do you ensure idempotency" is that Celery's default guarantee is at-least-once delivery, not exactly-once. A worker can execute a task, crash before acknowledging it to the broker, and the broker redelivers it to another worker: now it has run twice. The fix is making the task's *effect* idempotent, not trying to prevent redelivery, which you can't reliably do: ```python @app.task(bind=True, max_retries=3) def charge_customer(self, order_id: int, idempotency_key: str): # dedup guard BEFORE the side effect, not after was_processed = redis_client.set(f"processed:{idempotency_key}", "1", nx=True, ex=86400) if not was_processed: return # already handled this exact request — no-op, not an error order = Order.objects.get(id=order_id) payment_provider.charge(order.total, reference=idempotency_key) order.status = "paid" order.save() ``` Two standard mechanisms: an **idempotency key plus a dedup store** (shown above, checked before the side effect happens), or **natural idempotency**, designing the operation so running it twice has the same result as running it once. `UPDATE orders SET status = 'shipped' WHERE id = %s` is naturally idempotent. `INSERT INTO shipments ...` is not, unless you add a unique constraint on `order_id` and catch the conflict. > **Remember:** you can't reliably stop a redelivery, so the dedup check happens before the side effect, using a key generated once by the caller, not once per retry. ```knowledge-check { "questions": [ { "id": "backend-systems-celery-idempotency-q1", "type": "mcq", "prompt": "Why does the dedup check in charge_customer() happen before payment_provider.charge(), rather than after?", "options": [ {"id":"a","text":"Order doesn't matter, since Redis is always fast enough"}, {"id":"b","text":"If the check ran after the charge, a redelivered task would charge the customer again before the dedup key ever got set, defeating the whole purpose of the guard"}, {"id":"c","text":"Checking after would make the function run faster"}, {"id":"d","text":"Celery requires all Redis calls to happen at the start of a task"} ], "correct": "b", "explanation": "The guard has to block the side effect itself. Checking or setting the dedup key after the charge already happened would let a redelivered task charge the customer a second time before the guard ever takes effect." } ] } ``` ## What happens when a worker dies This depends entirely on **acknowledgment mode**. - **Early ack (the default)**: the worker acks the message as soon as it *starts* the task. If the worker dies mid-task, the message is already gone from the broker: the task is silently lost. Fine for best-effort, non-critical work. - **Late ack (`task_acks_late=True`)**: the worker acks only *after* the task finishes. If the worker crashes mid-task, the broker never got an ack, so it redelivers the message to another worker. Safer for critical work, but it means a task that crashes the worker itself will be retried, which is exactly why the task body must be idempotent. ```python app.conf.task_acks_late = True app.conf.worker_prefetch_multiplier = 1 # don't let a slow/crashing worker hoard several tasks at once ``` `worker_prefetch_multiplier = 1` matters alongside late-ack: with the default prefetch, a worker reserves several tasks at once, and if it crashes, *all* of those reserved-but-unstarted tasks get redelivered together, potentially all landing on one already-busy worker. > **Remember:** early ack can silently lose a task on worker crash; late ack redelivers it but requires the task to be idempotent. Pick late ack plus `prefetch_multiplier=1` for anything that must actually complete. ```knowledge-check { "questions": [ { "id": "backend-systems-celery-ack-q1", "type": "mcq", "prompt": "task_acks_late=True is set, and a worker crashes halfway through a task. What happens?", "options": [ {"id":"a","text":"The task is lost permanently, since the ack already happened"}, {"id":"b","text":"The broker never received an ack, so it redelivers the task to another worker, meaning the task body must be safe to run again"}, {"id":"c","text":"Celery automatically pauses all other tasks until the crash is investigated"}, {"id":"d","text":"The task result backend deletes the task record"} ], "correct": "b", "explanation": "Late ack only confirms completion after the task finishes. A crash mid-task means no ack was ever sent, so the broker treats the message as undelivered and hands it to another worker, which can re-run a task that already did partial work." } ] } ``` ## Task routing and priority queues By default every task goes to one queue and any worker can pick it up. Routing sends different tasks to different queues, so a dedicated pool of workers can handle slow tasks (video processing) separately from fast ones (sending an email). Otherwise, one slow task blocks a worker that could have cleared ten fast ones in the meantime. ```python task_routes = { "orders.tasks.send_receipt_email": {"queue": "fast"}, "orders.tasks.generate_invoice_pdf": {"queue": "slow"}, } ``` ```bash celery -A myproject worker -Q fast --concurrency=8 -n fast@%h celery -A myproject worker -Q slow --concurrency=2 -n slow@%h ``` Celery has no true priority *within* a queue on Redis by default; it's FIFO. To get priority, either run separate queues per priority tier, as shown above, or switch to RabbitMQ as the broker, which supports a real per-message priority field. The interview answer: "priority" in Celery is almost always implemented as queue separation, not a priority field, because the default broker doesn't support message priority at all. **Chains** run tasks sequentially, each one receiving the previous task's return value. **Chords** run a group of tasks in parallel, then fire a callback once every one of them finishes, with their results collected as a list. ```python from celery import chain, chord pipeline = chain(fetch_data.s(source_id=1), transform.s(), save_result.s()) pipeline.apply_async() job = chord( [resize_image.s(image_id=99, size=s) for s in ("small", "medium", "large")], notify_all_sizes_ready.s(upload_id=42), ) job.apply_async() ``` A chord's callback is itself just another task. Celery tracks completion with a counter in the result backend, decrementing it as each group member finishes and firing the callback at zero. **This is why a chord requires a result backend**: without one, there is no way to know when the group is actually done. > **Remember:** "priority" in Celery usually means separate queues, not a priority field, because the default broker (Redis) doesn't support one. A chord needs a result backend to know when its group is finished. ```knowledge-check { "questions": [ { "id": "backend-systems-celery-routing-q1", "type": "mcq", "prompt": "Why does a Celery chord require a result backend, while a simple fire-and-forget task does not?", "options": [ {"id":"a","text":"Chords must know when every task in the group has finished, which Celery tracks with a counter stored in the result backend"}, {"id":"b","text":"Result backends are required for every Celery task, chord or not"}, {"id":"c","text":"Chords cannot use Redis as a broker without a result backend"}, {"id":"d","text":"A chord's callback runs before the group tasks, so it needs a place to store their future arguments"} ], "correct": "a", "explanation": "The callback only fires once every task in the group is done. Celery has no other way to detect group-wide completion except tracking a countdown in the result backend as each member finishes." } ] } ``` ## Custom task states, periodic tasks, and the result backend Beyond Celery's built-in states, `update_state` reports custom progress, essential for a long task a frontend needs to show progress for. ```python @app.task(bind=True) def generate_report(self, report_id): rows = fetch_rows(report_id) for i, row in enumerate(rows): process_row(row) if i % 100 == 0: self.update_state(state="PROGRESS", meta={"current": i, "total": len(rows)}) return {"report_id": report_id, "rows_processed": len(rows)} ``` The **result backend** (commonly Redis or Postgres) is where Celery writes task state and return values, separate from the **broker**, which only queues the task messages themselves. Without a result backend, `task.delay()` still runs the task, but `AsyncResult.status` stays `PENDING` forever and `.get()` hangs, because there's nowhere for the answer to be written. Periodic tasks run through `celery beat`, a separate scheduler process that pushes tasks onto the broker at configured times; actual execution still goes through normal workers. ```python from celery.schedules import crontab app.conf.beat_schedule = { "cleanup-expired-sessions-every-hour": { "task": "myapp.tasks.cleanup_expired_sessions", "schedule": crontab(minute=0), }, } ``` Run exactly one `beat` process. Two of them will double-schedule everything. > **Remember:** the broker queues messages; the result backend stores outcomes. They're conceptually separate even when both point at the same Redis instance, and only one of them tells you whether a task is done. ```knowledge-check { "questions": [ { "id": "backend-systems-celery-resultbackend-q1", "type": "mcq", "prompt": "No result backend is configured. A task is sent with task.delay(). What happens?", "options": [ {"id":"a","text":"The task never runs at all"}, {"id":"b","text":"The task runs normally, but AsyncResult has nowhere to read status or return value from, so .status stays PENDING and .get() hangs"}, {"id":"c","text":"Celery raises a configuration error at startup"}, {"id":"d","text":"The broker itself stores and returns the result automatically"} ], "correct": "b", "explanation": "The broker only delivers the task message; it is not built to store outcomes. Without a result backend configured, there's no destination for status or return value, so checking on the task from the caller side never resolves." } ] } ``` ## Choosing between Celery, Temporal, and a custom worker Celery is not the only option, and knowing when to reach for something else is itself an interview-worthy answer. **Temporal** is a workflow orchestration engine. You write a workflow function that calls "activities," the actual side-effecting steps, and Temporal's server durably persists execution state after every step. If a worker crashes mid-workflow, a new worker resumes from the last completed activity, not from the start. That's the specific thing Celery doesn't give you: durable, resumable, *multi-step* state, plus a UI showing exactly which step a given execution is on. The cost is real: Temporal needs its own server plus Postgres plus a UI, roughly 6-7x heavier at idle than a Redis-plus-worker Celery setup, which matters on a small cluster. **A custom DB-backed worker** claims rows from a `jobs` table using `SELECT ... FOR UPDATE SKIP LOCKED`, so multiple worker processes never double-process the same row: ```python async def run_worker(concurrency=5): while True: with transaction.atomic(): tasks = list( Task.objects.select_for_update(skip_locked=True) .filter(status="pending").order_by("created_at")[:concurrency] ) if tasks: await asyncio.gather(*[handle(t) for t in tasks]) else: await asyncio.sleep(2) ``` `skip_locked=True` is the key detail: a second worker running the same loop skips rows this one already locked, instead of blocking on them. This option needs zero new infrastructure if you already run Postgres, at the cost of hand-rolled retry logic and a throughput ceiling in the low thousands of jobs per second. | | Custom DB worker | Celery | Temporal | |---|---|---|---| | Extra infra | None (reuses Postgres) | Redis | Temporal server + Postgres | | Retry logic | Manual | Built in | Built in | | Multi-step workflows | Manual orchestration | `chain` / `chord` | Native, durable, resumable | | Setup time | Fast | Fast | Slow: deploy the server stack first | The decision framework: simple, independent tasks (send an email, resize an image) or a small, resource-constrained cluster both point at Celery. A multi-step pipeline needing step-by-step visibility and resumability across a crash, parse, chunk, run AI calls, generate output, points at Temporal. A team that wants low overhead now but may grow into complex workflows later should start with Celery and migrate only the specific workflow that outgrows it, rather than moving the whole system upfront. > **Remember:** Celery for simple or independent tasks; Temporal for multi-step workflows that must resume from the last completed step after a crash. Start simple and migrate the one workflow that outgrows it, not the whole system. ```knowledge-check { "questions": [ { "id": "backend-systems-celery-temporal-q1", "type": "mcq", "prompt": "A pipeline parses a document, chunks it, runs several AI calls, and generates output, and it must resume from the last completed step if a worker crashes mid-way. Which tool is actually built for this?", "options": [ {"id":"a","text":"Celery, since chain() already covers this case identically"}, {"id":"b","text":"Temporal, since it durably persists state after every step and resumes a crashed workflow from the last completed activity, not from the start"}, {"id":"c","text":"A custom DB-backed worker, since SELECT FOR UPDATE SKIP LOCKED provides the same durability guarantee"}, {"id":"d","text":"None of these tools can express a multi-step pipeline"} ], "correct": "b", "explanation": "Celery's chain restarts a whole chain from scratch on worker loss unless you build resumability yourself. Temporal's entire design is durable, step-by-step state that survives a crash, which is exactly this scenario." } ] } ``` ## BullMQ: the same idea in Node BullMQ is a Redis-backed job queue for Node.js, the JavaScript-ecosystem equivalent of Celery. The core idea is identical: move slow work out of the request/response cycle onto workers pulling from a shared queue. ```js import { Queue, Worker } from 'bullmq'; const connection = { host: 'localhost', port: 6379 }; const emailQueue = new Queue('emails', { connection }); await emailQueue.add('welcome-email', { userId: 42 }, { attempts: 3, backoff: { type: 'exponential', delay: 1000 }, }); new Worker('emails', async (job) => { await sendWelcomeEmail(job.data.userId); }, { connection }); ``` `emailQueue.add` pushes the job onto a Redis-backed structure and returns immediately, without waiting for the email to send. A separate `Worker` process, possibly on a different machine, picks it up, runs the callback, and if it throws, BullMQ retries automatically using the configured exponential backoff, up to the `attempts` limit. What BullMQ adds over a plain Redis list: delayed jobs, automatic retries with backoff, priority queues, and per-queue rate limiting, the same category of feature Celery gives Python. A candidate coming from Python can map BullMQ concepts onto Celery concepts almost one to one: `Queue.add` is `task.delay()`, `attempts`/`backoff` is `autoretry_for`/`retry_backoff`, and a `Worker` is a Celery worker process. > **Remember:** BullMQ is Celery's Node equivalent: a Redis-backed queue, a worker pool, and built-in retries with backoff. The concepts transfer almost directly between the two ecosystems. ```knowledge-check { "questions": [ { "id": "backend-systems-celery-bullmq-q1", "type": "mcq", "prompt": "A Python engineer new to Node sees BullMQ's { attempts: 3, backoff: { type: 'exponential' } } option. What is the closest Celery equivalent?", "options": [ {"id":"a","text":"task_routes"}, {"id":"b","text":"max_retries plus retry_backoff=True, since both configure automatic retry count and exponential spacing"}, {"id":"c","text":"beat_schedule"}, {"id":"d","text":"There is no equivalent concept in Celery"} ], "correct": "b", "explanation": "Both BullMQ's attempts/backoff and Celery's max_retries/retry_backoff configure the same thing: how many times to retry a failed job, and how to space those retries out." } ] } ``` 91:T2c0c,Kafka questions separate candidates who've used a queue from candidates who've used *this* queue. Interviewers probe partitioning, consumer groups, and delivery guarantees because that's exactly where Kafka's design diverges from something like RabbitMQ or SQS. This lesson covers the architecture, a working producer and consumer, and the ordering and duplication questions that come up in nearly every backend system-design interview. ## Kafka's building blocks Picture a topic as a set of parallel, append-only log files, called partitions. Producers write to the end of a partition; consumers read from wherever they last stopped, at their own pace. Nothing is ever removed on read. - **Topic**: a named stream of records, split into **partitions**. Splitting into partitions is how Kafka parallelizes work: each partition is its own ordered log, and different partitions can be consumed independently. - **Broker**: one Kafka server. A cluster is several brokers, each holding some partitions and replicas of others. - **Producer**: writes records to a topic, choosing which partition each record lands in. - **Consumer**: reads records from a partition, tracking its position with an **offset**, a per-partition sequence number. - **Consumer group**: a set of consumers that split a topic's partitions between themselves. Each partition is read by exactly one consumer in the group at a time, which is how Kafka spreads out work without any duplication. Kafka keeps records for a configured retention period, not just until someone reads them, so multiple independent consumer groups can each read the same topic at their own pace, including replaying from the very beginning. > **Remember:** a topic-partition is a durable, ordered log. Producers append, consumers read at their own pace by offset, and nothing disappears just because it was read once. ```knowledge-check { "questions": [ { "id": "backend-systems-kafka-architecture-q1", "type": "mcq", "prompt": "Two different consumer groups both subscribe to the same Kafka topic. What happens?", "options": [ {"id":"a","text":"Only one group can read the topic at a time"}, {"id":"b","text":"Each group reads every record independently, at its own pace, since offsets are tracked per (group, partition), not globally"}, {"id":"c","text":"The second group only receives records the first group has not yet read"}, {"id":"d","text":"Kafka merges the two groups into one automatically"} ], "correct": "b", "explanation": "Kafka tracks each consumer group's progress separately. Two groups reading the same topic are entirely independent views, each able to replay or lag without affecting the other." } ] } ``` ## A producer and consumer that actually commit correctly ```python from kafka import KafkaProducer, KafkaConsumer producer = KafkaProducer( bootstrap_servers=["localhost:9092"], acks="all", # wait for every in-sync replica to acknowledge enable_idempotence=True, # see duplication below ) def publish_order_event(order_id: str, status: str): # keying by order_id guarantees every event for the same order lands # in the same partition, preserving per-order ordering producer.send("orders.events", key=order_id.encode(), value={"order_id": order_id, "status": status}) producer.flush() ``` ```python consumer = KafkaConsumer( "orders.events", bootstrap_servers=["localhost:9092"], group_id="order-notifier", enable_auto_commit=False, # commit manually, only after processing succeeds ) for message in consumer: process_order_event(message.value) consumer.commit() # advance the offset only after success ``` `enable_auto_commit=False` plus a manual `commit()` after processing is the pattern to lead with. Auto-commit on a timer can advance a consumer's offset for a message that then fails to process, silently dropping it, since Kafka now believes that message was handled. > **Remember:** commit the offset manually, after processing succeeds. Auto-commit on a timer can mark a message "done" before you actually know that. ```knowledge-check { "questions": [ { "id": "backend-systems-kafka-commit-q1", "type": "mcq", "prompt": "Why is enable_auto_commit=False plus a manual commit() after processing safer than the default auto-commit?", "options": [ {"id":"a","text":"Manual commits are always faster than automatic ones"}, {"id":"b","text":"Auto-commit on a timer can advance the offset for a message that then fails to process, silently dropping it, since Kafka now believes it was already handled"}, {"id":"c","text":"Auto-commit is not supported on Kafka topics with more than one partition"}, {"id":"d","text":"Manual commits use less network bandwidth"} ], "correct": "b", "explanation": "Auto-commit doesn't know whether your processing actually succeeded. It advances the offset on a timer, which can mark a message as done right before your code throws on it, permanently losing that message." } ] } ``` ## Consumer groups and the parallelism ceiling Add a second consumer process with the same `group_id`, and Kafka's group coordinator rebalances: 6 partitions split between 2 consumers means 3 each. Add a third and it takes some from the other two. Add a *seventh* consumer to a 6-partition topic, and it sits idle. **Partition count is the hard upper bound on parallelism within a group.** That's the detail interviewers check for when they ask how you'd scale consumption. > **Remember:** you cannot have more actively-consuming workers in a group than the topic has partitions. Scaling consumers past that count just leaves the extras idle. ```knowledge-check { "questions": [ { "id": "backend-systems-kafka-parallelism-q1", "type": "mcq", "prompt": "A topic has 6 partitions and a consumer group scales up to 10 consumers. What happens to the 4 extra consumers?", "options": [ {"id":"a","text":"They each get a fair share by splitting existing partitions into smaller pieces"}, {"id":"b","text":"They sit idle, since a partition can only be read by one consumer in a group at a time, and there are only 6 partitions to hand out"}, {"id":"c","text":"Kafka automatically creates 4 more partitions to accommodate them"}, {"id":"d","text":"The consumer group fails to start"} ], "correct": "b", "explanation": "Partition count is the ceiling on parallel consumption within one group. Extra consumers beyond that count have nothing left to claim and simply sit idle." } ] } ``` ## Ordering: guaranteed within a partition, never across Kafka guarantees order *within one partition only*. Records sharing a key always land in the same partition, through the default hash partitioner, and are delivered to that partition's consumer in write order. There is no ordering guarantee *across* different partitions. - Need strict, global ordering: use a single partition. This caps throughput to one consumer. - Need ordering per entity (per order, per user): key by that entity's ID, let Kafka spread entities across partitions, and accept there's no ordering guarantee *between* different entities. Almost every real system picks the second option, which is exactly why the producer example above keys every event by `order_id`. > **Remember:** Kafka orders records within one partition, never across partitions. Keying by entity ID is how you get "ordered enough" without capping throughput to a single partition. ```knowledge-check { "questions": [ { "id": "backend-systems-kafka-ordering-q1", "type": "mcq", "prompt": "A system needs every event for a given order to be processed in the order it happened, but does not care about ordering between different orders. What's the standard approach?", "options": [ {"id":"a","text":"Use a single partition for the whole topic"}, {"id":"b","text":"Key each event by order_id, so all events for one order land in the same partition and are delivered in order, while different orders can spread across partitions"}, {"id":"c","text":"Kafka guarantees global ordering automatically, so no special handling is needed"}, {"id":"d","text":"Use a separate topic per order"} ], "correct": "b", "explanation": "Kafka's default partitioner routes same-key records to the same partition. Keying by the entity that needs internal ordering gets you exactly that guarantee, while spreading unrelated entities across partitions for parallelism." } ] } ``` ## Handling duplicate delivery Two separate layers of defense, answering two different questions: 1. **Producer-side, idempotent producer** (`enable_idempotence=True`). Kafka assigns each producer an ID and each message a sequence number; the broker deduplicates retries of the same pair, caused by the producer retrying after an ack timeout. This stops duplicate *writes* caused by retries, not duplicate *processing*. 2. **Consumer-side, at-least-once delivery is the default**, so consumers must be idempotent. Kafka can redeliver a message if a consumer crashes after processing but before committing its offset. Handle it the same way as any idempotent API: track a unique ID per message and skip work you've already done. ```python def process_order_event(event, db_session): dedupe_key = f"{event['order_id']}:{event['status']}" if ProcessedEvent.objects.filter(key=dedupe_key).exists(): return # already handled, skip re-applying side effects apply_side_effects(event) ProcessedEvent.objects.create(key=dedupe_key) ``` For true exactly-once *semantics* end to end, not just exactly-once delivery, Kafka offers transactional producers that atomically write to multiple partitions and commit consumer offsets together. Most interview-level answers are expected to name the at-least-once-plus-idempotent-consumer pattern instead, since that's what's actually deployed in most real systems. > **Remember:** an idempotent producer stops duplicate writes from retries. An idempotent consumer, keyed by a unique message ID, is what actually protects you from duplicate side effects. ```knowledge-check { "questions": [ { "id": "backend-systems-kafka-duplication-q1", "type": "mcq", "prompt": "enable_idempotence=True is set on the producer. Does this alone guarantee the consumer never processes a duplicate?", "options": [ {"id":"a","text":"Yes, idempotent producers eliminate all forms of duplication"}, {"id":"b","text":"No, it only stops duplicate writes caused by producer retries; a consumer crash between processing and committing its offset can still cause redelivery, so the consumer must also be idempotent"}, {"id":"c","text":"No, idempotent producers only work with a single partition"}, {"id":"d","text":"Yes, but only for topics with exactly one consumer"} ], "correct": "b", "explanation": "Producer idempotence and consumer idempotence solve different problems. The producer setting only dedupes retries at write time; the default at-least-once delivery model still means a consumer can see the same message twice." } ] } ``` 92:T33ad,Moving work out of the request cycle is easy. Moving it out *reliably*, so a crash halfway through doesn't corrupt anything or lose an event, is the part that separates "I used Celery to send an email" from "I understand distributed failure modes." This is a favorite senior-level interview area: multi-stage pipelines, dead letter queues, and the outbox pattern. ## Three shapes of async work **Fire-and-forget.** A request triggers work and doesn't wait for it: a Celery task or a FastAPI `BackgroundTasks` call. The simplest case. **Fan-out / fan-in.** One input splits into many parallel subtasks, then the results are combined. Resize an upload into 5 sizes at once, mark it "processed" once all 5 finish. **Pipeline (multi-stage).** Stage N's output is stage N+1's input, and each stage scales and retries independently: upload, virus scan, transcode, thumbnail, notify. ```python from celery import Celery, chain app = Celery("pipeline", broker="redis://localhost:6379/0") @app.task(bind=True, max_retries=3, default_retry_delay=10) def scan_upload(self, file_id: str) -> str: if not virus_scan(file_id): raise ValueError(f"file {file_id} failed virus scan") return file_id @app.task(bind=True, max_retries=3, default_retry_delay=10) def transcode(self, file_id: str) -> str: try: run_transcode(file_id) return file_id except TranscodeError as exc: raise self.retry(exc=exc) @app.task def generate_thumbnail(file_id: str) -> str: make_thumbnail(file_id) return file_id @app.task def notify_owner(file_id: str) -> None: send_notification(file_id, "Your upload is ready") def start_pipeline(file_id: str): pipeline = chain(scan_upload.s(file_id), transcode.s(), generate_thumbnail.s(), notify_owner.s()) pipeline.apply_async() ``` Each stage is its own task with its own retry policy. A transient transcode failure retries on its own, without re-running the (expensive) virus scan that already succeeded. That independence is the whole point of building a pipeline instead of one giant function: it isolates each stage's failure domain and retry policy. > **Remember:** a pipeline's real value is isolating each stage's failures. A retry in stage 3 should never have to redo stages 1 and 2. ```knowledge-check { "questions": [ { "id": "backend-systems-asyncpipelines-shapes-q1", "type": "mcq", "prompt": "Why build a 5-stage pipeline out of separate tasks instead of one function that runs all 5 steps in sequence?", "options": [ {"id":"a","text":"Separate tasks always run faster than one function"}, {"id":"b","text":"Each stage gets its own retry policy and failure domain, so a transient failure in a later stage doesn't force re-running the earlier stages that already succeeded"}, {"id":"c","text":"Celery does not support functions longer than a few lines"}, {"id":"d","text":"One function cannot call another function inside a task"} ], "correct": "b", "explanation": "The entire benefit of a multi-stage pipeline is isolating failure and retry per stage. A single function retries the whole thing on any failure, redoing expensive work that already succeeded." } ] } ``` ## Partial failures: what state is left behind "How do you handle partial failures in a pipeline" is really asking: what happens when stage 3 of 5 fails, and what does the system look like afterward? Three rules: 1. **Every stage must be idempotent.** A retry re-runs the stage, so running `generate_thumbnail` twice for the same file must not create two thumbnails. Use an upsert (`ON CONFLICT DO UPDATE` in Postgres) instead of a blind insert. 2. **Track stage status explicitly**, in a table, not by inferring it from queue state, which disappears the moment a task finishes or fails. A status row lets you query "what's stuck right now" and resume a stage from its last completed step instead of starting over. 3. **Decide per failure: retry, skip, or fail the whole pipeline.** Not every failure deserves the same response. ```python @app.task(bind=True, max_retries=3) def transcode(self, file_id: str) -> str: run = get_or_create_run(file_id, stage="transcode") run.status, run.attempts = StageStatus.RUNNING, run.attempts + 1 db.commit() try: run_transcode(file_id) except UnsupportedFormatError as exc: run.status, run.error = StageStatus.FAILED, str(exc) # not transient — don't retry db.commit() raise except TranscodeTimeoutError as exc: db.commit() raise self.retry(exc=exc, countdown=2 ** self.request.retries) # transient — worth retrying else: run.status = StageStatus.DONE db.commit() return file_id ``` The distinction between a **permanent** failure (bad input, retrying never helps) and a **transient** one (a network blip, worth retrying with backoff) is the single most important decision in any pipeline. Retrying a permanent failure just burns queue capacity and delays the signal that a human actually needs to look at it. > **Remember:** classify every failure as permanent or transient before deciding to retry. Retrying a permanent failure wastes capacity and delays the alert that a human is actually needed. ```knowledge-check { "questions": [ { "id": "backend-systems-asyncpipelines-partial-q1", "type": "mcq", "prompt": "A transcode task fails because the uploaded file format is fundamentally unsupported. What should happen?", "options": [ {"id":"a","text":"Retry with exponential backoff up to the max attempts, same as any other failure"}, {"id":"b","text":"Fail immediately without retrying, since this is a permanent failure that no amount of retrying will fix"}, {"id":"c","text":"Silently skip the stage and continue the pipeline as if it succeeded"}, {"id":"d","text":"Restart the entire pipeline from the first stage"} ], "correct": "b", "explanation": "An unsupported format will fail identically on every retry. Treating it as permanent and failing fast avoids burning queue capacity, and gets the failure signal to a human sooner instead of after 3 wasted retries." } ] } ``` ## Dead letter queues: a graveyard needs a way back out A dead letter queue (DLQ) is where a task lands after exhausting its retries or hitting a permanent failure, instead of vanishing or retrying forever. ```python from celery.signals import task_failure @task_failure.connect def handle_task_failure(sender=None, task_id=None, exception=None, args=None, kwargs=None, **extra): send_to_dead_letter_queue( task_name=sender.name, task_id=task_id, payload={"args": args, "kwargs": kwargs}, error=str(exception), ) ``` With RabbitMQ or SQS-style brokers, a DLQ is often a first-class feature: configure a max-retry count and a target queue, and the broker moves the message there automatically. With Redis and Celery, it's usually rolled by hand, as above, or via `acks_late` plus a max-retries exception handler. What actually matters for the interview: **a DLQ entry needs a replay path.** A write-only DLQ is just a failure graveyard. Build, or at least describe, a way to inspect a dead-lettered task, fix the underlying issue, and re-enqueue it, often an admin endpoint or CLI command that reads the stored arguments and calls the task again. > **Remember:** a dead letter queue without a replay path is just a place failures go to be forgotten. The whole point is inspecting, fixing, and re-enqueuing. ```knowledge-check { "questions": [ { "id": "backend-systems-asyncpipelines-dlq-q1", "type": "mcq", "prompt": "A team builds a dead letter queue that logs every permanently failed task, but has no way to re-run one after fixing the underlying bug. What's missing?", "options": [ {"id":"a","text":"Nothing; logging failed tasks is the entire point of a DLQ"}, {"id":"b","text":"A replay path: a way to inspect a dead-lettered task's stored arguments and re-enqueue it once the underlying issue is fixed"}, {"id":"c","text":"A faster broker"}, {"id":"d","text":"More retry attempts before giving up"} ], "correct": "b", "explanation": "A DLQ that only records failures without a way to act on them is a write-only graveyard. The value of a DLQ comes from being able to fix the root cause and replay the exact failed work afterward." } ] } ``` ## The outbox pattern: writing to a database and publishing an event, atomically The problem: you often need to update the database *and* publish an event together, for example creating an order and publishing `OrderCreated`. Done as two separate operations, there's a window where one succeeds and the other fails: the database commits and the process crashes before the publish, or the publish succeeds and the transaction then rolls back. Either way, your database and your event consumers now disagree about reality. The outbox pattern fixes this by writing the event into an **outbox table, in the same database transaction** as the business data. A separate relay process reads unpublished rows and publishes them, retrying until it succeeds. Because the outbox write is transactional with the business write, the event is guaranteed to exist if and only if the business data was actually committed. ```sql CREATE TABLE outbox ( id UUID PRIMARY KEY DEFAULT gen_random_uuid(), aggregate_id TEXT NOT NULL, event_type TEXT NOT NULL, payload JSONB NOT NULL, created_at TIMESTAMPTZ NOT NULL DEFAULT now(), published_at TIMESTAMPTZ ); ``` ```python def create_order(db_session, order_data: dict): with db_session.begin(): # one transaction order = Order(**order_data) db_session.add(order) db_session.flush() # get order.id without committing db_session.add(Outbox( aggregate_id=str(order.id), event_type="OrderCreated", payload={"order_id": str(order.id), "total": order.total}, )) # both rows commit together, or neither does return order ``` ```python def relay_outbox_events(db_session, publisher): unpublished = db_session.query(Outbox).filter(Outbox.published_at.is_(None)).order_by(Outbox.created_at).limit(100) for event in unpublished: try: publisher.publish(event.event_type, event.payload) event.published_at = datetime.now(UTC) db_session.commit() except PublishError: db_session.rollback() break # stop here, retry this batch next tick, preserving order ``` This is sometimes paired with change data capture (reading the database's own write-ahead log, instead of polling) to catch the outbox insert the instant it commits, worth naming as the "at scale" version if asked. The best guarantee outbox plus retry can offer is at-least-once delivery, since a crash between publishing and marking `published_at` can still cause a duplicate publish. Pair it with an idempotent consumer, keyed on event ID, to close the loop: ```python def handle_order_created(event: dict, db_session): if db_session.query(ProcessedEvent).filter_by(event_id=event["event_id"]).first(): return # duplicate delivery, safely ignored with db_session.begin(): fulfill_order(event["order_id"]) db_session.add(ProcessedEvent(event_id=event["event_id"], processed_at=datetime.now(UTC))) ``` That combination, a transactional outbox on the producer side paired with an idempotent, event-ID-keyed handler on the consumer side, is what "reliable event publishing" means in practice: not zero duplicates, but zero *lost* events, and safe handling of the duplicates that do slip through. > **Remember:** the outbox table is written in the same transaction as the business data, so the event's existence is tied to the write actually committing. A relay process publishes it afterward, at-least-once, which is why the consumer still needs to be idempotent. ```knowledge-check { "questions": [ { "id": "backend-systems-asyncpipelines-outbox-q1", "type": "mcq", "prompt": "Why does writing to an outbox table in the same transaction as the business data solve the 'DB commits but the event never publishes' problem?", "options": [ {"id":"a","text":"It doesn't fully solve it; a separate relay process still has to publish the outbox row later, which is why the consumer must also be idempotent"}, {"id":"b","text":"The outbox table publishes events directly without needing a relay process"}, {"id":"c","text":"Writing to two tables in one transaction is always instantaneous, so there's no window for failure"}, {"id":"d","text":"Outbox rows are automatically deleted once read, which guarantees delivery"} ], "correct": "a", "explanation": "The transactional write guarantees the event ROW exists if and only if the business data committed. Actually publishing it still happens afterward, by a separate relay process that can itself fail partway, which is why outbox alone gives at-least-once, not exactly-once, delivery." } ] } ``` 93:T2703,The moment your backend runs on more than one machine, you inherit a new class of failure: what happens when the network drops a packet, or two machines both think they're in charge? This lesson covers the CAP theorem, retrying safely, and the idempotency pattern that makes retries safe in the first place. ## CAP theorem: the choice you actually have to make CAP says a distributed system can guarantee only two of three properties **during a network partition**, a moment when some nodes can't talk to others: - **Consistency**: every read sees the most recent write, or an error. - **Availability**: every request gets a real, non-error response. - **Partition tolerance**: the system keeps working despite dropped or delayed messages between nodes. Here's the catch: partitions *will* happen on any real network, so partition tolerance isn't really optional. The actual choice is **CP vs AP**, and only during a partition. A CP system (a Postgres primary with synchronous replication, etcd, ZooKeeper) refuses a write it can't confirm is durable across nodes, giving up availability. An AP system (Cassandra in its default configuration, DynamoDB) keeps answering requests on both sides of the partition and reconciles conflicts afterward, giving up strict consistency. The right question isn't "which system is better," it's which failure mode actually fits the feature. A payments ledger wants CP: better to reject a write than record two different balances. A social media like-counter wants AP: better to show a slightly stale count than go down entirely. > **Remember:** partition tolerance isn't a real choice, it's a fact of networks. The actual decision is CP vs AP, and it should follow from what the feature can tolerate, not a general preference. ```knowledge-check { "questions": [ { "id": "backend-systems-distributedbasics-cap-q1", "type": "mcq", "prompt": "Why is 'pick two of three' a misleading way to describe CAP in practice?", "options": [ {"id":"a","text":"Because partitions happen on any real network, so partition tolerance isn't optional; the real choice is CP versus AP, and only during an actual partition"}, {"id":"b","text":"Because CAP does not apply to systems with more than 3 nodes"}, {"id":"c","text":"Because consistency and availability can always be achieved together with enough hardware"}, {"id":"d","text":"Because partition tolerance only matters for systems using UDP"} ], "correct": "a", "explanation": "Networks partition in the real world, so giving up partition tolerance isn't a realistic option. The meaningful trade-off only appears during an actual partition, between staying consistent (CP) and staying available (AP)." } ] } ``` ## Eventual consistency and read-your-own-writes **Eventual consistency** is a guarantee that if no new writes happen, every replica *eventually* converges to the same value, with no fixed bound on how long that takes, though in practice it's usually milliseconds to seconds. It's what AP systems offer instead of strong consistency. Concretely: you write to replica A, a read hits replica B a moment later and gets the old value, and a read shortly after that gets the new one once replication catches up. The common complaint about this in interviews is **read-your-own-writes**: a user posts a comment, refreshes, and doesn't see it, because their read landed on a lagging replica. Standard fixes: route a user's reads to the primary (or the replica that served their last write) for a short window afterward, or use a session token that pins reads to a replica at least as fresh as that user's last write. > **Remember:** eventual consistency means replicas converge, eventually, with no fixed deadline. Read-your-own-writes is the specific, user-visible bug this causes if you don't route a user's own reads carefully. ```knowledge-check { "questions": [ { "id": "backend-systems-distributedbasics-eventual-q1", "type": "mcq", "prompt": "A user posts a comment, refreshes immediately, and doesn't see it, even though the write succeeded. What is the standard fix?", "options": [ {"id":"a","text":"Route that user's reads to the primary, or to a replica known to be at least as fresh as their last write, for a short window after writing"}, {"id":"b","text":"Nothing can be done; this is an unavoidable cost of using replicas"}, {"id":"c","text":"Switch the entire system to strong consistency permanently"}, {"id":"d","text":"Ask the user to wait exactly 60 seconds before refreshing"} ], "correct": "a", "explanation": "This is the read-your-own-writes problem: a read landed on a replica that hasn't caught up yet. Pinning that user's reads to a sufficiently fresh source for a short window is the standard, targeted fix." } ] } ``` ## Retry with exponential backoff and full jitter Retrying immediately on a struggling downstream service makes things worse: a thundering herd of retries piles onto a service that's already struggling. Exponential backoff spaces retries out; jitter stops many clients from retrying in lockstep. ```python import random, time def retry_with_backoff(fn, max_attempts=5, base_delay=0.5, max_delay=30.0): for attempt in range(max_attempts): try: return fn() except (ConnectionError, TimeoutError): if attempt == max_attempts - 1: raise delay = min(max_delay, base_delay * (2 ** attempt)) delay = random.uniform(0, delay) # full jitter time.sleep(delay) ``` "Full jitter," picking a random delay between 0 and the computed maximum rather than a fixed exponential value, is the detail that separates a correct answer from a memorized one. It decorrelates retry timing across many clients hitting the same failing service at once, which is why it beats no-jitter and "equal jitter" backoff under real contention. > **Remember:** full jitter picks a random delay up to the backoff ceiling, not the ceiling itself. That randomness is what stops many clients from retrying in lockstep. ```knowledge-check { "questions": [ { "id": "backend-systems-distributedbasics-jitter-q1", "type": "mcq", "prompt": "Why does full jitter (a random delay between 0 and the computed backoff) outperform a fixed exponential delay under heavy contention?", "options": [ {"id":"a","text":"It makes each individual client's retries happen faster"}, {"id":"b","text":"It decorrelates retry timing across many clients, so they don't all retry at the exact same moment and re-overwhelm the struggling service"}, {"id":"c","text":"It uses less CPU than a fixed delay"}, {"id":"d","text":"It guarantees every retry will succeed"} ], "correct": "b", "explanation": "A fixed exponential delay computed from the same failure moment means every client retries at the same instant. Full jitter spreads that mass of retries out over a range, reducing the chance of a second, synchronized overload." } ] } ``` ## Idempotency: making retries safe to send twice "How do you handle a network partition?" for a write, the honest answer is you can't always tell whether your write succeeded or just the response got lost. So the client retries, and the server has to make that retry safe. That's idempotency: applying the same request N times has the same effect as applying it once. ```python @transaction.atomic def create_payment(request): body = json.loads(request.body) idempotency_key = request.headers.get("Idempotency-Key") if not idempotency_key: return JsonResponse({"error": "Idempotency-Key header required"}, status=400) existing = IdempotencyRecord.objects.select_for_update().filter(key=idempotency_key).first() if existing: return JsonResponse(existing.response_body, status=existing.response_status) # don't re-charge payment = Payment.objects.create(amount=body["amount"], account_id=body["account_id"]) response_body = {"payment_id": payment.id, "status": "created"} IdempotencyRecord.objects.create(key=idempotency_key, response_status=201, response_body=response_body) return JsonResponse(response_body, status=201) ``` The idempotency key is generated once, client-side, before the first attempt, and sent on every retry of that same logical request. The lookup-and-insert happens inside the same transaction as the actual write, so a crash between "create the payment" and "record the key" is impossible: either both commit or neither does. `POST` endpoints that mutate money, inventory, or anything non-repeatable should support this header. `PUT`/`DELETE` are naturally idempotent by HTTP's own rules, though a `PUT` is only idempotent if it's a full replace, not a partial increment. > **Remember:** the idempotency key is generated once by the client, before the first attempt, and reused on every retry. Generating a new key per retry defeats the entire mechanism. ```knowledge-check { "questions": [ { "id": "backend-systems-distributedbasics-idempotency-q1", "type": "mcq", "prompt": "A client generates a new Idempotency-Key for every retry of the same failed request. What breaks?", "options": [ {"id":"a","text":"Nothing; a new key each time is the correct approach"}, {"id":"b","text":"The server sees each retry as a brand-new request, so it processes the payment again on every retry, which is exactly what the idempotency key was supposed to prevent"}, {"id":"c","text":"The server rejects all requests with a 400 error"}, {"id":"d","text":"Only the first request ever succeeds"} ], "correct": "b", "explanation": "The whole mechanism depends on the same key being reused across retries of one logical request, so the server can recognize a repeat and return the original result instead of repeating the side effect." } ] } ``` 94:T371d,A distributed lock makes sure only one process at a time touches a shared resource, for example, only one worker runs a scheduled job at once, even though "the worker" might be running on five different machines. The basic Redis version (`SET key token NX PX ttl`, released with a token-checked script) looks solid, but it isn't safe under every failure mode. This lesson covers why, what Redlock proposes to fix it, and why even Redlock is a genuinely contested design. Martin Kleppmann and Redis's own creator publicly disagreed about it, and knowing both sides of that disagreement is what separates a strong answer here from a memorized one. ## Why a TTL alone doesn't make a lock safe A lock's TTL (its expiry time) exists so a crashed holder doesn't lock the resource forever. But the TTL itself creates a new failure: 1. Client A acquires the lock, TTL 10 seconds. 2. Client A pauses for 15 seconds, a garbage-collection pause, a CPU steal in a shared VM, slow disk I/O, still believing it holds the lock. 3. The lock expires at 10 seconds. Client B acquires it and starts working on the protected resource. 4. Client A wakes up, finishes its work, and without a token check could release B's lock, or worse, both A and B now act on the resource the lock was supposed to serialize, at the same time. The two things worth stating plainly in an interview: the release must be a script that checks a token, not a plain `DEL`, because check-then-delete without atomicity is a race condition; and the lock needs a TTL in the first place, so a crashed holder doesn't block everyone forever. But here is the deeper point those two details don't fully solve: **a lock's TTL is a guess about how long you'll hold it, and the process holding it has no way to know the guess was wrong until it's already too late.** No amount of "picking a better TTL" fixes this. It's a structural property of using a clock to coordinate mutual exclusion. > **Remember:** a TTL protects against a holder that's gone. It does nothing for a holder that's merely paused past its TTL and still believes it's in charge. ```knowledge-check { "questions": [ { "id": "backend-systems-distributedlocks-ttl-q1", "type": "mcq", "prompt": "A client holding a Redis lock pauses for a garbage-collection stop-the-world longer than the lock's TTL. What is the actual risk?", "options": [ {"id":"a","text":"None, since Redis pauses the TTL countdown automatically during a client GC pause"}, {"id":"b","text":"The lock expires while the paused client still believes it holds it; another client can then acquire it, and both can end up acting on the resource at once"}, {"id":"c","text":"The paused client's connection is automatically terminated by Redis"}, {"id":"d","text":"Redis extends the TTL automatically whenever a client is slow"} ], "correct": "b", "explanation": "A TTL is a timer Redis enforces regardless of what the holder is doing. A holder that pauses past it has no way to know the lock already expired, which opens a window where two clients both believe they're the sole holder." } ] } ``` ## Lock with TTL and renewal Renewal, a heartbeat that extends the TTL while work is ongoing, narrows the window above without closing it: the TTL now only expires if the holder is genuinely stuck, not merely slow to renew in time. ```python import redis, threading, uuid r = redis.Redis(decode_responses=True) RELEASE_SCRIPT = """ if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) end return 0 """ RENEW_SCRIPT = """ if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('pexpire', KEYS[1], ARGV[2]) end return 0 """ class DistributedLock: def __init__(self, resource, ttl_ms=10_000): self.key, self.token, self.ttl_ms = f"lock:{resource}", str(uuid.uuid4()), ttl_ms self._stop_renewal = threading.Event() def acquire(self) -> bool: acquired = r.set(self.key, self.token, nx=True, px=self.ttl_ms) if acquired: self._start_renewal() return bool(acquired) def _start_renewal(self): def renew_loop(): # renew at half the TTL, so one missed renewal still leaves time before real expiry while not self._stop_renewal.wait(self.ttl_ms / 2 / 1000): renewed = r.eval(RENEW_SCRIPT, 1, self.key, self.token, self.ttl_ms) if not renewed: break # someone else holds it now — stop pretending we do threading.Thread(target=renew_loop, daemon=True).start() def release(self): self._stop_renewal.set() r.eval(RELEASE_SCRIPT, 1, self.key, self.token) ``` This is the "watchdog" pattern: renew at half the TTL, so a single missed renewal doesn't cause an immediate expiry. Redis's own client library and Redlock's reference implementation both build this in under the hood. > **Remember:** renewal narrows the failure window (it only fires if the holder is really stuck), it does not close it. A renewal thread can itself stall for the same reasons the original work could. ```knowledge-check { "questions": [ { "id": "backend-systems-distributedlocks-renewal-q1", "type": "mcq", "prompt": "Why does the renewal loop renew the lock at half the TTL, rather than waiting until just before it expires?", "options": [ {"id":"a","text":"Renewing more often just wastes Redis bandwidth for no benefit"}, {"id":"b","text":"Renewing at half the TTL leaves a full half-TTL of buffer, so one missed or delayed renewal still doesn't let the lock expire before the next attempt"}, {"id":"c","text":"Redis requires renewal to happen at exactly half the TTL"}, {"id":"d","text":"It has no effect on safety, only on performance"} ], "correct": "b", "explanation": "Renewing right before expiry leaves no margin for a delayed renewal call. Renewing at the halfway point means even a missed cycle still has time before the lock would actually lapse." } ] } ``` ## Redlock: quorum across independent instances Redlock coordinates a lock across N independent Redis instances (separate masters, not replicas of each other, typically 5) so a single instance failing doesn't break the lock: 1. Record the current time. 2. Try to acquire the lock (the same `SET NX PX`) on all N instances, one at a time, using a short per-instance timeout so one down instance doesn't stall the whole attempt. 3. The lock counts as acquired only if it was acquired on a **majority** (N/2 + 1) of instances, **and** the total time spent acquiring is less than the TTL, since otherwise it may already be expiring on the earliest instances by the time you finish the last. 4. If acquired, the effective remaining validity is the TTL minus time spent acquiring, minus a small safety margin for clock drift. 5. If a majority wasn't reached, release the lock on every instance where it *was* acquired, and let the caller retry after a random delay. ```python class Redlock: def __init__(self, nodes, ttl_ms=10_000): self.clients = [redis.Redis.from_url(url) for url in nodes] self.ttl_ms, self.quorum = ttl_ms, len(nodes) // 2 + 1 def acquire(self, resource): token, start, acquired_count = str(uuid.uuid4()), time.monotonic(), 0 for client in self.clients: try: if client.set(f"lock:{resource}", token, nx=True, px=self.ttl_ms): acquired_count += 1 except redis.RedisError: pass # an unreachable node counts as a failed acquire, not a crash elapsed_ms = (time.monotonic() - start) * 1000 validity_ms = self.ttl_ms - elapsed_ms - (self.ttl_ms * 0.01) # 1% clock-drift margin if acquired_count >= self.quorum and validity_ms > 0: return token self._release_all(resource, token) return None ``` > **Remember:** Redlock's safety comes from quorum, a majority of independent instances agreeing, not from any single instance being trustworthy. A minority acquiring the lock is treated as a failure and cleaned up. ```knowledge-check { "questions": [ { "id": "backend-systems-distributedlocks-redlock-q1", "type": "mcq", "prompt": "In Redlock with 5 nodes, a client successfully acquires the lock on 2 of them. What should happen?", "options": [ {"id":"a","text":"Treat the lock as acquired, since 2 out of 5 is a reasonable majority"}, {"id":"b","text":"Treat it as a failed acquisition, since 2 is below the quorum of 3, and release the lock on the 2 instances where it was set"}, {"id":"c","text":"Wait indefinitely for the remaining 3 instances to respond"}, {"id":"d","text":"Automatically extend the TTL on the 2 acquired instances"} ], "correct": "b", "explanation": "Redlock requires a majority, N/2 + 1, which for 5 nodes is 3. Acquiring only 2 is below quorum, so the correct behavior is to treat the attempt as failed and release the partial locks rather than proceed as if you held it." } ] } ``` ## What Redlock does not solve This is the question interviewers ask specifically to check whether you know the critique, not just the algorithm. - **TTL races with pauses**, as covered above: no lock built on wall-clock TTLs can guarantee the holder is still logically the holder at the moment it acts. - **Clock drift or jumps across nodes.** Redlock assumes clocks move forward at roughly the same rate on every instance. An NTP correction that jumps a clock backward or forward can make a lock look valid on one instance and expired on another. - **The fencing token problem.** Even a "correctly acquired" lock only proves *who acquired it*, not that the protected resource itself will reject a write from a holder whose lock has since expired. Kleppmann's proposed fix is a monotonically increasing **fencing token** issued with every acquisition, so the protected resource rejects any write carrying a token lower than the last one it accepted. Standard Redlock, as originally specified, does not include this, and that gap is the core of the Kleppmann/antirez disagreement. - **Sequential per-node cost.** Trying N instances one at a time, even with per-node timeouts, adds latency, which in practice pushes teams toward parallel acquisition or fewer, faster nodes. > **Remember:** Redlock protects against one Redis instance failing. It does not protect against a paused holder, clock drift between nodes, or a downstream resource accepting a write from a holder that no longer actually owns the lock, that last one is what a fencing token fixes. ```knowledge-check { "questions": [ { "id": "backend-systems-distributedlocks-fencing-q1", "type": "mcq", "prompt": "A client's Redlock lock expires, is re-acquired by another client, and then the original client's delayed write still reaches the protected resource. What closes this gap?", "options": [ {"id":"a","text":"Using a longer TTL closes this gap completely"}, {"id":"b","text":"A fencing token: the resource itself rejects any write carrying a lock-acquisition token lower than the last one it accepted, regardless of what the lock service believes"}, {"id":"c","text":"Adding more Redis nodes to the Redlock cluster"}, {"id":"d","text":"This gap cannot exist if the lock was acquired correctly"} ], "correct": "b", "explanation": "A lock only tracks who acquired it, not whether a delayed write from a former holder still lands. A fencing token makes the resource itself enforce ordering, rejecting any stale write regardless of what the lock currently says." } ] } ``` ## When a TTL+renewal lock is good enough Practical answer, in order of increasing rigor: 1. Pick a TTL comfortably larger than the expected work duration, and renew via a heartbeat, so expiration only fires when the holder is genuinely gone. 2. Always release through a token check, never a bare `DEL`. 3. For anything where a stale-lock double-execution would cause real damage, double-charging a payment, corrupting a file, don't rely on the lock alone. Add fencing tokens so the resource enforces ordering itself, or make the operation idempotent so a duplicate execution is harmless regardless of locking. 4. For most application-level uses, preventing a scheduled job from double-running, deduping a webhook handler, a TTL-plus-renewal lock without fencing is a pragmatic, industry-standard trade-off. Know which tier you're in, and say so explicitly. The thread running through this whole lesson: a lock is only as trustworthy as the clock and scheduler underneath it. Every fix here, renewal, quorum, fencing, narrows the gap between "I believe I hold the lock" and "I actually still hold the lock." None of them close that gap completely. > **Remember:** know which tier your use case is in. "Good enough" (TTL plus renewal) versus "needs fencing or idempotency" is a decision you should be able to justify out loud, not guess at. ```knowledge-check { "questions": [ { "id": "backend-systems-distributedlocks-tier-q1", "type": "mcq", "prompt": "A scheduled cleanup job uses a Redis lock so it never runs on two machines at once. If the lock's safety guarantee is occasionally imperfect, what's the actual risk?", "options": [ {"id":"a","text":"A payment could be charged twice"}, {"id":"b","text":"The cleanup job might run twice in a rare edge case, which is usually a low-stakes, tolerable outcome for this kind of task"}, {"id":"c","text":"Data loss across the entire database"}, {"id":"d","text":"There is no way to reason about the risk without fencing tokens"} ], "correct": "b", "explanation": "Knowing which tier a use case falls into is the point: a scheduled cleanup job double-running occasionally is usually a tolerable, low-stakes outcome, which is exactly the case where a TTL-plus-renewal lock without fencing is a reasonable, industry-standard trade-off." } ] } ``` 95:T520a,"Design an API for X" is one of the most common backend interview prompts, because the answer shows whether you think in terms of resources, consistency, and room to grow, or just wire up whatever routes come to mind first. This lesson covers what "RESTful" actually means, how to shape full CRUD for a resource, the exact difference between POST, PUT, and PATCH, pagination that survives a large table, and the networking layers (DNS, routing, HTTPS) a request travels through before it ever reaches your code. ## What makes an API "RESTful": the Richardson Maturity Model Picture three different ways to build a vending machine. The cheapest one has a single button: you tell the attendant what you want out loud, and they fetch it. A better one has one button per item. The best one also lights up which buttons are still in stock before you press anything. The Richardson Maturity Model grades APIs the same way, from "one endpoint for everything" up to "the API tells you what you can do next." - **Level 0: one endpoint, everything is a message.** Every request goes to the same URL, usually a `POST`, with the real instruction buried in the body: `POST /api` with `{"action": "getUser", "id": 42}`. This is a function call disguised as HTTP. It is not REST. - **Level 1: one URL per resource.** `/users/42`, `/orders/7` each name a specific thing, but every request might still be a `POST`. - **Level 2: proper HTTP verbs and status codes.** Resources plus `GET`/`POST`/`PUT`/`PATCH`/`DELETE` used for what they actually mean, and status codes (`200`, `404`, `409`) that tell the client what happened without it having to parse the body. **This is what "RESTful API" means in practice for almost every real system**, including the one built in this lesson. - **Level 3: HATEOAS.** Every response includes links to what you can do next (`"actions": {"cancel": "/orders/7/cancel"}`), so a client can navigate the API without hardcoding URL shapes ahead of time. Almost nobody fully implements this: it adds real client complexity for a benefit that mostly matters to browser-driven, hypermedia-style clients, not the typical mobile app or microservice caller. The interview answer: know that Level 2 is the practical target for nearly every API you'll ever build, and be able to name what Level 3 would add and why most teams skip it. > **Remember:** Level 2, resources plus correct HTTP verbs and status codes, is what "RESTful" means in practice. Level 3 (HATEOAS) is a known term you should recognize, not a bar you need to clear. ```knowledge-check { "questions": [ { "id": "backend-apis-rest-api-design-maturity-q1", "type": "mcq", "prompt": "An API has separate URLs per resource (/users/42, /orders/7) and uses GET, POST, PUT, and DELETE correctly with matching status codes, but responses never include links to related actions. What Richardson Maturity Level is this?", "options": [ {"id":"a","text":"Level 0"}, {"id":"b","text":"Level 1"}, {"id":"c","text":"Level 2, which is what most production APIs, including RESTful ones, stop at"}, {"id":"d","text":"Level 3, since it uses proper URLs"} ], "correct": "c", "explanation": "Resources plus correctly used HTTP verbs and status codes is Level 2. Level 3 would additionally embed links to related actions in every response (HATEOAS), which most real systems skip." } ] } ``` ## Designing full CRUD for a resource Take a small blog: posts, comments on a post, and likes on a post. The data shapes first: ```python # FastAPI example — posts, comments, likes from fastapi import FastAPI, HTTPException, Query, status from pydantic import BaseModel from typing import Optional app = FastAPI() class PostCreate(BaseModel): title: str body: str author_id: int class PostUpdate(BaseModel): title: Optional[str] = None body: Optional[str] = None class Post(BaseModel): id: int title: str body: str author_id: int like_count: int ``` And the routes that operate on them: ``` POST /posts create a post GET /posts list posts (paginated, filterable, sortable) GET /posts/{id} fetch one post PATCH /posts/{id} partial update PUT /posts/{id} full replace DELETE /posts/{id} delete GET /posts/{id}/comments list comments on a post (nested resource) POST /posts/{id}/comments create a comment on a post POST /posts/{id}/likes like a post (idempotent-in-effect: liking twice = still liked) DELETE /posts/{id}/likes/me unlike ``` Nesting `/posts/{id}/comments` under the post communicates ownership, and reads cleanly as "comments on this post." A flat `/comments?post_id={id}` is easier to filter and sort generically. Both are defensible; say which one you picked and why out loud. The one rule that always holds: cap nesting at one or two levels. `/posts/{id}/comments/{id}/replies/{id}` is ugly to read and ugly to route. Beyond two levels, go flat with a query parameter instead. > **Remember:** name resources as nouns, use nesting to show ownership one level deep, and switch to a flat resource with a query parameter once nesting would go past two levels. ```knowledge-check { "questions": [ { "id": "backend-apis-rest-api-design-crud-q1", "type": "mcq", "prompt": "Why does /posts/{id}/comments/{id}/replies/{id} become a problem as a URL design, even though each level is a real resource?", "options": [ {"id":"a","text":"FastAPI cannot route more than two path parameters"}, {"id":"b","text":"Deep nesting gets hard to read and route; beyond one or two levels, flatten with a query parameter instead"}, {"id":"c","text":"REST forbids nested resources entirely"}, {"id":"d","text":"Nested resources cannot be paginated"} ], "correct": "b", "explanation": "Nesting is fine one level deep to show ownership, but it gets unreadable fast. The practical rule is to cap it at one or two levels and go flat with query parameters after that." } ] } ``` ## POST vs PUT vs PATCH: idempotency Think of a light switch versus a light dimmer you nudge up by one notch. Flipping the switch to "on" a hundred times leaves the light exactly as on as flipping it once: that's idempotent. Nudging the dimmer up by one notch a hundred times leaves it much brighter than nudging it once: that's not idempotent. HTTP methods carry the exact same distinction. | Verb | Semantics | Idempotent? | Body | |---|---|---|---| | `POST` | Create a new resource (server assigns the ID), or a non-idempotent action | No | Full or partial resource, or an action payload | | `PUT` | Replace a resource entirely at a known URL | Yes | The full resource; fields you leave out get cleared or defaulted | | `PATCH` | Partially update a resource | Not guaranteed by the spec, but usually implemented as idempotent | Only the fields to change | **Idempotent** means calling something N times has the same effect as calling it once. `PUT /posts/7` with the same body twice leaves the post in the same state both times. `POST /posts` called twice creates two posts. This is not academic: idempotent methods are safe to retry blindly after a network timeout, since you don't know whether the first request landed, but retrying can't make things worse. A non-idempotent method needs an idempotency key if you want that same retry safety. ```python @app.patch("/posts/{post_id}", response_model=Post) async def update_post(post_id: int, patch: PostUpdate): post = get_post_or_404(post_id) update_data = patch.model_dump(exclude_unset=True) # only fields the client actually sent for field, value in update_data.items(): setattr(post, field, value) save_post(post) return post @app.put("/posts/{post_id}", response_model=Post) async def replace_post(post_id: int, body: PostCreate): post = get_post_or_404(post_id) post.title = body.title # PUT sets every field from the request body — post.body = body.body # there is no partial PUT; that's what PATCH is for post.author_id = body.author_id save_post(post) return post ``` `exclude_unset=True` is what makes `PATCH` genuinely partial. Without it, fields the client never sent would come through as their defaults and silently overwrite existing data, turning your PATCH into an accidental PUT. **Common mistake:** treating PATCH and PUT as interchangeable. A client sending a partial body to a PUT-shaped handler will unknowingly wipe out every field it didn't include. > **Remember:** PUT replaces the whole resource and is always idempotent. PATCH changes only the fields sent. POST creates something new every time, so retries of a POST need an idempotency key. ```knowledge-check { "questions": [ { "id": "backend-apis-rest-api-design-verbs-q1", "type": "mcq", "prompt": "A client's request to your API times out. It doesn't know if the request reached the server. For which method is it always safe to just retry the exact same request?", "options": [ {"id":"a","text":"POST, since it always creates a fresh resource"}, {"id":"b","text":"PUT, since calling it twice with the same body leaves the resource in the same state either way"}, {"id":"c","text":"Neither is ever safe to retry"}, {"id":"d","text":"Both are equally unsafe without an idempotency key"} ], "correct": "b", "explanation": "PUT is idempotent by definition: repeating it with the same body produces the same end state, so a blind retry after a timeout cannot cause harm. POST creates a new resource on every call, so retrying it risks a duplicate unless you add an idempotency key." } ] } ``` ## Pagination, filtering, and sorting at scale ```python @app.get("/posts", response_model=list[Post]) async def list_posts( author_id: Optional[int] = None, sort: str = Query("created_at", pattern="^(created_at|like_count)$"), order: str = Query("desc", pattern="^(asc|desc)$"), limit: int = Query(20, le=100), # cap page size — never let a client ask for unbounded rows cursor: Optional[str] = None, # opaque cursor, not a raw offset ): filters = {} if author_id is not None: filters["author_id"] = author_id posts, next_cursor = post_repository.list( filters=filters, sort=sort, order=order, limit=limit, cursor=cursor ) return {"items": posts, "next_cursor": next_cursor} ``` **Offset pagination** (`?page=3&page_size=20`) reads like the simple choice, but it degrades on a large table: `OFFSET 60000` still makes the database scan and throw away 60,000 rows before returning anything. It also gets confused under concurrent writes. If a new row is inserted while a user is on page 1, everything after it shifts by one, so paging forward skips or repeats rows for that user. **Cursor pagination** (`?cursor=&limit=20`) encodes the last row you saw, for example its `created_at` and `id`, into an opaque token. The next query becomes `WHERE (created_at, id) < (last_created_at, last_id) ORDER BY created_at DESC, id DESC LIMIT 20`, an indexed range scan instead of a skip-then-scan. New inserts elsewhere in the table don't shift your position. For any "pagination at scale" question, lead with cursor pagination and say why offset breaks down. > **Remember:** offset pagination scans and discards every row before the page you asked for; cursor pagination jumps straight there with an indexed range scan, and stays correct while rows are being inserted. ```knowledge-check { "questions": [ { "id": "backend-apis-rest-api-design-pagination-q1", "type": "mcq", "prompt": "A table gets thousands of new rows a minute. Why does offset pagination (?page=3) become unreliable here, not just slow?", "options": [ {"id":"a","text":"Offset pagination only works with fewer than 1,000 rows total"}, {"id":"b","text":"A row inserted while a user pages through shifts every later row by one position, causing that user to skip or repeat rows"}, {"id":"c","text":"Databases do not support the OFFSET keyword at scale"}, {"id":"d","text":"Offset pagination requires a full table lock"} ], "correct": "b", "explanation": "Offset counts rows from the start on every request. A concurrent insert shifts every row after it by one position, so a user's page 2 can silently skip or duplicate a row compared to what they saw on page 1." } ] } ``` ## REST vs SOAP | | REST | SOAP | |---|---|---| | What it is | An architectural style, a set of constraints, not a protocol | A strict messaging protocol with a formal specification | | Transport | HTTP, in practice | Transport-agnostic: HTTP, SMTP, TCP, message queues | | Data format | Any; JSON is standard, XML or plain text also work | XML only, inside a rigid envelope | | Contract | Loose, documented via OpenAPI/Swagger, not enforced by the protocol | Strict; a WSDL file formally defines every operation, type, and fault | | Payload weight | Lightweight (JSON is compact) | Heavy (verbose XML, namespaces) | | Built-in security | None; relies on HTTPS, OAuth, and so on, layered on top | WS-Security and WS-ReliableMessaging are part of the spec itself | | Typical use today | Public APIs, mobile backends, microservices, the default for anything new | Legacy enterprise systems, banking and payment gateways, domains with a regulatory need for a formal contract | The one-sentence interview answer: REST is a flexible, resource-oriented style that won because it's simple and maps naturally onto HTTP, while SOAP is a rigid, contract-first protocol still found in enterprise and financial systems, where the formal WSDL contract and built-in security guarantees outweigh the overhead. You'll almost certainly build a REST API, but you may still need to talk to a SOAP-based system, like a bank or an airline booking system, that predates REST's dominance. > **Remember:** REST is a style layered on HTTP with a loose, documented contract. SOAP is a strict, self-describing protocol still common in banking and legacy enterprise systems. ```knowledge-check { "questions": [ { "id": "backend-apis-rest-api-design-soap-q1", "type": "mcq", "prompt": "Why would a bank's payment gateway still use SOAP today instead of a REST API?", "options": [ {"id":"a","text":"SOAP is always faster than REST over HTTP"}, {"id":"b","text":"SOAP's formal WSDL contract and built-in security/reliability guarantees fit a legacy, regulated system, and switching a working integration has little upside"}, {"id":"c","text":"REST cannot transmit XML data"}, {"id":"d","text":"SOAP is a newer standard than REST"} ], "correct": "b", "explanation": "SOAP is older than REST, not newer. Its appeal in finance and legacy enterprise systems is the strict, machine-checkable WSDL contract and the reliability/security features built into the protocol itself, which matter more there than payload size." } ] } ``` ## How HTTPS keeps a connection private: the TLS handshake Plain HTTP sends every byte in the clear. Anyone sitting on the network path between you and the server, a public Wi-Fi hotspot, a compromised router, an ISP, can read or change it in transit. HTTPS wraps HTTP inside TLS (the successor to SSL) encryption. Here's the handshake that sets that encryption up, worth being able to explain step by step: 1. The client connects and lists the TLS versions and cipher suites it supports ("ClientHello"). 2. The server answers with its chosen cipher suite and its certificate, which contains its public key and is signed by a Certificate Authority. 3. The client checks the certificate: is it signed by a CA the client trusts, does the domain name match, and has it not expired? 4. The client and server briefly use asymmetric cryptography (slow, but fine for a small handshake) to agree on a shared symmetric session key. 5. Every byte from here on is encrypted with that fast symmetric key. This is exactly what blocks a person-in-the-middle attack: an eavesdropper who intercepts the connection can't read the traffic without the session key, and can't forge a valid certificate for a domain they don't own, because a browser will flag a forged one as untrusted. A few practical details that come up: HTTP defaults to port 80, HTTPS to port 443. Certificates come in tiers: Domain Validated (DV) just proves you control the domain and can be automated with Let's Encrypt; Organization Validated (OV) checks the requesting organization; Extended Validation (EV) is the strictest, though its old green-address-bar signal has since been dropped by most browsers. An HTTPS page that loads one HTTP resource, an image or a script, creates "mixed content," a hole an attacker can exploit; modern browsers block active mixed content (scripts) outright and warn on passive mixed content (images). > **Remember:** the TLS handshake uses slow asymmetric crypto only to agree on a fast symmetric session key, then encrypts everything else with that key. A forged certificate for a domain the attacker doesn't own is what the handshake is built to catch. ```knowledge-check { "questions": [ { "id": "backend-apis-rest-api-design-tls-q1", "type": "mcq", "prompt": "Why does TLS use slow asymmetric cryptography only briefly during the handshake, instead of for the whole connection?", "options": [ {"id":"a","text":"Asymmetric crypto is illegal to use for bulk data in most countries"}, {"id":"b","text":"Asymmetric crypto is too slow for streaming data, so it's used only to safely agree on a fast symmetric session key, which then encrypts the rest of the traffic"}, {"id":"c","text":"Browsers do not support asymmetric crypto past the handshake"}, {"id":"d","text":"Symmetric keys are less secure, so they are used only briefly"} ], "correct": "b", "explanation": "Asymmetric crypto is computationally expensive, which is fine for a one-time handshake but too slow for every byte of a connection. TLS uses it only to bootstrap a shared symmetric key, then switches to that fast key for everything else." } ] } ``` ## How a hostname turns into a server: DNS and routing Two small pieces of networking that get asked back-to-back in a "fundamentals" round, precisely because each one is quick to cover on its own. **DNS** turns a hostname like `api.mindforge.test` into an IP address through a hierarchical lookup: root nameservers point to nameservers for the top-level domain (`.com`), which point to the authoritative nameserver for `mindforge.test` itself, which finally answers with the actual IP. That result gets cached at the OS, the browser, and the resolver, according to a TTL (time to live) on the DNS record. This caching is exactly why a DNS change can take time to reach everyone even after the authoritative record has already been updated: every cache holding the old answer has to wait out its own TTL first. **A routing table** is what a router consults to decide where to send a packet next. It maps network destinations to a next-hop address, and a router only knows the next hop, not the full path. A packet crosses the network one hop at a time, each router forwarding it a little closer, until it reaches the network the destination lives on. > **Remember:** DNS resolves a name to an address through a chain of nameservers, and every cache along that chain waits out its own TTL before it asks again. Routing moves a packet one hop closer at a time; no single router knows the whole path. ```knowledge-check { "questions": [ { "id": "backend-apis-rest-api-design-dns-q1", "type": "mcq", "prompt": "A team updates a DNS record, but some users still reach the old server for several minutes afterward. What explains this?", "options": [ {"id":"a","text":"DNS updates are always instant, so this points to a misconfigured record"}, {"id":"b","text":"The old answer is still cached somewhere along the resolution chain (OS, browser, or resolver) until that cached copy's TTL runs out"}, {"id":"c","text":"Routing tables, not DNS, control which server a request reaches"}, {"id":"d","text":"Only the authoritative nameserver's cache matters, and it always updates instantly"} ], "correct": "b", "explanation": "DNS results are cached at several layers (OS, browser, resolver), each governed by the record's TTL. Even after the authoritative record changes, a cache that already has the old answer keeps serving it until its own TTL expires." } ] } ``` The next lesson, API Versioning and Error Handling, picks up where the brief versioning mention here leaves off: the real trade-offs between versioning strategies, and a standardized way to shape errors so every client can handle them the same way. 96:T3c94,An API that works is table stakes. An API that can change without breaking every client that calls it is what separates a junior design from a senior one. This lesson covers the real trade-offs between versioning strategies, what actually counts as a breaking change, a standardized error shape every endpoint can share, the status codes worth knowing cold, and rate limiting at the API layer. ## Choosing a versioning strategy | Strategy | Example | Strength | Weakness | |---|---|---|---| | **URL path** | `/v1/posts`, `/v2/posts` | Explicit, cacheable, visible in logs and metrics, easy to route to different code | Versions the whole API even for one unrelated change; the URL stops being a stable name for the resource | | **Header** | `Accept: application/vnd.myapi.v2+json` | Keeps URLs stable; the resource's identity never changes | Invisible in logs and the browser, harder to test by hand (curl needs an explicit header), harder to cache by URL | | **Query param** | `/posts?version=2` | Simple to add | Easy to forget, mixes with other query semantics, the least conventional choice | Picture a shop that renumbers every aisle whenever it changes one shelf, versus one that only renumbers when it rebuilds the whole layout. Most production APIs use **URL path versioning at the major-version level only** (`/v1`, `/v2`), and handle everything else, new optional fields, new endpoints, deprecations, without bumping the version at all. A new major version means running two full codepaths side by side, which is expensive, so the practical answer to "how would you version an API" is: version rarely, and reserve it for genuine breaking changes. > **Remember:** version at the major level only, through the URL path, and treat a version bump as expensive. Most changes don't need one. ```knowledge-check { "questions": [ { "id": "backend-apis-versioning-strategy-q1", "type": "mcq", "prompt": "Why do most production APIs version only at the major level (/v1, /v2) instead of bumping a version for every change?", "options": [ {"id":"a","text":"HTTP only supports two API versions at a time"}, {"id":"b","text":"Each major version means maintaining a full parallel codepath, so it's reserved for genuinely breaking changes, not routine additions"}, {"id":"c","text":"Minor versions are not supported by any web framework"}, {"id":"d","text":"URL path versioning is the only strategy that works at all"} ], "correct": "b", "explanation": "A new major version usually means keeping two complete implementations running side by side until clients migrate. That cost is why teams reserve version bumps for real breaking changes and handle everything else without one." } ] } ``` ## What counts as a breaking change - Removing a field from a response - Renaming a field - Changing a field's type (`string` to `int`) - Making validation stricter, so requests that used to succeed now get rejected - Changing the status code an existing scenario returns **Not breaking:** - Adding a new optional field to a response (a client that doesn't know about it just ignores it) - Adding a new endpoint - Adding a new optional request parameter with a sensible default - Loosening validation, so requests that used to be rejected now succeed The rule to say out loud: additive changes are safe, removals, renames, and type changes are not. Pair that with deprecating gracefully: add a `Deprecation` and `Sunset` header and give clients a real migration window before removing anything. ```python from fastapi import Response @app.get("/v1/posts/{post_id}") async def get_post_v1(post_id: int, response: Response): response.headers["Deprecation"] = "true" response.headers["Sunset"] = "Sat, 31 Jan 2026 00:00:00 GMT" response.headers["Link"] = '; rel="successor-version"' return get_post(post_id) ``` > **Remember:** adding is safe, removing/renaming/retyping is not. Deprecate with a `Sunset` header and a migration window before you ever remove a field. ```knowledge-check { "questions": [ { "id": "backend-apis-versioning-breaking-q1", "type": "mcq", "prompt": "Which of these is a breaking change to an existing API endpoint's response?", "options": [ {"id":"a","text":"Adding a new optional field that existing clients can safely ignore"}, {"id":"b","text":"Changing a field's type from string to int"}, {"id":"c","text":"Adding a brand new endpoint elsewhere in the API"}, {"id":"d","text":"Loosening a validation rule so more requests succeed"} ], "correct": "b", "explanation": "Changing a field's type breaks any client that parses that field expecting the old type. Additive changes (a new field, a new endpoint, looser validation) are the safe category; removals, renames, and type changes are not." } ] } ``` ## Keeping the version boundary out of business logic ```python from fastapi import FastAPI, APIRouter app = FastAPI() v1_router = APIRouter(prefix="/v1") v2_router = APIRouter(prefix="/v2") @v1_router.get("/posts/{post_id}") async def get_post_v1(post_id: int): post = post_service.get(post_id) return {"id": post.id, "title": post.title, "body": post.body} # v1 shape @v2_router.get("/posts/{post_id}") async def get_post_v2(post_id: int): post = post_service.get(post_id) # same underlying service call return { "id": post.id, "title": post.title, "body": post.body, "author": {"id": post.author_id, "name": post.author.name}, # v2 adds nested author } app.include_router(v1_router) app.include_router(v2_router) ``` Both routers call the exact same `post_service.get()`. The version boundary lives at the serialization layer, the shape returned to the client, not duplicated inside business logic. That single detail is what shows an interviewer you won't end up copy-pasting an entire module every time you cut a new version. > **Remember:** keep one shared service underneath every version. Only the response shape changes per version; the logic that fetches and validates data never forks. ```knowledge-check { "questions": [ { "id": "backend-apis-versioning-boundary-q1", "type": "mcq", "prompt": "Why should the /v1 and /v2 routers in the example both call the same post_service.get() instead of each having their own copy of the fetch logic?", "options": [ {"id":"a","text":"FastAPI requires every router to share the exact same functions"}, {"id":"b","text":"Duplicating business logic per version means every future bug fix or change has to be made twice, and the two versions will eventually drift"}, {"id":"c","text":"Only one version of an API is allowed to touch the database"}, {"id":"d","text":"Shared functions run faster than duplicated ones"} ], "correct": "b", "explanation": "Keeping the version boundary at the serialization layer means a bug fix or new validation rule only needs to be written once. Forking business logic per version guarantees the two copies drift apart over time." } ] } ``` ## A standardized error response shape Every endpoint, every error, the same envelope, so a client writes one error-handling path instead of one per endpoint. ```python from fastapi import FastAPI, Request, HTTPException from fastapi.responses import JSONResponse from fastapi.exceptions import RequestValidationError import logging app = FastAPI() logger = logging.getLogger(__name__) def error_envelope(code: str, message: str, details: list | None = None) -> dict: return { "error": { "code": code, # stable machine-readable string, e.g. "VALIDATION_ERROR" "message": message, # human-readable summary "details": details or [], } } @app.exception_handler(RequestValidationError) async def validation_exception_handler(request: Request, exc: RequestValidationError): details = [ {"field": ".".join(str(p) for p in err["loc"]), "issue": err["msg"]} for err in exc.errors() ] return JSONResponse( status_code=422, content=error_envelope("VALIDATION_ERROR", "Request validation failed", details), ) @app.exception_handler(HTTPException) async def http_exception_handler(request: Request, exc: HTTPException): return JSONResponse( status_code=exc.status_code, content=error_envelope(f"HTTP_{exc.status_code}", str(exc.detail)), ) @app.exception_handler(Exception) async def unhandled_exception_handler(request: Request, exc: Exception): # Never leak internals (stack traces, DB errors) to the client — log them, return a generic message logger.exception("Unhandled exception on %s %s", request.method, request.url.path) return JSONResponse( status_code=500, content=error_envelope("INTERNAL_ERROR", "An unexpected error occurred"), ) ``` The catch-all `Exception` handler is the one interviewers pay attention to. Without it, an unhandled bug leaks its stack trace, and sometimes a database connection string inside it, straight to whoever sent the request. With it, the client sees a clean generic message while the full detail still lands in your own logs. > **Remember:** log the full error server-side, but never send a stack trace or internal detail back to the client. A generic message plus a stable error code is enough for the client to act on. ```knowledge-check { "questions": [ { "id": "backend-apis-versioning-errors-q1", "type": "mcq", "prompt": "Why does the catch-all Exception handler return a generic \"An unexpected error occurred\" message instead of the real exception's text?", "options": [ {"id":"a","text":"FastAPI does not allow returning the real exception text"}, {"id":"b","text":"The real exception can contain internal details, like a stack trace or a database connection string, that must never reach the client; full detail is logged server-side instead"}, {"id":"c","text":"Generic messages are required by the HTTP specification"}, {"id":"d","text":"It makes the response smaller, which is the only reason"} ], "correct": "b", "explanation": "An unhandled exception's message or traceback can expose internals an attacker could use. Logging the full detail server-side while returning a generic message to the client is what keeps that information from leaking." } ] } ``` ## Status codes worth knowing cold | Code | Meaning | When | |---|---|---| | 200 | OK | A successful GET, PUT, or PATCH | | 201 | Created | A successful POST that created a resource; include a `Location` header | | 204 | No Content | A successful DELETE, or a PUT/PATCH with nothing to return | | 400 | Bad Request | A malformed request the client should fix (the generic case) | | 401 | Unauthorized | Missing or invalid authentication | | 403 | Forbidden | Authenticated, but not allowed to do this | | 404 | Not Found | The resource doesn't exist | | 409 | Conflict | A state conflict, like a duplicate unique key or a version mismatch on optimistic locking | | 422 | Unprocessable Entity | Syntactically valid but semantically invalid (FastAPI's default for a failed Pydantic validation) | | 429 | Too Many Requests | Rate limited; include a `Retry-After` header | | 500 | Internal Server Error | An unhandled failure on the server | | 503 | Service Unavailable | Temporarily down, for a deploy or an overload; include `Retry-After` | > **Remember:** 401 means "I don't know who you are," 403 means "I know who you are, and the answer is no." Mixing those two up is one of the most common status-code mistakes. ```knowledge-check { "questions": [ { "id": "backend-apis-versioning-statuscodes-q1", "type": "mcq", "prompt": "A logged-in user with a valid session tries to delete another user's post. What status code fits?", "options": [ {"id":"a","text":"401 Unauthorized, since they aren't allowed to do this"}, {"id":"b","text":"403 Forbidden, since they are authenticated but not permitted to perform this action"}, {"id":"c","text":"404 Not Found, to hide that the post exists"}, {"id":"d","text":"400 Bad Request"} ], "correct": "b", "explanation": "401 means the server doesn't know who is asking (missing or invalid authentication). This user is authenticated, so the correct code is 403: identity is known, but the action is not permitted." } ] } ``` ## Rate limiting at the API level A rate limiter built as middleware, wrapping the same sliding-window idea used for a Redis-backed cache elsewhere in this course: ```python from fastapi import Request, HTTPException from starlette.middleware.base import BaseHTTPMiddleware class RateLimitMiddleware(BaseHTTPMiddleware): def __init__(self, app, redis_client, limit: int = 100, window_seconds: int = 60): super().__init__(app) self.redis = redis_client self.limit = limit self.window_seconds = window_seconds async def dispatch(self, request: Request, call_next): client_id = request.headers.get("X-API-Key", request.client.host) key = f"ratelimit:{client_id}:{int(time.time()) // self.window_seconds}" count = self.redis.incr(key) if count == 1: self.redis.expire(key, self.window_seconds) if count > self.limit: return JSONResponse( status_code=429, content=error_envelope("RATE_LIMITED", "Too many requests"), headers={"Retry-After": str(self.window_seconds)}, ) response = await call_next(request) response.headers["X-RateLimit-Limit"] = str(self.limit) response.headers["X-RateLimit-Remaining"] = str(max(0, self.limit - count)) return response app.add_middleware(RateLimitMiddleware, redis_client=redis.Redis(), limit=100, window_seconds=60) ``` Rate limit by API key, or by authenticated user ID, whenever you have one, and only fall back to the raw IP address for anonymous traffic. IP-based limiting alone is easy to both defeat and over-trigger: a malicious client can rotate IPs to dodge the limit, while an entire office sharing one NAT'd IP can get throttled together for someone else's traffic. > **Remember:** rate limit by API key or user ID first, and only fall back to IP for anonymous traffic. IP alone is both too easy to dodge and too easy to over-trigger on shared IPs. ```knowledge-check { "questions": [ { "id": "backend-apis-versioning-ratelimit-q1", "type": "mcq", "prompt": "Why does the rate limiter prefer the X-API-Key header over the client's raw IP address when both are available?", "options": [ {"id":"a","text":"IP addresses cannot be used as a Redis key"}, {"id":"b","text":"An API key identifies one specific client, while an IP can represent a whole shared office (over-triggers on legitimate traffic) or be rotated by an attacker (under-triggers on abuse)"}, {"id":"c","text":"Rate limiting by IP is not supported in FastAPI"}, {"id":"d","text":"API keys never expire, so they are simpler to track"} ], "correct": "b", "explanation": "An IP is a poor proxy for identity: many legitimate users can share one IP behind NAT, and a determined abuser can rotate IPs. An API key or authenticated user ID identifies the actual caller directly." } ] } ``` 97:T863a,Every API interview eventually asks some version of one question: how does the server know who's asking, and what stops that from being abused? This lesson covers JWTs, OAuth, and API keys, a real JWT login flow, refresh token rotation, session versus JWT, CSRF, SQL injection, secrets management, password hashing, and the OWASP API Security Top 10. It's the single most-asked backend topic in interviews; expect at least one system-design question and one "explain the difference between X and Y" question built from this exact material. ## JWT, OAuth, and API keys: three different problems These three get lumped together because they can all ride in the same `Authorization` header, but each one answers a different question. **JWT (JSON Web Token)** is a signed, self-contained token that proves a claim, "this is user 42, expires at time T", without a database lookup. It has three base64 parts separated by dots: `header.payload.signature`. ```python import jwt # PyJWT import datetime SECRET = "use-an-env-var-in-real-code" payload = { "sub": "42", "exp": datetime.datetime.now(datetime.UTC) + datetime.timedelta(minutes=15), "iat": datetime.datetime.now(datetime.UTC), } token = jwt.encode(payload, SECRET, algorithm="HS256") decoded = jwt.decode(token, SECRET, algorithms=["HS256"]) # raises on bad sig or expiry ``` The server never stores this token. Anyone holding the secret (or the matching public key, for the RS256 variant) can verify it. That's the whole point, and also the whole risk: a leaked signing key, or a stolen token that hasn't expired yet, can't be revoked without extra machinery, which is exactly what refresh token rotation exists for. **OAuth 2.0** is a delegation protocol, not an authentication mechanism by itself. It lets a user grant a third-party app limited access to their data on another service, "let this app read your calendar", without ever handing over their password. The output is usually an access token (often a JWT) plus a refresh token. The Authorization Code flow, with PKCE for public clients, is the one to be able to draw on a whiteboard: 1. The app redirects the user to the provider's `/authorize` endpoint with a `client_id`, `redirect_uri`, `scope`, and `state`. 2. The user logs in and approves; the provider redirects back with a one-time `code`. 3. The app's backend exchanges that `code`, plus a `client_secret` or a PKCE `code_verifier`, for an access token at `/token`. 4. The app calls the resource API using the access token. **API keys** are a static, long-lived secret that identifies a *client*, a service or app, not a *user*. No expiry, no claims, just "is this string in my allowed set." Good for server-to-server and third-party integrations, bad for representing a logged-in human, since a key can't carry identity claims or expire gracefully on its own. | | Identifies | Expires | Carries claims | Typical use | |---|---|---|---|---| | JWT | A user, usually | Yes, short-lived | Yes | API auth after login | | OAuth token | A user, via delegation | Yes | Yes (scopes) | Third-party access | | API key | A client or service | No, until rotated | No | Server-to-server | > **Remember:** JWT proves a claim about a user, OAuth delegates limited access on a user's behalf, and an API key just identifies a client. Reach for the one that matches who or what you're actually identifying. ```knowledge-check { "questions": [ { "id": "backend-apis-security-jwtoauthkeys-q1", "type": "mcq", "prompt": "A mobile app needs to read a user's Google Calendar without ever seeing the user's Google password. Which mechanism is designed for exactly this?", "options": [ {"id":"a","text":"A shared API key given to every mobile client"}, {"id":"b","text":"OAuth 2.0, since it delegates limited access to a third-party app without sharing the user's credentials"}, {"id":"c","text":"A JWT signed by the mobile app itself"}, {"id":"d","text":"Basic auth with the user's real password sent on every request"} ], "correct": "b", "explanation": "OAuth exists precisely for this case: a user grants a third-party app scoped access to their data on another service, without that app ever learning the user's password." } ] } ``` ## A real JWT login flow The shape you'd write in an interview or a take-home: hash passwords, issue a short-lived token, verify it on every protected route. ```python from datetime import datetime, timedelta, UTC from fastapi import FastAPI, Depends, HTTPException, status from fastapi.security import OAuth2PasswordBearer, OAuth2PasswordRequestForm from passlib.context import CryptContext import jwt SECRET_KEY = "read-from-env" # os.environ["JWT_SECRET"] in real code ALGORITHM = "HS256" ACCESS_TOKEN_EXPIRE_MINUTES = 15 app = FastAPI() pwd_context = CryptContext(schemes=["bcrypt"], deprecated="auto") oauth2_scheme = OAuth2PasswordBearer(tokenUrl="token") # Stand-in for a DB lookup FAKE_USERS = { "alice": {"username": "alice", "hashed_password": pwd_context.hash("secret123")} } def create_access_token(subject: str, expires_delta: timedelta) -> str: to_encode = { "sub": subject, "exp": datetime.now(UTC) + expires_delta, "iat": datetime.now(UTC), } return jwt.encode(to_encode, SECRET_KEY, algorithm=ALGORITHM) @app.post("/token") def login(form_data: OAuth2PasswordRequestForm = Depends()): user = FAKE_USERS.get(form_data.username) if not user or not pwd_context.verify(form_data.password, user["hashed_password"]): raise HTTPException(status_code=401, detail="Incorrect username or password") token = create_access_token( user["username"], timedelta(minutes=ACCESS_TOKEN_EXPIRE_MINUTES) ) return {"access_token": token, "token_type": "bearer"} def get_current_user(token: str = Depends(oauth2_scheme)) -> str: try: payload = jwt.decode(token, SECRET_KEY, algorithms=[ALGORITHM]) username = payload.get("sub") except jwt.ExpiredSignatureError: raise HTTPException(status_code=401, detail="Token expired") except jwt.InvalidTokenError: raise HTTPException(status_code=401, detail="Invalid token") if username not in FAKE_USERS: raise HTTPException(status_code=401, detail="User not found") return username @app.get("/me") def read_current_user(username: str = Depends(get_current_user)): return {"username": username} ``` Three details interviewers check for: passwords are hashed with bcrypt, never stored or compared as plaintext; expiry is enforced server-side, `jwt.decode` raises automatically once `exp` has passed; and the signing secret never leaves the server (with the asymmetric RS256 scheme, only the private key signs, and the public key can be handed to other services so they can verify tokens without ever gaining the power to mint one). > **Remember:** hash with bcrypt, let `exp` expire tokens automatically, and never let a signing secret leave the server that issues tokens. ```knowledge-check { "questions": [ { "id": "backend-apis-security-jwtlogin-q1", "type": "mcq", "prompt": "In the login flow above, what actually enforces that an expired token gets rejected?", "options": [ {"id":"a","text":"The server checks a separate expiry database on every request"}, {"id":"b","text":"jwt.decode() itself raises ExpiredSignatureError once the token's exp claim is in the past, with no separate lookup needed"}, {"id":"c","text":"FastAPI automatically deletes expired tokens from memory"}, {"id":"d","text":"Expired tokens are rejected by the browser before the request is sent"} ], "correct": "b", "explanation": "A JWT is self-contained: its exp claim is checked by the decoding library itself. No database lookup is needed to know a token has expired, which is the whole appeal of a JWT over a server-stored session." } ] } ``` ## Refresh token rotation Access tokens are short-lived, minutes, so a leaked one does limited damage. Refresh tokens are long-lived, days or weeks, and exist only to mint new access tokens, but a long-lived token sitting in storage is itself a target. Rotation means: every time a refresh token gets used, invalidate it and hand back a brand new one. If a stolen refresh token is ever used by an attacker *and* later by the real user, or the other way around, the reuse of an already-rotated token is a clear, detectable signal that something has been stolen. ```python import secrets from datetime import datetime, timedelta, UTC # refresh_tokens table: token_hash, user_id, expires_at, revoked, replaced_by def issue_refresh_token(db, user_id: str) -> str: raw_token = secrets.token_urlsafe(32) token_hash = hash_token(raw_token) # sha256, never store raw db.refresh_tokens.insert( token_hash=token_hash, user_id=user_id, expires_at=datetime.now(UTC) + timedelta(days=14), revoked=False, ) return raw_token def rotate_refresh_token(db, raw_token: str) -> dict: token_hash = hash_token(raw_token) record = db.refresh_tokens.get(token_hash=token_hash) if record is None or reco

Lab: FastAPI Async — Concurrent Aggregation