System Design line, station 4 of 8
Scaling Building Blocks
Learn the building blocks that let an app grow from one server to millions of users: load balancers, caches, object storage and CDNs, queues, rate limits and real-time updates.
- 7lessons
- 4.5 hto read and do
- Intermediatelevel
- 7podcast episodes
- 9checked exercises
- 3simulators
Tools you'll use in this course
The lessons open these with a template ready. They work for your own job too, no course needed.
About this course
One server and one database can carry an app a long way. Then a festival rush, a marketing SMS or a popular new feature arrives, and the app slows down, logs people out or sends the same message three times. This course teaches the building blocks that real systems use to grow past that point: many stateless copies behind a load balancer, caching, object storage and CDNs, background queues, rate limits and real-time updates.
Each lesson explains one block with an everyday picture first, then the mechanism, the numbers that matter and the mistakes teams make in production. You build each piece with NestJS, Redis, Postgres, Nginx and Docker, practise the core logic in auto-checked JavaScript exercises in your browser, and leave with questions you can bring to your own team's design reviews.
Every example happens at Mangrove Market, a fictional grocery chain with 320 stores, a customer app, a Partner app for 1,800 corner shops and 600 delivery riders. The capstone asks you to get Mangrove ready for festival week, when app traffic grows four times.
What you will be able to do
- Make an API stateless and work out how many copies to run for a peak
- Put a load balancer in front of several servers with the right algorithm, health checks and timeouts
- Add a Redis cache with TTLs, safe invalidation and stampede protection, and agree how stale each screen may be
- Move files to object storage with presigned uploads and serve them through a CDN with hashed names
- Move slow work to background queues with idempotent workers, capped retries and a dead-letter queue
- Protect endpoints with rate limits, and deliver live updates with SSE, WebSockets and push notifications
Syllabus
7 stops, about 4.5 h in total. Each stop fills in when you complete the lesson.
Scaling up vs scaling out
When one server is not enough, you can buy a bigger server or run more copies of the same one. This lesson shows when each choice works, and the one rule that makes "more copies" possible: keep your app servers stateless.
Horizontal scalingStateless servicesCapacity planningAutoscaling
Load balancers
A load balancer is the front door that spreads requests across your server copies and stops sending traffic to a copy that is sick. This lesson shows how it picks a server, how it notices failure, and the settings that cause most real outages.
Load balancingHealth checksTimeouts and keep-aliveHigh availability
Caching
A cache keeps a copy of data that is slow to get somewhere that is fast to read. Done well, it cuts latency and database load by ten times or more. Done badly, it shows users wrong prices. This lesson covers both sides.
CachingCache invalidationStampede protectionHTTP caching
Files, object storage and CDNs
Photos, PDFs, exports and app updates do not belong in your database or on your API server's disk. This lesson moves them to object storage, lets phones upload straight to it, and puts a CDN in front so users download from a server near them.
Object storage and CDNsPresigned URLsCDN cachingCache busting
Queues, background jobs and pub/sub
Some work is too slow, too big or too fragile to do while the user waits. A queue lets the API say "got it" in milliseconds and hands the work to background workers. This lesson shows how that works, how jobs fail and retry safely, and how to pick a tool.
Background jobs and queuesIdempotencyRetries and backoffPub/sub
Rate limiting and protecting your system
A rate limiter caps how often each client may call you, so one buggy app, one scraper or one attacker cannot use up the capacity everyone else needs. This lesson explains the main algorithms, where to put limits, and how to build one that works across many servers.
Rate limitingToken bucketDistributed counters in RedisLoad shedding
Real-time updates: polling, WebSockets, SSE and push
An order changes status on the server. How does the screen in a store, or on a partner shop owner's phone, find out? This lesson compares the five ways to get news from a server to an app, and shows how to keep them working across several servers, flaky networks and closed apps.
Real-time deliveryServer-Sent EventsWebSockets at scalePush notifications
Capstone: Get Mangrove ready for festival week
A realistic project with a rubric and a model answer.
Final exam and certificate
10 questions drawn at random, 70% to pass.
Capstone project
Get Mangrove ready for festival week
Mangrove Market expects four times its normal app traffic during the coming festival week: about 240,000 orders a day instead of 60,000, most of them between 6 pm and 10 pm. Today the customer app's API runs as one NestJS process on one VM. Product photos are saved on that VM's disk, the order confirmation SMS is sent inside the checkout request, OTP login has no limit, the catalogue is read straight from Postgres on every tap, and customers refresh the order screen to see whether a rider has picked up. Ken, the engineering manager, asks you for a short design document and a small proof of concept that make the system ready: several stateless copies behind a load balancer, a catalogue cache, photos in object storage behind a CDN, SMS through a queue, rate limits on login, and live order status.
You will hand in
- A 2 to 3 page design document with one diagram of the target setup and the capacity math for the evening peak
- A list of every piece of hidden state in today's API and where each one moves
- A cache plan table: what is cached, where, the TTL, how it is invalidated, and what is never cached
- Working code for at least two pieces, for example the cache-aside helper with a stampede lock, the idempotent SMS worker, or the token bucket, with a short test for each
- A one-page festival runbook: which numbers to watch and the first action when each one goes wrong
Check what you know
Already know some of this? Answer 7 quick questions, one from each lesson, and we will mark the lessons you can skim. It takes about 4 minutes and nothing is graded.
Questions
How long does this course take?
About 4 to 5 hours for the seven lessons, including the practice exercises, plus 2 to 6 hours for the capstone project if you do it. Each lesson also has a podcast episode of about 13 minutes that you can listen to on the go.
What should I know before I start?
You should know roughly what an API, a database and a server are, and be able to read a little JavaScript or TypeScript. The How the Web Works course covers those basics. SQL & Data Modeling helps with the database parts but is not required.
Do I need to install anything?
No. Every practice exercise runs in your browser and checks itself. If you want to follow the Build it sections on your own machine, you need Node.js, Docker and a code editor; the lessons run Postgres, Redis, Nginx and MinIO in Docker containers.
Is the certificate free?
Yes. The lessons, podcasts, exercises, final exam and certificate are all free.
How does the final exam work?
Each attempt draws 15 random questions from this course's question bank, and you need 70% to pass. If you do not pass, you can try again after 24 hours. The questions are new scenarios at Mangrove Market, so understanding the ideas matters more than remembering the lesson text.
Is it really free?
Yes. Every lesson, podcast episode, exercise, quiz, final exam and certificate is free. The labs and their templates for real work are free too. Plus and Premium add every lab challenge, weekly extras and a mentor on top, and they never lock the tools or the courses.