This goal of this book is to provide a reliable and easy to understand strategy to approach system design questions. The process and justification of your ideas are the most important things in system design interviews. Thus the combination of right strategy and knowledge is vital to the success of your interview. Some candidates fail because lack of knowledge while some fail because they do not find the right way to approach the problem. This book provides valuable ways to fix both problems. By the time you finish the book, you are exceptionally well-equipped to tackle any system design questions.
About the author Alex is an experienced software engineer and entrepreneur. He enjoys hand-on engineering and the thrill of working on a variety of software products including business applications, web apps and mobile apps. He has worked at Apple and Twitter among other internet companies. While not doing software development, Alex enjoys hiking and gaming.
During the job interviews, he learned many things about system design interviews and achieved many successes. But, it is very time consuming to find the effective materials to prepare the interview, so Alex wrote this book offering the best knowledge to ace the design interviews. Alex hopes this book will save you a lot of time, energy to master the system design questions.
TABLE OF CONTENTS CHAPTER ONE: SCALE FROM ZERO TO TEN MILLION USERS CHAPTER TWO: DESIGN CONSISTENT HASHING CHAPTER THREE: DESIGN A KEY-VALUE STORE CHAPTER FOUR: DESIGN A URL SHORTENER
System Design Interview exposes readers to many concepts that they might otherwise not consider when designing systems. Unlike Designing Data Intensive Applications by Martin Kleppmann, System Design Interview does not provide a foundational first-principles understanding of *why* we can achieve performance improvements. There were two very notable examples of this (and many more I leave undiscussed):
1. At one point, in the Chat design discussion, the author recommends we use a key-value store like Cassandra over a conventional database, but does not provide the critical insight that key-value stores use SSTables which provide sparse, in-mem indices which can performantly support many more rows than on-disk b-trees for highly distributed/"partitioned" systems (also: fewer disk-seeks). This very key distinction of in-mem hash vs on-disk indexing is critical, but the author merely says it "scales better". In general, the author doesn't seem to provide users with a clear grasp of why some NoSQL databases are better than others for some applications, but instead sort of charges ahead with a particular implementation, which I find troubling.
2. The discussion of designing Youtube is clearly a copy of the Facebook whitepaper of how they built their distributed video upload service. However, the author fails to mention a critical detail that most thinking readers would consider, a detail which the Facebook white paper clearly addresses (how to avoid memory leaks/unpredictable uploading times with different-sized videos, by chunking/parallelizing them). It's almost as if he simply wrote the top points from the paper, without actually stopping to carefully think about the overall system.
That said, the links and concepts in System Design Interview are quite helpful, and you will almost certainly learn something you did not previously understand, especially if you pair it with Kleppmann's book and follow-up with reading the end-of-chapter references. The author does a workmanlike job of actually outlining how to orchestrate various systems together, highlighting many details that are easy to overlook. His last chapter on designing Google Drive is impressively thorough and included many factors I would not have otherwise considered.
I primarily recommend the book for its references, which alone are good enough to justify buying the book, which begs the question: why didn't he quote them directly in the book? God knows we engineers know how to copy-paste.
5/5 for the content. 2/5 for the layout and the quality of the printing.
The content is great, I wish there were more books like this one. Most of the books have theory and not enough or not at all practical examples. Alex put 16 great exercises for system design. I would also say that the title doesn't help the book, either you plan to go to interviews or not, the book will teach you how to think about system design. One thing it may misses is to talk a bit about Cloud Economics and how someone should think about the cost of their design and the tradeoffs there.
Good stuff. Interesting ideas (scenarios) one can use for system design interviews. What should you know before buying and reading this book?
1. the scenarios are not super-unique; I've used approximately 50% of them before, but they are very well-chosen and interesting 2. the scenarios are well covered, but it doesn't mean you don't have to have the necessary knowledge on your own - quite the contrary: they guide you through what should be covered, but the devil is (of course) in the details - it's up to you to decide on what you focus upon
Is it an essential book? No, it isn't. I did well before and so will you if you have sufficient engineering curiosity and some expertise. But it's a useful resource - both if you want to use it directly, or if you want some inspiration to come up with your own scenarios.
I recently went through the interview process and I found this book a helpful practice set.
The Good This book is most useful as a way to see the things that an experienced distributed systems engineer would explore when answering a systems design interview that go beyond the rote answer to the question (what's the overall data flow and where should it run). Topics like AuthN/Z, partitioning, Abuse (DDOS, malware, abuse imagery, etc), Datacenter failure tolerance, etc are mentioned in follow ups.
It's ALSO a great way to get exposure to systems with which you may not have had personal experience (the search domain is a weakness of mine), with some associated real world solutions.
Finally - I found the second chapter's point to lay out a script for yourself for how to handle interviews to be very helpful.
For Coding TPSs my script was: 1. Explain / Clarify the problem statement. 2. Explore edge cases (what if the tree is null, what if the tree only has negative numbers?) . 3. Present a high level design - get buy-in. 4. Code up the solution. 5. Walk through the solution - resolve bugs. 6. Give runtime and space complexity.
For System Designs I followed a slightly modified script from the one in this book : 1. Explain / Clarify problem statement (make sure you understand inputs and outputs). 2. Brain storm ideas - present a main high level approach - get buy in. 3. Call out major edge cases and mention other things which you're thinking about but may tackle later (abuse, DDOS, replication, etc). 3. Discuss scale / do back of the envelope math if appropriate. 4. Diagram out your solution. 5. Walk through the solution with the interviewer.
The Bad The only issue I found with this book is that all of these systems presented are online (there are almost no offline systems discussed). The examples themselves are also relatively basic (though still great practice).
Overall Cheap insurance for the system design portion - would recommend for any backend distributed systems engineer going through the loop.
Nice quick read, I like the systematic approach to solving the problems and breaking the process into steps or stages with expectations set of each step, which helps in improving communication between interviewer and interviewee. Also a decent collection of problems that are common enough. Highly recommended for prepping to interviews, obviously not comprehensive enough for the subject but that's to be expected.
This book had some great case studies and really helped me understand how to break down these types of interviews. It actually got me excited again to code and be a software engineer and have to make these kinds of decisions. It’s probably not the best book for applying these ideas in practice but that’s why I added a bunch of other books in this genre to my want to read.
Why I read it: I participate in system design interviews as an interviewer from time to time. And unfortunately this is one of my weaker skills. I thought maybe reading a book about system design interviews would help me to understand the nuances of the exercise better and become a better interviewer.
Since the book consist of multiple different design exercises I read it one chapter per week. Read the intro part first, spent some time figuring out my take on the design and then read the solution and reflected a bit why I have taken different paths and things I forgot to consider.
What I liked about it: This is a really good reference book. Each design explanation is easy to read, well illustrated, have links for relevant resources. It covers most of the typical design exercises + short introductions to scaling and back of the envelope estimation. There is a list of additional resources and engineering blogs at the end.
I have expected this exercise I planned for myself to be really gruelling. But the easy and approachable style of the book made it quite easy and quick (I’ve spent around an hour on each).
It gave me a little ego boost as I realised I am already familiar with part of the technologies and solutions mentioned in the book.
What I disliked: I think I got out of it a lot less than I’ve expected. I only read what was in the book, did not follow up on the references. I would have liked it more if the chapters were more detailed and forced me to think more when reading (instead of hoping I won’t be lazy and do the extra work of looking up references).
The book was not very well suited for the kind of exercise I designed for myself. When reading the intro it wasn’t always clear when I should stop to not see any spoilers (though usually it was ok to stop after the example exchange of the candidate and interviewer). The solutions didnt follow a consistent pattern (e.g. high level design, api, database schema etc.) so sometimes after doing a practice design I’d see I went in a completely different direction. (Though I do understand why the book was written this way, as different designs were there to illustrate different problems and it did not make sense to follow the same pattern.)
My main take away from the exercise: ‘Never ASSUME… it makes an ASS out of U and ME’. Or in other words: I noticed I tend to skip things I see as ‘obvious’ and jump to the places I consider interesting or problematic but a lot better common ground (and system design) can be reached when starting simple and voicing out all the assumptions made.
Çok basit bir dille ve çok basit bir anlatımla YouTube’dan, twitter’a, Google Drive (ya da Dropbox)’dan WhatsApp’a çeşitli uygulamaların ya da bileşenlerinin tasarımlar ele alınmış. Kitabımızın isminden de anlaşıldığı üzere anlatım mülakat şeklinde. Öyle olunca kısmen kolayına kaçmış yazar. 1 saatte bunları nasıl tasarlarsın gibi ele alınca makul. Ama işte, Ama okunur, okunur. Bir de her bölüm bir sürü ek okuma linki paylaşmış. Onlar esas hazine. Bir güzel tarafı da bu tasarımlar üzerine ekleye ekleye giden yapılara dönüşüyor. Mesela dağıtık sistemde id üretimi var bir bölümde. Onu tasarla diyor. Sonra onu bir başka tasarımda onu da kullanıyorsun. Aynısı “key value store” için de geçerli gibi gibi… Hem kendi kendine tekrar eden -hatırlatan- yapıları, hem de ek okumalarıyla sevdim, basit dilinin yanında.
“Designing Data Intensive Applications” bu işin feriştahı. Onun öncesinde okunması yerinde olacaktır tabii. Benim gibi tersini yapmamalı. :)
The pacing isn't quite right - there are rapid jumps from fundamental concepts to advanced concepts and back again. Within 8 pages the book covers (with diagrams) read/write quorums, strong, weak and eventual consistency, vector clock inconsistency resolution, gossip protocol failure detection, and more. This is far too many topics for that amount of pages and reads a bit like a laundry list of topics to learn from another source.
The book should have spent more initial time on the essential building blocks of scalable systems: DNS, load balancers, cache, SQL vs NoSQL databases, database sharding & replication, etc and then explaining how these concepts fit together.
Then, when the book moves to examples of systems, each concept should be discussed with reference to the earlier decisions (e.g. "remember that we are choosing to focus on consistency over availability for this system with low read latency").
As this is essentially a study book, structuring the book like this (starting at the basics and then referencing back to these fundamentals) would have ensured that the content remains in long-term memory as the material would be constantly reinforced. Instead, each paragraph feels mostly stand-alone without much relation to what was previously covered in the chapter or previous chapters.
This is a useful book to read, but only after you have good knowledge of the main concepts in the field.
Content is quite ok, but it 90% overlaps with "Grokking the system design interview" (also, course has some more exercises, and, in my opinion, is much better structured). So if you're trying to decide between the two - I'd definitely opt for the course. Anyways, the examples themselves are quite good, well-explained, decisions are motivated etc, and author touches all the topics, that interviewer will probably be interested in - figuring out requirements, some back-of-the-envelope calculations to estimate scale of the system, db structure, "birds-eye view" of overall design, and deep dives into most interesting parts of the systems.
کتاب بسیار سر راست و خوبی برای سیستم دیزاین هست. من برداشتم این بود خیلی از نکاتشو میدونم ولی بازم خیلی چیزای خوبی یاد گرفتم
عیب مهمش اینه که خیلی عمیق نیست ولی واقعا مصاحبه سیستم دیزاین هم خیلی عمیق نیست
از طرفی این کتاب ها تاریخ انقضا دارن و حس میکنم این کتابم چند سال دیگه خیلی کاربردی نباشه. مگر اینکه نویسنده ویرایش کنه نویسنده یه کانال خیلی خوبم داره که خیلی از مفاهیمی که گفته رو بهتر توضیح داده. مثلا بلوم فیلتر یا چیزای دیگه
Solid if superficial overview of various software systems you'd see at big tech companies and how to build them.
I think if you have some experience working with a system or two like those described here, or have read about them in other books, blogs, or papers, this offers a nice quick summary of the highlights that could guide your thinking during a system design interview. If not, then a lot of it is seemingly arbitrary memorization which might mislead you into thinking you understand the concepts at play.
For example, Xu sometimes says things like "use technology X to get property Y" without a good explanation of what property Y means, or why it's really useful for this scenario (or he'll offer an over-simplified justification for it). I totally understand that he wants it to be concise, but it's written more like review notes for a class than something I'd study first-hand.
Also, there are a number of grammatical (and factual) mistakes, but nothing too egregious.
Last time I went up for tech jobs, I know I definitely lost positions because I bombed the system design interview. That won't happen again.
Xu's book provides wonderful examples of how to get through one of these, with examples of the right questions to ask in terms of scale, queries, and reliability, and examples of practical questions, from a simple rate limiter to complex infrastructure Youtube and Google Drive. The 16 examples are clearly explained with increasingly detailed diagrams and extensive notes.
This isn't a deep dive, more of a wave at key ideas like horizontal scaling, stateless web servers, caching, and load balancing. As other reviewers have pointed out, Kleppman's Designing Data Intensive Systems gets at the gritty implementation of these things in a cursed world of fallible hardware and network connections in a much deeper way. But System Design Interview is a worthy companion to Cracking the Coding Interview for flimflamming the asshole standing between you and a salary.
Seeing the reviews both on Amazon and here on GR I expected so much from this one, what a letdown it's turned out to be.
Lazily written with overly simplified offhand claims which (more often than not) don't have anything to back them up, and the gravest sin of all - there's almost no meaningful discussion of the presented solutions. All the complex solutions look more or less the same - the author will present you with a system you need to design, showcase a mock requirements gathering session and then will proceed with explaining his design while leaving out the most important bit, in my book at least - a step-by-step thought process of how he arrived at the design, what alternatives were considered, what their tradeoffs were and why they weren't chosen.
Add to that a pretty stale list of references (probably remnants of the first edition) and what you get is a book that should have been called System Design: An Overview of How FAANG Implemented Their Stuff.
Interesting book. Just read out of curiosity, of course. Not for any other reason. Just some light reading during my time off. A time when I haven't been interviewing. Yep, just was interested is all. And boy did I learn a lot. Hypothetically, if one were to be interviewing (not saying I was), this would be a great intro to the system design component of a technical interview. A good preliminary reference, I think, though you'd probably want to check out more in-depth sources after going through this book--just to really solidify your understanding. I imagine this would be pretty useful if this territory was largely unfamiliar to you. Of course, I don't know what a system design interview looks like because I've never done one. Because I'm not interviewing! So take everything I say with a grain of salt!
I don't know if I've been doing "wrong" interviews my entire life, because I had never faced one with such design problems as shown in the book (and I'm glad I didn't!). I could learn interesting things from the book, but I don't know if it was worth reading it entirely. Its main content is showing examples of products we know (Google, Youtube, Facebook...) and how would we design their systems in a 1h interview. It starts with simpler examples and there are about 15 of them. In the end I was tired of reading it. It is useful to make us think about and discover how some things work but, in general, I think it is a book that is worth quick-reading and then consulting as needed (when you face a similar design problem).
The book is useful for a high level review of systems an engineer might work with or may be asked about in an interview. I applaud the author also for attempting to demystify the system design interview - probably the more important part of any interview loop for senior candidates.
I wish the book had more depth (even considering the material is meant just to cover a 45-60 minute interview session). The level is probably good enough for up to senior candidates, but a bit lacking for staff+ roles. The writing style could be improved as well: the author would have benefited from having other engineers review the content prior to publication.
The book describes a fairly standard set of design interview topics like: horizontal vs vertical scaling, "back of the envelope" estimation, SQL vs NoSQL choice, etc. Some chapters are detailed while others are rather sloppy and remind personal notes with diagrams. Nevertheless, I quite liked the book overall. It's easy to read and explains some important concepts (e.g. consistent hashing) really well. Additional links to papers with architectures are useful as well.
Although the book is primarily for people who need to prepare for system design interviews, it is 100% recommended for everyone interested in designing software systems. You can't read the book without prior knowledge of the fundamental topics and general experience as it does not teach any specific topic in-depth, rather it discusses typical showcases, like designing a scalable notifications system, a rate limiter, YouTube, and others. Plus, every chapter is followed by a list of research documents and blog articles for a deeper understanding of the topics. Again, absolutely worth reading!
Maybe my expectations for the book were too high or maybe it is the fact that I don't have experience with System Design interviews but overall I didn't like it.
Most of the chapters felt too shallow, even the deep dive sections. I liked some of the them but for most of them, you have to follow the reference links at the end of every chapter in order to gain some understanding.
One of the nicer books that I have read about System Design. The introductory chapters are lucid and gradually introduce the reader to the concepts without throwing in a lot of jargon. The author takes a consistent framework based approach which is really easy to follow and can be practically applied to most interviews. However, there are a few shortcomings - for example - a lot is left to the reader to be learnt via reference materials(present towards the end of each chapter), but, I can understand the reason of that, as a balance needs to be observed between the content and the length of the book, however, just as a thought, a hybrid approach could have been taken with first few chapters dealing will less of reference material than the later ones. But, despite the shortcomings, the book can very well act(recommended) as an introductory level book for System Design with the deep dive later on left to the interested reader.
Хорошая книга, показывающая общий план разработки достаточно крупных продуктов(сосредоточенная, правда, почти исключительно на вебсервисах). Иногда даются и конкретные алгоритмы, как при описании rate limiter, генератора айдишников или бэкенда для автокомплита. Если вы ��сю жизнь чинили баги в чем-то крупном, а проектировали изредка и какие-то мелочи, книга будет вам полезна как минимум для выработки привычки "не цепенеть". Лично для меня, в силу максимальной нацеленности на практику без ручной имплементации алгоритмов консенсуса, "Интервью" оказалась даже полезнее, чем легендарная книга с кабанчиком
There is a specific kind of literature for negligent schoolchildren - a collection of ready-made homework for literature lessons. You just need to copy the text from this booklet, change some words, and voila, your homework is ready without using your brains.
The second part of the System Design Interview (starting from part 9) reminded me these booklets.
This is a type of book I hadn't seen up to this point - it's a collection of system design prompts with implementations. Basically, exactly what you would be expected to do in an interview setting. This book on it's own will probably teach you a techniques on how to handle questions during an interview setting, but this won't actually teach you to design systems. That being said, interviews are their own realm and you need to be good at them - which is what this book aims for.
I would recommend pairing this book with other resources - namely Klepmann's Designing Data-Intensive Applications, his Distributed Systems video lecture series on YouTube, and most of the whitepapers that are listed in the reference section of each chapter in this book. Read up on Dynamo, GFS, ZooKeeper, Cassandra, etc etc - most of the links are in this book so you should be able to find them. The references section are a real gold mine of additional information.
One last point about the particular implementations - don't memorize them and don't try to copy them word for word. Some of them are good, some of the implementations are quite lacking in details and are very hand-wavy. Try to understand the constraints and challenges around each situation and adapt your knowledge of other systems when you are faced with interview questions.
This is a good overview of system thinking, and it provided several new design concepts to me, but at the same time I think some relevant complexities are ignored in favor of discussing less interesting design aspects.
For example, coordination between multiple databases is much easier said than done. When B depends on A, and something in A is deleted, how do you safely cascade that delete into B? Similarly, sharding is kind of touched on, but not nearly as much as I know that it'll be discussed in an interview. I'm also not a huge fan of the amount of caches put into the designs, but that's more of an arbitrary tradeoff decision.
This is not a beginner’s book for system design. The descriptions and introductions to system design concepts are short and kept rough, sometimes to a single sentence. The author does a good job at presenting different systems, but also the explanations of those leave big gaps that I had to fill by reading other designs, watching videos, reading engineering blogs, etc.
So I can recommend reading the book once you have some foundation of distributed systems and the components, and then you can practice those specific designed that are presented in the book.
One thing I missed are systems based on batching rather than real-time, like for HPC applications.