Saga Client Server |work| -

The client should not block waiting for a long-running Saga. Typically, the server returns an 202 Accepted HTTP status with a Location header pointing to a status resource. The client then polls or receives a webhook notification when the Saga completes or fails.

// Do real work... processedMessages.add(msgId); return success;

: The server holds the connection open (HTTP long polling) until the entire chain of events is finalized. Microservices.io Key Benefits & Risks Pattern: Saga - Microservices.io saga client server

While the Saga Client Server pattern offers several benefits, it also presents some challenges and limitations:

: The brain of the operation. It is a stateful service (or a state machine) that receives the client request, executes step 1 (via RPC/message), waits for the response, executes step 2, and manages retries or compensations. This server holds the "Saga Execution Log." The client should not block waiting for a long-running Saga

: Each step in the saga is an independent, atomic operation within its own service and database.

// Step 2 PaymentReceipt receipt = paymentClient.charge(req.getPayment()); saga.addStep("PAYMENT", receipt); // Do real work

In this approach, a central (a dedicated service or part of an API gateway) receives the client’s request. The orchestrator tells each participating service what to do and when. It maintains the state machine of the Saga. If a service fails, the orchestrator decides the compensation path and invokes the compensating actions.