What do you think?
Rate this book
System Design Interview – An insider's guide
The system design interview is considered to be the most complex and most difficult technical job interview by many. This book provides a step-by-step framework on how to tackle a system design question. It includes many real-world examples to illustrate the systematic approach with detailed steps that you can follow.
What’s inside?
- An insider’s take on what interviewers really look for and why.
- A 4-step framework for solving any system design interview question.
- 15 real system design interview questions with detailed solutions.
- 188 diagrams to visually explain how different systems work.
Table Of Contents
Chapter 1: Scale From Zero To Millions Of Users
Chapter 2: Back-of-the-envelope Estimation
Chapter 3: A Framework For System Design Interviews
Chapter 4: Design A Rate Limiter
Chapter 5: Design Consistent Hashing
Chapter 6: Design A Key-value Store
Chapter 7: Design A Unique Id Generator In Distributed Systems
Chapter 8: Design A Url Shortener
Chapter 9: Design A Web Crawler
Chapter 10: Design A Notification System
Chapter 11: Design A News Feed System
Chapter 12: Design A Chat System
Chapter 13: Design A Search Autocomplete System
Chapter 14: Design Youtube
Chapter 15: Design Google Drive
Chapter 16: The Learning Continues
What’s inside?
- An insider’s take on what interviewers really look for and why.
- A 4-step framework for solving any system design interview question.
- 15 real system design interview questions with detailed solutions.
- 188 diagrams to visually explain how different systems work.
Table Of Contents
Chapter 1: Scale From Zero To Millions Of Users
Chapter 2: Back-of-the-envelope Estimation
Chapter 3: A Framework For System Design Interviews
Chapter 4: Design A Rate Limiter
Chapter 5: Design Consistent Hashing
Chapter 6: Design A Key-value Store
Chapter 7: Design A Unique Id Generator In Distributed Systems
Chapter 8: Design A Url Shortener
Chapter 9: Design A Web Crawler
Chapter 10: Design A Notification System
Chapter 11: Design A News Feed System
Chapter 12: Design A Chat System
Chapter 13: Design A Search Autocomplete System
Chapter 14: Design Youtube
Chapter 15: Design Google Drive
Chapter 16: The Learning Continues
324 pages, Kindle Edition
First published June 10, 2020
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 173 reviews
May 16, 2021
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.
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.
January 17, 2021
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.
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.
October 21, 2022
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.
4.5 stars
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.
4.5 stars
May 24, 2021
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.
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.
January 25, 2021
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.
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.
November 29, 2022
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.
April 23, 2021
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.
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.
December 5, 2022
Had to throw in some light software reading for the comp sci boys at home!!
September 27, 2021
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.
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.
July 25, 2022
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.
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.
December 21, 2022
کتاب بسیار سر راست و خوبی برای سیستم دیزاین هست. من برداشتم این بود خیلی از نکاتشو میدونم ولی بازم خیلی چیزای خوبی یاد گرفتم
عیب مهمش اینه که خیلی عمیق نیست ولی واقعا مصاحبه سیستم دیزاین هم خیلی عمیق نیست
از طرفی این کتاب ها تاریخ انقضا دارن و حس میکنم این کتابم چند سال دیگه خیلی کاربردی نباشه. مگر اینکه نویسنده ویرایش کنه
نویسنده یه کانال خیلی خوبم داره که خیلی از مفاهیمی که گفته رو بهتر توضیح داده. مثلا بلوم فیلتر یا چیزای دیگه
عیب مهمش اینه که خیلی عمیق نیست ولی واقعا مصاحبه سیستم دیزاین هم خیلی عمیق نیست
از طرفی این کتاب ها تاریخ انقضا دارن و حس میکنم این کتابم چند سال دیگه خیلی کاربردی نباشه. مگر اینکه نویسنده ویرایش کنه
نویسنده یه کانال خیلی خوبم داره که خیلی از مفاهیمی که گفته رو بهتر توضیح داده. مثلا بلوم فیلتر یا چیزای دیگه
October 1, 2021
It’s full of typos.
May 15, 2023
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.
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.
November 2, 2021
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.
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.
Read
September 4, 2021Interesting 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!
March 25, 2021
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).
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).
August 29, 2021
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.
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.
June 22, 2021
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.
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.
July 11, 2022
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!
February 1, 2023
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.
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.
October 10, 2021
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.
March 26, 2022
Хорошая книга, показывающая общий план разработки достаточно крупных продуктов(сосредоточенная, правда, почти исключительно на вебсервисах). Иногда даются и конкретные алгоритмы, как при описании rate limiter, генератора айдишников или бэкенда для автокомплита. Если вы всю жизнь чинили баги в чем-то крупном, а проектировали изредка и какие-то мелочи, книга будет вам полезна как минимум для выработки привычки "не цепенеть". Лично для меня, в силу максимальной нацеленности на практику без ручной имплементации алгоритмов консенсуса, "Интервью" оказалась даже полезнее, чем легендарная книга с кабанчиком
February 17, 2022
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.
The second part of the System Design Interview (starting from part 9) reminded me these booklets.
March 19, 2021
A lot better than other resources like educative.io, algoexpert.io etc.
November 2, 2021
Damn that was fun. Totally did not expect how interesting this could be.
January 21, 2023
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.
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.
December 8, 2021
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.
Overall, good, but not amazing.
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.
Overall, good, but not amazing.
February 18, 2023
This books sets up a good foundation for understanding large scale system design. It’s quite broad and doesn’t go into many details, but that’s exactly what I needed. It helped me be a better systems thinker.
May 8, 2023
Good inspiration on designing big-scale distributed systems. It is focused on 1-hour interview conversations... But I think it's a valuable read in all contexts.
I liked it because:
- 1-hour interview mindset is a great way to start brainstorming designs on a high level for topics that may seem intimidating at first
- it features a lot of good resources (blogs, books, etc) that are well worth studying
- it's a good companion to "Designing Data Intensive Applications", in this sense that DDIA is very low level, while this book is very high level and gives you a good sense of where techniques described in DDIA apply
I liked it because:
- 1-hour interview mindset is a great way to start brainstorming designs on a high level for topics that may seem intimidating at first
- it features a lot of good resources (blogs, books, etc) that are well worth studying
- it's a good companion to "Designing Data Intensive Applications", in this sense that DDIA is very low level, while this book is very high level and gives you a good sense of where techniques described in DDIA apply
January 22, 2021
I have an ambivalent feeling about this book. It discusses so many topics, each of which is worth another book and thus is inevitably shallow. It, however, works pretty well as an index of major software architectural issues. No matter how experienced you are, it's not probable that you have worked on all of search engine, messaging, social network, video sharing, and cloud file storage. This book gives you time to think about all of these and contains a good collection of references you can check if you want to delve into each topic.
Displaying 1 - 30 of 173 reviews