Hacker News Reader

Comment by amluto | Hacker News Reader

All this "event sourcing" stuff is fun to watch. I've been using essentially this paradigm in production for years. The difference is that I use a simple custom append-only database for it. The consumer side can read, parse, and handle well over 1M events per second on a single core. Take that, Postgres. If the code wasn't such a mess, I'd open source it.

I'm a bit mystified as to why it's called event sourcing, though. Everything sources events. The difference is that this data model has everything consuming events instead of consuming state.

View on HN

> If the code wasn't such a mess, I'd open source it.

Those are always the best kind. Real, live, messy, production code. You should open source it. We will learn something

Also if it works well someone will come along and cleanup and write tests for those hairy bits so you don't have to...

I second this. Please open source it. I suggest using the ISC, MIT or the 2-clause BSD license.

> I'm a bit mystified as to why it's called event sourcing, though. Everything sources events.

That's a bit like saying Historians know everything, since every known fact is in the past and therefore history :P

I think the point is that the events are kept and can continue to be used as the primary source of truth, rather than used and discarded.

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.

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.

along the lines I know geteventstore.com and kafka are used for event sourcing as "append only" db, but anyway, it would be cool if you opensourced your system :) even if it's a mess

I sort of missed this in the bit, volume numbers and query times.

Not what I do anymore so it isn't a surprise, but yeah, I was unaware this got a fancy name. In the late 90s, I built almost exactly what's described in article for a dot.com for a bulk mail delivery manager. Seemed like the obvious thing to do.

Reply on news.ycombinator.com