Top Ideas in This Book
Start by ensuring you understand the problem and expectations that the interviewer has for the system. Nothing is worse than making undocumented assumptions.
You’ll be tempted to start diving into the details. Don’t do that.
Get buy-in on a high level design, then explore more details. By aligning on a high-level design you demonstrate your ability to manage stakeholders and shine light on assumptions.
The best way to use a high-level design is by walking through critical user flows. For instance, if you were designing YouTube, a critical user flow would be uploading video. Another would be serving video.
Break down your high level design into smaller components. Focus on diagramming the flow of data through the system.
It’s okay to just mention and diagram the type of technology, not specific implementation details. For instance, you don’t need to say which specific key/value store you would use. That would probably be too granular for this interview.
I’ve made this mistake before – spending too much time on data modeling and relationships. That’s what I thought system design was.
But system design is more about the components that come together to deliver a holistic solution to a technical problem. The reach goes beyond data modeling.
Candidates would be served well to have their phone handy for calculations.
When making rough calculations, rather than averages try to focus on peaks: peak queries per second, peak users per minute, etc.
Some components like a CDN are super complex and you’d never build yourself. You can usually just draw a bubble around them and keep the implementation details out.
By suggesting multiple approaches, you demonstrate creative thinking skills and a stronger understanding of the tradeoffs between areas like simplicity/complexity and performance.
For many engineers, diagramming may not feel comfortable. Our jobs don’t always require it of us. But in a system design interview diagramming is a primary means of communication and you should practice diagramming systems that you haven’t previously built.
One common tactical mistake is to diagram things so small that you don’t allow for new components to be added that would increase scalability, like caches and queues.
How strongly do I recommend System Design Interview?
7 / 10
System Design Interview details how to design 16 real-world systems. I was amazed at how many of the systems covered in this book that my Engineering team at TrainHeroic has built and continuously scaled:
In other words, while interviewing is the obvious application of this book there are actually three use cases: