2 ms·

Here's why I used event sourcing. We were modeling well dynamics. And to calculate interesting properties of the well we needed sensor data, the previous stat

Here's why I used event sourcing. We were modeling well dynamics. And to calculate interesting properties of the well we needed sensor data, the previous state of the well, and a model of the well built by a petroleum engineer. Unfortunately the model of the well wasn't always up to date (pump was replaced, etc..), so we needed to be able to replay all of the sensor data into the well when a model was retroactively changed. Event sourcing was such an easy pick because our events were very simple (15 fields of data) and our replay requirement was a showstopper.

y4mi 5y ago
it sounds pretty straightforward to implement with basic crud too, though. you'd just need an inserted timestamp field so that you can rerun the analysis with where inserted >= the_date order by inserted
- nivertech 5y ago
  I think GP mixing up Stream Processing with Event Sourcing [1]. Event Sourcing is usually used in complex business domains, Stream Processing in simple domains, but with large amounts of data (i.e. IIoT). if you use a timeseries databases like kdb+/q, TimescaleDB, InfluxDB, QuestDB, etc., you don't even need to order by the insertion timestamp. Unlike RDBMS/SQL where rows/tuples are unordered, in timeseries databases they're usually ordered by the insertion time, more similar to dataframes than to SQL tables. -- [1] Martin Kleppmann — Event Sourcing and Stream Processing at Scale https://www.youtube.com/watch?v=avi-TZI9t2I https://www.youtube.com/watch?v=avi-TZI9t2I