Architecture as a set of decisions
How can a service architecture be defended with measurements and explicit trade-offs?
Slide contents
1. Architecture as a set of decisions
How can a service architecture be defended with measurements and explicit trade-offs?
2. Architecture starts with a testable requirement
A technology name is not a user outcome.
3. Workload shape selects useful mechanisms
Assess reads, writes and task size separately.
4. Invariants cross component boundaries
Local successes must compose into the contract.
One taskId per key
Accepted tasks preserved
One local result
States remain consistent
5. An accepted response has a precise meaning
The task is durably accepted, not yet completed.
6. The diagram follows the task
Each transition has data and an owner.
7. Choose the read mode per operation
Outcome verification requires sufficient freshness.
8. Two local boundaries are connected by retry
There is no shared transaction with the broker.
9. A lost reply tests the whole design
A retry must return the original task.
10. A late ACK tests the effect boundary
Redelivery reads the committed outcome.
11. Uncertainty needs a resolution path
A timeout does not create a new business action.
12. Dependencies constrain overall availability
Replicating one component does not replicate the others.
13. A failure table connects mechanisms to promises
Each scenario has an allowed mode.
14. A sequential path spends a shared deadline
Intervals of one operation add together.
15. Required branches wait for the slowest
Parallelism changes the latency shape.
16. Worker capacity has explicit assumptions
Estimate a rough bound, then measure.
17. A queue buys time, not capacity
Sustained overload necessarily accumulates work.
18. Average spare capacity cannot save a hot key
The request distribution determines the bottleneck.
19. Reliability consumes resources and complexity
Every extra guarantee has a cost.
20. Move computation toward heavy data
Moving work and moving data have different costs.
21. Authority management is also a dependency
Coordination failure changes serving authority.
22. An alternative must face the same requirements
Compare the change’s effect, not diagram size.
23. A decision record preserves why it was chosen
A reader should reconstruct the argument without its author.
24. Defend the design with evidence, not names
Choose a change and state its guarantee boundary.
Identify the bottleneck
Compare two changes
Request the needed experiment
25. A defense connects promise, mechanism and experiment
Every conclusion has a checkable boundary.
26. Decisions for our service
Connect each requirement to a mechanism and a check.
Calculate an illustrative budget and state its assumptions.
Defend an alternative using measured evidence and limitations.