Components description - kristianrpo/mom-grpc-microservices GitHub Wiki

1. Client

The Client is the entry point for users who want to interact with the system. It is an EC2 instance that users access remotely via SSH to initiate requests. These requests are sent through HTTP/REST to the API Gateway. Client forwards user-defined operations (e.g., addition, subtraction, multiplication) to the API Gateway.

It is important to mention that also you can use the public IP from the API GATEWAY and the code from the client that we created in our repository to test de project in your local environment.

2. API Gateway

The API Gateway is the central control unit of the architecture. It functions as a Swarm manager and is responsible for receiving REST API requests from the client, resolving which microservice the request corresponds to, and then initiating gRPC communication to that microservice.

If the target microservice is available, the API Gateway forwards the request and returns the result back to the client. If the microservice is unavailable, the Gateway reroutes the request to the MOM (Message-Oriented Middleware) for failover handling.

The API Gateway also serves as a service router and orchestrator, centralizing how services are accessed and ensuring service discovery is efficient.

3. Microservices: Sum, Subtraction, Multiplication

Each microservice is deployed as a Docker container within Docker Swarm, and they all communicate using gRPC. These microservices are in charge of performing their respective arithmetic operations:

  • SUM: Handles addition requests. It’s the only microservice configured with replicas, which makes it go through the Docker Swarm load balancer for request distribution.
  • SUBTRACTION: Processes subtraction logic.
  • MULTIPLICATION: Handles multiplication operations.

All microservices support two modes of execution:

  • Direct gRPC request-response from the API Gateway.
  • Polling tasks from Redis queues in case of previous downtime (failover recovery).

Each microservice is responsible not only for processing current requests but also for recovering pending tasks that were enqueued while they were inactive.

4. MOM (Message-Oriented Middleware)

The MOM component is a custom message handling layer, designed to ensure fault tolerance and task recovery. When a microservice is down, the API Gateway sends the task to MOM via gRPC, which enqueues it into a specific Redis queue using a point-to-point (P2P) messaging pattern.

Once a microservice becomes available again, it pulls tasks from its assigned queue using a polling strategy. After processing the task, the microservice returns the result to MOM, which stores it in Redis along with a Time-To-Live (TTL).

5. Redis

Redis is used as a persistent storage layer for managing:

  • Pending tasks for unavailable microservices.
  • Processed results to be retrieved by clients later.

Each microservice has its own Redis queue, allowing clear separation of responsibilities. Redis also manages TTL-based expiration, ensuring that stale data is automatically purged. The integration with MOM ensures that Redis acts as both a task buffer and a temporary result store, enabling robust asynchronous processing.