Software Engineering at Scale

Build a Distributed System

Required. You cannot write architecture decision records for distributed systems without having built one. Implement a distributed system with consensus, fault tolerance, and observable performance — this is the empirical foundation for every architectural opinion that follows.

Master System Design (Senior Level)

Required. Designing 10 production-grade systems peer-reviewed by senior engineers is the core postgraduate SWE credential. The required sequence (build a distributed system first, then design 10 systems) reflects the real-world dependency: architectural judgment comes from having built, not just studied.

Author Architecture Decision Records for Systems You Own

Elective. Author 3 Architecture Decision Records for real systems you own or are actively working on. Each ADR must include the alternatives considered, trade-offs documented, and — critically — consequences you have actually observed, not hypothesised. A principal engineer will ask 'what would make you revisit this decision?' You must answer in terms of your actual system.

Make Your First Open Source Contribution

Elective. Get a PR merged into a public repository with 100+ stars. Navigating a real codebase you didn't write, understanding its conventions and constraints, and shipping code that passes a real maintainer's review — this is the postgraduate SWE equivalent of applied research: your work must meet a standard set by someone else.

Operate as a Staff Engineer

Elective capstone. Operating as a Staff Engineer requires influencing technical decisions without direct authority and shipping work that outlasts your involvement — the same skills this path builds toward. Students who complete this path have the technical foundations; the Staff Engineer outcome adds the organisational and communication dimension.

Master Rust (Beginner to Systems Project)

Elective depth track. Systems-level programming with ownership, lifetimes, and safe concurrency — Rust's type system enforces the same safety guarantees that distributed systems architecture tries to achieve through design. A complement to the distributed systems and architecture steps for students who want maximum systems depth.

The most important book for this path. Covers replication, partitioning, transactions, consensus, and stream processing with the rigour of a distributed systems textbook and the practicality of a senior engineer's experience. Required reading before writing ADRs for distributed systems.

The best available treatment of software design principles at the module and system level. Ousterhout's concept of 'deep modules' and 'strategic vs tactical programming' is the vocabulary for architectural decision records — understanding what makes a good abstraction is what the ADR step is testing.

Free collection of essays by the architects of major open-source systems (nginx, PostgreSQL, Git, Eclipse) explaining the design decisions and trade-offs they made. The most direct available resource for understanding real architectural decision-making at scale.

The standard ADR template collection. Review existing ADRs from real projects (Markdown Any Decision Records format) to understand the structure and depth expected before writing your own. The quality bar for the cs-engineering-architecture-decision step.