I’ve been thinking about how we build systems that can stand the test of time. Recently, I found myself debugging a production issue where critical business data seemed to disappear without a trace. The audit logs were incomplete, and we couldn’t reconstruct what actually happened. This experience led me down the path of event sourcing – a way to never lose the story of your data.

What if I told you there’s a way to build systems that naturally preserve every change, provide complete audit trails, and allow you to reconstruct state at any point in time? Let me show you how we can build such a system using Go, PostgreSQL, and NATS Streaming.

Event sourcing fundamentally changes how we think about data. Instead of storing only the current state, we store every state change as an immutable event. This approach gives us a complete history of what happened in our system. Have you ever wondered what your application’s data looked like exactly one week ago? With event sourcing, you can answer that question with precision.

Let’s start with the core building blocks. In Go, we define events as simple structs that implement specific interfaces. Here’s how we structure our base event type:

type Event struct {
    ID           uuid.UUID       `json:"id"`
    AggregateID  uuid.UUID       `json:"aggregate_id"`
    EventType    string          `json:"event_type"`
    EventData    json.RawMessage `json:"event_data"`
    EventVersion int             `json:"event_version"`
    Timestamp    time.Time       `json:"timestamp"`
}

Each event represents something that happened in our domain. For example, in an order system, we might have OrderCreated, OrderShipped, or OrderCancelled events. The beauty of this approach is that events are facts – they cannot be changed or deleted once recorded.

But how do we ensure these events are stored reliably? We use PostgreSQL as our event store, leveraging its transactional guarantees. Here’s a simple implementation for appending events:

func (s *EventStore) AppendEvents(ctx context.Context, events []Event) error {
    tx, err := s.db.BeginTx(ctx, nil)
    if err != nil {
        return err
    }
    
    for _, event := range events {
        _, err := tx.ExecContext(ctx, `
            INSERT INTO events 
            (id, aggregate_id, event_type, event_data, event_version, aggregate_version, timestamp)
            VALUES ($1, $2, $3, $4, $5, $6, $7)`,
            event.ID, event.AggregateID, event.EventType, event.EventData, 
            event.EventVersion, event.AggregateVersion, event.Timestamp)
        if err != nil {
            tx.Rollback()
            return err
        }
    }
    
    return tx.Commit()
}

Notice how we’re using database transactions to ensure all events for a single operation are stored atomically. This prevents partial updates that could leave our system in an inconsistent state.

Now, here’s an interesting question: what happens when multiple processes try to modify the same aggregate simultaneously? We handle this with optimistic concurrency control. Each event includes the aggregate version it expects, and we reject events that would create conflicts.

The real power of event sourcing emerges when we combine it with CQRS (Command Query Responsibility Segregation). Commands (write operations) and queries (read operations) follow separate paths. Commands produce events that are stored in our event store, while queries read from optimized read models.

This is where NATS Streaming comes into play. After we store events in PostgreSQL, we publish them to NATS for other services to consume. Here’s how we set up our event publisher:

type EventPublisher struct {
    sc stan.Conn
}

func (p *EventPublisher) Publish(event Event) error {
    data, err := json.Marshal(event)
    if err != nil {
        return err
    }
    
    return p.sc.Publish("events", data)
}

Subscribers can then process these events to build read models, send notifications, or trigger other business processes. This decoupled architecture allows each component to scale independently and fail without bringing down the entire system.

But what about performance? Rebuilding an aggregate from thousands of events can be slow. This is where snapshotting comes in. We periodically save the current state of an aggregate, allowing us to load from the latest snapshot and only replay events that occurred after it.

type Snapshot struct {
    AggregateID    uuid.UUID       `json:"aggregate_id"`
    AggregateType  string          `json:"aggregate_type"`
    AggregateState json.RawMessage `json:"aggregate_state"`
    Version        int             `json:"version"`
    Timestamp      time.Time       `json:"timestamp"`
}

Testing event-sourced systems requires a different approach. We focus on testing the behavior rather than the state. Here’s a simple test pattern I’ve found effective:

func TestOrderAggregate(t *testing.T) {
    order := NewOrder(uuid.New())
    
    err := order.CreateOrder("customer-123", 100.00)
    assert.NoError(t, err)
    
    events := order.GetUncommittedEvents()
    assert.Len(t, events, 1)
    assert.Equal(t, "OrderCreated", events[0].EventType())
}

Deployment considerations are crucial for production readiness. We use Docker to containerize our application and ensure consistent environments. Monitoring event flows and aggregate health becomes essential – we instrument everything with metrics and structured logging.

One common challenge is schema evolution. How do we handle changes to event structures over time? We version our events and use upcasters to transform older event versions to newer ones during projection.

Building this system has transformed how I think about data integrity and system design. The complete audit trail alone has proven invaluable during incident investigations. The ability to replay events to recreate past states or build new projections has opened up possibilities we never considered before.

What questions do you have about implementing event sourcing in your projects? Have you encountered similar data traceability challenges? I’d love to hear about your experiences in the comments below. If you found this useful, please share it with your team or colleagues who might benefit from these concepts.