Fix the thing that is actually breaking at 100 users, then 1k, then 10k — in the order real teams hit them, instead of over-building.
Your app works. Ten people use it. Then a launch post lands, traffic multiplies overnight, and something you never thought about — a connection pool, a missing index, a session held in memory — takes the whole thing down at the worst possible moment. Most scaling advice doesn't help here, because it describes the architecture of a company you aren't yet. This course walks the timeline instead. Day 0 is one VM with TLS, backups and migrations. At 100 users you add logs, metrics and three alerts, so the next failure is visible. At 1,000 the database cracks first, and you learn query plans, indexes, N+1 and connection pooling. At 10,000 you scale reads with caching, replicas and a CDN, then push slow work into queues. After that: statelessness and horizontal scale, replicas and sharding, capacity math and cost per request, deploys that can't take users down, and running your first real incident through to a blameless post-mortem. Code tabs in Go, Python, Node and Rust where code matters. Every task is one concrete move, in the order you'd actually make it.
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 database buckles first, and it does so predictably — read a query plan, add the right index, and kill the N+1 before users notice.
Reads are most of your traffic. Cache them, serve them from replicas and a CDN, and take pressure off the database without a rewrite.
Anything slower than a few hundred milliseconds doesn't belong in a request. Move it to a worker without losing or double-running the job.
One box is a single point of failure. Push state out to Redis, S3 and the DB so you can add or kill instances mid-traffic unnoticed.
Vertical first, pooler next, replicas after — and partition long before you shard, because the shard key you pick is hard to take back.
Do the capacity math before traffic arrives: what you can serve, what each request costs, and which alerts are worth waking someone for.
Ship several times a day with no user-visible 5xx: rolling deploys, feature flags, kill switches, and a rollback you have actually drilled.
At 100k users something will break badly. Have an incident process, a blameless post-mortem habit, and comms ready before that day.
Complete all modules, then submit the required number of capstone projects. Each must earn a passing rating from an admin reviewer.
Pick a toy CRUD app (build a tiny one if you have to). Write a 'launch to 100k DAU' plan: starting stack, projected milestones at 100/1k/10k/100k users, capacity math at each stage, the three things you'd add first, the three things you'd do *wrong* on the first try and how you'd recognize the mistake, and the SLOs you'd defend. The plan is the artifact; the app is the prop.
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 taking a "Scaling to 100k Users" course that's organized by user-count milestone (Day 0 → 100 → 1k → 10k → 100k) rather than by primitive. It covers: single-server stacks, observability, DB performance, caching and CDN, queues, horizontal scale and statelessness, the database at scale, capacity/cost/SLOs, deploys and blast-radius control, and incidents/post-mortems. Here's my context: 1. My current product/project is: [describe] 2. Current user/traffic state: [e.g. pre-launch / 50 DAU / 5k DAU / etc.] 3. My current stack: [language, DB, hosting] 4. Where I think the next bottleneck is: [my guess] Given that, answer these specifically: - Which module of this course should I prioritize, and why? - Name 3 concrete things in my current state that would benefit most from this course. - Name 1 thing the course will NOT help me with so I don't have wrong expectations. - If I only have 2 hours this week, which single skill from the syllabus gives me the biggest payoff, and how would I measure that it worked?
Pick a real (or fictional) service. Write a complete on-call package: SLO doc, top-5 alert rules each with annotations and runbook, an incident response template (declare/IC/comms/post-mortem), a kill-switch registry with at least 4 entries, and a quarterly chaos-drill schedule. Submit the pack — this is the artifact a new SRE would inherit.
Take a real (or scaffolded) app under realistic load. Find and fix three perf bottlenecks: one DB-level (index, N+1, query rewrite), one app-level (caching, projection, async), one infra-level (CDN, gzip, HTTP/2, keepalive). Submit before/after p99 latency, throughput, and cost-per-request — with the EXPLAIN plans and profiling output to back each up.
Take a single-box (or sticky) app to 3+ instances behind a load balancer. Move every piece of state — sessions, uploads, locks, in-memory caches — out to shared infrastructure. Verify by killing instances mid-traffic with zero user-visible errors. Submit the diff, the LB config, the /readyz semantics, and chaos-test evidence.
Take a deploy process that currently risks user-visible 5xx. Add: rolling deploys with /readyz semantics + drain handler, feature flags (with kill switches), a smoke-test gate in CI, a quarterly rollback drill, and a documented blue-green or canary plan for a specific class of risky changes. Submit before/after deploy timeline, evidence of zero-5xx deploys over the next 10 deploys, and the rollback drill record.
Modules 8 and 10 pull directly from this. The chapters on monitoring, alerting on SLOs, and postmortem culture are required reading.
Stability patterns (circuit breakers, bulkheads, timeouts), capacity, deployment — the practitioner's companion to this course.