
Avoiding Double Payments in a Distributed Payments System - spockz
https://medium.com/airbnb-engineering/avoiding-double-payments-in-a-distributed-payments-system-2981f6b070bb
======
jzoch
ive been thinking of this problem a lot recently and this is good but I wonder
how a given service (of which there could be many replicas of said service)
finds its idempotency key. If I take a key / generate a key and then crash,
how do I find my key again? I assume they do something simple like have a
unique service identifier ie service-name+replica# and use that for querying
for a particular key.

they mention using a deterministic key for this kind of problem but that can
be tough too

~~~
spockz
For some things it is relatively easy. Charging for a booking would include
the booking id and the amount, perhaps even the credit card number. This
allows the customer/seller to hit charge multiple times but it will happen
only once.

But more importantly, as far as I can tell, the ID generation happens in the
preRPC phase and is commuted to the database. The RPC call is only done after
the ID is persisted so if any crashes occur the pre and post logs can be
automatically reconciled.

This system looks a lot like a combination of command and event sourcing with
a nice library for putting the right actions in pre, rpc, and post.

