ซากาสำหรับเวิร์กโฟลว์ที่ทำงานเป็นเวลานาน

In an event-driven system, a single business outcome often requires many steps across multiple aggregates: place order, reserve stock, charge payment, schedule shipping. No single command handler owns that whole flow.

A Saga coordinates such a long-running workflow by listening to events and reacting with new commands. It is the glue that turns one event into the next step of a process.

• Reactive: a saga is triggered by events, not called directly.
• Stateless dispatcher: in NestJS, a CQRS saga maps an event stream to a command stream.
• Decoupled: handlers stay small; the saga owns orchestration.

In @nestjs/cqrs a saga is a class method decorated with @Saga() that receives an RxJS Observable of all published events and returns an Observable<ICommand>.

Whatever commands the returned stream emits are automatically dispatched through the CommandBus. The framework subscribes to your stream for you.

• Input type: Observable<any> (the global event stream).
• Output type: Observable<ICommand>.
• You shape the flow with RxJS operators like ofType, map, and mergeMap.

The global stream carries every published event. You almost always start a saga by filtering it down to the event types you care about with ofType(...EventClasses).

ofType is a custom RxJS operator shipped by @nestjs/cqrs. It filters by event constructor and, crucially, narrows the TypeScript type of downstream values to that event, so event.orderId type-checks.

• Pass one or more event classes: ofType(A, B).
• Always filter early — never map over the raw stream blindly.

The simplest saga is a one-to-one translation: each matching event produces exactly one command. map is the right operator here because it is synchronous and emits one value per input.

The pattern below reacts to a successful stock reservation by issuing a payment command — moving the workflow forward one step.

Use map when one event yields exactly one command synchronously. Use mergeMap (a.k.a. flatMap) when a single event must produce zero, one, or many commands, or when you need an inner Observable.

• mergeMap + of(...) lets you emit several commands per event.
• Return EMPTY to emit no command (skip).
• mergeMap runs inner streams concurrently — good for independent fan-out steps.

A saga class only runs if it is listed in the module's providers. NestJS's CqrsModule discovers every provider that exposes @Saga() methods and subscribes them to the event bus at bootstrap.

• Import CqrsModule.
• Add the saga class to providers alongside command and event handlers.
• No manual subscription, no onModuleInit wiring needed.

Most sagas need a correlation id — typically the aggregate id (e.g. orderId) — carried on every event so steps can be tied to the same process instance.

The CQRS saga itself is stateless: it just maps events to commands. The workflow state (which step completed, what was reserved) lives in the aggregate or a dedicated read model, updated by command handlers. The saga reacts to the events those handlers emit.

• Always include the correlation id in event payloads.
• Keep mutable progress in an aggregate/persistence layer, not in the saga.

Distributed workflows cannot use a single ACID transaction across services. Instead a saga guarantees consistency through compensating actions: if a later step fails, earlier successful steps are semantically undone.

If payment fails after stock was reserved, the saga reacts to PaymentFailedEvent by dispatching a ReleaseStockCommand. Compensation is forward-recovery, not a rollback — you issue a new command that reverses the effect.

A saga returns one long-lived Observable. If an error escapes that stream, RxJS terminates the subscription and your saga stops reacting to all future events — a silent, system-wide failure.

Protect the stream with catchError. Recover by mapping the failure to a compensating command and continuing, rather than letting the observable die.

• Never let exceptions propagate out of the saga pipe.
• Prefer per-event isolation: put catchError inside the inner mergeMap so one bad event doesn't kill the outer stream.

When events are delivered over a broker (Kafka, RabbitMQ) the saga may see the same event more than once after a redelivery or restart. Dispatching the same command twice can double-charge or double-ship.

The fix is not in the saga's RxJS plumbing but in the command handler: make it idempotent by recording a processed key (correlation id + step) and ignoring duplicates.

• Sagas should produce commands that are safe to retry.
• Track (orderId, step) in a dedup table or use the aggregate's version.
• Design for at-least-once, not exactly-once.

You can model the exact event-to-command mapping a saga performs using plain RxJS — no NestJS runtime required. This mirrors how ofType + map drive a workflow, and is great for reasoning about the flow in isolation.

You learned how to coordinate long-running workflows with RxJS-based CQRS sagas in NestJS:

• A @Saga() maps the global Observable of events to an Observable<ICommand> that the CommandBus dispatches automatically.
• Start every saga with ofType(...) to filter and type-narrow; use map for 1:1 and mergeMap for 0/1/many commands per event.
• Register sagas as providers in a CqrsModule — no manual subscription.
• Carry a correlation id on events; keep workflow state in aggregates/read models, not the saga.
• Achieve distributed consistency via compensating commands, not transactions.
• Guard the stream with catchError so one failure can't kill the saga, and make command handlers idempotent for at-least-once delivery.