Architecture · 7 nodes
Architecture in the real world
Boundaries, transactions and the organisational reasons behind both. Every node here came out of a system that was already running when I arrived.
Is this path right for me?
Nothing is tracked and nothing is locked — the map exists so you can see where an article sits.
-
Where the boundaries are
Learn where the same word is allowed to mean two different things across a codebase, and who has to arbitrate the day those two meanings collide badly.
- Ubiquitous language
- Context maps
-
Transaction boundaries
Find the single line in a codebase that decides what succeeds or fails together, and why it is usually drawn once, early, and never revisited after.
- Unit of work
- Aggregate size
-
Events, and what they promise
Find out what an event actually guarantees once it leaves the service that raised it, and which of those promises the consumer has to absorb itself.
- At-least-once
- What the consumer must tolerate
-
Idempotency keys and safe retries
Give every retry a key, store its result in the same transaction as the effect, and stop worrying whether a lost response means the work happened twice.
- Idempotency keys
- Replay windows
-
When a broker is the wrong answer
See three real systems that reached for a queue to patch a missing transaction boundary, and what broke later because a broker cannot supply one.
- Queues as coupling
- Backpressure
-
Strangler-fig migration
Replace a running production system without stopping it, and see the routing and data-ownership decisions that actually determine whether it survives.
- Routing at the edge
- Data ownership
-
Writing the decision down
Write down the cheapest documentation a team ever produces, in the one format still worth reading a year later when nobody remembers why a call was made.
- Decision records
- Diagrams that survive