4 ms·

I'm currently writing a book on this (ES/CQRS), but I have come to the conclusion through some of our projects that a "subscription" model is actually less idea

I'm currently writing a book on this (ES/CQRS), but I have come to the conclusion through some of our projects that a "subscription" model is actually less ideal as you end up falling back to keeping a lot of state in the application heap. We rather prefer to have a subscriber who re-runs the projections which are purely functional, and dump their state. This mandates that you have some way of querying relevant events from the underlying store. Sometimes the best store for this is a DBMS, sometimes it's something simpler like CAS linked lists in Redis or similar (lists of hashes pointing to keys, similar to git's ref/tag model) Either way, this idea that you subscribe to a stream makes reconnection and place-holding (cursor) semantics difficult, and simply calling as-frequently-as-makes-sense your update function is simpler to reason about, and helps highlight performance issues by making it easier to see the perf of frequently called short lived processes vs dealing with any VM bloat of your choice of language's runtime managing long lived subscribers. Caveat: naturally this is all very subjective, just my 2 ¢

fnord123 9y ago
>Either way, this idea that you subscribe to a stream makes reconnection and place-holding (cursor) semantics difficult This is true. It's also a problem if you drop a packet - you need to build up state again on the client side. If you're writing a book about event sourcing, I should think you'll spend a good deal of time covering trading systems and order books since these are an area where event sourcing (AIUI) has been used for decades.
karmajunkie 9y ago
Yeah, i agree with most of that, particularly the utility of having your projections be pure functions. You can go a really long way on ES by doing on-demand projections (with or without snapshots as you describe). However, I stand by what I said earlier in that you don't query streams—though whether you subscribe as a live projection or request the entire stream (or perhaps the entire stream from version number X onward, to be used with snapshots) is definitely a YMMV kind of question.

fnord123 9y ago

>Either way, this idea that you subscribe to a stream makes reconnection and place-holding (cursor) semantics difficult This is true. It's also a problem if you drop a packet - you need to build up state again on the client side. If you're writing a book about event sourcing, I should think you'll spend a good deal of time covering trading systems and order books since these are an area where event sourcing (AIUI) has been used for decades.

karmajunkie 9y ago

Yeah, i agree with most of that, particularly the utility of having your projections be pure functions. You can go a really long way on ES by doing on-demand projections (with or without snapshots as you describe). However, I stand by what I said earlier in that you don't query streams—though whether you subscribe as a live projection or request the entire stream (or perhaps the entire stream from version number X onward, to be used with snapshots) is definitely a YMMV kind of question.