The key question
A queue is a processing contract. Which messages may be lost? When is a message considered complete? Can redelivery trigger the same business action again? Without those answers, choosing a replacement is premature.
What to inventory
- Inventory queues, producers, consumers and message types.
- Determine whether data changes and messages are transactionally coupled.
- Document retries, expiry, priorities and dead-letter behaviour.
Design the target deliberately
Depending on the requirement, a dedicated broker, a transactional outbox pattern or a database-backed queue can be appropriate. PostgreSQL LISTEN/NOTIFY is a notification mechanism, not a drop-in replacement for durable AQ processing. Durability and delivery logic must be explicit in the target design.
A concrete validation step
A good pilot uses one bounded message type. Document the complete path from business event to confirmed outcome and define restart behaviour at every interruption point.
Evidence required before sign-off
- Simulate a consumer failure between processing and acknowledgement.
- Handle duplicate messages using business keys.
- Test database and broker failures separately.
- Monitor backlog, restart behaviour and failed messages.
Primary sources & further reading
These recommendations are engineering guidance. Specific options depend on source and target versions, privileges and operating model.