Our client came to us wanting to build a real time auction application for supplying fuel to ships.
This was exciting! We were going to be auctioning upwards of 1000 metric tons of fuel using Elixir and Phoenix! What could go wrong?
From the beginning of the project there was a hard requirement for auditing. Anything that happened in the system needed to be recorded. This lead us to the idea of Event Sourcing.
What is Event Sourcing?
Event Sourcing is a way of ensuring all changes to an application's state are stored as a sequence of events. Those events can be queried, logged and used to reconstruct past states.
In this talk I'll cover the benefits and challenges with Event Sourcing and the solutions we came up with.
Benefits:
- Predictability. Having a list of Events helped us to troubleshoot and reason about the state of our application.
- Testability. Using events to start the application in a desired state made Test setup easier.
- Resiliency. The ability to rebuild the state of any auction at any time made our application more resilient. An auction crashing during the bidding process was no longer as scary.
Challenges:
- Complexity. Early on we struggled with deciding to implement the pattern ourselves or use a library. After trial and error we thought through our domain, and chose to implement it ourselves. This had both benefits and draw backs.
- Ordering. The order in which things happened our system was important. Ordering events across multiple asynchronous processes was complex.
- Race Conditions. Dealing with timers that trigger events without race conditions was difficult.
This project was both fun and challenging. I want share the knowledge that we gained from it, as well as our mistakes.
James was so captivated by development that he worked his way through one of his high school’s only two programming books. It focused on Pascal, and since he didn’t have the expensive software necessary to make Pascal run on his computer, he’d write programs by hand on paper then go back through the book to double-check his syntax.
At Gaslight you’ll find him in front of his Mac, writing Web apps in Ruby and JavaScript. He loves using his creativity to solve problems with code and watch software take on a life of its own after the initial development process. He’s also our office expert on Elixir and gave a talk at the first-ever ElixirConf.
James is largely a self-taught developer and got his start in technology when he joined Cincinnati Christian University’s IT department while still a student. Around 2007, he discovered Ruby and spent six months learning the language as he discovered the Cincinnati Ruby community. Eventually, he landed a full-time Ruby job at Meyer Tool, an aerospace company. In 2010, James became employee number one (after the co-founders) at Gaslight.
He lives in Amelia, Ohio, with his wife, two sons, a red Australian cattle dog named Mila, and Mastiff named Honey. While he considers programming both a job and a hobby, James also describes himself as a serial gamer and outdoor lover.