| very interesting. There is some few-years-old inhouse eventsourcing system that starts to choke on few dozen million events, because of.. many reasons. And there was a plan to scrap it and rewrite. Though the new one may or may not be pure eventsourcing - as long it does the job (tracking claims and all their follow-up, like communications etc, with full audit i.e. "why-this-is-so"). So... for about an year i have been toying with the idea to use a bitemporal database (xtdb) instead of eventsourcing, using the particular-state-of-db for any business processing as-of-its-timestamp. Parallelizing the sagas as much as needed/allowed-as-of-business - as long as they can get their as-of time-cut (and also replicating the database (== indexes == "reading-aspect") as much as needed). Although, as that is somewhat higher level than just what eventsourcing gives, that means maybe rewriting a bit more than just the data-storage/access, i.e. some layer of the saga's business logic as well - e.g. the notion of readmodel disappears, being replaced by a query to the bitemporal-db as-of-time-x. Then a few weeks ago i stumbled upon EventStoreDb, and thought that... maybe it can be used to replace just the data-storage/access, and not having to rethink the business logic above that (still may need some rewrite, but hopefuly not completely reverse-engineer + splitting notions). Now i see even more alternatives :) The funny thing is.. i have not tried either approach for real, yet. But going to.. very soon. There is now a project and resources for it.. e-mail is in the profile |