Microservice Architecture of a Catalog and Sales Order Management System

Welcome to the continuation of my lecture about developing a catalog and sales order management system using a microservice architecture. Mi...

Welcome to the continuation of my lecture about developing a catalog and sales order management system using a microservice architecture.

Microservice is a design architecture that breaks apart the monolithic system into a collection of related services.

Here are some of the microservice principles

• Highly cohesive - related features must be kept in one service
• Loosely coupled - one service knows little about the others. In fact one service could be running on Java while the other is on .NET.
• Organized per business domain or functionality - it has a single responsibility
• Maintained by a small team
• Independently maintainable and testable - it’s easier to debug and test a lightweight microservice vs a complex monolithic application.

The downsides are

• It needs more collaboration between teams.
• It will definitely require automated deployment or DevOps.
• Communication problem between microservices leads to poor performance.
• Much harder to test the complete system.

For more information about microservices, you can visit the links in the description section below.

Here are some microservices framework for Java

• Spring Framework - https://spring.io/ 
• Axon Framework - https://axoniq.io/
• Micronaut - https://micronaut.io
• Thorntail - https://thorntail.io/

But for this project, we will use the Spring Framework.

It’s now time to set up the microservice architecture of our catalog and sales order management system. Fortunately, Spring has already provided the lift for the much-needed dependencies in Spring Cloud.

Here is a diagram of all the microservices and their relationship that we will need for this project.

1. Terawarehouse-config-server - it handles the externalized configuration of our distributed system. For this project, we will use GIT as the store provider.
2. Terawarehouse-service-discovery (Eureka) - is a service registry where all our services should be registered. With Eureka client-side service discovery it allows the services to find and communicate with each other without knowing the hostname and port but only the Spring application name which it will use to register.
3. Terawarehouse-load-balancer (Zuul) - is a reverse proxy that lets us route client-side requests to a microservice and do server-side load balancing. It uses Ribbon to locate a microservice instance registered in Eureka.
4. Terawarehouse-catalog - microservice that manages the catalog (category, product, serial).
5. Terawarehouse-inventory - microservice that manages the product inventory and movement.
6. Terawarehouse-sales - microservice that handles product orders from customers.
7. Terawarehouse-reporting - we can aggregate the data using Apache NiFi or queue and then save in a reporting database.

Going thru our projects’ dependencies, we can actually group them in four:

1. Config server
2. Eureka/discovery server
3. Zuul/load balancing server
4. Microservices.

References

• https://microservices.io/

Repositories

• https://github.com/orgs/broodcamp
• https://github.com/orgs/terawarehouse