Spring Boot Microservices Architecture using Shared Database
If you got here, you have probably been researching about microservices projects using shared databases. I suppose you found a lot of people talking about it, but you didn’t find any code showing it in practice.
Yes, I know. This is a controversial topic and one that brings a lot of discussions. According to Martin Fowler, if you want to apply the concept of microservices to the letter, you must use a decentralized database approach. It means that each microservice has its own database. This may sound confusing, especially if you coming from the monolithic world. Fowler discussed this topic and pointed out some issues to be considered involving decentralized data management. In general, you should consider an additional effort for decentralized update management and integrity assurance to avoid inconsistencies.
This can make sense in small applications but it can get a little confusing for large ERP systems, or even for the migration of large monolithic systems highly dependent on centralized databases to a microservice architecture. As Fowler said, error is acceptable as long as the cost for the correction is offset by the gain in speed to meet demand.
So, what to do? My answer is: it depends on your need.
Let’s remember that there are several supposed benefits to using a microservice architecture. Decoupling parts of the system and transforming them into isolated and independent microservices can allow the allocation of more computational resources to the most requested components. Another interesting point is that each microservice can be written in a different programming language, since they communicate using standardized mechanisms, such as HTTP APIs.
There are several reasons for using a microservice architecture when starting a new project or even migrating existing systems. You are not required to be looking for all the benefits of microservices to decide this. You may want only a few advantages, and not necessarily about databases.
What I mean is that, in my opinion, you are not required to strictly follow all microservice architecture concepts. If your project needs? Great! If not, you can use a single database on different microservices without being crucified for it. After all, you may have issues at the backend layer and not at the database.
So, let’s see how to do this in practice, using Spring Cloud and Netflix libraries.
Since part of the libraries used to deal with microservices were developed by Netflix, let’s use as an example an application called netflix-simulator.
It is not the purpose of this article to detail the complete construction of a Spring Boot microservice. I suggest you download the source code from my github repository to follow the explanation.
This article will focus on presenting the shared database approach. To understand the DevOps approach implemented to compile and run the entire microservice stack in an automated way using Maven, Docker and shell script, take a look at:
Netflix Simulator is a set of three microservices, where two of them use the same Mysql database and the other uses an instance of a MongoDB.
Eureka Service Discovery library is used to register the microservices. Zull Gateway is used to receive requests and forward them to microservices. And finally, Spring Cloud Config library to serve as a centralized point for storing configuration data for microservices.
Therefore, the following figure shows an overview of the project architecture.
The proposed approach started with the creation of a project to group the entities common to the two microservices. In this case, Category and Movie entities. This project is called netflix-data. This is not a Spring Boot project, it is a simple java/maven project, with the default jar packaging.
In summary, this project contains classes with object-relational mapping and DTOs for the Category and Movie entities with their respective JPA annotations.
Therefore, you need to add the netflix-data dependency entry to the netflix-category-microservice and netflix-movie-microservice projects.
<dependency>
<groupId>com.soares.microservice</groupId>
<artifactId>netflix-data</artifactId>
<version>1.0.0</version>
</dependency>Since entities are imported from another project with a different package path, you need to inform the base package in the main class application using the EntityScan annotation. The following code shows this on line 12 for netflix-category-microservice. The same is done for netflix-movie-microservice.
The rest of the code architecture for each project follows well-established web development standards. I mean: controller / service / repository. You are probably already comfortable with that, if you don’t, feel free to check everything in the project.
Once you have defined the base package, you can use repositories by passing these entities as type parameters.
As previously mentioned, the database connection data of each microservice is centralized in netflix-config. This project contains the connection data for Mysql database as well as the connection data for Mongo needed for the netflix-user-microservice. Since this last microservice has its own exclusive database, the User entity is defined within the project itself, and not in a separate project as done with the Category and Movie entities.
Running
To run the application, you need the following dependencies:
All you need to do is run the following commands:
git clone https://github.com/marcelohweb/netflix-microservices
cd netflix-microservices
make build
make runYou don’t need java or maven in your machine because this project is compiled inside a docker container.
Before you start using, check the container logs to see if all microservices are running. It takes some time.
You can use Portainer to check.
You can then access eureka service discovery here: http://localhost:8010/
Username: user
Password: user
You will see all registered microservices as the following image:
Usage
You can use this API by importing the Postman collection located in the postman directory.
First of all, you need to create a user using user-create request.
After that, use user-login request to authenticate and get the token. The token is in the header response.
Then, access http://localhost:8081/ to visualize the mongo database via Mongo Express.
Username: user
Password: password
As you can see, there is a database called db_netflix_app_user. Click on it to explore and then click on user collection to verify the user you created.
So now, let’s create category and film. Return to Postman and open category-create request. Go to Authorization tab, select Bearer Token, then paste the token into the field.
Once the token is set, create a category.
Copy the generated id to the category and use it to create a movie using the movie-create request. Remember you also need to put the token to call movie microservice.
After creating a movie, use category-get-all request to view all records.
You can also view mysql data via phpmyadmin running at http://localhost:8080/
Username: user
Password: password
Conclusion
In this article, we discuss microservice architecture with shared databases. The proof of concept presented demonstrates an approach to the use of the same database by multiple microservices. Although this is a very controversial topic, my opinion is that you don’t need to migrate your entire existing stack to a microservice architecture just because there are a lot of people talking about it. Managing microservices is not an easy task. In some cases, a monolithic architecture can solve your problem. If you think that the benefits of this architecture outweigh the effort of a migration, you shouldn’t be hated if you need to use centralized databases. It all depends on need.
