Question: how to avoid performance bottleneck with huge number of events

[walnutist]

Hi dear author and all participants, I am still quite new to the whole DDD/Event-sourcing architecture as well as this library, but I do get the idea of the event recording and replay idea. But my question is: what if we have huge amount of events regarding large number of entities? Isn't it slow to reconstruct the state of the entity each every time for a simple listing first 10 entities query?

For example, let us say I have an online forum running with 100K topics and each every topic averagely has 15-20 replies. I understand for each every topic/reply created, we need to initiate the domain event and persist it to the backend database table stored_events and optional stored_snapshots. Now, if the user request for the 10th page of all topics with a page_size 20, then this library can transparently covert the query to select corresponding stored_events records and replay the event stream to construct the particular 20 topics. Isn't it slow comparing to the old school topics/replies database table which contains only the latest snapshot? how can I combine both the snapshot table and eventsourcing library? What if I want to have a filtering mechanism?

Sorry for the questions if they are too noob since I am indeed a newbie and english is really not my tongue language (That is where I am so confused trying to understand all the DDD/ES concepts! ). Any feedback would be highly appreciated.

[johnbywater]

Hi @walnutist! Thanks for your nice question. The short answer is that you would do best by supporting the query you describe with a "materialised view" that is updated by processing the recorded events. There is an example in the docs about this. The schema for the materialised view might look quite similar to the "old school topics/replies database table".