DCB

Back in February I wrote about implementing a DCB-compliant event store in SQLite: a four-column table, a few indexes, and SQLite’s own file lock doing the heavy lifting on consistency. It worked, but it had one obvious limit: SQLite is embedded, so the technique only helped the one process holding the file open. TamarackDB is that idea turned into something you can actually run. It’s a standalone event store: written in Go, reachable over HTTP, backed by SQLite. It follows the DCB specification, but works just as well for plain old aggregates. Not a library you import into your app. A small service that sits next to your apps and holds their events. ...

Dynamic Consistency Boundary doesn’t require specialized infrastructure. A four-column SQLite table is enough. The DCB specification defines the minimal feature set an Event Store must provide to support Dynamic Consistency Boundary. This article walks through how to implement it using SQLite, requirement by requirement. This approach relies on SQLite’s global file-level lock to guarantee consistency. It cannot be applied as-is with MariaDB, MySQL, or PostgreSQL. See the appendix for details. The READ Requirements Let’s go through each READ requirement from the spec and map it to a column. ...

Event sourcing is often overlooked A lot of people hesitate to adopt event sourcing. The literature is full of distributed systems, eventual consistency, sophisticated event stores, and architectural diagrams that look like they belong at Netflix. It’s easy to walk away thinking this is not for me. Most of that complexity is self-inflicted. None of it is inherent to event sourcing. It’s a set of choices, and you can make different ones. ...