Exactly-Once Payments at Airbnb

The author didn’t work at Airbnb, this post is just a reductive summary of a 2019 Airbnb blog post: https://medium.com/airbnb-engineering/avoiding-double-paymen...

The original post goes into much more detail.

Also don’t wanna sound grumpy but I don’t understand what’s novel or hard about this problem either. Every single e-commerce cite has the same struggle to face and they do it just fine. Of course there’s a period between storing the idempotency key (essentially beginning the transaction) and doing processing.

Maybe it’s just me but this sounds like some rediscovering a very very common problem that been solved thousands of times over.

I am very confused by this article. Is it trying to explain the equivalent of PayPal `PAYMENT.CAPTURE.COMPLETED` webhook? Also, why is this such a problem for Airbnb since they don't have to settle immediately (it's not like someone is withdrawing crypto). If the payment failed, Airbnb has probably ample time to revert the booking (as most bookings happens days if not weeks in advance).

I hate to sound like a crochety old man, but this sounds like a huge amount of overengineering for something that could easily be put in an ACID database to begin with.

100,000 requests/day is less than 2 a second. Most self-respecting databases would giggle at calling that a stretch.

The reason I know this is that I've built and maintained systems that handled millions of ACID transactions a day.

In tables with millions of rows. Uphill, both ways, in the snow.

Now excuse me while I go outside and yell at clouds, because I'm surely missing something profound here.

So, you use DB row locks as a shared mutex? Am I reading that right? You created a centralized mutex service that your services use to share state with the cunning use of DB row locks.

It sounds like their architecture enables them to solve much more interesting problems than would usually be encountered in meeting their business requirements.

Ok architect astronaut

{From:Account, To: Account, TxTimeStamp: Time, Description: String, Amount: Integer }

2 transactions with the same timestamp and same description? Ignore.

Jeez

TL;DR: use idempotency tokens to prevent reprocessing of duplicate requests.