System design interviews
Boxes and arrows and a computer, that you didn’t even know existed, which can render your computer unusable.
This interview is mostly about designing high-level components (boxes and arrows) for solving a very general scenario.
The problem will be described with very few details and is up to you to go and capture all the requirements.
Requirements are divided into two:
Functional requirements: What should the system do?
Non-functional requirements: Attributes of the system such as scalability, availability, fault-tolerance, latency, data integrity, security, etc.
The number of things that can be discussed is pretty much endless, so your interviewer will guide you through the areas they consider most important to be discussed.
System design interviews can touch a bit of every topic but dive deep in only a handful. Some people do more emphasis on the type of database used while others care more about designing a clean API.
Distributed systems
A distributed system is one in which the failure of a computer you didn’t even know existed can render your own computer unusable.
– Leslie Lamport
Here you have a shortlist of (very complex) topics you should read about:
Understanding the CAP theorem and its importance
Consistent hashing and its applications
Consistency levels and their trade-offs
Types of databases and when to use which
Sharding and replication
Load balancing and API gateways
Publish-subscribe pattern
Consensus protocols (no need to go too deep here)
There is no good or bad solution, it all depends on the problem you are trying to solve and the trade-offs you are willing to make. You might prefer availability over consistency when calculating the number of likes on a social media post. There it’s not a big deal if you show incorrect (as in stale) data for a while as long as you show something.
Whereas in systems that handle money we are usually more worried about strong consistency (calculating the right value) at the expense of some downtime.
Avoid naming names
I highly encourage you to avoid naming specific technologies and just stay with the most generic abstraction possible. Instead of saying “I would cache things in Redis”, just say that you would use an in-memory datastore. Use a NoSQL database in place of “I would use MongoDB”.
The moment you put a name out there your interviewers are going to start asking questions about that specific technology and why you’ve made that specific choice. Restrain yourself from mentioning technologies you are not too familiar with. For this kind of situation, I always say something like:
Disclaimer, I’ve never worked with this technology but I read that ${BUZZWORD} is generally used to solve this kind of problem.
– Pablo
You should at least know the very basics of ${BUZZWORD} technology and why people recommend it for solving this problem. Don’t just talk for the sake of talking. In general, we prefer to work with someone who admits when they don’t know something instead of bullshiting their way out of a situation.
Not knowing is fine, dishonesty is not. This interview can bring up a wide variety of topics and no one is expected to be an expert in all of those. It’s more about how you would tackle the unknowns and your thought process for that. Identify single points of failure and bottlenecks. Be mindful of trade-offs and explicitly mention them to your interviewer.
Practice is the best teacher
My way of learning about these topics is to first start by reviewing existing architectures and then go deep into theory as needed. For instance, if you first understand the problem consistent-hashing is trying to solve, then the specifics will make much more sense to you. Don’t read theory for the sake of reading theory. It won’t hurt you but it will also not be the best usage of your time. You need tools to solve problems.
Which kind of problems? Here you have a not so short list I recommend for practicing:
Design a rate limiter
Design a URL shortener (like TinyUrl or Pastebin)
Design a distributed ID generator (like Twitter Snowflake)
Design a web crawler
Design a notification system
Design a ticketing system (like Ticketmaster or BookMyShow)
Design a hotel booking system (like Booking or Airbnb)
Design a news feed system in a social media platform
Design a chat system
Resources
System Design Interview – An insider’s guide is a fantastic source of examples for preparing the SD interview. If you don’t know how to start, please start with this book.
An interviewer from FAANG recommended me the following course Grokking the system design interview. I haven’t used it but I heard amazing things about it.
I also wanted to share a few YouTube channels that I used:
Those channels are more about practical examples and interview preparation but if you want more something theoretical check Martin Kleppman’s channel. He is the author of the famous Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems.
Also some blogposts I liked: