You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The README says you shouldn't use Journaled for event sourcing because it doesn't provide ordering guarantees.
We propose to add an ability to ride on top of ActiveRecord Optimistic Locking's lock_version column to version events.
This is good because the semantics of optimistic locking are often what you want for a data model that needs to spin events off (avoiding data races from multiple writers is probably desirable, these models are important).
It's not necessarily ideal for every possible use case, though, because unless every single update to the ActiveRecord with a lock_version results in an event, there will be gaps in the version number in the events sent, which means you can't guarantee that you've received all the events in order before processing on the downstream side.
So in short, this isn't a complete solution to event sourcing because unless each event is data-complete irrespective of historical events in a given stream, a missing historical event could result in an incorrect computation, meaning the downstream couldn't compute confidently. But for use cases where you only need the latest value, this approach can ensure eventual consistency between OLTP database and the downstream data processing service.
The text was updated successfully, but these errors were encountered:
The README says you shouldn't use Journaled for event sourcing because it doesn't provide ordering guarantees.
We propose to add an ability to ride on top of ActiveRecord Optimistic Locking's
lock_version
column to version events.This is good because the semantics of optimistic locking are often what you want for a data model that needs to spin events off (avoiding data races from multiple writers is probably desirable, these models are important).
It's not necessarily ideal for every possible use case, though, because unless every single update to the ActiveRecord with a
lock_version
results in an event, there will be gaps in the version number in the events sent, which means you can't guarantee that you've received all the events in order before processing on the downstream side.So in short, this isn't a complete solution to event sourcing because unless each event is data-complete irrespective of historical events in a given stream, a missing historical event could result in an incorrect computation, meaning the downstream couldn't compute confidently. But for use cases where you only need the latest value, this approach can ensure eventual consistency between OLTP database and the downstream data processing service.
The text was updated successfully, but these errors were encountered: