Semester 8: System Design & Technical Leadership
Year 4 -- Production Engineering | Phase 8 | Weeks 76-83 | 8 weeks
Curriculum Readiness: Blueprint
Semester 8 is roadmap-visible as Blueprint in the canonical readiness matrix. Use this system design and leadership material as structure and planning context until content/portal/readiness-matrix.json promotes it to Learner-ready or beyond.
Goal
Use architecture knowledge to design production-grade systems end-to-end and communicate decisions to a mixed audience of engineers, product, and leadership. By the end of the semester you should be able to walk into an unfamiliar design problem, frame it, estimate it, decompose it, stress-test it, and defend it in writing.
Prerequisites
You should enter Semester 8 carrying the outputs of Semester 7 (quality-attribute scenarios, an architecture review packet, working DDD boundaries and ADRs) and the distributed-systems fluency of Semester 6 (replication, partitioning, consistency, failure models). Large-scale design turns every box on your diagram into a small distributed system; if the S6 or S7 material is shaky, remediate before starting -- this semester will not re-teach it.
Phase Completion Contract
- Explain: end-to-end system design tradeoffs, decomposition strategy, reliability/performance constraints, and the communication path for technical decisions.
- Build: large design docs, system case studies, and at least one strategy memo or leadership-oriented artifact.
- Evidence: architecture reviews, scale/failure reasoning, written alternatives, and communication artifacts that a mixed audience could follow.
- Do not advance if: you still cannot defend design choices under scale, failure, or stakeholder-pressure questions.
Modules
| # | Module | Focus |
|---|---|---|
| 1 | System Design Methodology | End-to-end design process: framing, estimation, high-level design, deep dive, stress test, and review-ready communication |
| 2 | Microservices & Service Decomposition | When services pay off, how to draw boundaries, own data, publish contracts, and operate a fleet without drowning in operational tax |
| 3 | Event-Driven Architecture | Events as facts, messaging patterns, log-based brokers, sagas, event sourcing, and CQRS applied to real flows |
| 4 | Scale, Reliability & Performance | Percentile latency, scaling strategies, SLI/SLO/error budgets, queuing-theory intuition, observability, and incident muscles |
| 5 | Technical Leadership & Strategy | Staff+ archetypes, Rumelt-style strategy (diagnosis / guiding policy / coherent action), influence without authority, written-first culture, and growing other engineers |
Core Resources
| Book | Role |
|---|---|
| System Design Interview (Alex Xu et al.) | Primary system design methodology and interview preparation |
| Building Microservices (Sam Newman) | Microservice architecture patterns and distributed system design |
| Software Architecture: The Hard Parts (Ford et al.) | Advanced architectural trade-offs and decision-making |
| Designing Event-Driven Systems (Ben Stopford) | Event-driven architecture and distributed system patterns |
| Staff Engineer (Will Larson) | Technical leadership and engineering strategy |
| The Manager's Path (Camille Fournier) | Engineering management and organizational dynamics |
| The Pragmatic Programmer (Thomas & Hunt) | Software engineering best practices and professional development |
| System Design Primer | Primary resource for system design methodology and interview-style exercises |
Non-Technical Parallel Reading
| Book | Theme |
|---|---|
| High Output Management (Andrew Grove) | Engineering leverage, one-on-ones, and running decision-dense meetings that actually produce output |
| Superforecasting (Philip Tetlock) | Calibrated judgment under uncertainty -- thinking in ranges, updating on evidence, and owning your track record |
Cross-Cutting Tracks Active This Semester
| Track | Level | Focus This Semester |
|---|---|---|
| A: Testing | L4 | Architecture-level test strategy: contract tests between services, synthetic load tests that back capacity claims, and failure-injection drills tied to SLOs |
| B: Git / CI/CD | L4 | Design docs and ADRs live in the repo and are reviewed with the same rigor as code; promotion pipelines treat architectural changes as first-class releases |
| E: Engineering Fundamentals | L4 | Runbook-style writing, troubleshooting thought process, and stronger technical communication under ambiguity |
| C: Security | L4 | Threat modeling at architecture scope: trust boundaries across services, data classification, blast-radius reasoning, and secure defaults baked into new designs |
| D: Observability | L3 | Design systems that are observable by construction -- golden SLIs, structured logs, traces across service hops, and dashboards that tell a cause-and-effect story |
Weekly Arc
| Week | Focus | Modules |
|---|---|---|
| 76 | Framing, estimation, and the four-phase design process | Module 1 (Clusters 1-2) |
| 77 | Deep dive, stress test, and design-doc polish on one kata | Module 1 (Clusters 3-5) |
| 78 | Decomposition criteria, service boundaries, and data ownership | Module 2 (first half) |
| 79 | Contracts, synchronous vs async communication, operating services | Module 2 (second half) |
| 80 | Events as facts, messaging patterns, log-based brokers | Module 3 (first half) |
| 81 | Sagas, event sourcing, and CQRS applied to the project | Module 3 (second half) + M4 opener |
| 82 | Percentiles, SLOs, capacity math, and incident muscles; leadership artifacts | Modules 4-5 |
| 83 | Project polish (design doc, ADRs, strategy memo), cumulative review, exam | Buffer + exam |
Spaced Repetition Schedule
Each week adds one S8 module deck and rotates through the prior-semester decks most relevant to that week's material. The goal is steady retrieval, not new reading.
| Week | New Deck | Review Decks |
|---|---|---|
| 76 | S8 M1 (framing, estimation) | S7 M1 (architecture fundamentals), S6 M5 (distributed fundamentals) |
| 77 | S8 M1 (deep dive, stress test, communication) | S8 M1 earlier cards, S7 M1, S6 M3 (replication & partitioning) |
| 78 | S8 M2 (decomposition criteria, boundaries) | S8 M1, S7 M3 (bounded contexts), S7 M5 (ADRs) |
| 79 | S8 M2 (contracts, communication styles, operating) | S8 M1-M2, S7 M4 (API design & evolution) |
| 80 | S8 M3 (events, messaging patterns, brokers) | S8 M1-M2, S6 M4 (transactions & consistency) |
| 81 | S8 M3 (sagas, event sourcing, CQRS) | S8 M2-M3, S7 M5 (ADRs & reviews), S6 M3 |
| 82 | S8 M4 + S8 M5 | S8 M1-M3 rotation, S6 M5 (distributed), S4/S5 reliability & concurrency cards |
| 83 | Cumulative (no new deck) | All S8 decks + integration prompts from S6 and S7 |
Weekly Learning Journal Schedule
Use the template at _templates/weekly-journal.md every week. Specific reflection prompts for this semester:
- Which design tradeoff was hardest to justify this week, and what would you need to learn to argue the other side convincingly?
- How would you explain this week's architecture decision to a product manager, a security partner, and a junior engineer -- without softening the underlying claim?
- If traffic grew 10x overnight, what would fail first in your current design, and which observability signal would tell you it was about to happen?
Semester Deliverables
- All module quizzes completed
- All code katas completed
- All Feynman notes written
- All spaced repetition decks created
- Semester project completed
- Checkpoint gate passed
- Cumulative review completed
- Semester exam completed
Capstone Throughline
Every semester must leave behind evidence that can survive into the final capstone defense.
- Artifact carried forward: system design review and leadership packet.
- What to preserve: Preserve the design review, facilitation notes, tradeoff memo, risk register, and leadership reflections.
- Module threads: Module 1: System Design Methodology, Module 2: Microservices & Service Decomposition, Module 3: Event-Driven Architecture, Module 4: Scale, Reliability & Performance, and Module 5: Technical Leadership & Strategy.
- Defense prompt: In Semester 10, explain how this semester's artifact changed a capstone decision, reduced a risk, or made the final system easier to defend.