Event Sourcing / CQRS

Question

I'm considering building a blockchain application following the Event Sourcing/CQRS pattern as described by Greg Young (https://cqrs.files.wordpress.com/2010/11/cqrs_documents.pdf).

Ideally I want to read/write a stream of events per entity instance. For example I have an event stream associated with account A (account-added, account-name-changed, account-address-corrected) and a separate stream associated with account B. Each time I create a new account (or any other kind of basic object) I create a new stream. I'll definitely end up with a large and growing number of streams. When a user command comes in to do something with an object I'll need to locate, read, and add to the stream. This needs to happen in fractions of a second. Does this sound feasible? Or am I trying to use the platform in a way for which it was not intended and is not suitable?

Answer 1

Yes, in general this sounds feasible. You can have millions of streams on a blockchain, and each node can choose which ones it subscribes to. You can have notifications for new items on a stream to which a node is subscribed (walletnotify runtime parameter).

But you need to think carefully about event ordering. Because this is a peer-to-peer network, different nodes can receive different items on a stream in different orders, and the ordering is only finalized when stream items enter the blockchain. All the stream querying APIs let you choose between local (per-node) and global (blockchain) ordering, so you need to see which maps better to your application's logic.