Coupez la moitié de vos topics : un audit sur 30 jours pour Pub/Sub, Kafka et SNS

Vous avez probablement, à cet instant, un topic dont personne n’a besoin. Il est toujours actif, toujours facturé, il réveille l’astreinte pendant une tempête de retries — et aucune valeur métier n’atteint un utilisateur. L’histoire, largement relayée ce mois-ci, d’une équipe qui a coupé Pub/Sub sans que personne ne s’en aperçoive n’était pas un hasard. Dans nos audits nearshore pour des startups et scale-ups US, nous constatons régulièrement que 20–40 % du trafic d’événements est du ballast : topics zombies, fanouts redondants, analytique accidentelle et flux « au cas où » dont personne n’est propriétaire.

Si vous exploitez Pub/Sub, Kafka (autogéré ou Confluent), SNS/SQS ou Kinesis, vous payez deux fois : en argent et en bruit. L’argent, c’est évident. Le bruit, c’est pire : retries en cascade, alertes de retard, et une taxe « systèmes distribués » à chaque déploiement. Le correctif n’est pas une réécriture sur six mois. C’est un audit de 30 jours, à faible risque, basé sur des circuit breakers avec garde-fous et brownouts. Voici le mode opératoire.

Pourquoi c’est important maintenant

• L’infrastructure événementielle a grandi plus vite que votre modèle de propriété. Publier est trivial ; déprécier est rare.
• Les fournisseurs encouragent le fanout. Un événement vers trois abonnements, c’est 3× de livraisons et 3× de surfaces de défaillance.
• Les fonctionnalités pilotées par l’IA amplifient le volume d’événements (clickstreams, traces, embeddings) et masquent le gaspillage sous l’« analytique ».
• Le bruit récent du secteur (« nous avons coupé Pub/Sub… ») a illustré ce que nous observons sur le terrain : pas de dégâts, grosses économies.

Dans un produit typique de série B–D avec 80–200 topics/flux, 150–600 groupes de consommateurs et quelques producteurs à fort débit, nous voyons :

• 10–30 % de topics sans consommateurs effectifs (aucun ack, aucun effet matérialisé, ou consommateur hors ligne depuis > 30 jours).
• 5–10 % de fanouts d’analytique qui dupliquent des batchs ou la CDC de l’entrepôt.
• 3–5 % de miroirs de notifications/événements vers plusieurs bus pour une « portabilité » qui n’a jamais vu le jour.
• 1–3 % de violations franches de politique (PII dans les payloads, réplication inter‑régions sans DPA).

Nettoyer tout cela réduit de 15 à 35 % la dépense mensuelle de messagerie et diminue les alertes d’incident d’environ 25 à 40 %, parce que votre système cesse de retenter dans le vide.

Le prisme de l’audit : cinq questions par flux

Ne commencez pas par les coûts ; commencez par les effets. Pour chaque triplet topic/flux/abonnement, répondez :

1. Que change-t-il pour un utilisateur si ce flux s’arrête 24 heures ? Nommez l’écran, l’API ou le SLA. Si vous ne pouvez pas, c’est suspect.
2. Le système consommateur peut‑il se remettre d’événements manquants ? Si la réponse est « nous pouvons recalculer depuis la source de vérité », c’est un candidat au brownout.
3. Ces données sont‑elles disponibles par un chemin moins coûteux ? Table d’entrepôt, CDC, batch périodique, appel direct de service ou cache en périphérie.
4. Qui en est propriétaire ? Si la propriété se résume à un handle Slack et non à une équipe avec rotation d’astreinte, c’est de la dette.
5. Quel est le multiplicateur de redondance ? Nombre de fanouts × tentatives de livraison × replays. Les grands multiplicateurs doivent être ré‑justifiés.

Mesurez avant d’agir : les sept métriques qui révèlent les zombies

Exportez ceci par topic/flux et par abonnement/groupe de consommateurs sur les 30 derniers jours :

• Taux d’ingestion (messages/s, octets/s) et taux de livraison par consommateur.
• Vivacité des consommateurs (horodatage du dernier ack, délai d’ack moyen, pourcentage du temps en consommation).
• Retard (offsets pour Kafka ; ancienneté du plus ancien non‑ack pour Pub/Sub/SQS).
• Comptes de retry/backoff et volume de DLQ.
• Taux de doublons (clés de message/événements vus > 1 à travers les groupes de consommateurs en N minutes).
• Volatilité des schémas (versions/mois) et violations de schéma (payloads invalides par 10 k messages).
• Indicateur de coût : livraisons × octets moyens de la charge utile (egress), heures de stockage × partitions/rétention, octets de réplication inter‑régions.

Tracez trois distributions : topics avec zéro ack récent, topics dont le retard des consommateurs augmente sans incident ouvert, et topics dont le total d’octets livrés > 3× les octets publiés. Cette dernière met au jour des fanouts multi‑abonnements coûteux où personne n’explique les deux consommateurs en plus.

Le plan sur 30 jours : à faible risque, réversible et visible

Jours 1–7 : inventorier, étiqueter et tracer

• Inventoriez sources et puits. Émettez un en‑tête producteur sur chaque message pendant 30 jours : x-stream-owner, x-purpose (impact client, analytique, cache interne), x-pii (aucune, pseudonymisées, sensibles) et x-criticality (niveau 0–3).
• Cartographiez les effets. Pour chaque groupe de consommateurs, nommez l’effet côté utilisateur : « la page commandes affiche un statut à jour », « e‑mails de facturation », « tableau de bord interne ». Pas d’effet, pas de protection.
• Activez le shadow tracing. Échantillonnez 1–5 % des messages et mettez en corrélation avec les appels d’API en aval, les écritures DB, ou la télémétrie UI. Si les flux ne corrèlent pas, ils sont probablement morts.
• Fixez des bases de coûts. Même si la tarification du fournisseur est opaque, calculez un score relatif : livraisons × octets × réplications. Pas besoin de précision en dollars pour choisir des cibles.

Jours 8–14 : classifier et rédiger la kill list

• Classez les flux : Niveau 0 (utilisateur/bloquant), Niveau 1 (utilisateur/dégradation acceptable), Niveau 2 (interne), Niveau 3 (analytique/backfill uniquement).
• Identifiez les zombies : zéro ack en 30 jours, ou consommateurs avec vivacité < 5 % et aucun historique d’incident.
• Trouvez les fanouts redondants : même payload publié sur plusieurs bus (par ex., SNS et Kafka) « au cas où ». Choisissez‑en un. Laissez un pont minimal si vous avez réellement besoin des deux.
• Repérez l’inflation de payload : gros blobs (100–500 KB) dans des événements utilisés pour un seul champ en aval. Remplacez par des IDs et fetch‑on‑read pour les Niveaux 1 et plus.
• Candidats au brownout : flux de Niveau 1 ou 2 dont les consommateurs peuvent recalculer ou tolérer une staleness de 24 h. Marquez‑les pour des essais de circuit breaker.

Jours 15–21 : installez les garde‑fous

• Introduisez des circuit breakers par abonnement. Abandon conditionné par feature flag à l’ingestion ou à la livraison d’abonnement. Par défaut, fail‑open pour les Niveaux 2–3 (drop des messages), fail‑closed pour le Niveau 0.
• Ajoutez une assurance de replay. Miroitez les événements bruts vers un stockage objet peu coûteux (par ex., GCS/Amazon S3) pendant 7–14 jours avec un journal JSONL ou Parquet compacté. Si une coupure casse quelque chose, réhydratez.
• Publiez des avis de dépréciation dans le flux lui‑même (un message de contrôle toutes les N minutes) et dans vos communications internes. Si personne ne crie, c’est un signe.
• Instantanés d’observabilité. Un tableau de bord par candidat : ingestion/livraisons/retard/retries, horodatage du dernier effet, et un grand nom de propriétaire.

Jours 22–30 : brownouts, coupures et consolidation

• Lancez des brownouts : baisse d’1 heure à 5–10 % du trafic en heures ouvrées pour les Niveaux 2–3. Puis 4 heures à 100 % pour le Niveau 3 en heures creuses. Surveillez les tickets support, les SLO et les tableaux de bord.
• Supprimez ou désactivez les zombies (pas d’acks, pas d’effet). Pas de demi‑mesure. Documentez la dépréciation avec une date de fin et un contact.
• Consolidez les fanouts. Faites passer les consommateurs purement analytiques par un bus unique et batcher vers l’entrepôt. Supprimez les fanouts directs vers trois puits analytiques.
• Réduisez la rétention sur les chemins chauds ayant une solide source de vérité. Si vous pouvez rejouer depuis la DB ou le stockage objet, vous n’avez pas besoin de 7 jours d’arriéré dans Kafka.
• Dimensionnez correctement les partitions. Si 80 % des partitions sont quasi inactives, divisez‑les par deux. Pour Pub/Sub et SQS, réduisez le parallélisme là où il gonfle le coût des requêtes sans gain de latence.

À quoi ressemblent les économies (ordres de grandeur réalistes)

La tarification de la messagerie est un labyrinthe. Vous n’avez pas besoin de dollars exacts pour décider. Utilisez ces ordres de grandeur pour cadrer les attentes :

• Le volume de livraisons est le plus grand levier. Si vous avez 200 M d’événements/mois et en moyenne 2,5 abonnements, vous traitez 500 M de livraisons. Supprimer un abonnement redondant sur 30 % des topics peut réduire de 15 à 25 % les livraisons totales immédiatement.
• La taille des payloads compte. Passer d’une charge utile moyenne de 20 KB à 3–5 KB (IDs, pas de blobs) réduit l’egress et le stockage de ~70–85 % pour ces flux. Si seulement 30 % de votre trafic est boursouflé, vous économisez tout de même ~20 % d’egress global.
• La rétention est une dépense furtive. Réduire la rétention Kafka de 7 jours à 48 heures sur les chemins chauds (tout en miroirant vers un stockage objet) peut rogner 40–60 % du stockage des brokers. Pour du Kafka managé, c’est une baisse de facture directe. En autogéré, ce sont moins de disques et moins d’alertes « Kafka is out of space ».
• Les partitions et connexions pèsent sur l’exploitation. Réduire de 30 à 50 % le nombre de partitions sur des topics sous‑utilisés supprime des tempêtes de rééquilibrage et réduit le CPU de plusieurs dizaines de pourcents.

Dans des entreprises qui dépensent de quelques milliers à plusieurs dizaines de milliers par mois en messagerie (Confluent, Pub/Sub, SNS/SQS, Kinesis), nous observons 15 à 35 % de réduction de coûts en 30–60 jours avec cet audit, plus une baisse mesurable du volume d’incidents. Le gain opérationnel dépasse souvent l’écart de facture.

La gouvernance qui empêche le gaspillage de repousser

Couper est la partie facile. Maintenir l’état coupé demande trois habitudes.

1) Rendre la propriété in‑band

• Tous les producteurs doivent renseigner x-stream-owner avec un alias d’équipe d’astreinte. Les politiques du broker rejettent les messages qui ne l’ont pas.
• Tous les consommateurs doivent enregistrer un tag x-criticality et une classification de données. Pas de tag, pas d’abonnement.
• Les topics sans équipe propriétaire expirent automatiquement sous 90 jours, sauf renouvellement.

2) Intégrer les brownouts au CI/CD

• Chaque nouveau flux est livré avec un flag de circuit breaker et un test de brownout d’1 heure en staging qui valide que les SLO côté utilisateur restent au vert ou se dégradent dans les bornes définies.
• Bloquez les déploiements des flux qui échouent au test de brownout sans dérogation Niveau 0 approuvée.

3) Cessez de prétendre que tous les événements sont temps réel

• Définissez deux voies : opérationnelle (latence < 1 s, Niveaux 0–1) et analytique (latence à l’échelle de la minute, Niveaux 2–3). Par défaut, orientez les nouveaux besoins analytiques vers du batch ou micro‑batch via l’ingestion de votre entrepôt (par ex., CDC + modèles incrémentaux).
• Auditez trimestriellement : tout consommateur analytique sur votre bus opérationnel doit obtenir une exception ou migrer.

Les compromis architecturaux à reconnaître

• Event‑sourcing vs. event‑driven. Si vous utilisez le log comme source de vérité, ne réduisez pas la rétention ou les partitions à l’aveugle. Votre stratégie de replay conditionne votre disponibilité.
• Couplage inter‑services. Remplacer des événements « lourds » par des IDs peut réintroduire des lectures synchrones. C’est acceptable pour les Niveaux 1–3 ; pour les chemins de Niveau 0 avec SLO de latence stricts, gardez un état minimal dans l’événement (hashes, IDs de version) et mettez en cache intelligemment.
• Latence analytique. Sortir l’analytique du bus chaud peut faire passer les tableaux de bord de « temps réel » à « quasi temps réel » (secondes à minutes). Demandez‑vous quelles décisions exigent réellement une fraîcheur sous la seconde. La plupart n’en ont pas besoin.
• Sécurité et conformité. Miroiter vers un stockage objet pour le replay est moins cher, mais vous devez appliquer les mêmes contrôles d’accès, chiffrement et politiques de rétention — ou mieux. L’équipe conformité doit valider.

Modes de défaillance courants (et comment les éviter)

• Consommateurs silencieux. Un service lit mais jette par terre. Détectez‑les via des « balises d’effet » : si un consommateur écrit dans une DB/une table, émettez un événement heartbeat périodique avec le dernier offset appliqué. Pas de balise = pas d’effet.
• Duplication fantôme. Deux équipes publient le même événement avec des schémas légèrement différents. Corrigez avec un registre, des contrats et une propriété claire. Les éditeurs en double sont un anti‑pattern ; fusionnez ou dépréciez.
• Cécité au brownout. Vous avez fait un brownout en période calme et déclaré victoire. Programmez au moins un essai en heures de pointe pour les Niveaux 1–2 avant de couper.
• Optimiser le mauvais bus. Certaines équipes s’obsèdent pour Kafka alors que 60 % du coût est dans les fanouts Pub/Sub ou les livraisons HTTP SNS. Mesurez tous les bus ; optimisez d’abord le plus coûteux.

Ce qu’il faut automatiser ensuite

• Scorecards de topics. Une tâche nocturne étiquette les topics avec un score de dette (pas de propriétaire, faible vivacité, fanout élevé, retries élevés) et ouvre automatiquement des tickets au‑delà de seuils.
• Garde‑fous budgétaires. Budgets par bus qui déclenchent automatiquement des brownouts pour les flux de Niveau 3 lorsque la dépense L7 dépasse la prévision de 20 %+.
• Linting de schéma. Un hook CI qui rejette les payloads dépassant un seuil de taille ou contenant des champs interdits (par ex., PII brutes), sauf dérogation.
• Bots de consolidation. Pour les consommateurs analytiques duplicatifs, proposez une sortie unique vers l’entrepôt avec un diff de contrat de données et une fenêtre de migration.

Où le nearshore s’insère

Si votre équipe est à capacité, c’est une mission propre et bornée pour un pod nearshore : 4–6 semaines, 2–3 ingénieurs en immersion, un lead SRE et un relais produit pour valider l’impact utilisateur. Attendez‑vous à 6–8 heures de recouvrement avec les fuseaux US depuis Brazil, des démos hebdomadaires, des rapports de brownout et une « cut list » concrète avec plans de rollback. C’est le genre de travail qui s’autofinance dès le premier trimestre — parce que les topics zombies ne discutent pas avec les tableurs.

Le bénéfice silencieux : moins d’alertes et des déploiements plus rapides

Quand vous éliminez le gaspillage, vous réduisez les tempêtes de rééquilibrage, les chaînes de backpressure et les cas limites d’idempotence qui n’apparaissent qu’à 2 h du matin. Moins de consommateurs, c’est moins d’endroits où fuiter des PII, moins de politiques IAM à gérer, et un périmètre d’impact plus réduit pour les inévitables mauvais déploiements. Vous n’économisez pas seulement de l’argent ; vous achetez de la clarté.

À retenir

• Vous exécutez probablement 20–40 % de trafic d’événements zombie ou redondant. Mesurez d’abord les effets, pas les dollars.
• En 30 jours, avec des circuit breakers et des brownouts, vous pouvez supprimer ou consolider en toute sécurité un tiers de vos topics.
• Concentrez‑vous sur les livraisons, la taille des payloads, la rétention et les partitions — ce sont vos plus grands leviers.
• Empêchez le gaspillage de repousser avec des tags de propriété in‑band, des brownouts en CI et une gouvernance à deux voies (opérationnelle vs. analytique).
• Le gain opérationnel (moins d’incidents, propriété plus claire) dépasse souvent la baisse de facture.