Re-Eventing the Wheel

There are plenty of databases and message busses for doing event sourcing or event driven architectures. I thought I'd reinvent the wheel for fun and build my own store. A few apps of mine share state via events stored in CoreData. I have a dashboard webapp, which these update but this is via an API call. Instead I'd like to have my dashboard driven by the events as well.

What's an Event Store?

An event store is an append-only log of events. Instead of storing the current state of something, you store every change that happened to it. If you want the current state, you replay the events. This is the core idea behind event sourcing -- your events are the source of truth, not a mutable row in a database.

The Basic API

My store if called Clio. Clio's API is simple. You can:

• Write events to an aggregation (a named stream of related events)
• List events for a given aggregation

In-Memory Storage

The storage backend is an in-memory map keyed by aggregation ID. Each aggregation holds an ordered slice of events. It's it's fast and simple, when we get an interrupt we write out the events to the disk.

type Store struct {
    aggregations map[string][]Event
}

Why?

Beyond the event sourcing use case, mostly to learn. It helps with my little hobby todo, notes, timer and time tracker apps, keeping the state of each in sync. Having a reliable source of what happened is invaluable for debugging.

As always, I appreciate any feedback or if you want to reach out, I'm @neuralsandwich on twitter and most other places.