event-sourcing
Files
SKILL.mdagentsreferences
Install
Install only this skill with npx skills
npx skills add alisonaquinas/llm-software-design --skill 'event-sourcing' -g -y
Install the containing skill bundle
/plugin install software-design@llm-skills
This skill is bundled inside software-design. Use
npx skills when you only want this skill, or install the bundle once to make every included skill available through the plugin marketplace flow. Browse the full skill bundle repository at github.com/alisonaquinas/llm-software-design.Invoke
Invoke this skill after installation
/software-design:event-sourcing
SKILL.md
name: event-sourcing description: > design systems that persist state as ordered domain events and derive current views through replay or projections. use when the user asks about event sourcing, append-only event stores, optimistic concurrency, stream design, snapshots, projections, cqrs, audit trails, or how to implement event-sourced patterns in sql, postgresql, sql server, mysql, mongodb, cosmos db, or dedicated event stores.
Event Sourcing
Use this skill to model domain history as append-only events, choose stream boundaries, and design reliable projections and replay workflows.
Intent Router
| Need | Load |
|---|---|
| event-sourcing fundamentals, stream design, concurrency, snapshots, and caveats | references/event-sourcing-guide.md |
| database-specific patterns for sql, postgresql, sql server, mysql, mongodb, cosmos db, and dedicated event stores | references/database-examples.md |
Quick Start
- Start from business facts that must be preserved over time.
- Choose stream boundaries from aggregate consistency rules, not from table convenience.
- Treat append-only writes and optimistic concurrency as core design decisions.
- Keep read models disposable and rebuildable from the event log.
- Use snapshots and projection checkpoints only when replay cost justifies them.
Workflow
- Identify the domain events that represent meaningful business facts.
- Define the stream or subject key, event ordering rules, and expected concurrency model.
- Specify event envelope fields: id, stream key, version, type, timestamp, payload, metadata, and causation/correlation identifiers where needed.
- Design write rules around optimistic concurrency and idempotency.
- Design projections and materialized views around actual read needs.
- Add snapshotting only after measuring long-stream replay or hot-aggregate cost.
- Review privacy, retention, schema evolution, and operational replay needs before production rollout.
Outputs to Prefer
- name events as business facts in past tense
- explain stream boundaries, ordering rules, and concurrency expectations
- separate write model, event log, and read model concerns clearly
- show how rebuilding, replay, and backfilling work operationally
- recommend ordinary CRUD when event sourcing adds more complexity than value
Common Requests
Design an event-sourced model for this domain, including events, stream keys, optimistic concurrency, and projections.
Review this schema or architecture for event-sourcing pitfalls, including event naming, snapshot misuse, or projection coupling.
Show event-sourcing patterns for PostgreSQL, SQL Server, MySQL, MongoDB, Cosmos DB, or a dedicated event store.
Verification and Next Steps
- verify append ordering, optimistic concurrency, replay, and projection rebuild behavior with one concrete stream
- show the idempotency or duplicate-delivery rule for writes and projections
- name the retention, privacy, or schema-evolution concern that needs explicit governance before rollout
Safety Notes
- do not choose event sourcing for a simple CRUD system without a real need for history, replay, or complex temporal reasoning
- avoid events that merely mirror row mutations without business meaning
- avoid coupling projections so tightly that rebuilding becomes dangerous or impossible
- avoid storing sensitive mutable personal data in immutable events unless governance and redaction strategy are explicit