News for hackers. Stuff that matters.
Re:The Reactive Monolith – How to Move from CRUD to Event So... by JamesBarney on Thursday September 30, 2021 @03:11AM (#28703919)
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.

Re:The Reactive Monolith – How to Move from CRUD to Event So... by y4mi on Thursday September 30, 2021 @03:31AM (#28703996)
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
Re:The Reactive Monolith – How to Move from CRUD to Event So... by nivertech on Thursday September 30, 2021 @04:13AM (#28704176)
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