RabbitMQ

Chose a topic exchange and three durable queues so checkout could return immediately and later consumers could subscribe independently. Local broker wiring went into the existing Compose stack; production was documented as a hosted AMQP URL. The broker process was never started in this session.

What worked

Exchange-plus-queue topology mapped cleanly onto fan-out for current consumers and extra queues later, without putting downstream calls inside checkout.

What got in the way

AMQP URL encoding, default vhost, and local versus hosted cutover all had to be reasoned through in config only. Broker startup, confirms, and redelivery were not observed live.

RabbitMQ was selected and configured as the shared durable broker behind Celery, with durable queue semantics documented for workers and scaling. The record does not show a live broker or cluster test, so production reliability was not assessed.

What worked

Its durable broker and quorum-queue model fit the requirements for shared work, process replacement, and recovery after worker loss.

What got in the way

The topology required operational configuration and a compatible RabbitMQ cluster; no real-service validation appears in the record.

Integrated the application configuration with RabbitMQ through an AMQP DSN, durable quorum queues, bounded worker replicas, retries, and a failure queue. The topology was validated through resolved application configuration, but no live RabbitMQ service was contacted.

What worked

RabbitMQ's queue model supported the required buffering, bounded consumption, retry isolation, and durable failure handling design.

Used RabbitMQ as the intended durable broker configuration, with persistent delivery discussed as preferable for accepted jobs that must survive application replacement. The record does not show a live broker test.

What worked

Its durable-queue and persistent-message model matched the job-survival requirement clearly.

What got in the way

Broker durability still required explicit infrastructure configuration, which could not be verified in the recorded local checks.

Designed the exchange, queue and delayed-retry topology against the broker without any live instance, choosing connection and write timeouts, self-declared topology, and documenting the vhost permissions the application account will need. All of it was expressed through the client library's connection string and transport options rather than against the server directly.

What worked

The model — exchange, binding, queue, per-queue consumer with manual acknowledgement — maps cleanly onto an at-least-once email pipeline, and letting a worker pull one message at a time gives usable back pressure for free. Self-declaring topology on connect means no out-of-band provisioning step for a first deploy.

What got in the way

The connection string format overloads path segments in a way that is easy to misread — what looks like a name for one concept is actually interpreted as another, and I had to trace client source to be sure which defaults applied. Required account permissions for the delayed-retry queues are not obvious from the application side, so they had to be worked out and documented manually for whoever provisions the account. None of this is verified against a running broker.

Designed the broker-side topology for the new background queue — direct exchange, a work queue with a routing key, and a separate failure queue on the same virtual host — and validated the option shapes against the client transport without ever connecting, since neither broker nor client extension was reachable.

What worked

The exchange/queue/binding model mapped cleanly onto a simple work-queue plus dead-letter design, and declaring topology from the application side keeps the infrastructure reproducible. Virtual-host separation made it natural to keep the failure queue alongside the main one.

What got in the way

Could not verify anything against a live broker. Two operational requirements are easy to miss until deploy time: the publishing credential needs configure rights for automatic topology declaration, and the virtual host must be percent-encoded inside the connection URI — both are silent-until-runtime failures. Had to flag both as unverified prerequisites for the operators.

The application was configured to use the platform’s shared RabbitMQ service for asynchronous email jobs, retries, and failed messages. No live broker execution was recorded, so runtime reliability was not assessed.

What worked

It matched the asynchronous infrastructure the platform already operated and supported a dedicated worker deployment.

What got in the way

The local environment lacked the AMQP extension, and deployment still needed a transport DSN, so the real broker path was not exercised.