[biot]

Combine this with the actor model (using Akka or similar) gives you guaranteed "one message at a time" processing and you don't have to deal with locks.

[taeric]

I question any amount of guarantees around "one message" anything. There might be this guarantee per actor, but you have no such guarantee per system. And, assuming a real system, this will be a problem.

So, you get to pick, "at most once" or "at least once." And then you need to build your system to act accordingly.

[hew]

Slightly shooting from the hip here (as I'm still learning).

Low-ish volume- design your system such that data flows [at the relevant crucial points] through a single actor to ensure proper concurrency.

High volume- trickier but I think same idea in principle. First thought that comes to mind here is the new GenStage stuff in Elixir.

[taeric]

I'm not sure what you are suggesting. There is no getting around "at most/at least once." You can shift the posts, some, but at some point that is your choice. This is a good read on the problem: http://bravenewgeek.com/you-cannot-have-exactly-once-deliver...

[eweise]

"Exactly once delivery" is not the same as "One message at a time". Akka Actors process one message at a time. Akka does no provide exactly once delivery. It default defaults to "at most once".

[taeric]

So, then to go back to the original.

You may not have to do deal with locks at a local level. You absolutely have to deal with locks at a system level.

[biot]

Correct. Message delivery strategy is separate from message processing once delivered. If you choose at-least-once delivery, you'll need to handle possible duplicates regardless of whether or not you can process a duplicate message in a lock-free manner.