[tasn]

Author here.

You obviously CAN guarantee ordering, it's just that you can't guarantee it as the sender, you need cooperation from the receiver. Additionally, putting them in a receive queue on the receiver doesn't solve the issue unless the receiver takes extra care to also read from the queue in strict (non-overlapping) order which is rarely the case, and even then has significant throughput implications. So it really is all on the receiver. This piece was written from the context of the sender.

Timestamps definitely don't solve the issue, I explicitly said to use a centralized sequence number if you must (not a great idea in most cases). Thin payloads: the idea behind that is essentially to use the webhooks as a "please update" kind of notification and then you get the most recent data from the server. Essentially what you called a "pull system", it's a combination of both a push (webhook) to know when to pull, and the pull to get the data. This also doesn't work as nicely in many scenarios (because oftentimes, receivers want the data immediately without having to fetch), but it's good in others.

Please take a look at the content of the article (rather than just the title), I've addressed most of it there too.

[makeitdouble]

I agree with the parent on the weirdness of how the problem is stated in the first place.

On your customer and card example, the issue is not message delivery order but processing order, or more precisely prerequisite satisfaction.

My first thought looking at it was to just store the data of any of the hooks coming in, check the prerequisites each time, and only process the whole when everything needed has arrived.

Trying to dictate order from the sender without any cooperation from the receiver seems like a fool's errand, as in any real world scenario where it really matters, the receiver will also want a way to check it actually received everything in order.

[rexreed]

I responded in much the same way below - your job as a sender is not to guarantee that the receiver will do its job in processing but to provide a reliable set of webhook messages so that if the receiver does fail, at least they can discover they've missed or skipped messages or are processing them out of order. As a sender, you certainly can provide guaranteed ordering or a way to identify the order of those messages. What you can't guarantee is that the receiver will process them in any given order if they choose to ignore the ordering you provide.

[tasn]

I understand it may not have been very clear. Though the point is that no one cares about delivery order, what they really care about is processing order. So it doesn't matter if you ensure delivery order if they process it out of order.

As for relying on the customers to get ordering correctly: it's actually more involved and easier to get wrong than people realize, and it's better to avoid it altogether in how you design your API if possible.

[jamesbfb]

Thanks for this, your post resonated with me. It’s good to know that most of what you did is what I ended up doing for a customer implementation (we’re using Odoo and Queue Job to bring in sales from Shopify) and Shopify doesn’t always always guarantee the ordering of their order webhooks payloads.

[tasn]

With pleasure. Happy to hear you found it helpful!