The systems layer

Roughly eight weeks of looking under the floorboards. In task 6 you ran a server, talked to a database, and deployed over a network you trusted on faith. Now you find out what all of it was actually doing. This is second-year curriculum, paced for someone with a life, and it is what separates engineers from people who know a framework.

Second-year curriculum, not interview cram

Be clear about what this task is. It is not "system design interview prep", which is a task 8 concern and a thin one. This is the material a CS undergraduate meets in second year: how networks move bytes, how databases arrange them on disk, how operating systems share a machine between liars and incompetents. The Teach Yourself CS authors put the stakes plainly: engineers who understand this layer go on to do interesting work; engineers who don't spend careers gluing libraries together and wondering why the glue leaks.

The reason this task sits seventh rather than first is sequencing, not importance. Systems knowledge taught before you have built anything is trivia; the same material after task 6 is a series of answers to questions you personally hold. You have a deployed app now. Every layer below it is a mystery you already care about.

The four paths, in order

Networking first, because it is the stack your project already sits on. You deployed to a URL; now follow a packet from your phone to that server and back. Sockets, TCP's promises, what HTTP rides on. This path pays off fastest because every later layer talks over it.
Databases second: what Postgres was actually doing underneath your app while you treated it as a magic dictionary. Pages, indexes, the write-ahead log, why your query was slow that one time. Run the B-tree simulator and the LSM-tree simulator alongside this path; storage engines make far more sense watched than read about.
Operating systems third: processes, threads, and memory, now that you have context to care. You have run servers that held ports, leaked memory, and spawned processes. The OS path explains every one of those incidents from the kernel's side of the desk.
The first half of system design, once the components feel real. Load balancers, caches, and queues are only meaningful after networking and databases have stopped being words. Stop halfway: the principles and the building blocks belong here; the interview-formatted drills belong in task 8.

Postmortems as bedtime stories

Nothing teaches systems like watching one fall over. The postmortems shelf is this task's reading-for-pleasure track: real incident reports from real outages, annotated. GitHub losing both sides of a split brain, Facebook withdrawing its own BGP routes and locking itself out of the buildings, GitLab deleting the wrong database during the incident about the database.

Read one a week, after the corresponding path when you can manage it: the BGP outages land differently once you have done the networking path, and the database incidents are a different genre entirely once you know what a WAL is. Postmortems are the only place you get senior-engineer pattern recognition, what actually breaks, and how failures cascade, without being on call for a decade.

Picking a direction

Somewhere in these eight weeks, a preference will surface. Some people light up following the packet; some can't stop running the storage-engine simulators; some keep drifting back to how the pieces compose. That pull is information. Backend, frontend, infrastructure, data: by the end of this task you should have a lean, even a tentative one.

When you do, open the roadmap and let the matching track sequence the depth from here: it will order the specialised material better than this plan can, because this plan does not know which branch you picked. The mental model is a tree. This plan is the trunk, and it is nearly done. The branches are yours.

What the competitive world warns about

A caution from an unexpected direction. The competitive-programming community, the people behind the USACO Guide and the CSES problem set, are unusually honest about what their sport optimises: code that is correct, fast, and written quickly, for a program that lives for one submission and is never read again. Maintainability, naming, design for change: explicitly not the game.

Interview prep is competitive programming's gentler cousin and inherits the same bias. Tasks 5 and 8 over-train the correct-fast-quick muscles; this task and task 6 train the rest, the parts of the job that involve code other people read and systems that run longer than 45 minutes. If the grind ever convinces you that engineering is solving puzzles against a clock, this task is the antidote, and the job will agree with the antidote.