ytu.los 1.0.1

Local Orchestrator Saga (LOS)

Overview

Distributed transaction management is a fundamental challenge in microservice architectures, where traditional ACID transactions are not feasible across service boundaries. The Saga pattern is commonly adopted to address this challenge by decomposing a global transaction into a sequence of local transactions with compensating actions.

This work proposes an alternative Saga execution model called Local Orchestrator Saga (LOS).
The LOS model aims to combine the advantages of both Orchestrated Saga and Choreographed Saga approaches, while mitigating their inherent limitations.

The primary objective of LOS is to reduce centralized coordination dependency without sacrificing process visibility, control, and deterministic compensation handling.

Motivation

Existing Saga approaches exhibit the following trade-offs:

• Orchestrated Saga

  • Provides strong process control and observability
  • Introduces a centralized orchestrator, increasing coupling and Single Point of Failure (SPOF) risk

• Choreographed Saga

  • Eliminates centralized coordination
  • Suffers from limited global visibility, complex rollback coordination, and implicit process flow

The LOS model is designed to bridge this gap by introducing localized orchestration, where coordination logic is embedded only within the service that initiates the business process.

Core Concept: Local Orchestration

In the LOS approach, the microservice that initiates a distributed workflow includes a lightweight orchestration component called the Local Orchestration Process (LOP).

Key characteristics of LOP include:

• It operates inside the initiating service
• It coordinates only the steps relevant to the initiated business process
• It does not act as a system-wide orchestrator
• It does not require other services to embed orchestration logic

As a result, orchestration responsibility is localized rather than centralized.

Process-Specific Control

The Local Orchestration Process manages the workflow in a process-scoped manner:

• The execution sequence is explicitly defined (e.g., via BPMN or a domain-specific language)
• Downstream services remain unaware of the global process
• Services only execute local actions and return execution results

This design preserves service autonomy while maintaining explicit process control at the workflow entry point.

Execution Model

In a normal execution scenario:

1. The initiating service performs its local transaction
2. The embedded Local Orchestration Process triggers subsequent workflow steps
3. Each participating service executes its local transaction independently
4. Execution results are reported back to the initiating service
5. The workflow is completed once all steps succeed

This execution model ensures ordered, observable, and deterministic workflow progression without global coordination.

Compensation Handling

Compensation in the LOS model is also handled locally by the initiating service.

In the event of a failure:

1. The Local Orchestration Process detects the failure
2. Previously completed steps are identified
3. Corresponding compensating actions are triggered in reverse order
4. The workflow is terminated in a consistent and well-defined state

Compensation logic is explicitly defined as part of the orchestration flow, enabling deterministic rollback behavior without relying on implicit event propagation.

Observability and State Management

LOS emphasizes explicit state tracking:

• Each workflow step�s state is recorded locally
• Execution progress and failures are observable
• Compensation steps are traceable and auditable

Compared to choreography-based approaches, this significantly simplifies monitoring, debugging, and failure analysis.

Benefits of the LOS Model

• Eliminates the need for a centralized orchestrator
• Reduces Single Point of Failure risk
• Preserves explicit process control
• Simplifies compensation coordination
• Improves observability and traceability
• Maintains service independence and loose coupling

Conclusion

The Local Orchestrator Saga (LOS) model introduces a hybrid Saga execution strategy that balances decentralization with control. By embedding orchestration logic only at the process entry point, LOS avoids the pitfalls of both centralized orchestration and fully distributed choreography.

This approach provides a practical and scalable alternative for managing distributed transactions in modern microservice-based systems.