Avoiding Double Payments in a Distributed Payments System

medium.com

23 pointsspockz2 comments

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

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.

Reply on news.ycombinator.com