Um 02:13 Uhr kam von einem Kollegen aus einem benachbarten Fintech Team die Nachricht, die man waehrend eines Launches nie lesen will:

"Checkout latency explodiert. Kafka lag steigt jede Sekunde."

Eine Influencer-Kampagne hatte ungefaehr fuenfmal mehr Traffic erzeugt als erwartet. Innerhalb weniger Minuten wurde der Payment Path zum Bottleneck.

Das ist keine Geschichte darueber, dass Kafka schlecht ist. Kafka ist stark, wenn es gut betrieben wird und zum Workload passt.

Es ist eine Geschichte darueber, was passiert, wenn ein self-managed Streaming Cluster direkt auf dem payment-critical Path sitzt, aber nicht genug Safety Margin hat.

Was kaputtging

Das erste sichtbare Symptom war Consumer Lag. Messages kamen schneller rein, als Payment Worker sie abarbeiten konnten, und der Backlog stieg ueber eine Million Events.

Dann bewegte sich Partition Leadership. Rebalances stoppten Producer und Consumer genau im falschen Moment.

Am Ende traf mehrere Broker Disk Pressure. Retention war nach Zeit konfiguriert, nicht nach Volume. Der Log wuchs schneller, als der Cluster Luft bekommen konnte. Broker schuetzten sich mit read-only Verhalten.

Checkout Endpoints begannen 5xx zu liefern. Marketing stoppte die Kampagne. Support Lines liefen heiss. Das Business schaetzte den Umsatzverlust in den ersten drei Stunden auf rund EUR 600.000.

Warum der Fehler eskalierte

Drei Probleme trafen gleichzeitig.

Erstens drueckte ein externer Load Balancer den Grossteil des Traffics in ein hot Topic. Die Partitionen waren ungleich verteilt, also trugen nur wenige Broker den Grossteil der Last.

Zweitens war Retention fuer normalen Traffic eingestellt. Beim Spike lief Disk voll, bevor Cleanup genug Entlastung schaffen konnte.

Drittens skalierten Consumer automatisch. Das klang hilfreich, erzeugte aber Group Membership Churn und damit einen Rebalance Storm genau dann, als das System Stabilitaet gebraucht haette.

Jedes einzelne Problem waere vielleicht ueberlebbar gewesen. Zusammen wurde aus einem grossen Traffic Spike ein Outage.

Die Recovery Entscheidung

Das Postmortem kam zu einer klaren Aussage: Self-managed Kafka sollte nicht laenger auf dem Payment Hot Path liegen.

Das Team verschob den Money Flow zu Google Cloud Pub/Sub, weil dadurch mehrere operative Aufgaben aus dem kritischen Pfad verschwanden:

• managed Scaling,
• regionale Replication,
• kein Broker Disk Management fuer das Application Team,
• weniger Rebalance Entscheidungen waehrend Spikes,
• klare Service-Level-Erwartungen.

Kafka wurde nicht geloescht. Es wanderte in eine Offline-Replay- und Analytics-Rolle, wo Operations Noise weniger gefaehrlich war.

Migration in vier Schritten

Das Team startete mit Mirror Mode. Ein Connector kopierte Live Kafka Traffic in Staging Pub/Sub Topics. Historische Logs, ungefaehr 1.2 Milliarden Events, wurden replayed, um Delivery Behavior und Downstream Compatibility zu pruefen.

Danach kam ein Feature-Flag Rollout. Zuerst wechselten fuenf Prozent der Producer. Die Metriken blieben gruen, also wanderte das Flag Schritt fuer Schritt auf 100 Prozent.

Billing Guardrails wurden vor dem kompletten Cutover eingebaut. Pub/Sub ist pay-per-use, also gehoerten Alerts auf Message Volume und Forecast Drift von Anfang an dazu.

Zum Schluss blieb Kafka als Cold Backup Archive. Es entschied nicht mehr, ob Checkout einen Spike ueberlebt.

Drei Monate spaeter

Black Friday brachte einen 10x Surge. Pub/Sub nahm den Spike ohne Notfall-Einsatz des SRE Teams auf.

p95 Latency fiel von ungefaehr 400 ms auf etwa 130 ms.

Die naechtliche Kafka On-Call Rotation verschwand. Engineers verbrachten Launch-Naechte nicht mehr damit, Broker neu zu starten und Disk Pressure zu jagen.

Am wichtigsten: Die Payment Platform hatte jetzt eine managed Messaging Layer mit klarem Uptime Target und weniger selbstgebauten Failover-Pfaden.

Der CTO fasste den Trade-off schlicht zusammen:

"Wir haben schlaflose Naechte gegen eine vorhersagbare Pub/Sub Rechnung getauscht."

Fuenf Health Checks, wenn du noch Kafka betreibst

Pruefe Partition Balance, bevor Traffic waechst. Ein hot Topic kann einen Broker zerdruecken, lange bevor clusterweite CPU gefaehrlich aussieht.

Setze Retention mit Disk Headroom im Blick. Age-based Retention reicht nicht, wenn Traffic ueber Nacht um ein Vielfaches steigen kann.

Vermeide eine einzelne Load-Balancer-Abhaengigkeit. Replizierte Broker helfen wenig, wenn Traffic durch eine fragile Eingangstuer kommt.

Halte Canary Consumers auf einem alternativen System bereit. Eine Shadow Subscription kann Failover zu einer kontrollierten IAM- und Routing-Aenderung machen, statt zu einem panischen Rewrite.

Bewerte On-Call Kosten ehrlich. Managed Messaging ist nicht immer auf der Rechnung billiger, aber Nachtarbeit von SREs ist ebenfalls echter Cost.

Takeaway fuer 2026

Kafka ist ein starkes System. Pub/Sub ist ein starker Managed Service. Die richtige Wahl haengt von Ownership, Latency Requirements, Compliance, Operational Maturity und Traffic Volatility ab.

Fuer diesen Fintech Payment Path war nicht Feature Richness entscheidend. Entscheidend war Blast Radius.

Wenn eine Queue zwischen Kunde und erfolgreicher Zahlung sitzt, ist der operative Aufwand Teil der Architektur. Wenn das Team diese Last waehrend eines Launch Spikes nicht sicher tragen kann, ist Managed Messaging oft die bessere Business Entscheidung.