Definition
AMQP (Advanced Message Queuing Protocol) is an OASIS standard application-layer messaging protocol that supports message queues, flexible routing, reliable delivery, and transactions. Enterprise message middleware such as RabbitMQ and Azure Service Bus use AMQP. Compared to MQTT's lightweight publish/subscribe model, AMQP is more enterprise-oriented, feature-rich, and supports abstractions such as Exchange, Queue, and Binding, making it suitable for complex business scenarios and high-reliability message processing.
Core Features
- Reliable Delivery: Supports at-least-once and exactly-once delivery, message persistence, and acknowledgment (ACK) mechanisms to ensure no message is lost
- Transaction Support: Supports transaction boundaries, allowing multiple messages to be committed or rolled back atomically
- Flexible Routing: Exchange types like Direct, Fanout, Topic, Headers enable publish/subscribe, point-to-point, and topic-based routing
- Multilingual and Interoperable: Standardized protocol, different vendor implementations can interoperate
And MQTT
MQTT is suitable for IoT devices (resource-constrained, weak network) and lightweight publish/subscribe; AMQP is suitable for servers, message middleware, and industrial IoT data processing pipelines. The two can complement each other: devices report to the platform via MQTT, and the platform forwards to backend systems via AMQP. AMQP over TLS ensures transmission security.
Typical Use Cases
Microservice decoupling, asynchronous communication, IoT data processing, financial transactions, log aggregation, etc. The SimtoLink cloud platform supports AMQP integration and can forward device data to customer RabbitMQ, Kafka, and other messaging systems.
The SimtoLink cloud platform supports messaging protocols such as AMQP and can integrate with enterprise messaging middleware to achieve reliable forwarding and asynchronous processing of IoT device data. For scenarios requiring high-reliability message delivery in industrial IoT, connected vehicles, etc., SimtoLink can provide customized AMQP-based connection solutions.
The exchange type decides which queues one message can enter
AMQP hands a message to an exchange first, then pushes it into queues by binding rules. The producer usually does not write a queue directly. A direct exchange matches the full routing key. A fanout exchange ignores the routing key and copies the message to every bound queue. A topic exchange wildcards a dotted hierarchy. A headers exchange compares key-value pairs in the message headers. If the type is wrong, the message does not raise a “protocol error.” It lands silently in the wrong queue, or no consumer matches it. Before go-live, check one sample message: the routing key, the binding pattern, and the target queue must be one set of rules.
Durability has to be set on the exchange, the queue, and the message together. If only the queue is declared durable, the message is still transient. After the broker restarts the queue is still there and the message is gone. If an IoT report must survive a power loss, the delivery mode must be persistent, and the broker must acknowledge only after the message is on disk. An in-memory queue is only suitable for telemetry that can be sampled again.
Acknowledgement mode is not the same thing as a transaction boundary
A consumer acknowledgement means “I have finished processing this, you may delete it.” Automatic acknowledgement deletes the message as soon as it is handed over. If the consumer crashes, the message is lost. Manual acknowledgement should wait until the business write to the database has succeeded. Acknowledging halfway tells the broker it may discard data that has not landed. A negative acknowledgement can requeue or discard. Negatively acknowledging again and again with no delay burns CPU on the same bad message. Send it to a dead-letter queue instead of redelivering forever.
A transaction makes a group of publishes either all commit or all roll back. The cost is that every message waits for the transaction to finish, and throughput drops sharply. Publisher confirms are asynchronous: the broker writes the message and then returns a batch receipt. Use a transaction only for reconciliation messages that need atomicity. A device pipeline fits publisher confirms plus persistence better. Stacking both mechanisms on the same channel makes a timeout hard to read: the transaction may not have committed, or the confirm may not have come back.
An oversized prefetch window fills consumer memory first
Prefetch limits how many unacknowledged messages the broker will push to one consumer at a time. Set too high, a slow consumer piles messages in local memory, the broker believes they are delivered, and idle consumers starve. Set too low, a fast consumer waits often for the next batch and throughput stays down. The basis is how long one message takes to handle. If it is parsed and forwarded, prefetch can be looser. If it must write to an external system, prefetch should sit near the concurrent processing capacity, not at the maximum the channel can hold.
If the SimtoLink cloud platform forwards device data to an enterprise AMQP broker, the cellular side only guarantees arrival from the device to the platform. Routing, acknowledgement, and prefetch after the exchange are the message bus’s own job. If the platform shows a successful report and the business database has no record, check the binding key and the consumer acknowledgement before suspecting that the IoT SIM card dropped. A channel heartbeat timeout tears down the whole connection, and every unacknowledged message on it must be redelivered. The heartbeat should be longer than the longest business-processing stall.
A message that entered the dead-letter queue is not a business success
When a message is rejected, expires, or the queue hits its length limit, it can be moved to a dead-letter exchange. Dead-lettering only means the original queue will not process it. It does not mean the business action ran. If the dead-letter consumer is written as “record one success,” the site can show a valve that never moved and a ledger that says the command completed. A dead-lettered message should keep the original routing key, the rejection reason, and the time it first entered the queue. A person or a separate compensation program then decides whether to replay or discard it. A dead letter with no reason field cannot later be split into expiry, rejection, or a full queue.
Replay must deduplicate on a business sequence number, because the original message may already have been partly executed. Putting the dead letter back into the same queue unchanged, while the consumer still rejects it, creates a loop. After the SimtoLink platform hands data to the enterprise broker, success depends on broker acknowledgements and the dead-letter count, not only on the bytes the platform sent. If dead letters pile up on the hour and the acknowledgement count does not move, stop the replay and check the consumer. Raising the IoT SIM report rate only fills the dead-letter queue faster.