New: Roadmaps ordered paths through our cheat sheets and flashcards, so you always know what to study next.
Explore themSee what's new on GitHubFrom CAP theorem and caching trade-offs to a design you can defend in a live interview.
A 15-step learning path. Follow it in order, or jump to what you need.
For backend engineers and career-changers getting ready for the system design portion of a senior interview, or anyone who wants to reason about scale instead of guessing at it. Plan on about 8 to 12 weeks at a few hours a week, moving from the vocabulary of caching, load balancing, and CAP theorem through databases, messaging, and microservices to a structured interview walkthrough. This path assumes you can already build and ship a backend service (that is Backend Developer's job) and stays off organizational architecture decisions and documentation, which belong to Software Architect; here the focus is trade-offs under scale and defending them out loud. By the end you can pick a caching and database strategy under real constraints, defend a CAP theorem call when someone pushes back on it, and walk an interviewer through a design like a rate limiter or a chat system end to end.
Expected: comfortable building and shipping a backend service already (see Backend Developer). Helpful but not required: time spent running a real database or a message queue in production.
Every interview question from here on drops a term (CAP theorem, consistent hashing, backpressure) assuming you already know it; skim this once and you'll recognize each one by name before you go deep on any single piece.
Before any load balancer or CDN in the next two steps can do its job, a client has to find the right address first: this is where that resolution actually happens, cache TTLs included.
Takes the load balancing algorithms table from step 1 and makes it concrete: once DNS from step 2 hands over an address, this is what decides which of your servers actually answers.
You can explain how a domain name resolves and how a load balancer picks the server that answers it, the exact path an interviewer expects you to draw first. Next up: what happens once that request needs data.
Finish this section to unlock.
+100 XP
Pushes the response even closer to the user than step 3's load balancer can reach, the edge caching layer that turns a slow database hit into a static file nobody waits for.
Moves caching from the edge in step 4 to the layer right in front of your database, where cache-aside, write-through, and invalidation stop being theory and start being the bug you'll debug at 2am.
Once you're caching writes as well as reads, the database underneath them matters: this lays out when a document store beats a relational one, the choice every design in step 7 assumes you already made.
Keeps the database you picked in step 6 alive when a node dies: replication modes, failover, and the read-heavy patterns that let one write survive as many reads as your load balancer sends its way.
This is where CAP theorem stops being a table you skimmed in step 1 and starts being a real constraint: expect to rebuild your intuition here, because every replication choice from step 7 is secretly a consistency trade-off.
You can choose a caching strategy, pick the right database for the job, and explain why consistency and availability can't both win during a network partition, the point where system design stops feeling like memorization (a few due flashcards from chapter 1 keep DNS and load balancing fresh while CAP theorem takes over here). Next up: keeping a dozen services talking to each other without any one of them taking the rest down.
Finish this section to unlock.
+100 XP
Solves a problem replication in step 7 can't: work that shouldn't block a response at all, handed off to a queue instead of forced through the CAP trade-offs you just wrestled with.
Take this if you're heading toward a system built entirely around events: stream processing and event sourcing turn the queue from step 9 into the backbone of the whole architecture, not just an overflow valve.
Zooms out from any single queue or database to the whole service boundary question: once step 9's queues connect your services, this is how you decide where one service ends and the next begins.
Reach for this once your design in step 11 already has a dozen services behind it: a gateway is the one front door that handles routing, auth, and rate limiting so no client has to know any of that sprawl exists.
You can decide when work belongs in a queue instead of a request, where an event stream earns its complexity, and where a service boundary or a gateway should sit in front of a growing set of services. Next up: protecting all of it and walking through the whole design out loud.
Finish this section to unlock.
+100 XP
Turns the gateway-level mention from step 12 into the actual algorithms: token bucket versus sliding window, and the classic design-a-rate-limiter question that shows up in nearly every system design interview.
Generalizes the single rate limiter from step 13 into the full defense: circuit breakers, retries, and bulkheads for every dependency that can fail, not just the one you throttle.
Pulls DNS, caching, databases, messaging, and resilience from every step before this into the one format an interviewer actually grades: a structured walkthrough, under a clock, defending your trade-offs out loud.
You went from a blank whiteboard to a defensible design: caching and database trade-offs, a resilient and rate-limited service layer, and the structured framework to walk an interviewer through any of it under a clock. That's the System Design badge, earned: you can reason about scale like someone who's shipped it and defend every choice when they push back.
Finish this section to unlock.
+100 XP
Finish every required step, at least 70% of them genuinely done (not skipped), to earn this badge and 500 XP.