Skip to main content

Choreography-Based Sagas: Ensuring Data Consistency in Distributed Systems

What is a Choreography-Based Saga?

A choreography-based saga helps maintain data consistency across microservices without a central coordinator. Instead, services communicate through events.

  • Each service completes its task and publishes an event.
  • Other services listen to these events and take necessary actions.
  • If a failure occurs, compensating transactions undo previous steps.

Implementing the Create Order Saga Using Choreography

Workflow: Happy Path

Here's how multiple services work together to process an order seamlessly:

  1. Order Service: Creates an order (APPROVAL_PENDING) and publishes an OrderCreated event.
  2. Consumer Service: Verifies the consumer and publishes a ConsumerVerified event.
  3. Kitchen Service: Creates a Ticket (CREATE_PENDING) and publishes a TicketCreated event.
  4. Accounting Service: Authorizes the payment and publishes a CreditCardAuthorized event.
  5. Kitchen Service: Moves the ticket to AWAITING_ACCEPTANCE.
  6. Order Service: Approves the order and publishes an OrderApproved event.






Key Considerations When Using Choreography-Based Sagas

Challenges & Design Issues

  • Managing event dependencies effectively.
  • Handling failures with compensating transactions.
  • Ensuring event ordering and deduplication.

Benefits

  • No centralized coordinator needed.
  • Scalability through independent services.
  • Loose coupling between microservices.

Drawbacks

  • Complex event management.
  • Harder to debug compared to orchestration.
  • Eventual consistency delays.

Final Thoughts

Choreography-based sagas are a great approach for managing distributed transactions, but they require careful planning to handle failures and dependencies.

Would you use choreography-based sagas in your system? Let us know in the comments! 

Labels:

Comments

Post a Comment

Popular posts from this blog

Hexagonal Architecture (Ports & Adapters Pattern)

Hexagonal Architecture , also known as the Ports and Adapters pattern, is a software design pattern that aims to create a decoupled and maintainable application by separating the core business logic from external concerns (like databases, APIs, and UIs). Structure of Hexagonal Architecture A typical Hexagonal Architecture has three main layers: 1️⃣ Core Domain (Application Logic) This contains the business rules and domain models. It is completely independent of external technologies . Example: If you’re building a banking system , this part would include logic for transactions, withdrawals, and deposits . 2️⃣ Ports (Interfaces) These are interfaces that define how the core interacts with external components. Two types of ports: Inbound Ports (driven by external inputs like APIs, UI, or events) Outbound Ports (used to interact with external services like databases, messaging systems, etc.) 3️⃣ Adapters (Implementation of Ports) These are concrete implementations of the ports, re...
Post a Comment
Read more

Recursion & Choice

Understanding Recursion and Choice Diagrams with Examples Understanding Recursion and Choice Diagrams with Examples Recursion is a powerful concept in programming where a function calls itself to solve smaller instances of the same problem. It's often used in solving complex problems that can be broken down into simpler subproblems. In this blog post, we'll explore the basics of recursion, understand choice diagrams, and see examples to illustrate these concepts. What is Recursion? Recursion occurs when a function calls itself directly or indirectly to solve a problem. A recursive function must have a base case to terminate the recursive calls and prevent infinite recursion. Here's a simple example of a recursive function to calculate the factorial of a number: public class RecursionExample { public static void main(String[] args) { int number = 5; int result = factorial(...
Post a Comment
Read more

Frameworks

  Communication Frameworks: BLUF:  Google's culture strongly emphasizes efficiency and directness, so getting to the "bottom line up front" is very common. SCQA:  Used in presenting proposals, making recommendations, and structuring project plans. PAS : Used in selling ideas and influencing others. BAB : Used in selling ideas and influencing others. Sparklines : Used in presentation to influence others. STAR:  Widely used in Google's interview process and performance evaluations. Problem-Solving/Decision-Making Frameworks: 5 Whys:  A fundamental technique for root cause analysis, and Google is known for its emphasis on data-driven decision-making, which often involves digging into the root causes of problems. Systems Thinking:  Given the complexity of Google's systems, a systems thinking approach is essential. The Four Questions : Used in post-mortem to review an incident. Human factors : Used in post-mortem to avoid the blame culture. Time Management/Prior...
Post a Comment
Read more