Hacker News Reader

Comment by fweespeech | Hacker News Reader

I'm not sure but the term is pretty old.

https://martinfowler.com/eaaDev/EventSourcing.html

This is an article I have from 10+ years ago and its still roughly the same way I do it now. I've never needed to scale it beyond something like Postgres or Redis.

View on HN

Isn't Event Sourcing the same as anything using a Write Ahead Log (WAL)? i.e. it's been around for decades.

No, a WAL is an implementation detail of a database—you could only consider that to be ES if you're building a database. ES refers to the primacy of domain-related events as the source of truth about your application state. Your application consumes event from individual streams (events belong to one or more streams—usually one) and changes state with each event. You can think of it as a functional data pattern.

>you could only consider that to be ES if you're building a database.

I poke around in the guts of databases, so that's what I meant. The WAL is ES in the context of databases. So I guess ES is the generalization/abstraction(?).

Probably more appropriate to think of ES as relying on a WAL for managing an ordered event stream. When getting the current state of a business object e.g. "SELECT * FROM table WHERE pk=313", you would replay the event log to get current state and discard it when you're done. Mutation is only done by adding an event to the stream.

It's not uncommon to see RDBMS's still used to improve read performance (but not as a source of truth, just a cache with SQL).

Right, and then, if the domain allows it, you can compact the logs into the current state so the compacted state is the single source of truth. e.g. HDFS works this way by having an fsimage and the edit logs. After a compaction, the fsimage is the HDFS namespace. The RDBMS that you mention is just a coarse tool for doing the same thing (IIUC).

Ok, you win that round :)

A simple idea made massively over-complicated.

Reply on news.ycombinator.com