The end of the Database Mangement System as we know it

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:

  1. MovieInventory team can change the implementation, and even the underlaying storage in any time
  2. Old version can be left in place during a transition phase (but it can be a costly solution)

Caveats:

  1. 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
  2. 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

 

Leave a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.