Channel Purger

Le bouton 'vider la queue' — utile en cas d'incident grave.

Problème

Pendant un incident, une queue accumule des messages obsolètes (ORDERS d'il y a 6h plus pertinents) ou poison messages qui bloquent les consumers. Comment vider proprement sans tout perdre ?

Forces

• Vider une queue sans archive = perte de preuves.
• Vider sans filtrer = perdre aussi les messages valides.
• Vider avec filtre complexe = besoin d'un outil contrôlé.
• Audit requis : qui a purgé quoi, quand.

Solution

Implémenter un Channel Purger : un outil CLI/dashboard qui (1) demande l'authentification, (2) accepte un filtre (avant une date, par partenaire, par type), (3) archive les messages purgés dans un canal d'audit (purged.[date].audit), (4) supprime de la queue cible, (5) logge l'action avec l'opérateur. Réversible : ré-injection depuis l'archive possible.

Implémentation EDI

En EDI, le Channel Purger est typiquement un script ops avec confirmation, lié au Control Bus, utilisé pendant les RCAs : 'purger tous les messages du partenaire X plus vieux que 2h pour stopper la cascade'. Archive obligatoire dans un topic Kafka edi.audit.purged avec retention 7 ans. RBAC : seuls les SREs senior peuvent déclencher.

Anti-patterns

• Purge sans archive — perte irréversible de preuves.
• Purge sans filtre — vider tout le edi.orders à 3h du matin pendant un incident.
• Purge automatique en boucle — masque les vrais problèmes.

Patterns liés

• Control Bus — canal de déclenchement.
• Dead Letter Channel — destination alternative.

Sources

• Hohpe G., Woolf B. — EIP, Channel Purger (p. 572). www.enterpriseintegrationpatterns.com/patterns/messaging/ChannelPurger.html