In Microservices architecture, you decompose your services in a set of fine-grained services. These services are full-stack software, from front end API down to database layer.
Each microservice is responsible and owns its data.
For instance if you have a MovieInventory service and a CheckIn/Checkout services, they must communicate each other via API.
To search on movie titles, the CheckIn services cannot do a direct query on the MOVIE_INVENTORY table, but need to ask to a query Api on MovieInventory.
The CheckIn service keep tracks of its movie on a CHECK_STATUS stable.
Benefits:
- MovieInventory team can change the implementation, and even the underlaying storage in any time
- Old version can be left in place during a transition phase (but it can be a costly solution)
Caveats:
- A change which modify an undocumented behavior (like a default ordering) can lead to bad things. Undocumented behavior cannot be easily spot up to a new revision is deployed
- You cannot do easily join between the two domains.
So you cannot easily build a report service doing a huble join between the CHECK_STATUS and MOVIE_INVENTORY.
The “database management system” as the central point of your company, the secret cave when all the known is kept, is slowly dis-integrating in small, fine-grained opaque data slot, at least in the microservice view.
Is worth of it? Comment it below