Member-only story
Microservices Communication: Data Sharing using Database, an AntiPattern !!!
One of the key advantages of working with Microservices Architectural style is — Independent Deployability, which means — once a feature is complete, the microservice can be deployed independently into the Production environment with no to low risk and without impacting other features of the product.
But we also know that microservices often communicate with each other (to query the data or to send a command) to fulfil some of the business use cases. As a standard practice, a microservice should abstract its implementation details and hide the domain data it owns and should expose standard interfaces for other microservices to communicate with it.
This interface can be in the form of APIs for Synchronous communication or Messages/Events for Asynchronous communication.
But I have also seen cases where a microservice happens to share the data it owns by directly exposing the database for other microservices to consume. And there could be valid justification for it !!!
One of the common reason which I have heard for such kind of data sharing model is — We were nearing the release schedule and there was a last moment request from Team X that they want data owned by Microservice Y to fulfil one of their important use case and they missed to communicate the dependency in advance, and Team Y team didn’t had the capacity to deliver as they had other P0 items to be delivered in the same release. And hence, as a quick workaround, Team Y directly exposed their database for Microservice X to consume. And, at the same time, Team Y also added a backlog ticket in their Technical Debt bucket that this needs to be fixed.
And when asked — So is this work around fixed now? And the answer I generally hear is — We are still waiting for that day to come !!!
If you see the situation here, Team Y did not have the time to implement the APIs for Team X to consume the data and Team X had this important feature to be released maybe because of contractual commitment and hence Team X and Y agreed on this approach. So there is always…
