Why Learn System Design?

AI can write code faster than any human. So why should you learn to build systems? Because writing code was never the hard part. The hard part is deciding what to build, how the pieces fit together, and what trade-offs you are willing to accept. Those decisions stay with humans.

The shift happening right now

For most of the last fifty years, software engineering meant one thing above all else: translating an idea into code. Typing the loops, the functions, the database queries. That work is being automated, and quickly. A capable AI can generate a working feature in seconds that would have taken a team a full sprint a few years ago.

The people who thrive in this shift are not the ones who type the fastest. They are the ones who can look at a system, understand what it is doing, and make smart decisions about what it should do next.

What AI cannot do well (yet)

Judge trade-offs in context

Every real system is a web of competing constraints: cost versus speed, simplicity versus flexibility, consistency versus availability. AI can list the options, but choosing the right one for your business, your users, and your budget is a human call.

Know what to ask for

AI is brilliant at answering the question you ask. It has no way to tell you that you are asking the wrong question. If you do not understand how load balancers, caches, and databases interact, you will not know what to even request.

Catch subtle failures

An AI can generate code that passes tests and still takes your whole site down at 2 a.m. under real traffic. Reading the output critically, spotting the race condition, the missing index, the cascading failure, requires understanding systems, not just code.

Own the decision

When the outage happens, or the bill triples, or the launch slips, someone has to answer for the choices. That someone is never the AI. The people who understand the system are the ones trusted to make those calls.

Infrastructure is the ultimate decision layer

Writing a function is tactical. Deciding how traffic is routed, where data lives, how failures are contained, how costs scale: that is strategic. Those decisions shape what the code can and cannot do, months or years before a single line is written.

A junior engineer writes a feature. A senior engineer decides the shape of the system the feature lives in. AI can help with the first. The second is still yours.

What you build here transfers everywhere

The System Design Lab is not a toy. The concepts you practice here are the same ones used to run every website, app, and service you use:

Instances and load balancers are how Netflix serves billions of video streams without one machine melting down.
DNS is how the entire internet finds anything.
Managed databases and caching are how Amazon handles Black Friday without losing a single order.
Snapshots and regions are how your bank survives a datacenter fire without you noticing.
Firewalls and ports are the difference between a secure system and one plastered across the news.

Every tech company in the world pays senior engineers very well to make decisions about these exact things. Not to type the code. To choose the shape.

Learning by doing beats learning by watching

You can read ten articles about load balancers and not really understand them. Then you provision one, attach two instances, run a load test, watch the traffic split across them, and it clicks. That moment of intuition is what this lab is built to create.

The goal is not to memorize configurations. The goal is to build intuition: to feel, in your gut, what happens when you add a cache, split a service, or move data closer to a user. Once you have that, you can direct AI to implement whatever you can imagine. Without it, you are just hoping the AI chose well.

What you can build at each tier

The lab has per-plan limits so a free account stays useful while a paid plan unlocks the bigger architectures used in later lessons. Here is the full breakdown.

Limit	Free	Creator	Pro
Compute
Servers (instances)	1	6	20
Sites per server	2	5	15
Site storage (MB each)	2	10	25
Server-attached DBs per server	1	3	5
DB size (MB each)	5	25	50
Managed databases	1	3	5
Networking
Load balancers	1	3	5
LB targets per LB	2	5	10
DNS zones	1	5	10
Storage and backup
Storage volumes	2	5	10
Snapshots	3	10	20
Data API
Records	500	5,000	50,000
Analytics retention (days)	7	30	90
Load testing
Max requests per run	500	1,000	100,000
Max duration (seconds)	30	60	120
Max concurrency	5	10	25
Cooldown between runs (seconds)	120	60	30
History kept per server	5	20	50

Cooldown is the wait time between load test runs. Lower is better. History is how many past runs are kept for that server. TLS certificates, sites, server-attached databases (the cost is rolled into the server), and snapshots are billed individually in the simulated cost widget on the dashboard.

Where this takes you

The skills you build here show up in:

Software engineering interviews, where system design rounds are now standard from new-grad through senior.
Side projects and startups, where the difference between a product that works and one that collapses is almost always infrastructure.
Any technical career, because every role touching software now benefits from someone on the team who understands how it is served.
Working with AI, because the better you understand the system, the better you can prompt, evaluate, and correct the AI building inside it.

The short version

AI is making it easier than ever to generate code. It is also making it more important than ever to understand systems. The person who can see the big picture, make the call, and defend the reasoning will always have a seat at the table.

That is what you are practicing here.