At-least-once delivery using Akka Persistence and the Extra-Cameo pattern

Question

I am developing an application that uses Akka, in which Actors are designed to avoid the Request-Response pattern. Using the Extra or the Cameo pattern is possible to model interactions among actors as a "stream" of messages.

The figure below summarizes the architecture of such actors.

The Cameo pattern is implemented to handle the responses coming from SK actors.

Now, imagine that I want to guarantee the at-least-once semantic between SF and SK actors. How can I do that? The implementation of ato semantic using Akka persistence needs the implementation of a Request-Response Pattern between those actors.

How can I ensure an at-least-once semantic between actors that use a Cameo to handle responses?

Thanks a lot

Answer 1

Jamie Allen helps me on Twitter to answer this question. The twitter conversation is this.

I try to summarize the discussion what Jamie said.

For reliable at-least-once, using Akka Cluster and Persistence to get it done is possible, but probably overkill. I say try to keep it simple. Have a GUID for the request, and send it with the request to the three SKs.

In the immutable ledger scenario, you'd then occasionally sweep the ledger to get rid of dups by GUID. How consistent that data needs to be will define that.

Simplicity is going to be a lot easier to maintain & avoid partial failures. You can handle idempotency on the SK side one of a few ways: either track all GUIDs when the requests are processed via an expiring cache, or store the GUIDs with the immutable updates in a ledger.

So, in this case, the better solution is to remove Akka Persistence completely and reduce the problem to good old message passing.

SF sends messages to SKs actors, the Cameo node waits for SKs responses. If such reactions don't arrive in a predetermined window of time, the Cameo node alerts SF using a timeout message. SF resends messages to SKs actors again.

The diagram that represents the above solution is the following.

The message in red, marked with number 5, models the timeout message.

As Jamie said:

I think ACK has to be the responsibility of the caller, all the way back to the sender of the original request. That’s the safest & simplest approach.

Hope it helps.