Limits of Event Sourcing?

[mikecann]

Lately I have been working my way through the Discord Engineering blogs just because its fascinating.

https://blog.discord.com/how-discord-stores-billions-of-messages-7fa6ec7ee4c7

It got me thinking, what are the limits of event sourcing?

Would Event Sourcing be an appropriate technology / usecase for a company like Discord? They want to store every message for all time which seems like a good usecase for Event Sourcing, but im wondering if you have a single event store with billions of eventsin it (growing 40 million events per day) then would it still be appropriate?

Im assuming snapshots would be essential in this case in which case the read models would be duplicating a bunch of data which would be expensive?

Anyways, just wondering what your thoughts are.

[superroma]

In this example, i would divide the problem. Even if they deal with billions of events, app is divided by "discord servers" - whether it physical servers or not - does not matter.
Any particular server is dealing with its events and its read models and can not care about other servers.
So, if it needs to rebuild its read model it can only deal with own events.

Snapshots - in reSolve meaning they are not very usable here. Snaphot is a state of one aggregate. Snapshot is useful when aggregate has a lot of events. If aggregate has 10 events, it is faster to load these events and run reducer. So in Discord - if aggregate is a message, then it is usually has 1 event, rarely several.
If aggregate is a chat log, then state is almost identical to event log (it is a history of messages), so again, it is easier to process events...

Regarding read models being duplication of data. In event-sourced Discord I would probably keep only recent chat history in read models, and compute anything older on-the fly from event store. Or keep those historic read models not in DB, but in files or S3 buckets. Again, ES/CQRS makes this quite easy - just set up read model that writes to files.

[mikecann]

Apologies for the late reply..

Any particular server is dealing with its events and its read models and can not care about other servers.
So, if it needs to rebuild its read model it can only deal with own events.

Interesting. So you would have to create read models that are specifically tailored to a specific server then I guess.

I guess if you ever need to rebuild a large read-model you could potentially do it in the background then do an A/B swap once its caught up?

Regarding read models being duplication of data. In event-sourced Discord I would probably keep only recent chat history in read models, and compute anything older on-the fly from event store. Or keep those historic read models not in DB, but in files or S3 buckets. Again, ES/CQRS makes this quite easy - just set up read model that writes to files.

Cool, thats a nice idea. Just spit balling. How would you evict old messages from the read model DB? Do it when you insert a new message?

[superroma]

Interesting. So you would have to create read models that are specifically tailored to a specific server then I guess.

We are thinking about splitting read models into independent parts/shards. This will allow a parallel and independent read model rebuilding. For instance, in multi-tenant app like, say, Slack, each tenant does not depend on other tenant's events.

In future reSolve release we will let developer provide a way to map event to partition and all partitions will be processed in parallel.

How would you evict old messages from the read model DB? Do it when you insert a new message?

Yes. Or you can do this as a part of maintainence job. Like, once a week. It can be done outside of reSolve. Or you can do system event in the app to trigger this.