Each level teaches one idea. You get a system that is about to fail. Figure out why, change the design, and keep users happy until the run ends. Every level can be beaten, and each one ends with a reference design and an explanation.
Your startup launched. 600 people per second are hitting a single API server.
Servers crash: out of memory, a bad disk, a kernel panic. Not if, but when.
Your API tier scales easily: just add servers. The database does not. It has a fixed connection pool and every read and write goes through it.
Caches make systems look much stronger than they are. A 90% hit ratio means the database only sees 1 in 10 reads.
Your team made the API 'resilient': every failed database call is retried 3 times, immediately.
Half your traffic is writes: orders being placed. Writes are expensive for the database.
Two API servers talk to the database over the network. Networks break in strange ways: packets just stop arriving, and nobody gets an error, only silence.
Writes outgrew one database, so the data is split across four shards by key.
A scheduled job sends notifications every minute by calling your API directly, the same API that serves users.
Final exam. You are on call. Chaos is set to Brutal: several different failures, sometimes overlapping, with misleading log noise.