AMQP

Problem

A C# checkout service sends orders through a message broker to a Java warehouse service. Both need to agree with the broker on how messages are encoded and how receipt is confirmed. If a connection breaks before confirmation arrives, the sender needs to know whether to retry. If the warehouse slows down, it needs a way to limit incoming messages. A shared protocol gives each participant consistent rules for these situations.

Solution — AMQP

AMQP stands for Advanced Message Queuing Protocol. AMQP 1.0 defines binary message formats and exchanges for transferring messages, reporting delivery outcomes, and controlling message flow, typically over TCP.
Checkout → Broker → Warehouse
Each receiver can report that it accepted a message. The broker accepting an order confirms that handoff; the warehouse confirms its own delivery separately. Receivers also advertise how many messages they are ready to accept, helping slower consumers control the flow. Compatible libraries handle these exchanges across programming languages. Broker persistence settings and application retry logic still determine recovery; if a confirmation is lost, a retry may produce a duplicate, so the warehouse can use the order ID to avoid processing it twice.
Core idea: AMQP provides a standardized protocol for interoperable message-oriented systems.