Greetings there!
Are you familiar with CQRS? Either way let me walk you through this project.
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.
- 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.
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 upNow, when you have started the project, you can check if your services have been registered or not by visiting:
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
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 grafanaThen launch k6:
aminehajali@cqrs:~/cqrs-microservices/stress-tester$ docker-compose run k6 run /scripts/test-cqrs.jsThe 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!