prooph/improoph

Good afternoon @prolic @codeliner

We are currently use the prooph framework for our loyalty engine. In short we have a setup that on each transaction that is created, an x amount of events are created on the player aggregate

The problem is that before we start acting on the player aggregate, we first load the player aggregate (snapshots taken) and then append 1 or more events on it depending on the life-cycle of the loyalty engine campaign. We do have snapshots in place so its not as if we are loading the full history of the player. But still the query generated by the framework to load from snapshot (AggregateRepository -> loadFromSnapshotStore) is quite CPU heavy on the RW db, compared to other queries

In the past we did POC moving to the AggregateStreamStrategy but as written in the documentation, we did struggle alot to have our projections as real time as possible. we would have 1000s of tables if we do one table per player.

So we are looking for options to perform better when loading the aggregate from a snapshot.

DBAs suggested to use partitioning of the main player aggregate table but not sure if prooph itself has that option. Otherwise if DBA create partitioned tables (prob one a day), then we need prooph framework to load the aggregate with these partitioned table.

Another idea that we had was to keep a parallel event store (inMemory) with the state of the players in the last 5mins. meaning that the player is kept in memory for around 5mins or even less.. that would drastically reduce the load on the db.

any other options/thoughts?

On a side note we are using prooph/event-store version 7.5.6 and we currently experience around 1.8million to 2million transactions at any given day. for each transaction we load the player aggregate (for the player related to that transaction) and append further events to the player aggregate