MicroServices and CQRS

Greetings there!
Are you familiar with CQRS? Either way let me walk you through this project.

What is CQRS?

CQRS stands for Command and Query Responsibility Segregation, a pattern that separates read and update operations for a data store. Implementing CQRS in your application can maximize its performance, scalability, and security. The flexibility created by migrating to CQRS allows a system to better evolve over time and prevents update commands from causing merge conflicts at the domain level.

Project architecture

• Config Service (Spring Cloud Config): The service that's going to provide the services config. The service configuration files are provided in the following GitHub repository.
• Service Registry (Spring Eureka): The services will register themselves directly when it's up.
• API Gateway (Spring Cloud Gateway): This will handle incoming requests and and redirects them to the corresponding registered internal services.
• Command and Query Services: The famous MicroServices implementing CQRS.
• RabbitMQ: The message broker that will allow us to synchronize between both databases by providing events.
• MongoDB: Our command DB, the choice behind this type of database is because of how fast writes are in it.
• ElasticSearch: Our query DB, the choice behind this type of database is because of how fast reads are in it.

A closer look on our MicroServices

Try it yourself!

It's easy! All you have to do is open your terminal in the root of the project and use the following command.

aminehajali@cqrs:~/cqrs-microservices$ docker-compose build
aminehajali@cqrs:~/cqrs-microservices$ docker-compose up

Now, when you have started the project, you can check if your services have been registered or not by visiting:

http://localhost:8761/

It should look something like this:

If the services are all registered, now you can test it out!

One thing to mention, in this project we're dealing with a sole entity Product.

"Product": {
    "ref": "str",
    "name": "str",
    "description": "str",
    "price": "float",
    "quantity": "int"
}

Commands:

Command	Method	Request	Body
Create Product	Post	localhost:8080/command/create	Product object
Buy Product	Post	localhost:8080/command/buy/{product-ref}	Nothing
Refill Product	Post	localhost:8080/command/refill/{product-ref}?quantity={quantity}	Nothing

Query:

Query	Method	Request
Get All Products	Get	localhost:8080/query/
Get Product By Reference	Get	localhost:8080/query/{product-ref}

If you want to purge both databases, just call the following Delete requests:

localhost:8080/query/purge

localhost:8080/command/purge

Stress testing the project

To stress test this project we used K6. The data provided from the tests will be visualized by Grafana.
How can you do the stress testing? Well, we have an another docker-compose file in the stress-tester folder!
The folder contains what we need to stress test our application! It will communicate with the API Gateway using an external network that we defined in both docker-composes.
First, launch Grafana and InfluxDB:

aminehajali@cqrs:~/cqrs-microservices/stress-tester$ docker-compose up -d influxdb grafana

Then launch k6:

aminehajali@cqrs:~/cqrs-microservices/stress-tester$ docker-compose run k6 run /scripts/test-cqrs.js

The results will be shown in Grafana at http://localhost:3000/d/k6/k6-load-testing-results

If you encounter any problem while testing this, please do contact me!

Thank you for your attention and don't forget to leave a ⭐