[mrkeen]

This is correct, but databases only help to the extent that the whole world is happy to live in your database.

As soon as you have customers (who interact via REST), or partner payment systems (e.g. stripe) you're back to:

  Two customers do a GET.  This gets dispatched to the DB, wrapped in a nice transaction, the transaction ends, the customers get their result.

  The two customers then do a POST to set a new value.  Also wrapped in a transaction.

Race condition with more steps.

[hackyhacky]

As I pointed out above, that's not the API that would be exposed in an actor model. See in particular the timestamp-based update condition, if you're principally concerned with end-user-caused races.

Less relevant, but message queues in Erlang and related languages are typically in-memory, no DB transaction required.