I've been using Akka's event stream in a Play app as an event bus where I can publish events and subscribe listeners and I wanted to know what are the gotchas I should take into account. Specifically there are two things:
- Each Listener is implemented via an actor which receives the published events and processes them. What if the actor's message queue starts to get big? How can I implement back-pressure safely, guaranteeing that each event is eventually processed?
- Related to the previous one: how can I persist the unprocessed events so, in the case of a failure the application can start again and process them? I'm aware of the existence of akka-persistence but I'm not sure if that would be the right thing to do in this case: the Listener actors aren't stateful, they don't need to replay past events, I only want to store unprocessed events and delete them once they have been processed.
Considering constraints I would not use Akka's event bus for this purpose.
Main reasons are:
-
Delivery - You have no guarantees that event listeners are in fact listening (no ACK). It's possible to lose some events on the way.
-
Persistance - There is no built in way of preserving event bus state.
-
Scaling - Akka's event bus is a local facility, meaning it's not suitable if in future you would like to create a cluster.
Easiest way to deal with that would be to use message queue such as RabbitMQ.
While back I was using sstone/amqp-client. MQ can provide you with persistent queues (queue for each listener/listener type).