Evento Framework
  • Introduction
  • Architecture Overview
    • Distributed Systems & Microservices
    • Recative Manifesto & Reactive Principles
    • State-of-the-art Patterns
      • DDD (Domain Driven Design)
      • CQRS (Command Query Responsability Separation)
      • Event Sourcing
      • Messaging
      • Saga
  • GETTING STARTED
    • Quick Start
    • TodoList - RECQ Tutorial
      • Problem Description and Requirement Gathering
      • RECQ Payload Design
      • RECQ Components Design
      • Set up your Development Environment
      • RECQ Payload Evento Implementation
        • Domain Commands
        • Domain Events
        • Views
        • Queries
      • RECQ Components Evento Implementation with Spring Data
        • TodoListAggregate
        • TodoList Model with Spring Data
        • TodoListProjector
        • TodoListProjection
        • TodoList Invoker
      • Expose the RECQ architecture with Spring Web
      • Test Your App
    • Extend TodoList - Handle Complexity Tutorial
      • Unique identifier generation
      • Extends behaviors with Observer and Services
      • Cross Domain Consistency with Sagas
      • Handle Real time data updates with MQTT and Save-Notify Pattern
  • RECQ Patterns
    • RECQ Patterns
    • RECQ System Pattern
      • Component
      • Message Gateway
      • System State Store
    • RECQ Communication Pattern
      • Component to Component
      • Component to System State Store
      • System State Store to Component
    • RECQ Component Pattern
      • Aggregate
      • Projector
      • Projection
      • Service
      • Invoker
      • Saga
      • Observer
  • Evento Framework
    • Evento Framework Introcution
    • Payload and Messages
      • Command
        • Domain Command
        • Service Command
      • Event
        • Domain and Service Event
      • Query and View
    • @Component
      • @Aggregate
        • Aggregate State
        • @AggregateCommandHandler
        • @EventSourcingHandler
      • @Projector
        • Projector @EventHandler
      • @Projection
        • @QueryHandler
      • @Service
        • @CommandHandler
      • @Invoker
      • @Saga
        • SagaState
        • @SagaEventHandler
      • @Observer
    • Dead Event Queues
    • EventoBundle
      • EventoServerMessageBusConfiguration
      • ConsumerStateStore
        • InMemoryConsumerStateStore
        • PostgresConsumerStateStore
        • MysqlConsumerStateStore
      • Context
      • TracingAgend and @Track
        • SentryTracingAgent
      • Autoscaling Protocol
        • ThreadCountAutoscalingProtocol
      • Injector and @Component
  • Evento Server
    • Evento Server Introduction
    • SetUp Evento Server
      • Advanced Options
      • Evento Event Store Modes: APES and CPES
    • Evento Server Cluster
    • Bundle Deploy Script
  • EVENTO GUI
    • Explore RECQ Systems Visually
    • GUI Auth
    • Payload Catalog
    • Component Catalog
    • Bundle Catalog
    • Cluster Status (Experimental)
    • Flows
      • Performance Evaluation
    • Application Graph
    • System State Store
  • Evento CLI
    • Evento CLI Introduction
    • Update Version
    • Publish
Powered by GitBook
On this page
  1. RECQ Patterns
  2. RECQ Component Pattern

Saga

A Saga component implements the Saga Pattern to manage distributed transactions.

PreviousInvokerNextObserver

Last updated 1 year ago

Sagas are specialized components responsible for coordinating and ensuring consistency across distributed transactions that involve multiple Aggregates or Services. Unlike Projectors that focus on materializing read models, Sagas modify the system state itself.

Saga Event Handler: The Heart of Transaction Orchestration

Sagas expose a single key method – the SagaEventHandler. This method takes centre stage when a relevant Event (related to the Saga's workflow) arrives:

  • Current State and Event as Inputs: The SagaEventHandler receives both the current state of the Saga and the incoming Event as inputs.

  • State Update and Command/Query Execution: Based on the current state and the received Event, the Saga can:

    • Update its internal state to reflect the progress of the workflow.

    • Send Command-type messages to relevant Aggregates or Services to trigger state changes within those components.

    • Send Query-type messages to retrieve information from Aggregates or Services to support its decision-making process.

Local State with Shared Persistence: Balancing Consistency and Performance

Similar to Aggregates, Sagas maintain an internal state that tracks the progress of the ongoing workflow. However, unlike Aggregates whose state resides in the globally accessible System State Store (SSS), Saga state is persisted in a Saga Shared Consumer State Store, which follows the Shared Database pattern.

  • Shared Consumer State Store with Local Focus:

    • This dedicated state store manages Saga instances of a specific type.

    • It provides methods to save and retrieve the state of individual Saga instances.

  • Consistency Similar to Projectors:

    • The implementation of the Saga Shared Consumer State Store shares similarities with the Projector Consumer State Store in terms of consistency.

    • However, the details of state retrieval and synchronization across instances are optimized for Saga-specific needs.

Scalability Constraints: Sequential Processing for Guaranteed Consistency

Sagas, like Projectors, exhibit limitations in raw processing power due to their focus on consistent cross-component workflows. Their SagaEventHandler typically processes events in a sequential manner to ensure the correct order of operations within the Saga workflow. This sequential processing can limit scalability for high-volume workloads involving frequent Sagas.

Relationship with Projectors: Addressing Different Needs

Both Projectors and Sagas play critical roles in RECQ architectures, but they cater to distinct needs:

  • Projectors: Focus on materializing optimized read models from event streams for efficient query processing.

  • Sagas: Orchestrate complex workflows across multiple components while ensuring consistency within those workflows.

Sagas in Action: Ensuring Consistency in Complex Workflows

Sagas are invaluable for managing scenarios where a single action might trigger a sequence of interactions across multiple Aggregates or Services. By orchestrating these interactions and ensuring consistent state changes, Sagas guarantee the overall integrity of distributed transactions within your RECQ application. While scalability constraints might exist, Sagas offer a powerful mechanism for handling complex workflows that require strong consistency across multiple components.

Capability

Can handle Command Messages

No

Can handle Query Messages

No

Can handle Events

Yes

Can send Command Messages

No

Can Send Query Messages

Yes

State type

Component

CAP Properties

CP

RECQ Big Picture
Saga Structure