There are plenty of videos about backend system design interviews and just few of them about mobile one. The same situation is with the articles, one can find a lot of articles and even courses that would help to be prepared to the backend system design interview and there is no articles at all about mobile system design interviews.

1. Grokking The System Design Interview Book
2. Grokking The System Design Interview Free
3. Grokking The System Design Interview Book Amazon
4. Grokking The System Design Interview Ebook

• System design interview questions have become a standard part of the software engineering hiring process. Performance in these interviews reflects upon your ability to work with complex systems and translates into the position and salary the interviewing company offers you.
• Jul 01, 2021 July 1, 2021. With Grokking the System Design Interview Coupon you will get a 40% discount on yearly plans and a 20% monthly discount oneducative.io. System design questions are increasingly becoming an integral part of software engineering interviews. Redeem 40% Discount. For monthly plan you will get an instant 20% discount.

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.

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.

Grokking The System Design Interview Book

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.

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

You can preview free chapters of the online course here and get the book on Amazon here. Apart from this book, here are some other good resources to learn about how real-world systems are built.

• Google's architecture in 2008 on High Scalability. I find it helpful to understand how companies handled scale over a decade ago. Keep in mind, Google was already bigger in 2008 than many companies need to worry about in 2020.
• Youtube architecture in 2008. Building a system similar to YouTube is a common challenge. It's good to understand how YouTube addressed this, early on.
• Scale at Facebook in 2010: how Facebook approached scaling challenges in their earlier days.
• Scaling Twitter in 2009 and in 2013
• The Netflix experimentation platform in 2016
• How these companies approached scale: Flickr, Dropbox, LinkedIn, Uber, Whatsapp, Pinterest.
• Money movements at scale at Uber - this is talking slightly home, as I worked with the system described in this article, and wrote about some of my learnings. Airbnb scaling their payments platform is also a good read.
• System Design Primer on GitHub: the largest collection of all systems related concepts worth knowing.
• High Scalability blog: the place to go for real-world scalability articles and discussions.
• Designing Data Intensive Applications book: this is a must-read book on distributed systems concepts and building blocks. It goes much deeper than this book does (or wants to). It's a more difficult and longer read. My two cents is anyone serious about distributed systems should read this book, which is also on my bookshelf.

Other paid courses:

Grokking The System Design Interview Free

• 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 both the below courses are a time-based subscription, meaning you lose access to them after a year. It's nice to see The Systems Design Interview online course being a lifetime access purchase - a rarity in today's subscriber economy.

One of the most common set of questions I get from people who are looking to interview with top tech companies (FAANG's) are :

'How to crack the software system design interview?'

'What is enough v/s what is not enough information to give?'

'How do I structure my system design round in the limited 45 mins that I get?'

While System design round can be difficult, we all need to understand that neither a system cannot be fully designed in 45 mins nor system design has one approved solution. There can be multiple ways to design the system based on what are the top problems you are trying to solve and What requirements are you going to be targeting while you design the system.

Here's an interesting approach that you can use to go around your system design interview:

1. Start by collecting the requirement and set the tone of the interview by level setting with the interviewer about what are the specific features or the requirements you are trying to address in this interview. (Time < 5 mins)
2. Navigate to some back of the envelope calculations. You may want to calculate the storage and memory requirements of the system considering scaling of the system over the period of 5 or 10 years. You may also want to calculate network bandwidth requirements parameters when required. (Time = 5-7 mins)
3. Design API's of the system with parameters and return type. You may get into the depth of API design depending on the role you are interviewing for. (Time ~ 5 mins)
4. Create ER diagram and select the type of Database you are going to select for solving the problem. You may select SQL, NoSQL or the combination of both depending on the type of problem. Be sure to provide your rationale behind DB selection and create ER diagram. Ask the interviewer how far they want to go. Do they want all the tables defined or they are fine with a few important ones. This is a very important step in the process. (Time = 10 mins)
5. Once you have got a high level idea of how your system will look like, create a high level system design. Create the block diagram placing all the services, Databases, Internal/External communication protocols, Authentication/Authorization mechanism, API's etc and try to provide a high level description while you draw the diagram. This should be interactive so think loud while you are drawing. (Time = 10 mins)
6. You interviewer will guide you to what part of the system they want to understand from you. Read that signal. Idea is to make sure you answer interviewers question and not speak about what you know. If you are not very sure about the answer, instead of digressing, stop there and affirm to the fact that you may need to look it up offline as you are not sure about that. It is ok to say you are not sure about something rather than taking the conversation somewhere else. (Time = N/A)
7. Once you have spoken about the key parts of the system, be sure to include load balancing and caching techniques (LB algorithms, Caching algorithms, Cache evection policy etc.). This is extremely important as you cannot design a scalable distributed system without LB and Cache. (Time = 5 mins)
8. Navigate to Database Partitioning) next. Partitioning is essential for a large scale distributed systems. Be sure to speak about Partitioning technique and why would you select that? (Time =2 mins)
9. By now you have covered major pieces in your system design. You only have around 5-7 mins left in your interview. To be a bar raiser, it is important to talk about telemetry. be sure to talk about the metrics (KPI's) you would be watching, What would be the response and how would you include the results the data you have collected by analytics to better the system further. Talking about telemetry gives you an edge over other folks as not everyone thinks about analytics. (Time = 5-7 mins)
10. You have exhausted your 45 min in the interview! Congratulations on navigating through it! I wanted to mention a few more things that are essential and you can fit them in your high level system design (Point 5) discussion -

• Data de-duplication.
• Redundancy and Replication (Important based on the type of problem you are solving)
• System should not have single point of failure.
• Scaling
• Trade-off's you have made and why?

With the above approach, solving the system design problem becomes manageable and you are more likely to succeed.

Resources: For your prep, I would recommend the following guides/resources that would be helpful.

1. Design Data-Intensive Application - Martin Kelppmann
2. Grokking the System Design Interview/ Grokking the Advanced system design Interview - Eductaive.io
3. System Design primer - Donne Martin (Available on GitHub)

Grokking The System Design Interview Book Amazon

Please like and share if this article provides any value and you learn some new information from it.

Grokking The System Design Interview Ebook

Disclaimer: Content in this article is provided only for information purposes. This content should be used as a reference and not an actual approved guide to crack an interview. All views provided in this article are my own and has nothing to do with any employer or entity I am affiliated with. I do not endorse any of the recommended resources above.