Nobody Needs Reliable Messaging

This is a solid article about reliable messaging. The crux is that reliable delivery does not ensure a reliable conversation.

Consider a bookstore app that uses a messaging service with a deliver-once guarantee (whether this is possible is another topic). The client sends an order

{time: t0, books: [{title: t, qty: q, price: p}, …]} 

Though the order arrives, until the server confirms (the article terms such a confirmation a business ACK to distinguish the messaging service’s transport ACK), the client cannot be sure the order’s titles are valid, enough books are in stock, the price hasn’t changed, the store closed, etc. If the client is restarted after receiving the confirmation but before displaying it, the user might reorder resulting in a duplicate order. (Showing recent orders is a UI solution but the user might not notice the widget.)

The recommended solution is idempotent requests: the server ignores duplicate requests. In the article, a client-assigned UUID de-duplicates the request. Another option is to use the request’s semantics [{ title: …, qty: …, time: … }, …] to de-duplicate: the server queries for identical, recent orders. The final option is a two-phase pattern. First, the client sends its shopping cart and the server returns an id. Second, the client orders the cart. The server times out unused carts. (The cart storage is a potential DoS attack but that’s a different topic.)