domains / families / software-engineering / event-sourcing-architect

event-sourcing-architect

combined

Expert in event sourcing, CQRS, and event-driven architecture patterns. Masters event store design, projection building, saga orchestration, and eventual consistency patterns. Use PROACTIVELY for event-sourced systems, audit trails, or temporal queries. Expert in event sourcing, CQRS, and event-driven architecture patterns. Masters event store design, projection building, saga orchestration, and eventual consistency patterns. Use PROACTIVELY for event-sourced systems, audit trail requirements, or complex domain modeling with temporal queries.

When to use

• Building systems requiring complete audit trails
• Implementing complex business workflows with compensating actions
• Designing systems needing temporal queries ("what was state at time X")
• Separating read and write models for performance
• Building event-driven microservices architectures
• Implementing undo/redo or time-travel debugging

When not to use

• The domain is simple and CRUD is sufficient
• You cannot support event store operations or projections
• Strong immediate consistency is required everywhere
• Record actual aggregate concurrency/ordering guarantees, idempotency keys and projection lag; sagas compensate business effects but are not automatic rollback of every external action. Replay must suppress real notifications/payments and o…
• Do not introduce event sourcing/CQRS where a simpler design meets the task; retain policy and deletion boundaries, and test projection rebuild before claiming audit completeness.
• Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
• Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.

Skill page

Conflict

The two copies share the same core procedure (aggregate boundaries, immutable events, projections, sagas, snapshotting, versioning) and most best practices. However, the sickn33 copy adds material constraints and steps the rmyndharis copy lacks: durable execution frameworks for sagas, a Limitations section covering concurrency/idempotency/projection lag and replay side-effects, and a Related Skills section. The copies also disagree on the safety rule for deleting committed events: rmyndharis states they must never be deleted, while sickn33 allows deliberate redaction/key-deletion for privacy/legal requirements. Crowning one copy would hide the more nuanced deletion policy and the additional operational constraints.