A 5-step guide to system design
How to tackle a tough system design discussion as an engineer
--
System design conversations can be really challenging. There can be a lot of ambiguity, options, and ideas —mixed with limited time and hard problems to solve. From experience, I’ve found a versatile approach that helps make these conversations more structured, interesting, and productive.
Let’s dive right in!
1. Requirements & Goals
A system design discussion often begins with an open-ended problem to solve. Think, “Let’s design Twitter”.
From the start, everyone needs to stay on the same page. You can make this happen by clarifying the problem and then hashing out an agenda for the discussion.
The first step in this agenda will be talking about requirements and goals, which can essentially be broken down into two pieces: Functional requirements, and non-functional requirements.
Functional requirements
Functional requirements are about the big-picture things like:
- What are we building?
- What are the main use cases (post tweets, follow users, etc.)?
- What are the target platforms (desktop, mobile?).
- What is the engineering team for this like?
Non-functional requirements are about the technical details:
- How should we think about availability, latency, and consistency Example: Perhaps we want the app to be highly available, low latency, consistency can take a hit. CAP theorem (Consistency, Availability, Partition tolerance) becomes a concern when scaling in distributed system.
- We want to do our best to follow the ACID model with databases: Atomicity (all-or-nothing in terms of transactions), Consistency (only valid data written to database), Isolation (multiple transactions at same time don’t interfere with each other), Durability (no data is lost even when nodes fail).
- What is the storage & network capacity? Perhaps we first want to think about key measurements to pay attention to, which could be number of users signed up as well as the number of daily or monthly…
