The cost of duplicating domain data for performance
A reflective post on architectural trade-offs, discussing why duplicating domain data across service databases for performance is an anti-pattern that creates synchronization debt and breaks modularity, arguing that immutable references between domains are the only stable interface.
I remember thinking at the time that this was the smarter engineering trade-off. We avoided the complexity of a new API interface, and the application responded faster. In reality, I was just ignoring the Rule of the Bolt. Instead of treating the immutable identifier as the only stable joint between modules, I had tied them together through shared, duplicated state.
I left the company months later, so I never had to deal with the inevitable synchronization nightmares that decision caused for the team that remained. I look back on that architectural decision as a failure. I prioritized short-term speed over long-term autonomy.
We should be comfortable with the cost of network calls if the alternative is breaking modularity. The only true interface between two domains should be an immutable reference. Everything else is just debt waiting to accumulate.