It’s actually based on the applicative protocol that the message represent. Once we know that we have the inventory needed to justify a shipment to the client (which may not be the entire order) we begin a protocol with our shipping partners seeing who can ship by when and how much of a discount we’ll get. If it takes too long to get a response to those messages from our preferred shipping partner, we’ll turn to a different partner.

In short, there’s not just one message (ShipItemsToCustomerMessage), but several.

Hope that makes sense.

I have a couple of questions:

Would it be fare to say that without Idempotent messages the use timeout, long running processes and the use of smaller messages would have required more processing and overheads? And one should set out in future to always design systems to use Idempotent messages?

In the article you state:

“Our company may work with multiple shipping partners, yet one is usually a preferred partner. There are cases where our preferred partner’s systems may be down, slow, or just not responding. In those cases, logic dictates that we should wait for up to five minutes for a response, and if no response arrives, to choose a different shipping partner.”

Doesn’t this introduce some subtle coupling to the partners, you are required to know how they process (slow\delayed) messages otherwise the shipping request could be fulfilled by more than 1 partner?

Thanks,
Ollie

Thanks very much for that.

I’m circulating it around my work as a great example of things to do (and avoid).

Thanks,
John

I have did similar observations as you explained in your solution. Additionally we had in our solution cope with near real-time data processing, geo scaling and high available persistent storage accessible across different geo locations.

While I have read article it comes up to my mind some related items to your solution which I would be glad if you can explain.

1) Would you recommend to use durable messaging for systems where are same requirements on data reliability as you had – i.e. not lose any message? If yes then why your final version of solution not using that? If you not recommend that then why.

2) In section “From large message to small one” you are saying that you break up large message into several small one and only change needed for was add flag indicating last update? How/if do you cope with out of order updates and how do you indicate on recipient side that some incremental update/addition is missing from client side.

I appreciate your answer.

Regards,

Libor

Glad you liked it.