Architect Event-Sourced Systems

Event Sourcing Architect is a skill that acts as an expert in event sourcing, CQRS and event-driven architecture patterns. It masters event store design, projection building, saga orchestration and eventual consistency patterns, and its description says to use it proactively for event-sourced systems, audit trail requirements, or complex domain modeling with temporal queries.

The listed capabilities are:

• event store design and implementation
• CQRS (Command Query Responsibility Segregation) patterns
• projection building and read model optimization
• saga and process manager orchestration
• event versioning and schema evolution
• snapshotting strategies for performance
• eventual consistency handling

Use it when you are building systems that need complete audit trails, implementing complex business workflows with compensating actions, or designing systems that need temporal queries such as "what was the state at time X". It also fits separating read and write models for performance, building event-driven microservices architectures, and implementing undo/redo or time-travel debugging.

Do not use it when the domain is simple and CRUD is sufficient, when you cannot support event store operations or projections, or when strong immediate consistency is required everywhere. Those are the situations where event sourcing adds cost without paying back.

The input is a domain or system you want to model with events. The skill lays out a seven-step approach for the design:

1. Identify aggregate boundaries and event streams.
2. Design events as immutable facts.
3. Implement command handlers and event application.
4. Build projections for query requirements.
5. Design saga and process managers for cross-aggregate workflows.
6. Implement snapshotting for long-lived aggregates.
7. Set up an event versioning strategy.

The output is guidance and design for those pieces: event streams and aggregates, immutable events, handlers, projections that serve your queries, sagas, snapshots and a versioning plan.

Two safety rules apply. Never mutate or delete committed events in production, and rebuild projections in staging before running the rebuild in production.

The best practices list reinforces the design: events are facts, so never delete or modify them; keep events small and focused; version events from day one; design for eventual consistency; use correlation IDs for tracing; implement idempotent event handlers; and plan for projection rebuilding. It also recommends durable execution for process managers and sagas, noting that frameworks like DBOS persist workflow state automatically, which makes cross-aggregate orchestration resilient to crashes.

The skill lists related skills that it works well with: saga-orchestration, architecture-patterns and the dbos family of skills. DBOS is mentioned as an example of a durable execution framework for workflow state.

Software architects and backend engineers designing auditable, event-driven systems, and teams that need to reason about history, projections and long-running workflows. The metadata shows a community source and a critical risk level, and the Limitations section says to use the skill only when the task clearly matches its scope, not to treat output as a substitute for environment-specific validation, testing or expert review, and to stop and ask when inputs, permissions, safety boundaries or success criteria are missing.