# Alex Xu's System Design Interview: keep the four-step framework, add the AI layer yourself > The most useful part of this system design interview book is not its 30 sample designs. It is the four-step answer framework, and FDE candidates should treat it as a guide to their first working session with a client. Bản gốc: https://fdetimes.net/en/books-courses/alex-xu-system-design-interview-fde/ ByteByteGo's official course page lists 30 chapters for System Design Interview, from "Scale From Zero To Millions Of Users" to "Stock Exchange". They teach you to design a news feed, a chat system, YouTube and a payment system. Not one of the 30 deals with ML or LLM systems. FDE candidates should know about this gap from the outset, especially if the interview includes an AI problem. The book covers product and infrastructure problems. ML systems are not among them. The book is still worth reading. For an FDE, though, its main value is not in the YouTube or Stock Exchange designs. It is in the short chapter on how to answer, because that method closely mirrors how an FDE works in a first session with a client. ## What does the book teach, and who has praised it? The chapter list falls into two groups. The foundations cover quick estimation (Back-of-the-envelope Estimation), rate limiters, consistent hashing and key-value stores. The second group is product-style design problems such as news feed, chat, YouTube and payments. Sandor Dargo, who reviewed the book independently on DevReads in February 2022, wrote that it offers a systematic way to prepare for and handle this type of question. In his view, experienced engineers benefit too, because the book presents problems from the interviewer's point of view. Bear in mind that this is a single, favourable review, and it names no weaknesses. To brush up on the distributed-systems concepts the chapters build on, Swimm's overview is a useful companion. It restates the CAP theorem: a distributed system can provide only two of three guarantees. It also describes Saga, a sequence of local transactions in which each step has a matching compensating action. You will meet this pattern in chapters on payments and digital wallets. Swimm is a company blog that promotes its own product, so use the piece only as a refresher. ## The four-step framework is a customer discovery session Step 1 asks you to understand the problem and settle the design scope. The book's advice is blunt: slow down, think carefully, and ask questions to clarify requirements and assumptions. Step 2 is to sketch a first high-level design and ask for feedback, treating the interview as a collaboration. Step 3 goes deep into the design while avoiding unnecessary detail. Step 4 is the wrap-up, and you should never say your design is perfect and has nothing left to improve. Now set those four steps beside real work. On a client site, an FDE asks questions before drawing, shows stakeholders an early sketch so they agree on the direction, digs deep only into the riskiest part, and finishes with a list of open items. So the sensible way to prepare for an FDE interview is to treat the framework as a short customer discovery session, not a script to memorise. **Điểm mấu chốt:** For FDE candidates, the book's value lies in the four-step framework rather than the 30 sample designs. ## One number can change the whole design Take this problem: "Design an internal document Q&A assistant for an insurance company with 2,000 employees." Someone who has memorised all 30 chapters may reach straight for sharding and multi-tier caching. Do step 1 and apply the estimation chapter first. Suppose each employee asks 10 questions a day. That is 20,000 questions over an eight-hour working day, or 28,800 seconds: fewer than one question per second. Even at a peak five times higher, it is only about 3.5 questions per second. At this load, scale is not the hard part. The difficulty shifts to the accuracy of the answers and the time spent waiting on the model. That one-minute calculation shows the interviewer you are solving the client's problem, not the one you are used to solving. It is also a skill worth putting on your CV. A single line about estimating load and then deciding *not* to build something is worth more than five lines listing technologies. ## What the book lacks: the three layers of an AI system To fill the AI gap, read the System Design Handbook's guide to AI system design alongside the book. It also begins by clarifying the problem, but it names the specific questions to ask: data types, latency and scale. That part matches Alex Xu's step 1. The difference lies in the high-level design. The guide recommends splitting the architecture into three layers, data, model and serving, and stating how you are trading scalability against cost and accuracy against latency. Go back to the insurance problem and sketch those three layers. The data layer is the store of policies, terms and internal procedures. The questions to ask are what format the documents are in, how often they are updated, and which employees may see which documents. The model layer finds the relevant passages and drafts an answer based on them. This is where to go deep in step 3, because getting a claims clause wrong does far more harm than waiting a few extra seconds. For the serving layer, the earlier calculation has already done the work: about 3.5 questions per second at peak does not need sharding or multi-tier caching. Because the load is low, a strong answer accepts a slightly slower model in exchange for accuracy, then in step 4 states clearly which parts still need to be measured against the client's real data. ## In what order should you read it? If you have only two weeks, read the framework chapter first, then the estimation chapter. Next come rate limiter, consistent hashing and key-value store for the foundations. Among the product chapters, chat and payments are closer to enterprise systems than YouTube. Read payments together with the Saga material to understand why compensating actions are needed. Then add the data, model and serving layers and re-solve any two problems from the book as AI versions, as with the insurance example above. Three habits are worth keeping once you close the book: ask before you draw, seek feedback early, and never claim your design is perfect. They will get you through the interview, and you should bring them to the client site from day one. **Thử ngay tuần này:** - Read the framework chapter and then Back-of-the-envelope Estimation, then work through an AI problem using all four steps and record your answer. - Write five clarifying questions for the 'internal document Q&A assistant' problem, covering data types, latency requirements and user scale. - Rewrite one line of your CV in the form 'clarified requirements with X, chose architecture Y because of trade-off Z' instead of a list of technologies. ## Nguồn - [System Design Interview (ByteByteGo course)](https://bytebytego.com/courses/system-design-interview) - [A Framework For System Design Interviews (ByteByteGo)](https://bytebytego.com/courses/system-design-interview/a-framework-for-system-design-interviews) - [System Design Interview: An insider's guide by Alex Xu](https://devreads.sandordargo.com/system-design-interview-by-alex-xu/) - [AI System Design: A Complete Guide (System Design Handbook)](https://www.systemdesignhandbook.com/guides/ai-system-design/) - [System Design: Complete Guide with Patterns, Examples, and Techniques (Swimm)](https://swimm.io/learn/system-design/system-design-complete-guide-with-patterns-examples-and-techniques)