backend-event-sourcing

Backend Event Sourcing

Purpose

Store state changes as an append-only sequence of events. Current state is derived by replaying events. Every event is immutable, auditable, and replayable.

Agent Protocol

Trigger

Exact user phrases: "event sourcing", "event store", "event stream", "event sourced", "rehydrate from events", "event replay", "projection rebuild", "append-only log", "event history", "event store pattern".

Input Context

• Domain aggregates and their state changes.
• Event store technology (PostgreSQL, EventStoreDB, DynamoDB).
• Projection requirements (read models, search indexes, materialized views).

Output Artifact

Event sourcing design as text. No file unless requested.

Response Format

Aggregate: {name}
Events: [{EventName, version, key fields}]
Current state: {derived by replay}
Projections: [{name, rebuild from}]

Completion Criteria

• All state changes are captured as events (not just some).
• Event store is append-only — no updates or deletes.
• Aggregate state can be rebuilt by replaying all events.
• Projections can be rebuilt from scratch by replaying all events.
• Events are immutable and carry version number.
• Event schema includes metadata (eventId, aggregateId, version, timestamp).
• Snapshot strategy defined for aggregates with many events.

Max Response Length

Per aggregate: 8 lines. Full design: 35 lines.

Architecture Decision Tree

Should I Use Event Sourcing?

Does the full history of changes matter?
  ├── Yes → Audit, compliance, dispute resolution → Event Sourcing candidate
  └── No → Is state derivation logic complex?
            ├── Yes → Event Sourcing simplifies temporal queries
            └── No → Are multiple projections of the same data needed?
                      ├── Yes → Event Sourcing enables flexible projections
                      └── No → Simple CRUD is sufficient — skip Event Sourcing

Event Store Selection

What infrastructure is already available?
  ├── PostgreSQL → Great event store (JSONB for event data, reliable, transactional)
  ├── EventStoreDB → Purpose-built for event sourcing (projections built-in)
  ├── DynamoDB → Serverless, single-table design for event streams
  └── Kafka → Durable log, but limited query capabilities for aggregate reconstruction