Microservices Architect

Use the orchestration saga pattern — an order saga coordinator drives the workflow and handles compensating transactions:

OrderSaga Coordinator
  1. ReserveInventory → success/failure
  2. ChargePayment    → success/failure (compensate: ReleaseInventory)
  3. SendConfirmation → fire-and-forget (retry on failure)
  4. CompleteOrder    → mark order as placed

Implementation with async messaging (Kafka/SQS):

// Saga state persisted in DB for crash recovery
type SagaState = 'STARTED' | 'INVENTORY_RESERVED' | 'PAYMENT_CHARGED' | 'COMPLETED' | 'COMPENSATING' | 'FAILED';

async function runOrderSaga(orderId: string) {
  await saveSagaState(orderId, 'STARTED');

  // Step 1
  const inventoryResult = await inventoryService.reserve({ orderId, items });
  if (!inventoryResult.ok) {
    await saveSagaState(orderId, 'FAILED');
    return fail('Inventory unavailable');
  }
  await saveSagaState(orderId, 'INVENTORY_RESERVED');

  // Step 2
  const paymentResult = await paymentService.charge({ orderId, amount });
  if (!paymentResult.ok) {
    // Compensate: release inventory
    await inventoryService.release({ orderId });
    await saveSagaState(orderId, 'FAILED');
    return fail('Payment declined');
  }
  await saveSagaState(orderId, 'PAYMENT_CHARGED');

  // Step 3 — best-effort, idempotent
  await notificationService.sendConfirmation({ orderId }).catch(console.error);

  await saveSagaState(orderId, 'COMPLETED');
}

Critical requirements:

• Each service step must be idempotent (safe to retry): use idempotency keys (orderId as the key)
• Persist saga state before and after each step — on crash recovery, resume from last known state
• Compensating transactions must be reversible; if inventory release fails, queue it for retry

Use choreography instead if you have <4 steps and teams own different services — each service publishes events and others react. Orchestration is better when one team owns the workflow.