In a senior role's interview, one question is almost certain: 'Build a URL shortener.' Nobody wants code here - they want the shape of your thinking. Whether you ask about requirements, whether you can divide the parts, and whether you can state the price (tradeoff) of every decision. The good news: almost every idea learned in this course works here.
The shape of any design - four steps
- Make the requirements clear - how many users, more reads or more writes, which features are definitely needed. Asking questions is not weakness, it is professionalism.
- Divide the parts - client, API server, database, cache, queue - which one is responsible for what.
- The data decisions - SQL or NoSQL, where to index, where to cache.
- State the tradeoffs - why this choice, what you gave up instead. There is no perfect answer; a conscious decision is the answer.
Example - a URL shortener
There is little writing, a lot of reading (redirects) - so keeping the reading path fast is the main job. Making a short code: turning a long URL's id into base62 to shorten it. Popular links in Redis cache - most redirects will not touch the database at all. In the database only the pair of code and real URL - since the structure is simple, SQL is enough. See - the cache decision is from week 3, the database one from week 2. System design is not separate magic, it is the arranged application of known ideas.
Think about the other two the same way. Notification system: the sending work in a queue (week 3), separate workers for which medium it goes through, retry on failure. Rate limiter: every user's count in Redis, because if the count is not in a fast place, the limiter itself becomes a burden. Take 20-25 minutes to draw each design - boxes and arrows are enough, no pretty picture needed.
The mistake everyone makes
Starting to draw the moment you hear the question - without asking requirements. Another mistake: drawing only the happy path (when everything runs fine). A good design also has failure in it - what happens if a server falls, what happens if the database slows down.
Today's practice
Draw all three designs on paper - URL shortener, notification system, rate limiter. Under each one, write two tradeoffs in one line each. When the drawing is done, explain any one of them out loud, as if an interviewer is sitting in front of you.
How to say it in an interview
Test yourself: 'In system design I first clarify requirements and ratios (reads vs writes), then divide the parts, take data and cache decisions, and state the tradeoff of every choice. Like in a URL shortener, since reads are higher, I kept a Redis cache on the redirect path and kept the database in simple SQL.'