Architecture
An event sourcing architecture diagram where all state changes are stored as an immutable sequence of domain events, with read projections built from the event stream and snapshot optimization for fast aggregate loading. This template shows how event sourcing eliminates data loss by preserving the complete history of every state transition. Critical for systems requiring full audit trails, temporal queries, and event replay capabilities.
Full FlowZap Code
Command { # Command Side
n1: circle label:"User Command"
n2: rectangle label:"Validate Command"
n3: rectangle label:"Load Aggregate"
n4: rectangle label:"Apply Business Rules"
n5: rectangle label:"Emit Domain Events"
n1.handle(right) -> n2.handle(left)
n2.handle(right) -> n3.handle(left) [label="Valid"]
n3.handle(right) -> n4.handle(left) [label="Current State"]
n4.handle(right) -> n5.handle(left) [label="State Change"]
n5.handle(bottom) -> EventStore.n6.handle(top) [label="Append"]
}
EventStore { # Event Store
n6: rectangle label:"Append Event to Stream"
n7: rectangle label:"Assign Sequence Number"
n8: rectangle label:"Persist Immutable Event"
n9: rectangle label:"Publish to Projections"
n10: rectangle label:"Snapshot Manager"
n6.handle(right) -> n7.handle(left)
n7.handle(right) -> n8.handle(left) [label="Write-Ahead Log"]
n8.handle(right) -> n9.handle(left) [label="Notify"]
n9.handle(bottom) -> Projections.n11.handle(top) [label="Event Stream"]
n10.handle(top) -> Command.n3.handle(bottom) [label="Fast Load"]
}
Projections { # Read Projections
n11: rectangle label:"Event Handler"
n12: rectangle label:"Build Read Model"
n13: rectangle label:"Update Materialized View"
n14: rectangle label:"Serve Query"
n15: circle label:"Query Response"
n11.handle(right) -> n12.handle(left) [label="Transform"]
n12.handle(right) -> n13.handle(left) [label="Upsert"]
n13.handle(right) -> n14.handle(left) [label="Ready"]
n14.handle(right) -> n15.handle(left)
}
Replay { # Event Replay
n16: rectangle label:"Replay from Offset"
n17: rectangle label:"Rebuild Projection"
n18: rectangle label:"Verify Consistency"
n16.handle(right) -> n17.handle(left) [label="Historical Events"]
n17.handle(right) -> n18.handle(left) [label="Rebuilt"]
n18.handle(top) -> Projections.n13.handle(bottom) [label="Replace View"]
}
Why This Workflow?
Traditional CRUD systems overwrite state on every update, losing the history of how the current state was reached. Event sourcing preserves every state change as an immutable event, enabling full audit trails, temporal queries, debugging by replaying events, and the ability to rebuild read models from scratch.
How It Works
- Step 1: A user command is validated against the current aggregate state.
- Step 2: The aggregate applies business rules and emits one or more domain events.
- Step 3: Events are appended to the event store with a sequence number (never updated or deleted).
- Step 4: Read projections consume the event stream and build materialized views.
- Step 5: Snapshots are periodically created to speed up aggregate loading.
- Step 6: Event replay can rebuild any projection from any point in time.
Alternatives
Traditional CRUD with audit tables captures changes but cannot rebuild state. Change Data Capture provides similar benefits without changing application code. This template shows the full event sourcing architecture with projections and replay.
Key Facts
| Template Name | Event-Driven Event Sourcing Architecture |
| Category | Architecture |
| Steps | 6 workflow steps |
| Format | FlowZap Code (.fz file) |
Related templates
Architecture
A CQRS architecture diagram combining separate command and query APIs with an event bus for asynchronous read model synchronization, including projectors that build denormalized views from domain events. This template demonstrates the full CQRS+ES stack where writes go through domain validation and reads are served from optimized materialized views. Ideal for high-throughput systems where read and write workloads have fundamentally different scaling requirements.
Architecture
A DDD bounded contexts architecture diagram with Order, Customer, Shipping, and Billing contexts connected through an anti-corruption layer, shared kernel, and context map defining integration relationships. This template visualizes the strategic DDD patterns for decomposing complex domains into autonomous bounded contexts that communicate through well-defined integration events. Critical for architects applying Domain-Driven Design to large-scale enterprise systems.
patterns
Event sourcing pattern with event capture, event store persistence, aggregate reconstruction, snapshot optimization, and temporal state queries.
Architecture
A microservices API gateway architecture diagram showing request routing, JWT authentication, rate limiting, service discovery, and response aggregation across distributed backend services. This template models the entry point for all client traffic in a microservices ecosystem, enforcing security policies before requests reach internal services. Ideal for platform engineers designing scalable API infrastructure with centralized cross-cutting concerns.
Architecture
A service mesh architecture diagram with Istio or Linkerd sidecar proxies handling mTLS encryption, traffic policies, circuit breaking, and distributed tracing across microservices. This template visualizes how a service mesh abstracts networking concerns away from application code, enabling zero-trust communication between services. Essential for teams adopting service mesh infrastructure to improve observability and security.
Architecture
A database-per-service architecture diagram where each microservice owns its dedicated data store, with event-driven synchronization via Kafka for cross-service data consistency. This template demonstrates the core microservices data isolation principle, showing how PostgreSQL and MongoDB coexist in a polyglot persistence strategy. Critical for architects enforcing service autonomy while maintaining eventual consistency.