Sagas to solve Pizza - the Microservices style

In the ever-evolving landscape of software architecture, microservices have emerged as a game-changer. The shift from monolithic to microservices architecture brings unprecedented flexibility, scalability, and agility. An architectural style that structures an application as a collection of loosely coupled, independently deployable services, have gained widespread adoption. This paradigm shift allows organizations to break down complex systems into manageable, autonomous components, fostering rapid development and deployment.

However, as we navigate the intricate web of distributed systems, a crucial element comes into play — sagas.

As microservices proliferate, the need for effective coordination between independently functioning services becomes paramount. Enter sagas — orchestrating the flow of transactions and maintaining consistency in a world where services operate independently yet collaboratively.

In a microservices architecture, traditional ACID transactions face challenges due to the distributed nature of services. Sagas provide a more resilient alternative by breaking down transactions into smaller, manageable steps, ensuring that the system remains consistent even in the face of failures. Sagas are also called long lived transactions (LLT) because of this nature as they break down a chain of calls into discrete steps. Saga is a design which can coordinate multiple changes in state, but avoids the need for locking resources for long periods of time.

Using sagas comes with the added benefit of forcing us to
explicitly model our business processes, which can have significant benefits.

In the context of EazyBake Corp, a pizza chain, let’s explore how a saga can be formed to manage a common process: the customer order fulfillment process.

Step 1: Order Placement
The saga begins when a customer places an order for a delicious EazyBake pizza through the online platform. At this stage, the system initiates a series of transactions that need to be coordinated to ensure a seamless order fulfillment process.

Step 2: Payment Processing
Once the order is placed, the first step in the saga involves processing the payment. The system communicates with the payment service to charge the customer for the pizza. If the payment is successful, the saga proceeds to the next step. If there’s an issue with the payment, a compensating transaction is triggered to handle the failure gracefully, such as notifying the customer and canceling the order.

Step 3: Inventory Management
With the payment confirmed, the saga moves on to the inventory management step. The system checks the availability of the pizza ingredients in the inventory. If there are sufficient ingredients, the order proceeds to the next step. If there’s a shortage, a compensating transaction is triggered to update the order status, notify the customer, and possibly suggest alternative menu options.

Step 4: Order Preparation
Assuming the inventory check is successful, the order moves to the preparation stage. The system communicates with the kitchen service to start preparing the pizza. If any issues arise during the preparation (e.g., oven malfunction), a compensating transaction ensures the order is appropriately updated, and the customer is notified.

Step 5: Delivery Scheduling
As the pizza is being prepared, the system coordinates with the delivery service to schedule the delivery. If the scheduling is successful, the order progresses. In case of a delivery scheduling failure (e.g., no available delivery drivers), a compensating transaction triggers actions such as updating the order status and providing the customer with revised delivery estimates.

Step 6: Order Delivery
The final step in the saga involves delivering the pizza to the customer. The delivery service ensures the pizza reaches the customer within the scheduled time. If successful, the saga concludes with the order marked as delivered. If any issues occur during delivery (e.g., the wrong address), compensating transactions manage the order status and customer communication accordingly.

Benefits of the Saga in EazyBake Corp:

1. Consistency: The saga ensures that at each step, the system is in a consistent state, and if an error occurs, compensating transactions bring the system back to a well-defined state.
2. Fault Tolerance: By breaking down the order fulfillment process into smaller, manageable steps, the saga enhances fault tolerance. If a specific step fails, it can be addressed without affecting the entire process.
3. Visibility and Traceability: The saga provides a clear and traceable flow of the order fulfillment process, making it easier to monitor and troubleshoot any issues that may arise.

In this way, EazyBake Corp uses sagas to orchestrate the customer order fulfillment process, ensuring a delightful and consistent experience for pizza lovers.

Let’s explore different ways to implement sagas for our EazyBake corporation

Choreography-Based Saga:
In choreography-based sagas, each service involved in the saga knows its responsibilities and communicates directly with other services to achieve the desired outcome.

In EazyBake Corp, when one wants to order a pizza, the customer initiates the order and the order service notifies the payment service. The payment service processes the payment and notifies the inventory service which in turn checks the updates the ingridient (stock) availability notifying the kitchen service. The kitchen service prepares the service and notifies the delivery service. The delivery service, finally schedules the pizza delivery and makes the order as delivered.

Benefits:

1. Decentralized Communication: Services communicate directly, reducing centralization.
2. Flexibility: Easy to add or modify services without affecting the entire process.

Drawbacks

1. Increased Complexity: Understanding the entire flow may become challenging as the number of services increases.

Orchestration-Based Saga:
In orchestration-based sagas, there is a central component (orchestrator) responsible for coordinating the interactions between services.

Discussing the same scenario here where one needs to order a pizza from EazyBake Corp. The orchestration service calls the order service and initiates the order, once the order has been successfully placed, the orchestration service gets the success response and then it calls the payment service to process the payment. This becomes a chain wherein when the orchestration service recieves a success response from the payment service it calls the inventory service then the kitchen service and lastly the delivery service.

Benefits:

1. Centralized Control: The orchestrator maintains a clear view of the entire process, making it easier to manage and monitor.
2. Easy to Understand: The overall flow is defined in one place, enhancing readability.

Drawbacks:

1. Single Point of Failure: The orchestrator becomes a critical component, and failure can impact the entire saga.
2. Potential Bottleneck: As the system scales, the orchestrator may become a performance bottleneck.

Hybrid Approach:
A hybrid approach combines choreography and orchestration, allowing certain parts of the saga to be orchestrated while others follow a choreography-based pattern.

An example would be the central orchestration service initiating the order and controlling the payment and inventory service. The payment service then processes the payment but communicates directly with the kitchen and delivery services, so does the inventory service communicate directly with the kitchen service. The kitchen service then prepares the pizza and delivery service schedules the delivery after that and marks the order as delivered.

Benefits:

1. Flexibility: Allows for a mix of centralized control and decentralized communication.
2. Scalability: Certain services can operate independently, enhancing scalability.

Drawbacks:

1. Increased Complexity: Requires careful design and documentation to maintain clarity.
2. Coordination Challenges: Ensuring seamless communication between orchestrated and choreographed services may be challenging.

When deciding implementations, EazyBake’s tireless engineers can choose any of these approaches and decide what works best for them. In their world they would have to weigh up flexibility, scalability, complexity and coordination to find the right balance for thier microservices. Implementing sagas for a pizza delivery chain as big as EazyBake would be a complex process for sure but the benefits of breaking it down into steps which are manageable and traceable, which can be made fault tolerant and consistent is better in the long term.

Let’s hope other companies learn from EazyBake!