Engineering / architecture
Architecture notes
Good architecture is a record of trade-offs that another person can inspect, change, and operate.
Draw the boundary
I start by naming what must be consistent, what can be eventually consistent, where data is allowed to move, and who is responsible for recovery. Those answers usually narrow the service choices more effectively than a technology list.
- One owner per state transition.
- One source of truth per domain record.
- One explicit reason for every asynchronous boundary.
Complexity earns its keep
A queue, cache, service, or abstraction is worthwhile when it buys a property the system needs. Otherwise it is a second failure mode and a second explanation future operators have to carry.
The architecture diagram should explain the system you have, not the system the tool catalogue made possible.
Change is normal
Documentation should say what is true now, what is assumed, and what would force the design to change. That is more useful than pretending the first diagram is permanent.