Skip to content

9.4 Onboarding Saga Wiring

Sprint: Sprint 09 - Subscription and Onboarding Saga
Feature ID: 9.4
Subtasks: 9.4.1, 9.4.2, 9.4.3

Objective

Deliver "Onboarding Saga Wiring" within Sprint 09 - Subscription and Onboarding Saga.

Dependencies

Aggregated from the subtasks below (prerequisite task IDs and enablers):

  • 9.3.1
  • 8.5.3
  • 9.4.1
  • 8.3.1
  • 9.4.2
  • 8.5.5
  • 8.3.3

Subtasks

9.4.1 Payment-completed consumer in subscription-service

  • ID: 9.4.1
  • Title: Consume payment.completed.v1 to activate subscription
  • Description: Idempotent (inbox) consumer of payment.completed.v1 invoking ActivateSubscriptionCommand for the order's subscription (saga step 4).
  • Business Purpose: Asynchronously activate on successful payment (FR-13, AC-01).
  • Inputs: event-catalog saga sequence, FR-13.
  • Outputs: Kafka consumer + inbox guard.
  • Acceptance Criteria:
  • One payment.completed.v1 yields exactly one activation (inbox-deduplicated) and a subscription.activated.v1 event.
  • Dependencies: 9.3.1, 8.5.3
  • Complexity: M

9.4.2 Order saga: confirm/fulfill on activation

  • ID: 9.4.2
  • Title: Drive order saga to FULFILLED on subscription.activated.v1
  • Description: In order-service, idempotent consumers of payment.completed.v1 (PENDING_PAYMENT->PAID) and subscription.activated.v1 (PAID->FULFILLED), updating saga_state at each step (FR-10).
  • Business Purpose: Complete the order on successful activation (FR-10, AC-01 step 5).
  • Inputs: FR-10, event-catalog saga, analysis Section 9.2.
  • Outputs: Order saga consumers + saga-state updates.
  • Acceptance Criteria:
  • On payment.completed.v1 the order becomes PAID; on subscription.activated.v1 it becomes FULFILLED; saga_state reflects each step; consumers are idempotent.
  • Dependencies: 9.4.1, 8.3.1
  • Complexity: L

9.4.3 Compensation flow

  • ID: 9.4.3
  • Title: Implement compensation on activation failure
  • Description: Wire the compensation chain, each consumed idempotently (inbox): a payment-service inbox consumer of subscription.activation-failed.v1 -> dispatch the existing RefundPaymentCommand -> payment.refunded.v1; and an order-service inbox consumer of payment.refunded.v1 -> CancelOrderCommand -> order.cancelled.v1. The saga-initiated cancel runs as a system actor and bypasses the customer ownership guard in CancelOrderCommandHandler (FR-12, analysis Section 9.2 compensation).
  • Business Purpose: Roll back a partially completed saga safely (FR-12).
  • Inputs: FR-12, event-catalog compensation sequence.
  • Outputs: Compensation consumers + events across the three services.
  • Acceptance Criteria:
  • A forced activation failure triggers a refund and moves the order to CANCELLED; the MSISDN is not left allocated; the flow is idempotent under redelivery.
  • Dependencies: 9.4.2, 8.5.5, 8.3.3
  • Complexity: L

Acceptance Criteria

Each subtask above carries its own objective, testable acceptance criteria. This feature is complete when every subtask's acceptance criteria are met.

Deliverables

  • Kafka consumer + inbox guard.
  • Order saga consumers + saga-state updates.
  • Compensation consumers + events across the three services.

Definition of Done

  • All subtasks (9.4.1, 9.4.2, 9.4.3) completed and their acceptance criteria verified.
  • All listed dependencies satisfied.
  • Build and tests green per the global conventions in ../README.md (Section 3).