Most architecture decisions don’t fail on day one. They fail quietly, for a year or two, while the interest compounds — until a routine feature request takes six weeks instead of six days, and everyone agrees something needs to change.
The shortcuts that don’t show up in a demo
A shared database between two services looks identical to a clean boundary in a demo. So does a synchronous call chain four services deep, or a “temporary” admin script that becomes the only way to fix a stuck record. None of these break anything at launch — they break the rate at which you can safely change things later.
What to check before you ship
- Can this service’s data model change without a coordinated release across teams?
- If this dependency is slow or down, does the caller degrade or does it cascade?
- Is there a documented, versioned contract, or does everyone just read the source?
None of these questions have a universally right answer — a shared database is sometimes the correct call for a small team moving fast. The expensive mistake isn’t taking the shortcut; it’s not knowing you took one.