Applied Event Sourcing

We shipped a cloud-native event sourced Ruby app that will have a key role in Australian energy infrastructure. I’ll be covering what we learned through this process regarding how to actually go about implementing an event sourced system.

There have been a few talks previously that address event sourcing at a high level - what it is and why you should want to use it. I’ll be taking up where they left off, and providing a hands-on account of how we’ve applied event sourcing, CQRS, and Domain Driven Design principles to our domain and put our application into production. I’ll be detailing how we proceeded to rewrite our previous Golang codebase in Ruby, dealt with eventual consistency, and transitioned to supporting replication, zero-downtime deployment, & continuous deployment.

Events and state: What do they store? Do they store things?? Let’s find out!

I’ve been working with event sourcing since the end of June, 2017. I was involved in the design and development of our Ruby event sourcing framework and develop with this every day.

There’s a bit of code, but mostly I’ll be discussing the concepts, concrete implementations of those, and various architectural choices. A key achievement is that we’re now able to use multiple replicas in Google Kubernetes Engine, allowing a seamless deployment pipeline; but I’m not covering Kubernetes itself and there’s enough buzzwords in the description already!