Alles skaliert außer der Datenbank
Wir haben unsere 20 Services wunderbar skaliert. Alle trafen auf dieselbe PostgreSQL-Instanz.
Die Architektur:
- 20 Microservices (unabhängig skalierbar! ✅)
- 1 PostgreSQL-Datenbank (nicht skalierbar ❌)
- Pro Service: Connection-Pool-Größe 10
- PostgreSQL max_connections: 100
Die Rechnung:
- 20 Services × 10 Verbindungen = 200 benötigt
- Maximal verfügbar: 100
- Ergebnis: Connection Starvation beim Skalieren
Was tatsächlich passierte:
- Services A, B, C schnappen sich alle Verbindungen
- Services D-T: „connection refused“
- Health Checks schlagen fehl
- Pods starten neu, schnappen sich noch mehr Verbindungen
- Todesspirale
Der Fix:
- PgBouncer fürs Connection Pooling
- Verbindungslimits pro Service
- Read Replicas für leselastige Services
- Schließlich: Database-per-Service-Muster
Lektion: „Microservices“ mit einer gemeinsamen Datenbank sind ein verteilter Monolith mit Extraschritten. Die Datenschicht ist das Erste, was wir in einem DevOps-Architektur-Review prüfen, denn sie ist die eine Komponente, die sich nie von selbst skaliert hat.
Incidents wie dieser sind vermeidbar. Unser AWS Managed Services-Team überwacht Kundenumgebungen 24/7 mit KI-gestütztem Monitoring und Senior Engineers am Pager — damit Geschichten wie diese im Archiv bleiben.