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 Communication Pattern

System State Store to Component

Asynchronous Event Distribution with Pub/Sub and Consumer State Stores

PreviousComponent to System State StoreNextRECQ Component Pattern

Last updated 1 year ago

In a RECQ architecture, the System State Store (SSS) utilizes a pub/sub (publish/subscribe) protocol for distributing information about state changes to interested components. This approach decouples the SSS from individual components and enables efficient event delivery.

The Role of (CSS):

  • Persistent Event Consumption Progress: CSS modules are introduced to maintain the state of event consumption by individual components. This persistence allows for:

    • Retry Logic: If a component fails to process an event, the CSS can track the consumed events and enable retries upon recovery.

    • Orderly Progress: The CSS ensures that events are processed in the correct order, even in the face of failures or restarts.

    • Consistency: By tracking consumption progress, the CSS helps maintain consistency between the state reflected in the component and the actual state stored in the SSS.

Communication Protocol:

  • Pub/Sub with the SSS:

    • The SSS acts as the publisher in the pub/sub model.

    • Whenever a new event is persisted in the SSS (e.g., after a state change), the SSS publishes the event message to a topic.

    • Topics are named channels that categorize events based on their type or purpose.

  • Subscription by Components:

    • Components interested in receiving specific events subscribe to relevant topics managed by the SSS.

    • Subscription allows components to filter the events they receive, ensuring they only process the data they need.

  • Consumer State Stores:

    • Components retrieve their specific consumption progress information from their associated CSS.

    • This information allows components to identify the last successfully processed event and avoid duplicate processing.

    • The CSS can also be used to store additional context related to event consumption by the component.

Benefits of Pub/Sub and Consumer State Stores:

  • Scalability: The pub/sub pattern decouples the SSS from individual components, allowing for independent scaling of both components and the SSS.

  • Flexibility: Components can subscribe to specific topics, receiving only the events relevant to their functionality.

  • Resilience: Consumer State Stores enable retry logic and ensure orderly event processing even in the face of failures.

Consumer State Stores
System STate Store to Component Communication