1. 4
  1.  

  2. 12

    IronMQ does not guarantee exactly-once delivery; failure or delay in either the client or the network can result in multiple delivery attempts. I don’t understand how this got published; it’s like claiming to have solved two-generals over the public internet.

    1. 5

      The exactly-once delivery is not actually that interesting.

      The reason being: your transport guaranteeing exactly once delivery doesn’t stop you from having to handle this in your application. The reason you have to handle this in your application is because: what happens when your app dies mid-processing a request? And once you can handle it in your app layer, your transport guaranteeing it becomes less interesting.

      1. 4

        This is more or less what I tell people. Just make message processing idempotent and you can ignore an entire class of problems. You should want that processing to be idempotent anyway.

        If you liked it, you should’ve slapped a unique id on it. (This is the motivation for Blacktip. For me, anyway.)