[spiffytech]

This is a big pain point with Stripe's webhooks, and I think there's ample room for improvement.

Senders could guarantee ordering by only sending webhook n+1 after the HTTP request for webhook n completes, rather than sending them concurrently or in arbitrary order. For efficiency, perhaps only guarantee ordering for hooks related to each resource rather than all of a customer's hooks.

Or, include a monotonic counter in the webhook so the recipient can tell when it would apply an old state on top of a new one.

What the recipient does when they receive the webhook is up to them (delays, parallelism, etc.), but at least they'd know the correct event order.

The author raises a good point about what to do in the face of errors, but I'd vastly prefer to handle special behavior upon recipient error (stall, dead letter queue) to the current Stripe reality of "things come in out of order, and we don't give you the info needed to reassemble the order on your end".

[tasn]

The problem with "n+1 after HTTP request for webhooks n completes" is that your throughput is very adversely impacted by this. Let's assume that a webhook takes 1s to process (usually much slower when you include network latency, and endpoint processing time), you're effectively limited to 1 request per second.

Counter makes it slightly better because then you can reconstruct the order without the above artificial limit, though it's also not great (though indeed much better!).