System Design
A model service still has to scale, and the system design interview is where that is tested. The page starts with the reading that teaches the vocabulary, moves to interview walkthroughs and scalability write-ups, then guided practice, and ends with the question notes themselves: the rate limiter and Twitter.
The same notes are in System design.
Two starting points are marked as amazing. System Design in a Hurry is Hello Interview's fast pass through the subject, and System Design and architecture is puncsky's repo for learning how to design large-scale systems and preparing for the system design interview. The figure below comes from that repo.
Once the vocabulary is there, the interview format itself needs explaining. Hired in tech has a System Design section, and Episode 06: Intro to Architecture and Systems Design Interviews is Jackson Gabbard's video introduction to that kind of interview. A System design template gives the answer a fixed shape. For an ML service the design often includes retrieval: RAG SD is Rick Merritt's NVIDIA explainer of retrieval-augmented generation, a technique for making generative AI models more accurate and reliable with facts fetched from external sources.
Jordan's interview series then works single problems end to end, each as a Systems Design Interview Questions With Ex-Google SWE episode by Jordan has no life: Distributed Job Scheduler is episode 20, Distributed Locking is episode 21, and Rate Limiter is episode 7, the same rate limiter question that closes this page.
The broadest single reference is (great) System Design Primer — Learn how to design large-scale systems. Prep for the system design interview. Includes Anki flashcards.
Every design question comes back to scalability, so the next block is about that one word. CS75 (Summer 2012) Lecture 9 Scalability Harvard Web Development David Malan is the lecture, posted by George Schott. a word about is "A Word on Scalability", which points out that "that doesn't scale" is often used as a magic word to end an argument, when it usually means the architecture limits how far the service can grow. scalability for dummies is the archived lecloud series on making a web service massively scalable, and its parts build on each other: 1 is clones, so servers scale horizontally; 2 is the database, for when the application gets slower even after that; 3 is the cache, for when users still wait on a scalable database; and 4 is asynchronism, told through a bakery that bakes the bread at night. Scalability, Availability & Stability Patterns (good for topics) is a slide deck that names the trade-offs, performance vs scalability, latency vs throughput, and availability vs consistency, and then the patterns for each. To pick between designs, Use Back-of-the-envelope-calculations to Choose the Best Design (good) is the High Scalability answer to how you know which is the "best" design for a given problem.
Reading only goes so far, so the last step is practice. System Design Guided Practice — AI-Powered platform provided guided practice on system design problem and behavior questions like the way you do at Leetcode. PracHub System Design Practice — Company-tagged interview prompts for timed, answer-first practice.
System design
After the reading list, these notes are the interview questions themselves: rate limiter and Twitter.
The same notes are in System Design.
The worked solutions come from the primer's section on How to design a system, which pairs each interview question with a solution.
The first question is the one from Jordan's episode 7: how would you design and implement an API rate limiter? The second is The twitter question, the primer's worked solution for designing Twitter, drawn below.
Last updated
Was this helpful?