New

I spent a few years working at a company where all our microservices backed into MongoDB instances. We were constantly under top-down pressure to deliver fast, and because MongoDB is schemaless, it felt very easy to just add fields to our documents whenever we needed to expose data to another service. We eventually arrived at what we thought was a genius optimization. We wrote a background script to propagate changes from Collection A in one service to another service database. That way, the second service would not need any code modification to see the data it needed.

Every time I remember that I still feel bad for not pushing back. We created an unclear interface that coupled our domains together. The second service became dependent on the internal document structure of the first, yet it had no contract to enforce that structure. We chose that path because it was the fastest way to hit our sprint goals. We let the immediate pressure win, and in doing so, we essentially guaranteed that both maintainer teams would be locked in a fragile, entangled dance for the foreseeable future.

I have since learned that sharing domain data across boundaries is a recipe for disaster. It is a classic example of prioritizing speed in the present while ignoring the mounting cost of coupling. The better approach should've been to respect domain boundaries and only connect them using a unique immutable identifier instead of sharing stateful objects or duplicating documents. By passing an ID, you maintain the independence of each service so they are free to evolve at their own pace, as long as they don't break the interfaces.