So I’m not super experienced with Axon but I have an interesting problem so please bear with me. I have a service for which I want an eventStore for all of its emitted events, but as this service is the core engine for all of my other services, the event count reaches extremely high numbers ~40k. Since I want to be able to replay the events, I made a singleton aggregate to maintain the order of my events, but the issue is that I am running into out of RAM issues every time I want to load my aggregate. However, if I was to separate the aggregate into multiple instances with my event identifiers, the order cannot be maintained, and thus replay will end up giving me errors. I have thought about using snapshots to circumvent this but are there any cleaner solutions to this problem?
the number of events needed to reconstruct an aggregate is not a reason to run out of memory. I have seen aggregate with millions of events in their history. I suspect there is something in the Aggregate’s design that keeps growing, eventually causing an out-of-memory.
What state do you keep in the aggregate? Which EventStore implementation do you use?
Besides, in general we very strongly recommend against using a singleton aggregate. I don’t know your usecase, but there are almost always alternative designs where multiple aggregate (instances, at least) can live simultaneously.
I believe the eventstore implementation is a MongoEventStore, and I have confirmed that it is mongo complaining about the out of memory. The reason for the singleton aggregate is because it is supposed to represent our engine service, but pretty much all our events from other services go through the engine one way or another. Our singleton aggregate is almost like a dummy aggregate as our engine uses another open source engine which stores its own state. The eventstore in this case is used purely for replays by other services. If it clarifies things we are still on Axon 2.
being on Axon 2 does explain this design. In Axon 3, you can simply publish events on the EventBus. As the EventStore also implements EventBus, choosing an EventStore implementation will automatically store these events, ensuring they’re available for consumers to read.
I did consider it but I realized that much of our codebase in our SDK is all based in Axon 2, so currently this option isn’t open given the scale of the features I’m trying to implement. Is there an alternative until we can fully migrate to Axon 3?
for my understanding. You’re saying MongoDB is running out of memory? I’m not sure how that’s caused by Axon trying to append events to it (other than that it’s giving MongoDB some work to do).
Could you elaborate on the problem and indicate why you believe Axon plays a part in it?