Fork me on GitHub!
Señor Developer!

RUG::B

Ruby User Group Berlin

State, when state? - answering the (sometimes) unanswerable

Armin Pašalić wants to give this talk

No event date yet

Sometimes, during the lifetime of your application, you might like to know answers to questions such as:

  • How many times has the product X been added to the cart but not bought during last year. Or, what products the user Y added to cart but never bought?
  • How much units of value did User Y spend during February last year?
  • What was the exact state prior to crash happening?

While some of these could be answered by looking at system logs, provided those existed and were detailed enough, there is another way you could approach maintaining the state which can all but guarantee you will get questions similar to these answered.

Very small architectural pattern enabling this is known as Event Sourcing and. In essence, it is a shift on how we think about what the "current" state as the source of THE TRUTH is. Instead of creating/updating the state directly, we persist all events that have happened into an immutable (append only) event store and shift the source of THE TRUTH to it. Now we are no longer destroying historical data and can reconstruct (project) any wanted state any way we want (SQL, document, graph database, memory...).

Since it plays so well with ES, there will also be some mention of CQRS pattern.