Lessons Learned

Caching #1

Redis-Cache-Überlastung legt Datenbank lahm

Ein Traffic-Spike trieb Redis auf 100% CPU, Timeouts galten als Cache Misses — der Stampede tötete die Datenbank in 30 Sekunden.

Lesen → Caching #2

Redis noeviction: Wenn Schreibvorgänge stoppen

Redis mit noeviction stürzt nicht ab — es lehnt Schreibvorgänge ab. Sessions und Zahlungen fielen aus, weil sie eine Instanz mit dem Cache teilten.

Lesen → Caching #3

Desaster durch veraltete Cache-Daten

Eine Aktion endete in der Datenbank, lebte aber vier Stunden im Cache weiter: 327 Bestellungen zum alten Preis, rund $49.000 verschenkt.

Lesen → Caching #4

Cache-Invalidierung: Zwei harte Lektionen

Ein Cache-Key, der die Daten eines Nutzers an alle auslieferte, und ein Invalidierungs-Fan-out, den niemand überblickte. Was wir geändert haben.

Lesen → Caching #5

Wenn Multi-Layer-Caching scheitert

L1-, L2- und L3-Cache für „bessere Performance“ — und plötzlich drei Stellen, an denen Daten falsch sein können, statt einer.

Lesen → Caching #6

Rate Limiter: Der Redis-Crash

Der Rate Limiter hielt seinen Zustand in Redis. Als Redis ausfiel, ging er auf Fail-open — und der abgewehrte Traffic flutete direkt in die API.

Lesen → Caching #7

Session-Storage-Migration auf Redis

Sessions für horizontale Skalierung nach Redis verlegt — und vergessen, dass Redis In-Memory ist. Ein Neustart loggte 50.000 Nutzer aus.

Lesen → Cloud #8

Spot-Instance-Desaster am Black Friday

100% Spot zum Kostensparen. Am Black Friday zog AWS 50 Instanzen auf einmal zurück, die AZ hatte keine freie Kapazität: 15 Minuten Teilausfall.

Lesen → Cloud #9

Die $50.000-CloudWatch-Logging-Rechnung

Log-alles-Kultur plus ein vergessenes Debug-Statement ergaben einen $50.000-CloudWatch-Monat. Die Rechnung dahinter und die Fixes auf $3.200.

Lesen → Cloud #10

Multi-Region-Replikation, die niemand nutzte

Replikation über drei Regionen für $8.000 im Monat, null Failover-Tests in 18 Monaten. Wie wir auf $1.200 kamen — mit einer gemessenen RTO.

Lesen → Cloud #11

Staging kostet mehr als Produktion

Staging lief 24/7 in Prod-Größe bei 24% Auslastung. Geplantes Abschalten, kleinere Instanzen und Slack-Hochfahren senkten die Kosten um 60%.

Lesen → Cloud #12

Überraschung bei den VPC-Egress-Kosten

Kaum Compute, trotzdem hohe AWS-Rechnung: das NAT Gateway verarbeitete 500GB Trainingsdaten täglich. VPC-Endpoints drückten $20.250 auf $1.200.

Lesen → Kubernetes #13

Autoscaling, das die Datenbank lahmlegte

Ein HPA skalierte Pods von 5 auf 50 und trieb PostgreSQL über max_connections in einen Restart-Sturm. PgBouncer und HPA-Ratenlimits halfen.

Lesen → Kubernetes #14

Health Checks, die logen

Pods meldeten sich gesund, konnten aber nicht bedienen — dann löste eine Liveness Probe mit Dependency-Checks einen Restart-Sturm aus.

Lesen → Kubernetes #15

Ausfall durch ConfigMap-Tippfehler

Zwei Stunden Produktionsausfall wegen eines falsch geschriebenen Keys in einer ConfigMap. Warum nichts ihn validierte und wie Fail-fast hilft.

Lesen → Kubernetes #16

Docker-Image mit 47 CVEs

Ein Security-Audit fand 47 bekannte CVEs in einem 18 Monate alten Produktions-Image. Wie Scanning, Pinning und Rebuilds Images sauber halten.

Lesen → Kubernetes #17

Hochverfügbarkeit, die keine war

Drei Replicas auf drei Nodes sahen hochverfügbar aus — bis wir merkten, dass alle Nodes in us-east-1a standen. Topology Spread richtig gemacht.

Lesen → Kubernetes #18

Rechnungsschock durch Cross-AZ-Traffic

Geschwätzige Microservices über drei AZs addierten still rund $8K im Monat an Datentransfer. Wie Topology-aware Routing den Traffic um 60% senkte.

Lesen → Kubernetes #19

Pod-Eviction-Kaskade

Ein Node erreichte die Eviction-Schwelle, verdrängte alle Pods und nahm sie gleich wieder auf. Wie die Schleife läuft und welche Limits sie brechen.

Lesen → Kubernetes #20

Ingress Controller als Single Point of Failure

Zwanzig Services mit je drei Replicas hinter einem einzigen ingress-nginx-Pod. Ein OOMKill nahm alle vom Netz. Der Fix: vier Zeilen Helm.

Lesen → Microservices #21

Microservices aus den falschen Gründen

Zwölf Deployables für 50 tägliche Nutzer und ein Vier-Personen-Team. Die echten Kosten — Bus-Faktor, Dauerbereitschaft, $3K/Monat Infrastruktur.

Lesen → Microservices #22

Microservices-Konsolidierung, die schiefging

10 Microservices zu 3 zusammenführen: sechs Monate statt sechs Wochen. Versteckte Async-Abhängigkeiten, doppelte Datenhoheit, umgekehrter Strangler.

Lesen → Microservices #23

Alles skaliert außer der Datenbank

20 Services wunderbar skaliert — alle auf derselben PostgreSQL-Instanz mit max_connections=100. Die Rechnung, die Todesspirale, der Fix.

Lesen → Microservices #24

20.000 Workloads nach Kubernetes: Post-Mortem

Als 20.000 Microservices verkauft, real 900 Services auf 20.000 Instanzen. Warum der Lift-and-Shift nach Kubernetes scheiterte und was funktioniert.

Lesen → Microservices #25

Den Monolithen zu schnell aufgeteilt

15 Microservices in 3 Monaten, 2 Jahre Korrektur: Warum Service-Grenzen nach Tabellen statt nach Bounded Contexts alles verlangsamten.

Lesen → Microservices #26

Die Hölle der Teilausfälle

1 von 8 Services zu 50% ausgefallen — und das ganze Produkt unbenutzbar. Warum Teilausfälle schlimmer sind als ein Komplettausfall.

Lesen → Microservices #27

Von 1K auf 10K RPS: Komplexitätsexplosion

10x Traffic sprengte Connection Pools, Timeout-Budgets und die Logging-Rechnung. Was brach, welche Signale es gab und welche Patterns halfen.

Lesen → Microservices #28

Microservices waren eine Organisationsfrage

Unsere Architektur spiegelte exakt das Organigramm. Als die Reorganisation kam, brach alles — Conway's Law in Aktion.

Lesen → Architektur #29

Blue-Green-Config-Drift

Ein nur in Blue umgelegtes Feature Flag fiel beim Cutover still zurück. Wie Git plus ein gemeinsamer Flag-Service den Drift beendeten.

Lesen → Architektur #30

Lambda Cold Starts: unser P99-Fix

P50 bei 50ms, P99 bei 8 Sekunden: Wie SnapStart und kleinere Pakete unsere Java-Lambda retteten — und welcher VPC-Rat veraltet ist.

Lesen → Architektur #31

Service-Mesh-Overhead: Was wir falsch gemacht haben

Wir gaben Istio die Schuld für 15ms pro Hop — ausgehungerte Sidecars waren der Grund. Realistische Mesh-Zahlen und wann sich ein Mesh lohnt.

Lesen → Architektur #32

Serverless-Lock-in: die Realität

Voll auf AWS Serverless gesetzt; eine Migration zu GCP würde 18 Monate dauern. Warum Lock-in ein Risiko ist, aber nicht automatisch ein Problem.

Lesen → Architektur #33

Blue-Green-Datenbank-Albtraum

Eine destruktive Schemamigration machte den Rollback mitten im Incident unmöglich. Expand/Contract über drei Releases hält Blue-Green umkehrbar.

Lesen → Architektur #34

Der Cache, der Latenz hinzufügte

Ein Redis-Cache sollte Requests beschleunigen — mit 3% Hit Rate machte er jeden Request langsamer. Die Cache-Rechnung, die jedes Team vorher braucht.

Lesen → Architektur #35

Event Sourcing für CRUD

Event Sourcing für eine CRUD-App mit 500 Nutzern: vier Monate Infrastruktur, zwei Wochen Features. Wann das Pattern seinen Preis wert ist.

Lesen → Architektur #36

Engpass bei horizontaler Skalierung

Auf 50 Instanzen skaliert, und der Engpass wanderte nur weiter: App, Datenbank, Load Balancer, Queue. Kapazitätsplanung Ende-zu-Ende, die trägt.

Lesen →