Microservices architecture is constantly growing. It brings many advantages when compared to outdated monolith architecture. Database design is one of the most important concerns while developing a microservices project. There are two crucial questions regarding data design – organizing your data and where to store it?
There are two types of Database Design in Microservices Architecture:
- Database per service
- Shared database
One of the core characteristics of this architecture is the loose coupling of services. Every service has its database, then polyglot persistence (using multiple databases in a single application/software) is between the microservices.
- Each database can scale independently
- Domain data is surrounded within the service
- If any database server is down or any changes has to be done in any services, this will not affect the other services
There are also benefits and some severe downsides when using the Database per service approach. Each service can only access its data, so there shouldn’t be any communication gap, but there should be a communication method to exchange data. Every service must provide a clear API. The next important problem is transactions. Transactions can negatively impact consistency across microservices.
Treating shared database an Anti-pattern
Scalability, independence, and resilience are the core properties of microservices that they lose when using a shared database. Therefore, selecting a shared database for the microservices projects is not the best option. Monolith would have done the job.
Some of the key benefits of the shared database are that there is no need for a communication channel between the services, and transaction management seems pretty easy. In addition, complicated queries can be efficiently executed.
Alterations related to the database could impact the services. For example, if an e-commerce platform is developed on microservices and the user’s panel goes down, the order panel would automatically go down as they work on the same database. This can be easily rectified when using per service.
A key step for Database Design in Microservices Architecture is choosing a database model. It can either be per service or shared. First, we need to understand the specific characteristics of the database to select the right technology.
- Read performance: It’s the speed of fetching queries or number of transactions per second.
- Write performance: – Writing to the database, not reading from it. If the projects need to process a lot of data, this can be a core parameter.
- Latency: – Delivering instant user experiences require a low-latency database, for example, Real Time Gaming
- Resource efficiency: – Consumption of lesser resources, the better. It may provide faster executions and reduce the host load.
- Provisioning efficiency: – Availability of Microservice components for rapid development and testing