Is every slow database query a saga?

No. Duration and a particular coordination pattern are different concepts.

Can compensation simply restore the original stored value?

Not safely in every case; intervening work may need to be preserved.

Must every saga have one central controller?

No. Orchestration uses a controller, while choreography coordinates through participating services' events.

AI Glossary / Data engineering and architecture / Advanced

Long-running transaction

Definition

A long-running transaction is an extended unit of work whose completion may span multiple steps, services or waiting periods. The phrase can also describe an ordinary database transaction that remains active unusually long. In workflow discussions, it often refers to coordinating separately committed operations, using recovery or compensation when the overall activity cannot finish. This entry emphasizes that workflow meaning while recognizing the overlap with long-lived transaction.

What it means

An application may need several systems to contribute to one business outcome. Completing the first step does not prove that the whole request has succeeded. For example, reserving equipment and arranging delivery are related actions even when different services manage them. A long-running workflow needs an explicit account of its progress and what happens when later work fails. It should not leave users to infer completion from one successful component. The challenge is coordinating an extended outcome without assuming that every participating system shares one continuously open database transaction.

How it works

A common approach is a saga: local transactions complete individual steps, while coordination determines what happens next. Microsoft describes both orchestration through a controller and choreography through exchanged events. Failure can require compensating previously completed actions, and repeated delivery requires careful handling of duplicate work. The original Sagas research distinguishes this approach from a single atomic outer transaction: intermediate effects can be observed, and compensation corrects meaning rather than necessarily restoring the exact old database state. Consequently, the complete design must address partial outcomes, concurrent changes and failures of the recovery actions themselves.

Three practical examples

An equipment-hire workflow coordinates a reservation and a delivery request, with explicit cancellation behavior if delivery cannot be arranged.
A document-processing service records progress across extraction, external analysis and result publication so an interrupted request can be understood and recovered.
A multi-service account setup tracks which components are complete and which require retry or correction before the account is declared ready.

Think of it this way

Think of organizing an event through several suppliers. Confirming one supplier does not confirm the event. If a later requirement fails, earlier arrangements may need cancellation or adjustment, and some effects may already have occurred. The coordination plan therefore needs both a route to completion and a way to handle partial progress. It is more than a list of independent bookings.

Worked example

Consider an original inventory illustration with ten available units. Workflow A reserves two units, leaving eight. An unrelated workflow B then reserves three, leaving five. A's next step fails, and its defined compensation releases A's two-unit reservation. Availability becomes seven: 10 - 2 - 3 + 2 = 7. Simply restoring the count to ten would incorrectly erase B's valid reservation. The example assumes both reservations and A's release succeed and that no other changes occur. It demonstrates why compensation must respect intervening work. It does not specify a full concurrency protocol, and repeating A's release must not add another two units; the implementation needs to recognize that the same reservation has already been released.

Illustrative case study

In a fictional equipment-rental service, a request reserves equipment before arranging transport. A test creates a transport failure after the reservation has committed. The team verifies that cancellation releases only the affected reservation and leaves other customers' allocations intact. A second test delivers the cancellation request twice, revealing the need to identify completed compensation. A third makes the release temporarily unavailable, so the workflow remains visibly awaiting recovery rather than falsely reporting a clean cancellation. The scenario illustrates the operational detail behind an extended transaction. It is not evidence that every rental process can use the same steps or recovery rules.

Common misconceptions and mistakes

Long-running does not identify one universal protocol or a fixed number of seconds. The surrounding context must establish whether it means an open database transaction or a coordinated business activity. Another mistake is describing compensation as if it made intermediate effects invisible. Other work may already have observed them. A coordinator also does not make failures disappear; its progress and decisions need dependable handling. Finally, a timeout establishes uncertainty about a response, not necessarily proof that the remote action never happened. Retrying without resolving that distinction can repeat an effect.

Business use

Use the concept to ask what a customer should see while a multi-step request is pending, partly complete or recovering. Define the point at which the organization can honestly report success. For each earlier committed step, establish whether later failure requires correction, retry or a different resolution. AI-based workflows deserve the same treatment when generation, approval and publication are separate actions. A successful model response is only one component if the promised outcome includes saving or publishing it. Operational reports should distinguish completed outcomes from work that merely started or still needs recovery.

Check your understanding

What was availability after both toy reservations?

Answer: Five units.

What was it after A's compensation?

Answer: Seven.

Why would resetting to ten be wrong?

Answer: B's three-unit reservation remained valid.

Why did the fictional service keep one cancellation pending?

Answer: Its corrective action had not yet completed, so a final canceled state would have overstated the result.

Related terms

Long-lived transaction
Orchestration
Choreography
saga
compensating transaction
idempotency

Learn next

Sketch a three-step fictional workflow and label the point at which each step commits. Introduce a failure after step two and describe the required corrections. Then introduce an unrelated concurrent change and a duplicate recovery message. Explain how the intended final state preserves the unrelated work and avoids repeating the correction.

Sources

Microsoft Azure Architecture Center, Saga Distributed Transactions Pattern: https://learn.microsoft.com/en-us/azure/architecture/patterns/saga Hector Garcia-Molina and Kenneth Salem, Sagas: https://www.cs.cornell.edu/andru/cs711/2002fa/reading/sagas.pdf The inventory arithmetic, event-organizing analogy and rental-service case are original educational illustrations. The entry uses the workflow sense of long-running transaction, acknowledges broader usage and does not equate compensation with the isolation of one ordinary atomic transaction.

Previous: Long-range dependence Next: Long Short-Term Memory