Oskar Dudycz

Pragmatic about programming

Let's build event store in one hour!

2023-01-08 oskar dudyczEvent Sourcing

Last year, I completed two items from my speaker bucket list NDC Oslo and Domain-Driven Design Europe. I’m proud and happy, as those conferences were a huge inspirations for me.

At NDC Oslo, I showed one of my favourite talks: “Let’s build event store in one hour!“. Why do I like it so much? It’s a fun mixture of live coding and theory explanation. At least for me.

It’s technically hard talk to deliver as I need to coordinate speaking, live coding and not boring people with technical details. It’s kinda speed run for me. But when precisely delivered, I think that’s fun talk to watch. Check it on your own!

This talk does not intend to persuade you to write your own event store. There are already mature solutions like Marten, EventStoreDB, Axon.

The intention is to dive a bit deeper, showing that Event Sourcing and event stores can be treated as boring technology in the good sense. It’s about showing that it’s not a hyped buzzword but a tool that can bring real benefits and give you the guarantees you need.

I like to see how people’s eyes get bigger when they see the SQL stored procedure. I also like when they’re surprised that I’m not using any messaging tooling or regular database transactions. Most people also don’t expect that read models can also be updated synchronously without having eventual consistency.

So it’s more about myths busting and explaining Event Sourcing pattern in a nutshell.

What are the requirements, then? In my opinion, at least:

  • appending event at the end of the stream,
  • reading all events from the stream,
  • a guarantee of the ordering within the stream,
  • being able to read your writes,
  • strong-consistent, atomic writes and optimistic concurrency.

The 2nd tier of event stores features (so great to have but not must-haves):

  • being able to subscribe to notifications about newly appended events (best if it’s push-based)
  • global ordering,
  • built-in projections,
  • streams archiving.

Check more on those considerations in the:

I also have something special for you, a self-paced kit on building event store on top of Relational Database using Postgres as an example. It starts with the tables set up and goes through appending events, aggregations, handling business logic, time travelling, projections, and snapshots.

I think that’s a fun way to learn Event Sourcing, check versions for:

Once you’re done, please don’t use it on production; rather, use some mature solutions. Maintaining it won’t be sustainable if it’s not your core business.

Event stores are databases. Just like you won’t say “hey, let’s build the relational database for our project”, you should not do that with an event store.

Still, it’s a lot of fun, nothing too time-consuming to build a simple one and an excellent exercise in understanding how Event Sourcing works.

Cheers!

Oskar

p.s. Ukraine is still under brutal Russian invasion. A lot of Ukrainian people are hurt, without shelter and need help. You can help in various ways, for instance, directly helping refugees, spreading awareness, putting pressure on your local government or companies. You can also support Ukraine by donating e.g. to Red Cross, Ukraine humanitarian organisation or donate Ambulances for Ukraine.

👋 If you found this article helpful and want to get notification about the next one, subscribe to Architecture Weekly.

✉️ Join over 2600 subscribers, get the best resources to boost your skills, and stay updated with Software Architecture trends!

Loading...
Event-Driven by Oskar Dudycz
Oskar Dudycz For over 15 years, I have been creating IT systems close to the business. I started my career when StackOverflow didn't exist yet. I am a programmer, technical leader, architect. I like to create well-thought-out systems, tools and frameworks that are used in production and make people's lives easier. I believe Event Sourcing, CQRS, and in general, Event-Driven Architectures are a good foundation by which this can be achieved.