Microservices Communication Patterns (Saga, Circuit Breaker) · 강의

코레오그래피 사가 해설

중앙 조정자 없이 서비스가 이벤트를 통해 직접 통신하는 코레오그래피 방식을 이해합니다.

코레오그래피 사가 해설은(는) CoddyKit의 무료 Microservices Communication Patterns (Saga, Circuit Breaker) 강의입니다. 이것은 4개 중 2번째 강의입니다. 아래에서 전체 강의를 무료로 읽을 수 있으며, 내장 코드 에디터와 24/7 AI 튜터와 함께 브라우저에서 직접 실습할 수 있습니다. 이 강의는 Microservices Communication Patterns (Saga, Circuit Breaker) 학습 경로의 일부이며, 진행 상황이 웹과 CoddyKit 앱에 동기화됩니다. Microservices Communication Patterns (Saga, Circuit Breaker) 강의에는 총 4개의 강의가 포함되어 있습니다.

이 강의의 일부는 아직 번역되지 않았으며 영어로 표시됩니다.

Choreography Saga Intro

Welcome! In this lesson, we'll explore the Choreography Saga pattern. It's a way to manage complex business transactions that span multiple services in a decentralized way.

Unlike an orchestra with a conductor, choreography is like a dance where each dancer knows their part and reacts to others' movements.

Decentralized Event Flow

In a choreography saga, there's no central coordinator service. Instead, each service involved in the transaction publishes events and listens for events from other services.

Services react to events.
They perform their part of the transaction.
They publish new events to trigger the next step.

Order Processing Example

Let's use a common example: processing a customer order. This involves multiple steps across different services:

Order Service: Creates the order.
Payment Service: Handles payment.
Inventory Service: Updates stock.

How do these services coordinate without a central brain?

Step 1: Order Created Event

When a customer places an order, the Order Service starts the saga. It saves the order and then publishes an OrderCreatedEvent.

This event signals to other services that a new order is ready for processing.

public class OrderService {
  public static void processNewOrder(String orderId) {
    System.out.println("Order Service: Received new order " + orderId);
    System.out.println("Order Service: Saving order " + orderId + " to database...");
    // Imagine database interaction here
    System.out.println("Order Service: Order " + orderId + " saved.");
    System.out.println("Order Service: Publishing 'OrderCreatedEvent' for " + orderId);
  }

  public static void main(String[] args) {
    processNewOrder("ORD789"); // Simulate a new order coming in
  }
}

Step 2: Payment Service Reacts

The Payment Service is subscribed to OrderCreatedEvents. When it receives one, it processes the payment for that order.

After processing, it publishes either a PaymentProcessedEvent or a PaymentFailedEvent.

public class PaymentService {
  public static void handleOrderCreated(String orderId) {
    System.out.println("Payment Service: Received 'OrderCreatedEvent' for order " + orderId);
    System.out.println("Payment Service: Processing payment for " + orderId + "...");
    // Simulate payment gateway interaction
    boolean paymentSuccess = true; // For this example, assume success
    if (paymentSuccess) {
      System.out.println("Payment Service: Payment successful for " + orderId + ".");
      System.out.println("Payment Service: Publishing 'PaymentProcessedEvent' for " + orderId);
    } else {
      System.out.println("Payment Service: Payment failed for " + orderId + ".");
      System.out.println("Payment Service: Publishing 'PaymentFailedEvent' for " + orderId);
    }
  }

  public static void main(String[] args) {
    handleOrderCreated("ORD789"); // Simulate receiving an event
  }
}

Step 3: Inventory Service Updates

Next, the Inventory Service listens for PaymentProcessedEvents. Upon receiving one, it reduces the stock for the ordered items.

It then publishes an InventoryUpdatedEvent to indicate its task is complete.

public class InventoryService {
  public static void handlePaymentProcessed(String orderId) {
    System.out.println("Inventory Service: Received 'PaymentProcessedEvent' for order " + orderId);
    System.out.println("Inventory Service: Updating stock for order " + orderId + "...");
    // Simulate inventory database update
    System.out.println("Inventory Service: Stock updated for order " + orderId + ".");
    System.out.println("Inventory Service: Publishing 'InventoryUpdatedEvent' for " + orderId);
  }

  public static void main(String[] args) {
    handlePaymentProcessed("ORD789"); // Simulate receiving an event
  }
}

The Challenge of Failures

What happens if a step in this flow fails? For example, if the payment fails, we can't update inventory. We also need to undo any previous successful steps.

This is where compensation logic comes in. It's about reversing previously completed actions.

Compensation in Choreography

In a choreography saga, compensation also happens through events. If a service fails, it publishes a compensation event.

Other services listen for these compensation events and perform their own rollback actions.

Compensation Example: Payment Fails

Imagine the Payment Service fails and publishes a PaymentFailedEvent. The Order Service, which started the saga, listens for this event.

Upon receiving it, the Order Service updates the order status to 'Cancelled', effectively rolling back the transaction from its side.

public class OrderService {
  public static void handlePaymentFailed(String orderId) {
    System.out.println("Order Service: Received 'PaymentFailedEvent' for order " + orderId);
    System.out.println("Order Service: Initiating compensation for " + orderId + ".");
    // Change order status to 'Cancelled'
    System.out.println("Order Service: Updating order " + orderId + " status to 'Cancelled'.");
    // Could publish OrderCancelledEvent if other services need to know
  }

  public static void main(String[] args) {
    handlePaymentFailed("ORD789"); // Simulate receiving a compensation event
  }
}

Pros and Cons of Choreography

Choreography offers benefits but also presents challenges:

Pros: Highly decoupled services, no central point of failure, simpler to implement for simple flows.
Cons: Can be harder to monitor the overall transaction flow, complex compensation logic, potential for 'event storms' if not designed carefully.

Choreography Check

Consider a choreography saga where an 'OrderConfirmedEvent' is published. Which statement accurately describes how the next step is initiated?

Recap: Choreography Saga

You've learned about the Choreography Saga pattern:

It's a decentralized approach for distributed transactions.
Services communicate by publishing and subscribing to events.
There's no central coordinator; each service knows its role.
Compensation for failures is also handled via events, allowing services to roll back their actions.

This pattern promotes loose coupling but requires careful design for monitoring and compensation.

자주 묻는 질문

“코레오그래피 사가 해설” 강의는 무료인가요?

네 — “코레오그래피 사가 해설” 전체 내용을 이 웹사이트에서 무료로 읽을 수 있습니다. 인터랙티브하게 실습하려면(내장 코드 에디터와 24/7 AI 튜터), CoddyKit PRO로 업그레이드하면 Microservices Communication Patterns (Saga, Circuit Breaker) 강의 전체를 잠금 해제할 수 있습니다. Microservices Communication Patterns (Saga, Circuit Breaker) 강의에는 총 4개의 강의가 포함되어 있습니다.

“코레오그래피 사가 해설”에서 뭘 배우나요?

중앙 조정자 없이 서비스가 이벤트를 통해 직접 통신하는 코레오그래피 방식을 이해합니다. 브라우저에서 직접 실행하는 실습 코드로 Microservices Communication Patterns (Saga, Circuit Breaker)을(를) 배우며, 24/7 AI 튜터가 강의를 진행하면서 질문에 답변해줍니다.

Microservices Communication Patterns (Saga, Circuit Breaker)을(를) 시작하는 데 경험이 필요한가요?

사전 경험은 필요하지 않습니다. CoddyKit의 Microservices Communication Patterns (Saga, Circuit Breaker)은(는) 초급자부터 고급 학습자까지를 위해 구성되어 있으므로, 여기서 시작하거나 처음부터 시작할 수 있으며 자신의 속도대로 진행할 수 있습니다. 이것은 4개 중 2번째 강의입니다.

“코레오그래피 사가 해설” 강의는 얼마나 걸리나요?

대부분의 CoddyKit 강의는 약 5~10분이 소요됩니다. 각 강의는 간결하고 인터랙티브하여 꾸준한 진행이 가능하며, 웹과 앱에서 중단한 부분부터 바로 시작할 수 있습니다.

이 Microservices Communication Patterns (Saga, Circuit Breaker) 강의에서 코드를 작성하고 실행할 수 있나요?

네. 모든 Microservices Communication Patterns (Saga, Circuit Breaker) 강의에는 내장 코드 에디터가 포함되어 있으므로, 브라우저에서 바로 실제 코드를 작성하고 실행한 후 즉시 AI 피드백을 받을 수 있습니다 — 로컬 설정이 필요 없습니다.

이 강의의 모든 강의

← Microservices Communication Patterns (Saga, Circuit Breaker)(으)로 돌아가기