Event Sourcing

All state changes are stored as a sequence of immutable events in an append-only log. Events are never modified or deleted; corrections are made by appending compensating events. This provides a complete audit trail of every decision made by the orchestration middleware, from task assignments to agent state transitions. The log serves as the system of record, enabling full historical reconstruction of fleet activity for compliance and debugging.

The current state of any entity—such as an agent's position, a task's status, or a zone's occupancy—is derived by replaying all events in sequence from the beginning of time. This eliminates the need for separate state databases and ensures that any materialized view can be rebuilt from the event stream. Key benefits include:

• Temporal queries: Reconstruct fleet state at any point in time
• Debugging: Replay events to reproduce and diagnose failures
• Migration: Rebuild projections with new business logic without data loss

Event Sourcing is commonly paired with Command Query Responsibility Segregation (CQRS) , separating write operations (commands that produce events) from read operations (queries against materialized views). In fleet orchestration, this means:

• Command side: Validates and processes commands like AssignTask or RerouteAgent, producing events
• Query side: Maintains optimized read models for dashboards, state estimation, and real-time monitoring This separation allows independent scaling of read and write workloads, critical for high-throughput fleet operations.

Events serve as the primary communication mechanism between microservices in the orchestration platform. When a new event is persisted, it is published to subscribers via the Message Bus. Downstream services—such as the Fleet State Estimation engine, Deadlock Detection module, or Human-in-the-Loop Interface—react to events asynchronously. This decouples producers from consumers, enabling:

• Loose coupling between orchestration components
• Independent deployability of services
• Natural integration with the Saga Pattern for distributed transactions

Replaying thousands of events to reconstruct state becomes computationally expensive over time. Snapshots capture the aggregate state at a specific event version, allowing replay to start from the snapshot rather than from event zero. The orchestration middleware periodically creates snapshots for each aggregate—such as an agent's full state or a task's lifecycle—balancing replay performance with storage efficiency. Snapshots are purely an optimization; they can be discarded and regenerated from the event log at any time.

As fleet orchestration requirements evolve, event schemas must change without breaking existing event streams. Strategies include:

• Upcasting: Transform old events to new schemas during replay using versioned mappers
• Schema Registry integration: Validate event compatibility at publish time, preventing breaking changes
• Weakly-typed payloads: Store event data in flexible formats like JSON with semantic versioning This ensures that events recorded months ago remain replayable even as the Unified Control API and agent drivers evolve.

An append-only, immutable database that persists the complete sequence of domain events for each aggregate. Unlike traditional databases that store current state, the event store is the system of record.

• Characteristics: Append-only, immutable, ordered by stream position
• Common implementations: EventStoreDB, Axon Server, Kafka with compacted topics
• Fleet context: Stores every robot movement, task assignment, and state transition as a permanent audit log

A consistency model where replicas of data are allowed to diverge temporarily, with the guarantee that they will converge to the same state once all pending events are processed. This is the natural consistency model of event-driven systems.

• Trade-off: Sacrifices immediate consistency for availability and partition tolerance (AP in CAP theorem)
• Fleet impact: A robot's reported position may lag behind its actual position by milliseconds; acceptable for most orchestration decisions
• Mitigation: Use strong consistency for safety-critical commands like emergency stops

A lightweight, immutable record of something that has already happened within the business domain. Named in past tense, domain events carry intent and context, not just data changes.

• Naming convention: RobotAssignedToTask, PickCompleted, BatteryLevelCritical
• Structure: Includes event type, aggregate ID, timestamp, causation ID, and payload
• Distinction: Unlike integration events, domain events are scoped to a bounded context and carry full business semantics

The process of reconstituting an aggregate's current state by sequentially applying all stored events from the beginning of its event stream. This is the core mechanism that makes Event Sourcing auditable and debuggable.

• Use cases: Rebuilding projections, forensic analysis of fleet incidents, testing new business logic against historical data
• Performance: Use snapshots to avoid replaying the entire stream from genesis
• Fleet scenario: Replay a warehouse shift to understand how a deadlock situation developed

A pre-computed, query-optimized representation of event data built by projecting events into a denormalized structure. These views are the read side of a CQRS system and are disposable—they can be rebuilt from the event store at any time.

• Examples: Current fleet dashboard, agent utilization report, task completion history
• Rebuild strategy: Drop and recreate from event stream; enables schema evolution without migration scripts
• Technology: Often implemented with Kafka Streams, ksqlDB, or dedicated projection workers