Know which scaling primitive actually fixes your bottleneck, and which one just adds machinery you’ll get paged about at 3am.
Your service is fine until it isn’t. Traffic triples, p99 goes from 40ms to four seconds, the database pins at 100% CPU, and every suggestion in the room — add Kafka, split into microservices, move to Kubernetes — costs a quarter of your roadmap and may not touch the actual bottleneck. This course is about telling the difference. You start with one small HTTP server in Go, Python, Rust, or Node, measure it honestly with wrk or oha, and find where it falls over. Then you add a layer at a time and re-measure: token buckets and sliding windows, an L7 load balancer you write yourself, LRU and Redis caches with stampede protection, a durable job queue with retries and a dead-letter path, replicas and partitions, service discovery, RED metrics and traces, circuit breakers and bulkheads. Every module ends with a project you can run and a number you can defend. By the capstone you take that same server to 10,000 requests per second on a laptop and explain why every piece of it is there.
Built by Lakshya Kumar
We grant free access case-by-case — students, career-switchers, builders on a tight budget. Sign in to send us a note.
Sign in to applyFinished the tasks? Take the prompt to your AI and get tested on it. We copy the prompt and open the app — just paste it in.
The three algorithms every production API uses, plus when each wins.
Write your own L7 balancer so you know exactly what nginx, HAProxy, and Envoy are doing on your behalf.
Every cache buys you speed until it serves the wrong answer; learn to keep the speed without the outage.
Move the slow half of every request off the critical path, with retries and idempotency that actually hold.
Your database breaks first — learn which of replicas, partitions, or shards buys the most room for the least pain.
Make your service stateless, then add instances until the only limit left is your budget.
Metrics, traces, and error budgets that let you diagnose an incident from the dashboard instead of guessing.
Contain a dying dependency so one bad downstream doesn’t take the whole service down with it.
Stack every layer onto the Module 1 server, load-test it for five minutes, and defend each decision with a number.
Complete all modules, then submit the required number of capstone projects. Each must earn a passing rating from an admin reviewer.
Take the Module 1 server and add: rate limiting, caching, a metrics endpoint, and structured logging. Load-test it at 10k rps on your laptop. Submit the code, a dashboard screenshot (or text table) of key metrics, and a writeup explaining every scaling decision.
Choose a real (or representative) database approaching scale limits. Write a sharding design doc: shard key analysis, rebalancing plan, cross-shard query handling, migration plan with zero-downtime, and a rollback strategy. Include capacity math for projected 10x growth.
Overlaps with this course's distributed-leaning chapters. The single most-returned-to book on most backend teams.
Good for naming and comparing primitives. Pair with the load balancer and cache modules.
Paste this into any AI chat. Fill in the bracketed parts with your context — you'll get back a straight answer on whether this belongs on your plate.
I'm considering a "Scalable Systems" course. It starts from a working web server and adds, one module at a time: rate limiting, caching, load balancing, queueing, observability, database scaling, sharding, replication, degradation, and back-of-the-envelope capacity planning. Demos are in Go/Python/Rust/Node. Capstone: scale one service to 10k rps on a laptop. Context: 1. Where I sit today: [e.g. "mid-level backend at 100-person startup", "solo dev shipping SaaS", "preparing for FAANG system-design interviews", "CTO of 5-person team"] 2. My actual scale today: [e.g. "100 users", "5 rps peak", "100k DAU but Postgres is on fire"] 3. My concrete pain right now: [describe it, or say "nothing yet, I just want to be ready"] Tell me straight: - Will this course solve my actual pain, or am I reaching for architecture when the fix is a missing index / better query / smaller instance? Diagnose from the context. - If I only need to take 3 modules out of 10, which 3 match my situation and why? - What's a concrete anti-pattern I might be tempted to apply (microservices, Kafka, K8s) that would hurt a team at my scale? - How would I know, in 3 months, that the course actually paid off — what measurable change should I see in my system or my decisions?
Take a single-instance service and horizontally scale it to 10 instances behind a load balancer. Include session affinity removal, distributed config, idempotent writes, and a load test showing linear throughput scaling. Document the limits where additional scale stops helping.
Implement circuit breaker (Hystrix-style) and bulkhead isolation across a service that depends on 3 downstream services. Demonstrate behavior when one downstream goes down: requests to it fail fast, but requests to healthy ones still succeed. Include a chaos test.
Design an active-active deployment across 2 regions: data-replication strategy (conflict resolution, consistency model), latency-based routing, regional failover playbook, and a tested DR drill. Produce the design doc and prototype the routing + replication.
Free online. The networking chapters explain why scaling-at-the-edge works the way it does.