6
votes

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.
1

1 Answers

2
votes

Considering constraints I would not use Akka's event bus for this purpose.

Main reasons are:

  1. Delivery - You have no guarantees that event listeners are in fact listening (no ACK). It's possible to lose some events on the way.
  2. Persistance - There is no built in way of preserving event bus state.
  3. 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).