Master the Saga Pattern: How to Ensure Consistency in Microservices with Quarkus, Apache Camel and OpenShift!

Imagine the scene: You, a Java developer, are working on a feature that performs multiple database operations. Then, out of nowhere, an error occurs in one of the steps. The result? The previous operations are already saved, messing up the entire database! ????

But hold on, there’s a solution! That’s where the famous @Transactional comes in. This magical annotation ensures that everything inside the method will only be saved to the database if everything works perfectly. If something goes wrong, it’s like hitting "Ctrl+Z"—everything gets rolled back, and nothing is saved. Simple as that!

@Transactional protects your database operations, ensuring they are only confirmed if the entire process is successful. If something fails, it undoes everything to keep the database clean.

Up to this point, everything works smoothly because it’s all happening within a single application. But what happens when we talk about a distributed system with multiple microservices? How can we ensure that every part of a complex transaction is either fully completed or properly rolled back if something goes wrong?

Think about booking a travel package. You purchase a plane ticket, book a hotel, and rent a car. If the hotel reservation fails, how do you cancel the plane ticket and car rental? Now, imagine an e-commerce platform during Black Friday: thousands of orders being processed, and any failure could lead to stuck inventory or incorrect charges. How does the system handle rollbacks in a microservices environment? ??

The answer is the Saga Pattern. Depending on the context, we can implement Choreography or Orchestration to manage these situations. And that’s exactly what I demonstrated today with an application built using Quarkus, Apache Camel, and OpenShift! ??

Saga with Choreography (Monolith)

In Choreography, each part of the system reacts to events without relying on a central controller. It’s like a well-rehearsed dance—one service publishes an event (e.g., "Payment Completed"), and another service listening to that event takes action (e.g., "Reserve Product in Stock").

In my case, I implemented Choreography within a monolithic application using Apache Camel for lightweight event management. Quarkus brought high performance and agility, and deploying on OpenShift ensured scalability and flexibility.

Advantage: Simpler integration and lower communication complexity.

Disadvantage: Harder to scale and maintain cohesion in larger systems.

Saga with Orchestration (Microservices via REST API)

In Orchestration, a central service controls the entire flow. This orchestrator tells each microservice what to do and triggers compensations if something goes wrong. It’s like a conductor managing an orchestra.

Here, I implemented Orchestration in a microservices environment where the orchestrator communicated with services through REST APIs. This provided more control over each step of the process. Using Apache Camel, I built robust, automated flows, Quarkus delivered high performance, and OpenShift ensured scalability to handle high-demand scenarios.

Advantage: Centralized control and easier failure tracking.

Disadvantage: The orchestrator can become a single point of failure if not well managed.

In Practice:

In an online purchase scenario:

• If the payment fails, the inventory service cancels the reservation.
• If the delivery can’t be scheduled, the payment is refunded.

With Apache Camel, I created clear and automatic compensation flows. The integration via REST API with microservices made the system more organized and flexible. OpenShift provided the scalability and resilience needed for high-traffic events like Black Friday.

Conclusion and Next Steps

The Saga Pattern is essential for ensuring consistency in distributed systems. Whether using Choreography in a monolith or Orchestration in microservices, the key is to adapt the approach to the project’s context. Combining Quarkus, Apache Camel, and OpenShift was the perfect solution to demonstrate these strategies in practice.

Thinking ahead:

• For Choreography, a natural evolution would be migrating to a distributed architecture with event streaming using tools like Apache Kafka or RabbitMQ, enabling more robust and scalable asynchronous communication.
• For Orchestration, integrating asynchronous messaging instead of REST APIs—or even exploring specialized tools like Camunda or Temporal.io—could reduce coupling and improve resilience.

And you? Have you implemented the Saga Pattern in your projects? Let’s talk about which approach makes the most sense for your application!

Links:

https://microservices.io/patterns/data/saga.html

https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/saga-choreography.html

https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/saga-orchestration.html