5 ms·

Credit card authorization might be better suited to a synchronous request, versus going through a message queue.

• Rapzid 12y ago
  It doesn't really matter either way. Unless you are using distributed transaction protocols, you pretty much MUST store-and-forward and have idempotent processes in the consumer/receiver to guarantee something happens. Usually the easiest way is to generate a transaction ID, such as a UUID, at the very start and use it end-to-end as indicated by the earlier nonce comment. Then each step along the way can either locally dedupe, or refer to a shared database/API with it.
  • jaimeyap 12y ago
    Well one difference is being able to easily propagate failures end to end. Agreed about idempotent processes in the "consumer" processes. But I generally prefer marking an end user session in a persistent store before propagating the request for payment (effectively acting as a sticky current transaction ID), and making synchronous requests down the chain versus generating a transaction ID and doing a bunch of async message queuing. It's just easier to know when something didn't work and display the appropriate user feedback. But your point is valid.