Comment by JamesBarney | Hacker News Reader

Comment by JamesBarney | Hacker News Reader

Parent Full thread

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.

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

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

Reply on news.ycombinator.com