Menu

Subscribe

System Design Interview Book Review: Finally, a Book for Getting Better at Architecting Systems

I've come across the book System Design Interview: an Insider's Guide by accident (paperback book, and online course). I was looking for good book resources after several people have been asking me how they can get better at building distributed systems or learning designing systems at scale. Especially when they don't have the opportunity to do so as part of their day-to-day work.

The topic is somewhat a chicken-and-egg one. You'll know how to design a large system after you designed one before. But if you've not done so: how would you build an URL shortener like bit.ly, with hundreds of millions of links? A chat app like Whatsapp? A file storage system like Dropbox or Google Drive?

There are many resources online - the most well-known one being System Design Primer on GitHub or reading High Scalability articles. In my case, I was looking for a more "structured" approach, as opposed to just dumping a bunch of concepts you need to know in these interviews.

This book is the most "real-world" systems design book I've come across that does a solid effort to teach concepts, step by step, to people who have yet to work at systems at scale. And it's also a welcome refresher to those who are familiar with some of these systems but would like to venture into various other types of large systems. It is clear from the start that the book was written by someone familiar with systems at scale. The author is Alex Xu, a software engineer previously at Oracle, Zynga, and Twitter.

The book comes with more than 10 case studies and a framework that it introduces and consistently uses with these case studies. There's also an accompanying online course that has the same content as the book, but you can follow along in a web browser, and the diagrams are colored.

Still, don't forget that this is just a book. Books can help with understanding the theory but are not a replacement actually working on large-scale production systems. These systems are always more complex than any book describes them.

Note that none of the below links are affiliate links or sponsored. See my ethics statement on the lack of such links.

Update on March of 2022: System Design Interview: Volume 2 is out, and I can recommend that book just as much as the first part, which I am reviewing here.

A framework for the systems design interview

System design interviews can feel intimidating, and having a framework on how to navigate them can help you feel more in control. The book recommends a 4-step process that I also agree with:

  1. Understand the problem and establish the design scope. I like to phrase this as confirming the problem, asking questions, and making constraints clear. "In a systems design interview, giving out an answer quickly does not give you you bonus points." - the book suggests. They are right.
  2. Propose high-level design and get buy-in. I see people all too often jump into implementing without confirming their approach satisfies the constraints, and they're not over-engineering. The interviewers expect a conversation - similar to real-life design - and this step helps you achieve exactly that.
  3. Design deep-dive. Once you know you're on the right track, it's time to roll up your sleeves and get into the details. This is the part you'll need to have the understanding and vocabulary of the systems domain. The book will help understand several of the concepts you'll need. Resources like System Design Primer also help with this phase.
  4. Wrap-up. With a design that seems sensible, you might close with identifying the bottlenecks and improvement areas.

The book lays out time allocation suggestions for an hour-long interview: a few minutes for understanding, 10-15 for the high-level design, 10-25 for the deepdive, and a few more for the wrap-up. I wouldn't be overly prescriptive, but I would suggest to not start the deepdive the first 10 minutes (gather enough context), and leave time for the wrap-up.

Case studies

I've done dozens of systems design interviews as an interviewer. Back when I was interviewing at the likes of Facebook and Uber, I also got feedback on how good (or not great) my approach was.

One thing you should avoid is "just memorizing" the approaches of the problems. That's far from the point. I made this mistake when I interviewed at Facebook, and was asked to build a part of Instagram. I had done this exercise, and so I just drew out a complicated system. I never talked about constraints or tradeoffs with my interviewer. In fact, I never had a two-way conversation.

A systems design interview is as much about communication with the interviewer as it is about your systems and architecture knowledge. This is why, while the book will help fill gaps you might have on how large systems are built, it won't substitute you collaborating with someone in designing a system.

The book's case studies work well as they go deeper and deeper into the problem domain, forcing you to understand relevant concepts at each step. Take the rate limiter problem and how it's tackled:

  1. Client-side vs server-side rate limiting, and their tradeoffs.
  2. Rate limiting algorithms: token bucket, leaking bucket, fixed window, sliding window log & counter.
  3. Deepdive: rate limiting rules. A look at Lyft's rate limiting component.
  4. Rate limiters in distributed environments, supporting multiple servers and/or concurrent threads.
  5. Performance optimization & monitoring. Most of this falls into productiozation, and operating a real-world system.
  6. References for further reading, linking to industry sources like the how Cloudfare built their rate limiter or understanding the AWS API rate limiting settings.

A pro for the book is how the case studies in the book cover good ground, and a variety of problems:

  • "Basics": rate limiter, consistent hashing, key-value-store, zero to millions of users.
  • Web: URL shortener, web crawler.
  • Social: newsfeed, notification system, chat
  • Videos & storage: design YouTube, design Google riveConclusion
  • Misc: unique ID generator in distributed systems, search autocomplete

My take

This book is a solid recommend from me: and not just for preparing for the systems design interview, but to strengthen your systems design muscle for the day-to-day. The book/course comes with typical design problems and brings a pretty good, step-by-step approach to them. But if you just read through them, you'll miss out on the real value of such a resource.

Diagrams are key for systems design and they are surprisingly pleasant to read in the book. There are more than 150 of them in the 300 pages.

Aim to draw out how you would design the system before reading how the author tackled the problem. You'll go through the book slower: but the concepts will stick. And you'll have approaches to use not just on the interview but when debating with colleagues on how to build a system.

There were a few topics that I missed from the book and that I would have covered. Though the book does a good job in going deep in fundamental concepts like rate limiting, consistent hashing, and sharding, or exploring the scene behind key-value stores, I wish things like caching and replication strategies would have been explored more. Both these topics are relevant in many scenarios.

While the book presents decent solutions to each of problems, I missed having alternative solutions with tradeoffs. In several cases, you can tradeoff the number of machines (and thus cost) for latency, resilience for disasters for cost or latency, and so on. These concepts are easier to grasp with examples. While the book goes deeper in this space that what I have otherwise seen, there is room for more depth.

Additionally, the book focuses on backend systems design. Client-side systems design problems for native mobile engineers or web engineers are usually different - I've helped design both these types of interviews. In all fairness, covering those approaches is likely out of scope for this book. Still, for non-backend engineers, the book can be helpful but potentially less applicable.

Fun facts about the book: from the author himself

After reading the book, I reached out to the author, Alex, congratulating him for a solid resource. As I'm also writing a book, we started talking about how he approached writing and what he's learned from this experience. Here area few fun facts, straight from the author:

  • Alex started to write the book when he was preparing for systems design interviews and could not find good resources to do so. His friends quickly became interested, and he ended up releasing the first version as a course and on Amazon.
  • The first version of the book came with lots of reader feedback. While the book has a good number of readers, many of them complained about diagrams not being clear and not being enough case studies. Alex decided to act on all the feedback and redid most of the book for the second version.
  • The second version of the book took a year to write. Alex progressed roughly one chapter per month. He shared how coming up with "easy to understand" diagrams were time-consuming, as was finding the balance of progressing with "good enough" speed for the reader to follow.
  • The book, over time, broke into the 100 Computers&Technology books on Amazon. At the time of my writing, it ranked as #89 in this category. Alex shared how this was an organic process. The book and accompanying course are now both popular enough for him to consider spending even more time on them.

Further systems design resources

Apart from this book, there are other good resources to learn about how real-world systems are built.

Other paid courses:

  • Systems Design Interview Course - from the author of this book, Alex Xu. Probably the most thorough resource.
  • Grokking the systems design interview by educative.io ($66/year). A similar number of case studies, but fewer diagrams, and the diagrams are not as neat, judging from the example material as I've found in the book. I have heard many people recommend this course in the past, though.
  • SystemsExpert by AlgoExpert ($79/year) 10 systems interview walkthroughs. Based on this video review, these are video walkthroughs. If you learn better with video, this might work well for you. I'd still recommend to pause and "draw ahead" to solidify the learnings.

Note that all of the above courses are a time-based subscription, meaning you lose access to them after a year. Another reason why getting a book might be a good investment: pay once; keep it forever.

Featured Pragmatic Engineer Jobs

  1. Senior Backend Engineer - C#/.NET at Straddle. £90-125K + founding team equity. Remote (UK).
  2. Senior Solutions Engineer at Tint. $130-195K. Remote (US).
  3. Product Engineer at Causal. Remote (US, UK). The team tackles interesting challenges like simplifying React state management.
  4. Backend Engineer - Data at Causal. Remote (US, UK).
  5. Senior Backend Engineer at Polarsteps. Amsterdam (Netherlands).
  6. Senior Data Engineer at GetHarley. £70-100K. Remote (UK) or Hybrid.
  7. Senior Frontend Engineer at GetHarley. £70-100K. Remote (UK) or Hybrid.
  8. Senior Software Engineer at Tint. $140-195K. Remote (US).
  9. Senior Product Engineer, Frontend at Attio. £90-125K + equity. Remote (Europe).
  10. Senior Data Engineer (RoR) at Terminal49. $140-200K. Berkeley, California.
  11. Engineering Manager - Security Product team at CAST AI. Remote (Lithuania).
  12. Software Engineer at Freshpaint. $130-210K + equity. Remote (US).

The above jobs score at least 10/12 on The Pragmatic Engineer Test. Browse more senior engineer and engineering leadership roles with great engineering cultures, or add your own on The Pragmatic Engineer Job board and apply to join The Pragmatic Engineer Talent Collective.

Want to get interesting opportunities from vetted tech companies? Sign up to The Pragmatic Engineer Talent Collective and get sent great opportunities - similar to the ones below without any obligation. You can be public or anonymous, and I’ll be curating the list of companies and people.

Are you hiring senior+ engineers or engineering managers? Apply to join The Pragmatic Engineer Talent Collective to contact world-class senior and above engineers and engineering managers/directors. Get vetted drops twice a month, from software engineers - full-stack, backend, mobile, frontend, data, ML - and managers currently working at Big Tech, high-growth startups, and places with strong engineering cultures. Apply here.