Skip to main content

External Exercises

Architecture is not learned by solving LeetCode. Real skill comes from reading and writing system designs and ADRs, analyzing real systems, and building module graphs. This page lists the most effective non-course exercises for this module.

How to Use This Page​

  1. Finish the relevant concept pages first.
  2. Pick one exercise per week; time-box strictly.
  3. Produce a written artifact for each (module graph, ADR, critique). Keep them.
  4. After 4-6 exercises, you will have a small architecture portfolio; review it every 3 months and notice patterns in your own mistakes.

Lane 1: Read and Critique Real Architectures​

Goal: build taste by reading professional architecture writing.

Produce: a one-page memo per article naming style(s), key tradeoffs, and one learning.

Lane 2: ADR Writing​

Goal: practice writing architectural decisions that could survive review.

Sources for real-looking prompts:

Produce: three ADRs on style decisions:

  1. "Adopt modular monolith for a new SaaS product"
  2. "Reject microservices for a 10-engineer startup"
  3. "Extract the search capability from the current monolith as a microservice"

Lane 3: Module-Graph Reverse Engineering​

Goal: read the architecture of an unfamiliar codebase.

Pick any popular open-source project. Good candidates:

For each chosen codebase:

  1. Draw the top-level module graph (mermaid or paper).
  2. Identify its style (layered, modular monolith, hybrid).
  3. Find one module that violates its apparent style boundary and write why.
  4. Estimate Ca/Ce for 5 modules by inspection.

Produce: a 2-page architecture write-up per project.

Lane 4: Codecrafters and System Design Practice​

  • Codecrafters -- https://codecrafters.io/. The HTTP server, Redis, Git, and Kafka challenges build genuine understanding of what the "dumb pipes" in microservices actually are. Not exactly architecture practice, but it removes mystery from the substrate.

Lane 5: Interview-Style System Design Prep​

The "system design interview" genre is optimized for microservices thinking. It is useful here because it forces explicit style choices under time pressure.

  • Grokking the System Design Interview -- pick five problems and solve each with two different style choices. Write which you would actually ship and why.
  • ByteByteGo newsletter -- https://bytebytego.com/. Read three diagrams per week; critique the style choice each made.

Produce: a dozen written system-design answers with explicit style justification.

Lane 6: Write Your Own Module Graph​

Goal: the most valuable exercise in this module.

For a system you work on (or any system you know well):

  1. Sketch the current module/service graph.
  2. Compute Ca/Ce for 6-10 modules.
  3. Write the 3 boundary rules you would commit to CI if you could (Concept 6).
  4. Write a one-page "evolution memo": where would you go next and what would trigger the move?

Produce: a complete architecture audit you could present to your team.

Completion Checklist​

  • Wrote at least 3 ADRs (Lane 2)
  • Reverse-engineered at least 2 OSS projects (Lane 3)
  • Critiqued at least 5 real architectures from blogs (Lane 1)
  • Produced one full architecture audit of a system you know (Lane 6)

This is the module whose exercises are least "LeetCode-style" and most "small writing." Budget for it; do not skip it.