Read and challenge a technical architecture
Read an architecture diagram, quantify requirements, understand the big choices and ask the questions that surface risks and trade-offs.
Read an architecture diagram without being an engineer, turn "it needs to be fast" into measurable requirements, understand the major choices (monolith or microservices, synchronous or asynchronous, data, cache, scaling, dependencies, build or buy) and ask the team the questions that bring risks and trade-offs to the surface. You leave with the architecture review of your own product: a diagram, quantified requirements, ten questions asked and their answers, a risk register and a decision recorded in an ADR.
What you will be able to do
- Read an architecture diagram (context and container levels of the C4 model) and spot its components, flows, boundaries and gray areas.
- Turn vague expectations ("fast", "reliable", "scalable") into measurable non-functional requirements, written as quality attribute scenarios.
- Compare monolith, modular monolith and microservices, then synchronous calls and asynchronous processing, based on the team, the load and the consequences for the user.
- Assess data choices (source of truth, transactions, replicas, consistency), scaling and caching, and spot the bottleneck of a user journey.
- Assess dependencies on third-party services (composite availability, degraded mode, vendor lock-in) and a build or buy decision.
- Frame an architecture trade-off, record it in an ADR and treat technical debt as a product decision.
- Run an architecture review of your product or of a proposal, with ten questions, a risk register and explicit trade-offs.
Prerequisites
- Be able to follow a request from the browser to the database and place the frontend, backend, API, cache, queue and third-party services, at the level of the course "Explain how a web product works, from browser to server"
- Have access to an architecture diagram or document for your product, or be able to get one from the team; failing that, the diagram produced in the previous course is enough to start
- No code to write and no paid tool: paper, a whiteboard or a free diagramming tool (draw.io, Excalidraw) is enough.
- Explain how a web product works, from browser to server
Syllabus
What will I be able to read and challenge by the end of this course, and in what order?
- Course overview2 steps
Objective · By the end of this overview, you will know what you will be able to do (read an architecture and challenge it with the team), the deliverable you will produce on your own product and which five modules get you there.
How do you read an architecture diagram and state precisely what the system must guarantee?
Objective · By the end of this lesson, you will be able to read an architecture diagram at the context and container levels of the C4 model, spot users, external systems, containers, flows and trust boundaries, and turn its gray areas into questions for the team.
Objective · By the end of this lesson, you will be able to name the quality attributes that matter for your product, rewrite a vague expectation ("fast", "reliable", "scalable") as a measurable six-part scenario, and choose an honest measure, such as a percentile rather than an average.
Should the system be split up, and when should you wait for a response rather than process later?
Objective · By the end of this lesson, you will be able to tell a monolith, a modular monolith and microservices apart, explain what each style costs and brings (deployment, coupling, operations, team organization), and judge whether a split addresses the problem at hand.
Objective · By the end of this lesson, you will be able to decide, for each step of a journey, whether it should be processed while the user waits or handed to a message queue, to anticipate duplicates, delays and failures, and to specify what the user sees in the meantime.
Where does the data live, what will give way first under load, and what happens when a vendor goes down?
Objective · By the end of this lesson, you will be able to name the source of truth for each piece of data in a feature, explain what a transaction guarantees and what copies cost (read replicas, caches, synchronized data), and specify the acceptable freshness and the behavior when copies differ.
Objective · By the end of this lesson, you will be able to estimate the load of a peak from a few product figures, get the bottleneck of a journey identified before any solution, tell vertical and horizontal scaling apart, and decide with the team whether a cache is relevant and with what freshness.
Objective · By the end of this lesson, you will be able to calculate the availability of a journey that depends on several services, specify a degraded mode for each non-essential dependency, assess vendor lock-in and argue a build or buy decision based on total cost.
How do you choose between two options, keep a record of the decision and deal with technical debt?
Objective · By the end of this lesson, you will be able to frame an architecture trade-off ("we favor X at the expense of Y"), judge whether a decision is reversible and therefore deserves more or less analysis, and write an ADR with context, options, decision, consequences and a review condition.
Objective · By the end of this lesson, you will be able to explain what technical debt and its interest are, classify it with Martin Fowler's quadrant, express a debt as a cost to the product and decide with the team when and how to pay it back.
How do you ask the team the right questions, without being an engineer, and turn them into risks and decisions?
Objective · By the end of this lesson, you will be able to prepare and run an architecture review with ten open questions, without taking the engineers' place, record the answers in a risk register and turn decisions into explicit trade-offs and ADRs.
- Exit kit and action plan4 steps
Objective · By the end of this lesson, you will have the course's templates, checklists and prompts (ten questions, quality scenario, data and dependency tables, risk register, ADR), and you will have planned how to apply them to your product over 7 and 30 days.