Microservices Architecture Patterns | SAGA Choreography Explained & Project Creation | JavaTechie

Summary

In this tutorial, the presenter explains how to implement the Saga Choreography Design Pattern to manage transactions in a microservices architecture. Using Spring WebFlux, Apache Kafka, and Spring Cloud Stream, the video demonstrates how to handle inter-service communication without relying on synchronous HTTP calls. By utilizing event-driven communication, services like order and payment can operate independently with their own databases. The tutorial walks through creating a multi-module Maven project, setting up event sourcing, and configuring Kafka topics. This approach ensures resilient and efficient transaction management in distributed systems.

Takeaways

• 😀 The saga pattern is a solution to handle distributed transactions in microservices, focusing on event-driven communication.
• 😀 In monolithic systems, a single database simplifies transaction management with easy commit and rollback.
• 😀 Microservices with a 'Database per Service' approach introduce challenges in transaction management due to separate databases.
• 😀 The choreography approach in saga pattern eliminates the need for HTTP requests between services by using event-driven communication via Kafka topics.
• 😀 Each service in the choreography pattern publishes and consumes events, facilitating decoupled and asynchronous communication.
• 😀 In the saga choreography pattern, payment services publish events such as payment success or failure, which are then consumed by the order service.
• 😀 Using event sourcing in saga choreography, order and payment services work independently without direct dependencies, reducing failure risks.
• 😀 Saga pattern helps mitigate issues caused by service downtime, ensuring the system continues functioning without manual intervention.
• 😀 A multi-module Maven project setup is used for implementing the saga pattern, with separate modules for order service, payment service, and common DTOs.
• 😀 The tutorial emphasizes using technologies like Spring WebFlux, Apache Kafka, Spring Cloud Stream, and MySQL to implement the saga choreography pattern.
• 😀 The next tutorial will cover the complete implementation of the saga choreography pattern, including event handling and database transactions.

Q & A

What is the Saga choreography pattern?

The Saga choreography pattern is a decentralized approach for managing distributed transactions in microservices. Instead of relying on a central orchestrator, services communicate through events to coordinate and manage long-running transactions.

Why is transaction management difficult in microservices compared to monolithic systems?

In microservices, each service has its own independent database, making it challenging to maintain ACID properties (Atomicity, Consistency, Isolation, Durability). Unlike monolithic systems, where everything shares a single database, coordinating transactions across multiple services requires patterns like Saga to ensure consistency and handle failures.

What are the key disadvantages of the HTTP request-based approach in microservices?

The key disadvantages are the need to send multiple HTTP requests for simple operations (leading to performance issues) and the risk of impacting revenue if one of the services is down, causing delays or failures in processing the request.

What role does Kafka play in the Saga choreography pattern?

Kafka is used as an event streaming platform to facilitate communication between services. In the choreography approach, services publish and consume events via Kafka topics to notify other services of important events like order status, payment completion, or failure.

What is the difference between choreography and orchestration in the context of the Saga pattern?

In choreography, each service makes decisions and publishes events based on the business logic. There is no central orchestrator. In contrast, orchestration involves a central service that coordinates the actions of other services, managing the sequence of events and decision-making.

Can you explain how event sourcing works in the context of the Saga choreography pattern?

Event sourcing is a technique where each state transition is captured as an event. In the Saga choreography pattern, each service publishes events representing changes in the state (e.g., order placed, payment successful) to a Kafka topic, which other services consume to react and update their states accordingly.

How does the payment service validate whether a user has enough balance for a purchase?

The payment service receives the order request and checks the user's balance in its database. If the balance is sufficient, it deducts the amount and publishes a 'payment completed' event. If the balance is insufficient, it publishes a 'payment failed' event.

What happens when the order service receives a 'payment failed' event from the payment service?

When the order service receives a 'payment failed' event, it cancels the order and notifies the user that the payment was unsuccessful, effectively rolling back the transaction.

Why does the author suggest using a multi-module project structure for this example?

A multi-module project structure allows for better organization, modularity, and reusability. It separates different concerns (Order Service, Payment Service, and Common DTOs) into independent modules, making the codebase easier to maintain and extend.

What technologies are being used in this implementation of the Saga choreography pattern?

The implementation uses Spring WebFlux for reactive programming, Apache Kafka for event streaming, Spring Cloud Stream for integration with Kafka, Spring Boot for application framework, and MySQL as the database.