# Exploring Event Sourcing for Order Management

##Goal

Implement event sourcing for Cropnest's order management system to:

• Enable complete audit trails of all state changes
• Allow state reconstruction at any point in time
• Support complex business processes with clear state transitions

##Context

Current system uses traditional CRUD operations on an orders table. Problems:

• No history of changes (who changed what, when)
• Hard to debug state transitions
• Can't reconstruct order state if data is corrupted

##Current State

Actively building the event store schema and projection system. Currently wrestling with:

• How to handle concurrent events without locking
• Whether to use PostgreSQL as the event store or a dedicated solution
• Testing strategies for event-sourced systems

Next step: Load testing with 1000+ events to measure replay performance.

##What I'm Trying

###Phase 1: Event Store Design

Building an event store with:

• Immutable events (OrderCreated, OrderUpdated, OrderCompleted)
• Stream per aggregate (one stream per order)
• Sequential ordering within streams

###Phase 2: Projection Building

Creating read models (projections) from events:

• Current order state
• Order history view
• Analytics views

###Phase 3: Snapshotting

Implementing snapshots for performance:

• Snapshot every N events
• Rebuild state from snapshot + recent events

##What I'm Unsure About

• Event versioning strategy at scale—how do we evolve event schemas without breaking existing streams?
• Cost of replay for long-lived aggregates (orders that stay open for months)
• Whether the operational complexity is worth it for our current scale

##Next Steps

1. Load test the event store
2. Implement snapshotting
3. Build a monitoring dashboard for event streams
4. Document the pattern for the team