BlogAnnounced at MongoDB.local NYC 2024: A recap of all announcements and updatesLearn more >>
MongoDB Developer
Java
plus
Sign in to follow topics
MongoDB Developer Centerchevron-right
Developer Topicschevron-right
Languageschevron-right
Javachevron-right

Microservices Architecture With Java, Spring, and MongoDB

Maxime Beugnet4 min read • Published Apr 16, 2024 • Updated Apr 17, 2024
SpringDockerMongoDBJava
Facebook Icontwitter iconlinkedin icon
Rate this tutorial
star-empty
star-empty
star-empty
star-empty
star-empty

Introduction

"Microservices are awesome and monolithic applications are evil."
If you are reading this article, you have already read that a million times, and I'm not the one who's going to tell you otherwise!
In this post, we are going to create a microservices architecture using MongoDB.

TL;DR

The source code is available in these two repositories.
The README.md files will help you start everything.

Microservices architecture

We are going to use Spring Boot and Spring Cloud dependencies to build our architecture.
Here is what a microservices architecture looks like, according to Spring:
Spring Microservices Architecture
We need several services to run this project. Let's talk about them one by one.
As you read this post, I suggest that you follow the instructions in the README.md file and start the service related to each section.

Config server

The first service that we need is a configuration server.
This service allows us to store all the configuration files of our microservices in a single repository so our configurations are easy to version and store.
The configuration of our config server is simple and straight to the point:
It allows us to locate the git repository that stores our microservices configuration and the branch that should be used.
Note that the only "trick" you need in your Spring Boot project to start a config server is the @EnableConfigServer annotation.

Service registry

A service registry is like a phone book for microservices. It keeps track of which microservices are running and where they are located (IP address and port). Other services can look up this information to find and communicate with the microservices they need.
A service registry is useful because it enables client-side load balancing and decouples service providers from consumers without the need for DNS.
Again, you don't need much to be able to start a Spring Boot service registry. The @EnableEurekaServer annotation makes all the magic happen.
The configuration is also to the point:
The last two lines prevent the service registry from registering to itself and retrieving the registry from itself.

API gateway

The API gateway service allows us to have a single point of entry to access all our microservices. Of course, you should have more than one in production, but all of them will be able to communicate with all the microservices and distribute the workload evenly by load-balancing the queries across your pool of microservices.
Also, an API gateway is useful to address cross-cutting concerns like security, monitoring, metrics gathering, and resiliency.
When our microservices start, they register themselves to the service registry. The API gateway can use this registry to locate the microservices and distribute the queries according to its routing configuration.
Note that our API gateway runs on port 8080.

MongoDB microservices

Finally, we have our MongoDB microservices.
Microservices are supposed to be independent of each other. For this reason, we need two MongoDB instances: one for each microservice.
Check out the README.md file to run everything.
Note that in the configuration files for the company and employee services, they are respectively running on ports 8081 and 8082.
Note that the two microservices are connected to two different MongoDB clusters to keep their independence. The company service is using the MongoDB node on port 27017 and the employee service is on port 27018.
Of course, this is only if you are running everything locally. In production, I would recommend to use two clusters on MongoDB Atlas. You can overwrite the MongoDB URI with the environment variables (see README.md).

Test the REST APIs

At this point, you should have five services running:
  • A config-server on port 8888
  • A service-registry on port 8761
  • An api-gateway on port 8080
  • Two microservices:
    • company-service on port 8081
    • employee-service on port 8082
And two MongoDB nodes on ports 27017 and 27018 or two MongoDB clusters on MongoDB Atlas.
If you start the script 2_api-tests.sh, you should get an output like this.
Note that the employee service sends queries to the company service to retrieve the details of the employees' company.
This confirms that the service registry is doing its job correctly because the URL only contains a reference to the company microservice, not its direct IP and port.

Conclusion

And voilà! You now have a basic microservice architecture running that is easy to use to kickstart your project.
In this architecture, we could seamlessly integrate additional features to enhance performance and maintainability in production. Caching would be essential, particularly with a potentially large number of employees within the same company, significantly alleviating the load on the company service.
The addition of a Spring Cloud Circuit Breaker could also improve the resiliency in production and a Spring Cloud Sleuth would help with distributed tracing and auto-configuration.
If you have questions, please head to our Developer Community website where the MongoDB engineers and the MongoDB community will help you build your next big idea with MongoDB.

Facebook Icontwitter iconlinkedin icon
Rate this tutorial
star-empty
star-empty
star-empty
star-empty
star-empty
Related
Article

How to Build a Search Service in Java


Apr 23, 2024 | 11 min read
Article

How Queryable Encryption Can Keep James Bond Safe


Apr 02, 2024 | 2 min read
Article

Using MongoDB Change Streams in Java


Apr 04, 2023 | 6 min read
Tutorial

Migrating PostgreSQL to MongoDB Using Confluent Kafka


Apr 10, 2024 | 10 min read
Table of Contents
  • Introduction