Event Sourcing: When It Helped, When It Hurt

Event sourcing came up during a design review for our order system. We needed complete audit trails and the ability to replay state for debugging.

sequenceDiagram
  participant C as Command
  participant A as Aggregate
  participant E as Event Store
  participant P as Projections

  C->>A: PlaceOrder
  A->>E: OrderPlaced
  A->>E: PaymentReserved
  E->>P: Update Read Model

What Worked

• Audit trail: Every state change is immutable and timestamped
• Debugging: Replay events to reproduce any historical state
• Temporal queries: “What did this order look like at 3 PM yesterday?”

What Hurt

• Projection lag: Read models 100-500ms behind writes
• Schema evolution: Event versioning is hard. We spent 3 sprints on migration strategy
• Team onboarding: Steep learning curve for developers used to CRUD

Decision

We kept event sourcing for the order aggregate only. Everything else stays traditional CRUD with audit logs. Pragmatic polyglot persistence.

Recommendation

Use event sourcing when:

• Audit requirements are regulatory, not nice-to-have
• You need temporal queries on core domain objects
• Team has experience with CQRS/ES patterns

Skip it when:

• Simple CRUD with audit columns suffices
• Team is small and moving fast
• Read latency requirements are strict