When you are decomposing your application to adopt microservices architecture, it is important to focus on the monolithic database. You will need to come up with a solid strategy to split your database into multiple small databases aligned with your applications. In short you need to decouple your applications/services from using a single monolith shared database.

You should design your microservices architecture in such a way that each individual microservice has its own separate database with its own domain data. This will allow you to independently deploy and scale your microservices.

Traditional applications have a single shared database and data is often shared between different components. We all have worked with such databases and have found the development to be simpler since the data gets stored in a single store. But there are multiple issues with this database design.

Problems with Monolithic Database Design

1. The traditional design of having a Monolithic Database for multiple services creates a tight coupling and inability to deploy your service changes independently. If there are multiple services accessing the same database, any schema changes would need to be coordinated amongst all the services – which in real world can cause additional work and delay in deploying changes.

2. It is difficult to scale individual services with this design, since you only have the option to scale out the entire monolithic database.

3. Improving application performance becomes a challenge. With a single shared database, over a period of time you end up having huge tables. This makes data retrieval difficult since you have to join multiple big sized tables to fetch the required data.

4. Most of the times you have a relational store as your monolith database. This constraints all your services to use a relational database. However there will be scenarios where a No-SQL datastore might be a better fit for your services and hence you don’t want to be tightly coupled to a centralized datastore.

How to handle your data in a Microservice architecture?

Each microservice should have its own database and should contain data relevant to that microservice itself. This will allow you to deploy individual services independently. Individual Teams can now own the databases for the corresponding microservice.

Microservices should follow Domain Driven Design and have Bounded Contexts.
You need to design your application based on domains which aligns with the functionality of your application. Its like following the Code First approach over Data First approach – hence you design your models first. This is a fundamentally different approach than the traditional mentality of first designing your database tables when starting to work on a new requirement or greenfield project. You should always try to maintain the integrity of your Business model.

While designing your database, look at the application functionality and determine if it needs a relational schema or not. Keep your mind open towards a NoSQL db as well if it fits your criteria.

Databases should be treated as private to each microservice. No other microservice can directly modify data stored inside database in another microservice.

In the below image, the Order Service wont be able to update the Pricing Database directly, it can only access it via the microservice API. This helps you to achieve consistency across different services.

Event-Driven Architecture is a common pattern to maintain data consistency across different services. Instead of waiting for an ACID transaction to complete processing and taking up system resources, you can make your application more available and performant by offloading the message to a queue. This provides loose coupling between services.

Messages to the queues can be treated as Events – and can follow the Pub-Sub model. Publishers publishes a message and is not aware of the Consumer, who has subscribed to the event stream. Loose Coupling between components in your architecture enables to build highly scalable distributed system.

Handling database changes in your journey from Monolith to Microservice is challenging. In this article, we understood the problems with Monolithic Database Design and how you can handle your data in a microservice architecture. Please let me know if you have any questions and I will be happy to discuss further.

For more information about Architecture for Containerized Applications, please download the free ebook provided by Microsoft here.

Categories: Architecture, Microservices