Schalten Sie die Hälfte Ihrer Topics ab: Ein 30‑Tage‑Audit für Pub/Sub, Kafka und SNS

Sie haben höchstwahrscheinlich gerade ein Topic, das niemand braucht. Es ist immer noch heiß, verursacht Kosten, paged den Bereitschaftsdienst während eines Retry‑Sturms – und null Business Value erreicht eine Nutzerin oder einen Nutzer. Eine viel geteilte Dev‑Story diesen Monat darüber, Pub/Sub abzuschalten und dass es niemand bemerkte, war kein Zufall. In unseren Nearshore‑Audits für US‑Startups und Scale‑ups finden wir routinemäßig, dass 20–40% des Event‑Traffics Ballast sind: Zombie‑Topics, redundante Fanouts, versehentliche Analytics und „für alle Fälle“-Streams ohne klare Ownership.

Wenn Sie Pub/Sub, Kafka (self‑managed oder Confluent), SNS/SQS oder Kinesis betreiben, zahlen Sie doppelt: Geld und Lärm. Das Geld ist offensichtlich. Der Lärm ist schlimmer: kaskadierende Retries, Lag‑Alarme und eine Distributed‑Systems‑Steuer bei jedem Deploy. Die Lösung ist kein sechsmonatiger Rewrite. Es ist ein 30‑tägiges, risikoarmes Circuit‑Breaker‑Audit mit harten Gates und Brownouts. Hier ist das Playbook.

Warum das jetzt wichtig ist

• Event‑Infrastruktur skaliert schneller als Ihr Ownership‑Modell. Publizieren ist trivial; das Ausphasen ist selten.
• Vendoren belohnen Fanout. Ein Event mit drei Subscriptions erzeugt 3× Zustellungen und 3× Fehlflächen.
• KI‑Features verstärken Event‑Volumen (Clickstreams, Traces, Embeddings) und verstecken Verschwendung unter „Analytics“.
• Jüngste Branchendiskussionen („wir haben Pub/Sub abgeschaltet…“) zeigen, was wir im Feld sehen: keine Explosion, aber große Einsparungen.

In einem typischen Series‑B‑bis‑D‑Produkt mit 80–200 Topics/Streams, 150–600 Consumer‑Gruppen und ein paar High‑Throughput‑Producern sehen wir:

• 10–30% Topics ohne effektive Consumer (keine Acks, kein materialisierter Effekt oder Consumer >30 Tage offline).
• 5–10% Analytics‑Fanouts, die Batch‑Jobs oder Warehouse‑CDC duplizieren.
• 3–5% Benachrichtigungs-/Event‑Spiegelungen auf mehrere Busse für „Portabilität“, die nie gebraucht wurden.
• 1–3% klare Policy‑Verstöße (PII in Payloads, Cross‑Region‑Replikation ohne DPA).

Das Aufräumen reduziert die monatlichen Messaging‑Kosten um 15–35% und verringert On‑Call‑Pages um ~25–40%, weil Ihr System nicht länger ins Leere retried.

Der Audit‑Blick: Fünf Fragen pro Stream

Starten Sie nicht mit Kosten; starten Sie mit Effekten. Beantworten Sie für jedes Topic/Stream/Subscription‑Tupel:

1. Was ändert sich für Nutzerinnen/Nutzer, wenn dieser Stream 24 Stunden pausiert? Nennen Sie den Screen, die API oder das SLA. Können Sie das nicht, ist der Stream verdächtig.
2. Kann das konsumierende System fehlende Events kompensieren? Wenn die Antwort lautet „wir können aus der Source of Truth nachberechnen“, ist das ein Brownout‑Kandidat.
3. Ist diese Daten auch über einen günstigeren Pfad verfügbar? Warehouse‑Tabelle, CDC, periodischer Batch, direkter Service‑Call oder Edge‑Cache.
4. Wer besitzt ihn? Ist die Eigentümerschaft ein Slack‑Handle statt ein Team mit Rufbereitschaft, ist das technische Schuld.
5. Wie hoch ist der Redundanz‑Multiplikator? Fanout‑Anzahl × Zustellversuche × Replays. Hohe Multiplikatoren brauchen neue Rechtfertigung.

Messen vor dem Handeln: die sieben Metriken, die Zombies entlarven

Exportieren Sie diese pro Topic/Stream und pro Subscription/Consumer‑Gruppe für die letzten 30 Tage:

• Ingest‑Rate (Nachrichten/s, Bytes/s) und Delivery‑Rate pro Consumer.
• Consumer‑Liveness (Zeitstempel des letzten Ack, durchschnittliche Ack‑Verzögerung, Prozent der Zeit konsumierend).
• Lag (Offsets bei Kafka; Alter der ältesten unbestätigten Nachricht bei Pub/Sub/SQS).
• Retry-/Backoff‑Zählungen und DLQ‑Volumen.
• Duplicate Ratio (Message‑Keys/Events >1× über Consumer‑Gruppen innerhalb von N Minuten gesehen).
• Schema‑Churn (Versionen/Monat) und Schema‑Verstöße (fehlerhafte Payloads pro 10.000 Nachrichten).
• Kosten‑Proxy: Zustellungen × durchschnittliche Payload‑Bytes (Egress), Storage‑Stunden × Partitionen/Retention, Cross‑Region‑Replikations‑Bytes.

Plotten Sie drei Verteilungen: Topics mit null jüngsten Acks, Topics mit wachsendem Consumer‑Lag ohne eröffnete Incidents und Topics, bei denen gelieferte Gesamtbytes > 3× publizierte Bytes sind. Letzteres deckt teure Multi‑Subscription‑Fanouts auf, bei denen niemand die zusätzlichen zwei Consumer erklären kann.

Der 30‑Tage‑Plan: risikoarm, reversibel und sichtbar

Tag 1–7: Inventarisieren, taggen und tracen

• Quellen und Senken inventarisieren. Emittieren Sie 30 Tage lang auf jeder Nachricht einen Producer‑Header: x-stream-owner, x-purpose (customer-impacting, analytics, internal cache), x-pii (none, pseudonymous, sensitive) und x-criticality (tier 0–3).
• Effekte abbilden. Benennen Sie für jede Consumer‑Gruppe den nutzerseitigen Effekt: „Bestellseite zeigt aktuellen Status“, „Billing‑E‑Mails“, „internes Dashboard“. Kein Effekt, kein Schutz.
• Schatten‑Tracing aktivieren. Samplen Sie 1–5% der Nachrichten und korrelieren Sie zu nachgelagerten API‑Calls, DB‑Writes oder UI‑Telemetrie. Wenn Streams nicht korrelieren, sind sie vermutlich tot.
• Kosten‑Baselines setzen. Auch wenn Ihr Vendor‑Pricing opak ist, berechnen Sie einen relativen Score: Zustellungen × Bytes × Replikationen. Sie brauchen keine Dollar‑Präzision, um Ziele zu wählen.

Tag 8–14: Klassifizieren und die Kill‑Liste entwerfen

• Streams klassifizieren: Tier 0 (nutzerrelevant/blockierend), Tier 1 (nutzerrelevant/Degradation ok), Tier 2 (intern), Tier 3 (Analytics/nur Backfill).
• Zombies identifizieren: null Acks in 30 Tagen oder Consumer mit Liveness < 5% und ohne Incident‑Historie.
• Redundante Fanouts finden: gleiche Payload auf mehrere Busse publiziert (z. B. SNS und Kafka) „für alle Fälle“. Wählen Sie einen. Lassen Sie eine minimale Bridge, falls Sie wirklich beide brauchen.
• Payload‑Aufblähung erkennen: große Blobs (100–500 KB) in Events, die downstream für ein einziges Feld genutzt werden. Ersetzen Sie durch IDs und Fetch‑on‑Read in Tier 1+.
• Brownout‑Kandidaten: Tier‑1‑ oder ‑2‑Streams, bei denen Consumer nachberechnen können oder 24h Staleness tolerieren. Für Circuit‑Breaker‑Trials markieren.

Tag 15–21: Sicherheitsleitplanken einziehen

• Circuit Breaker pro Subscription einführen. Per Feature‑Flag gesteuertes Droppen am Ingress oder bei der Subscription‑Zustellung. Standard: fail‑open für Tier 2–3 (Nachrichten verwerfen), fail‑closed für Tier 0.
• Replay‑Versicherung hinzufügen. Spiegeln Sie Raw‑Events für 7–14 Tage in günstigen Objektspeicher (z. B. GCS/Amazon S3) als kompaktiertes JSONL‑ oder Parquet‑Log. Falls ein Kill etwas bricht, rehydrieren.
• Deprecation‑Hinweise veröffentlichen – im Stream selbst (alle N Minuten eine Control‑Message) und in Ihrer internen Kommunikation. Wenn niemand reagiert, ist das ein Signal.
• Observability‑Snapshots. Ein Dashboard pro Kandidat: Ingest/Deliveries/Lag/Retries, letzter Effekt‑Zeitstempel und der Owner‑Name prominent.

Tag 22–30: Brownouts, Cuts und Konsolidierung

• Brownouts fahren: 1‑stündiges Droppen bei 5–10% Traffic zu Geschäftszeiten für Tier 2–3. Dann 4‑stündig bei 100% für Tier 3 außerhalb der Peak‑Zeiten. Beobachten Sie Support‑Tickets, SLOs und Dashboards.
• Zombies löschen oder deaktivieren (keine Acks, kein Effekt). Keine halben Maßnahmen. Deprecation dokumentieren mit Enddatum und Kontakt.
• Fanouts konsolidieren. Analytics‑only‑Consumer über einen Bus routen und ins Warehouse batchen. Direkte Fanouts auf drei Analytics‑Sinks killen.
• Retention verkürzen auf Hot‑Pfaden mit starker Source‑of‑Truth. Wenn Sie aus DB oder Objektspeicher re‑playen können, brauchen Sie keinen 7‑Tage‑Backlog in Kafka.
• Partitionen passend dimensionieren. Wenn 80% der Partitionen nahezu idle sind, halbieren. Bei Pub/Sub und SQS Parallelität reduzieren, wo sie Request‑Kosten ohne Latenz‑Gewinn aufbläst.

So sehen Einsparungen aus (realistische Spannen)

Messaging‑Preise sind ein Labyrinth. Sie brauchen keine exakten Dollarbeträge, um Entscheidungen zu treffen. Nutzen Sie diese Überschlagsrechnungen für Erwartungen:

• Delivery‑Volumen ist der größte Hebel. Wenn Sie 200 Mio. Events/Monat haben und durchschnittlich 2,5 Subscriptions, verarbeiten Sie 500 Mio. Deliveries. Das Abschalten einer redundanten Subscription auf 30% der Topics kann sofort 15–25% der Gesamtauslieferungen schneiden.
• Payload‑Größe zählt. Die durchschnittliche Payload von 20 KB auf 3–5 KB zu senken (IDs statt Blobs) reduziert Egress und Storage für diese Streams um ~70–85%. Selbst wenn nur 30% Ihres Traffics aufgebläht sind, sparen Sie ~20% Gesamt‑Egress.
• Retention ist versteckter Spend. Kafka‑Retention auf Hot‑Pfaden von 7 Tagen auf 48 Stunden zu kürzen (während parallel in Objektspeicher gespiegelt wird) kann 40–60% Broker‑Storage trimmen. Bei Managed‑Kafka reduziert das direkt die Rechnung. Bei Self‑Hosted sind es weniger Disks und weniger „Kafka ist voll“-Pages.
• Partitionen und Verbindungen treiben den operativen Overhead. 30–50% weniger Partitionen auf unterausgelasteten Topics entfernen Rebalancing‑Stürme und senken CPU zweistellig.

Über Firmen hinweg, die von einigen Tausend bis zu Zehntausenden pro Monat für Messaging (Confluent, Pub/Sub, SNS/SQS, Kinesis) ausgeben, sehen wir mit diesem Audit 15–35% Kostenreduktion in 30–60 Tagen – plus einen messbaren Rückgang der Incidents. Der operative Gewinn übertrifft oft die Rechnungskürzung.

Governance, die Verschwendung am Nachwachsen hindert

Abschalten ist der einfache Teil. Abgeschaltet halten erfordert drei Gewohnheiten.

1) Ownership in‑band verankern

• Alle Producer müssen x-stream-owner auf einen on‑call‑fähigen Team‑Alias setzen. Broker‑Policies weisen Nachrichten ohne ab.
• Alle Consumer müssen ein x-criticality‑Tag und eine Datenklassifikation registrieren. Kein Tag, keine Subscription.
• Topics ohne eigentümendes Team laufen nach 90 Tagen automatisch ab, sofern nicht verlängert.

2) Brownouts in CI/CD

• Jeder neue Stream wird mit einem Circuit‑Breaker‑Flag ausgeliefert und einem 1‑stündigen Brownout‑Test in Staging, der validiert, dass nutzerseitige SLOs grün bleiben oder innerhalb definierter Grenzen degradieren.
• Deploys blockieren für Streams, die den Brownout‑Test nicht bestehen – außer mit genehmigter Tier‑0‑Ausnahme.

3) Hören Sie auf, alle Events als Echtzeit zu behandeln

• Definieren Sie zwei Spuren: operativ (unter 1 s Latenz, Tier 0–1) und analytisch (Minuten‑Latenz, Tier 2–3). Standardisieren Sie neue Analytics auf Batch oder Mikro‑Batch über Ihre Warehouse‑Ingestion (z. B. CDC + inkrementelle Modelle).
• Quartalsweises Audit: Jeder analytische Consumer auf Ihrem operativen Bus muss eine Ausnahme verdienen – oder umziehen.

Architekturelle Trade‑offs, die Sie adressieren sollten

• Event‑Sourcing vs. Event‑Driven. Wenn Sie das Log als Source of Truth nutzen, schneiden Sie Retention oder Partitionen nicht blind. Ihre Replay‑Story ist Ihre Uptime‑Story.
• Cross‑Service‑Kopplung. Das Ersetzen fetter Events durch IDs kann synchrone Lookups wieder einführen. Für Tier 1–3 ist das okay; für Tier‑0‑Pfade mit strengen Latenz‑SLOs behalten Sie minimalen State im Event (Hashes, Versions‑IDs) und cachen klug.
• Analytics‑Latenz. Analytics vom Hot‑Bus zu nehmen, kann Dashboards von „Echtzeit“ zu „Beinahe‑Echtzeit“ (Sekunden bis Minuten) verschieben. Fragen Sie, welche Entscheidungen wirklich Sub‑Second‑Frische brauchen. Die meisten tun es nicht.
• Security und Compliance. Spiegeln in Objektspeicher fürs Replay ist günstiger, aber Sie müssen dieselben Zugriffskontrollen, Verschlüsselung und Retention‑Policies anwenden – oder bessere. Das Compliance‑Team sollte zustimmen.

Häufige Fehlermodi (und wie Sie sie vermeiden)

• Stille Consumer. Ein Service liest, wirft aber alles weg. Erkennen über „Effect‑Beacons“: Wenn ein Consumer in eine DB/Tabelle schreibt, emittieren Sie ein periodisches Heartbeat‑Event mit dem zuletzt angewendeten Offset. Kein Beacon = kein Effekt.
• Shadow‑Duplikation. Zwei Teams publizieren dasselbe Event mit leicht unterschiedlichen Schemata. Beheben mit Registry, Contracts und klarer Ownership. Doppelte Publisher sind ein Geruch; zusammenführen oder deprecaten.
• Brownout‑Blindheit. Sie haben während einer ruhigen Phase gebrownoutet und den Sieg erklärt. Planen Sie vor dem Kill mindestens einen Versuch in Peak‑Zeiten für Tier 1–2.
• Den falschen Bus optimieren. Manche Teams fixieren sich auf Kafka, während 60% der Kosten in Pub/Sub‑Fanouts oder SNS‑HTTP‑Deliveries stecken. Messen Sie alle Busse; optimieren Sie zuerst den größten Verursacher.

Was Sie als Nächstes automatisieren sollten

• Topic‑Scorecards. Nächtlicher Job taggt Topics mit einem Debt‑Score (kein Owner, niedrige Liveness, hoher Fanout, viele Retries) und eröffnet automatisch Tickets nach Schwellen.
• Budget‑Guards. Pro‑Bus‑Budgets, die automatische Brownouts für Tier‑3‑Streams auslösen, wenn der Spend L7 die Prognose um 20%+ übersteigt.
• Schema‑Linting. CI‑Hook, der Payloads über einer Größen‑Schwelle oder mit unzulässigen Feldern (z. B. rohe PII) ablehnt, sofern keine Ausnahme vorliegt.
• Konsolidierungs‑Bots. Für doppelte Analytics‑Consumer einen einzigen Egress ins Warehouse vorschlagen – mit Data‑Contract‑Diff und Migrationsfenster.

Wo Nearshore passt

Wenn Ihr Team ausgelastet ist, ist dies ein sauberes, abgegrenztes Engagement für ein Nearshore‑Pod: 4–6 Wochen, 2–3 Engineers eingebettet, eine SRE‑Leitung und eine Product‑Ansprechperson zur Validierung des Nutzer‑Impacts. Erwarten Sie 6–8 Stunden Überlappung mit US‑Zeitzonen aus Brazil, wöchentliche Demos, Brownout‑Reports und eine konkrete „Cut‑Liste“ mit Rollback‑Plänen. Diese Arbeit amortisiert sich meist im ersten Quartal – denn Zombie‑Topics diskutieren nicht mit Spreadsheets.

Der leise Vorteil: weniger Pages und schnellere Deploys

Wenn Sie Verschwendung entfernen, reduzieren Sie Rebalancing‑Stürme, Backpressure‑Ketten und Idempotenz‑Edge‑Cases, die nur um 2 Uhr nachts auftauchen. Weniger Consumer bedeuten weniger Orte für PII‑Leaks, weniger IAM‑Policies zum Managen und einen kleineren Blast‑Radius bei unvermeidlichen Fehl‑Deploys. Sie sparen nicht nur Geld; Sie kaufen Klarheit.

Wichtigste Erkenntnisse

• Wahrscheinlich laufen bei Ihnen 20–40% Zombie‑ oder redundanter Event‑Traffic. Messen Sie zuerst Effekte, nicht Dollar.
• In 30 Tagen können Sie mit Circuit Breakern und Brownouts gefahrlos ein Drittel Ihrer Topics löschen oder konsolidieren.
• Fokussieren Sie auf Deliveries, Payload‑Größe, Retention und Partitionen – das sind Ihre größten Hebel.
• Halten Sie Verschwendung klein mit in‑band Ownership‑Tags, CI‑Brownouts und Zwei‑Spuren‑Governance (operativ vs. analytisch).
• Der operative Gewinn (weniger Incidents, klarere Ownership) übertrifft oft die Rechnungskürzung.

Autor: Diogo Hudson Dias