The cost of duplicating domain data for performance

I was building a system a few years ago under immense pressure to ship. We had a choice. We could implement a new API call between two domains, or we could duplicate the domain data into multiple service databases. I argued for duplication because I believed the extra network call would compromise our latency goals, and the business demand for speed felt urgent.

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.