At least once events delivery

Github Issues
1

From @asyncee on Thu May 17 2018 14:53:59 GMT+0000 (UTC)

Hello! Is it possible to implement at least once events delivery?

I have few microservices broadcasting domain events to event bus and if one of them goes down, them system can become to inconsistent state. Currently i have no idea how to fix this, because there are can be 0…N subscribers to any particular event.

So i thought that maybe it is possible that at-least-once-delivery for event messages can be implemented? For example, messages may be persisted in queue for some time until expiration timeout, or something like ReplaySubject (rxjava) may be implemented (it emits all the items of the source Observable, regardless of when the subscriber subscribes).

Or, maybe, there are already good practices to solve this problem exist?

Thanks!

Copied from original issue: https://github.com/nameko/nameko/issues/543

2

From @mattbennett on Sat May 19 2018 10:43:10 GMT+0000 (UTC)

All the AMQP entrypoints do at-least-once-delivery actually. The ack is not sent until after the service method has returned, and if the connection is lost in the mean time the unack’d message is reclaimed by the broker and returned to the queue for redelivery.

One caveat to this is if you are using the “broadcast” handler type (as opposed to the default “service pool”). In this mode you have to tell Nameko how to uniquely identify a service instance if you care about persisting events between restarts. See the docs on the broadcast_identifier.

Unfortunately the only way to set the broadcast_identifier at the moment is to subclass the EventHandler. There’s no way to pass it into the constructor.