The mapping
Each AMQP concept maps onto the log so that standard clients behave as they expect, while the durability and replay of a log come for free.
| AMQP | XCON Quee |
|---|---|
| durable queue | its own topic + subscription |
| exchange | a routing table evaluated at publish time (direct/fanout/topic, full */#) |
basic.ack | advance the subscription cursor (an invisible "delete") |
basic.qos prefetch | the credit window |
| publisher confirm | the engine fsync (returned after the durable append) |
| SASL PLAIN password | the bearer token |
| message properties | round-tripped through the message headers |
Because acking is a cursor move and not a delete, the log stays for retention and replay. A brand-new queue starts empty (latest), which matches AMQP's "no history" expectation; an existing subscription resumes where it left off.
Route at publish time
A publish to a named exchange is routed the instant it is published: the
exchange's bindings are evaluated (direct = exact key, fanout = all, topic =
*/# match) and one durable copy is written per matched queue. This is why a
topic-exchange application runs unchanged — the full wildcard grammar is
honoured — while delivery stays a simple cursor read.
Cross-protocol
A queue-topic is one log both surfaces share. A message published by the native SDK is consumed by an AMQP client on the same queue, and vice versa — same topic, same cursor, same framing.