Channel Purger
The "drain the queue" button — useful during severe incidents.
Problem
During an incident, a queue accumulates stale messages (6h-old ORDERS no longer relevant) or poison messages blocking consumers. How to drain cleanly without losing everything?
Forces
- Draining a queue without archive = loss of evidence.
- Draining without filtering = also losing valid messages.
- Draining with complex filter = need for a controlled tool.
- Audit required: who purged what, when.
Solution
Implement a Channel Purger: a CLI/dashboard tool that (1) authenticates, (2) accepts a filter (before a date, by partner, by type), (3) archives purged messages to an audit channel (purged.[date].audit), (4) deletes from the target queue, (5) logs the action with the operator. Reversible: re-injection from the archive possible.
EDI implementation
In EDI, Channel Purger is typically an ops script with confirmation, tied to Control Bus, used during RCAs: "purge all messages from partner X older than 2h to stop the cascade". Mandatory archive in edi.audit.purged Kafka topic with 7-year retention. RBAC: only senior SREs can trigger.
Anti-patterns
- Purge without archive — irreversible loss of evidence.
- Purge without filter — wiping out all of edi.orders at 3 AM during an incident.
- Automatic purge in a loop — masks real problems.
Related patterns
- Control Bus — triggering channel.
- Dead Letter Channel — alternative destination.
Sources
- Hohpe G., Woolf B. — EIP, Channel Purger (p. 572). www.enterpriseintegrationpatterns.com/patterns/messaging/ChannelPurger.html