$npx -y skills add wshobson/agents --skill event-store-designDesign and implement event stores for event-sourced systems. Use when building event sourcing infrastructure, choosing event store technologies, or implementing event persistence patterns.
| 1 | # Event Store Design |
| 2 | |
| 3 | Comprehensive guide to designing event stores for event-sourced applications. |
| 4 | |
| 5 | ## When to Use This Skill |
| 6 | |
| 7 | - Designing event sourcing infrastructure |
| 8 | - Choosing between event store technologies |
| 9 | - Implementing custom event stores |
| 10 | - Optimizing event storage and retrieval |
| 11 | - Setting up event store schemas |
| 12 | - Planning for event store scaling |
| 13 | |
| 14 | ## Core Concepts |
| 15 | |
| 16 | ### 1. Event Store Architecture |
| 17 | |
| 18 | ``` |
| 19 | ┌─────────────────────────────────────────────────────┐ |
| 20 | │ Event Store │ |
| 21 | ├─────────────────────────────────────────────────────┤ |
| 22 | │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ |
| 23 | │ │ Stream 1 │ │ Stream 2 │ │ Stream 3 │ │ |
| 24 | │ │ (Aggregate) │ │ (Aggregate) │ │ (Aggregate) │ │ |
| 25 | │ ├─────────────┤ ├─────────────┤ ├─────────────┤ │ |
| 26 | │ │ Event 1 │ │ Event 1 │ │ Event 1 │ │ |
| 27 | │ │ Event 2 │ │ Event 2 │ │ Event 2 │ │ |
| 28 | │ │ Event 3 │ │ ... │ │ Event 3 │ │ |
| 29 | │ │ ... │ │ │ │ Event 4 │ │ |
| 30 | │ └─────────────┘ └─────────────┘ └─────────────┘ │ |
| 31 | ├─────────────────────────────────────────────────────┤ |
| 32 | │ Global Position: 1 → 2 → 3 → 4 → 5 → 6 → ... │ |
| 33 | └─────────────────────────────────────────────────────┘ |
| 34 | ``` |
| 35 | |
| 36 | ### 2. Event Store Requirements |
| 37 | |
| 38 | | Requirement | Description | |
| 39 | | ----------------- | ---------------------------------- | |
| 40 | | **Append-only** | Events are immutable, only appends | |
| 41 | | **Ordered** | Per-stream and global ordering | |
| 42 | | **Versioned** | Optimistic concurrency control | |
| 43 | | **Subscriptions** | Real-time event notifications | |
| 44 | | **Idempotent** | Handle duplicate writes safely | |
| 45 | |
| 46 | ## Technology Comparison |
| 47 | |
| 48 | | Technology | Best For | Limitations | |
| 49 | | ---------------- | ------------------------- | -------------------------------- | |
| 50 | | **EventStoreDB** | Pure event sourcing | Single-purpose | |
| 51 | | **PostgreSQL** | Existing Postgres stack | Manual implementation | |
| 52 | | **Kafka** | High-throughput streaming | Not ideal for per-stream queries | |
| 53 | | **DynamoDB** | Serverless, AWS-native | Query limitations | |
| 54 | | **Marten** | .NET ecosystems | .NET specific | |
| 55 | |
| 56 | ## Templates and detailed worked examples |
| 57 | |
| 58 | Full template library and detailed worked examples live in `references/details.md`. Read that file when you need the concrete templates. |
| 59 | |
| 60 | ## Best Practices |
| 61 | |
| 62 | ### Do's |
| 63 | |
| 64 | - **Use stream IDs that include aggregate type** - `Order-{uuid}` |
| 65 | - **Include correlation/causation IDs** - For tracing |
| 66 | - **Version events from day one** - Plan for schema evolution |
| 67 | - **Implement idempotency** - Use event IDs for deduplication |
| 68 | - **Index appropriately** - For your query patterns |
| 69 | |
| 70 | ### Don'ts |
| 71 | |
| 72 | - **Don't update or delete events** - They're immutable facts |
| 73 | - **Don't store large payloads** - Keep events small |
| 74 | - **Don't skip optimistic concurrency** - Prevents data corruption |
| 75 | - **Don't ignore backpressure** - Handle slow consumers |