Referenzarchitektur: hohe Skalierung / hoher Traffic

Wächst der Traffic, gibt es eine richtige Reihenfolge zum Schutz der Datenbank: zuerst die einfachen, günstigen Hebel, dann die komplexen. Dieser Baum geht Schritt für Schritt die Reihenfolge vertikale Skalierung → Read Replica → Sharding, Caching-Muster (Cache-Aside, Write-Back), Pufferung mit Queue + Backpressure, Rate Limiting, Isolation der Datenbank mit Bulkheads/Circuit Breakern und die Vermeidung von Hotspots durch. Grundprinzip: Schwer umkehrbare Entscheidungen wie Sharding kommen zuletzt, die günstigen Gewinne zuerst ausschöpfen.

Wo liegt der Engpass: Ist eine einzelne Instanz ausgelastet, sind Lese- oder Schreibvorgänge hoch, oder ist der Traffic stoßweise?

Um ein Skalierungsproblem an der richtigen Stelle zu lösen, bestimme zuerst den Engpass. Ist eine einzelne Instanz bei CPU/Speicher ausgelastet, dominieren Lesevorgänge, stoßen Schreibvorgänge an das Limit, oder erdrücken plötzliche Trafficspitzen die Datenbank? Jedes deutet auf eine andere Komponente.

• Eine einzelne Instanz ist ausgelastet; die einfachen Hebel habe ich noch nicht versucht
• Lesevorgänge sind sehr hoch und wachsen
• Plötzliche Trafficspitzen / stoßweise Last erdrücken die DB

An welchem Skalierungsschritt bist du: vertikal, Read Replicas oder Sharding?

Skalierung hat eine richtige Reihenfolge. Vertikale Skalierung (stärkere Hardware) ist der einfachste erste Schritt; dann verteilst du Lesevorgänge auf Replicas; erst wenn ein einzelner Primary die Schreibvorgänge nicht mehr bewältigt, wechselst du zu horizontaler Partitionierung (Sharding). Wo stehst du?

• Ich habe die Hardware noch nicht aufgerüstet / das Basis-Tuning noch nicht ausgeschöpft
• Schreibvorgänge passen auf eine Instanz, aber ich muss die Leselast verteilen
• Ein einzelner Primary bewältigt die Schreiblast nicht mehr

Wie schützt du die Datenbank vor Last: Pufferung, Begrenzung oder Isolation?

Skalierung bedeutet nicht immer, die DB größer zu machen; oft geht es darum, die DB vor Überlast zu schützen. Glättest du plötzliche Schreibspitzen mit einer Queue, begrenzt du die eingehende Request-Rate (Rate Limiting), oder verhinderst du, dass eine einzelne Abhängigkeit das ganze System lahmlegt (Bulkhead/Circuit Breaker)?

• Ich will plötzliche Schreibspitzen glätten
• Ich will die eingehende Request-Rate begrenzen/fair aufteilen
• Ich will nicht, dass eine ausfallende Abhängigkeit das ganze System mitreißt

Empfehlung: zuerst vertikale Skalierung und Basis-Tuning

Der günstigste und risikoärmste Schritt ist vertikale Skalierung: mehr CPU/RAM/schnellere Disks hinzufügen und die Grundlagen korrigieren (Indizes, Connection Pooling, Speicherparameter). Schöpfe diese Gewinne aus, bevor du komplexe Entscheidungen wie Sharding triffst.

Empfehlung: Lesevorgänge mit Read Replicas verteilen

Schreibvorgänge bleiben auf einem einzelnen Primary, während Read-only-Traffic auf eine oder mehrere Replicas verteilt wird. Das ist viel einfacher als Sharding und löst die meisten leseintensiven Workloads; der Primary bleibt nur für Schreibvorgänge und konsistenzkritische Lesevorgänge.

Empfehlung: Sharding (horizontale Partitionierung) als letztes Mittel

Bewältigt ein einzelner Primary die Schreiblast nicht, teilst du die Daten nach einem Schlüssel in mehrere unabhängige Teile (Shards) auf; jeder Shard übernimmt einen Teil der Schreibvorgänge. Das ist mächtig, aber schwer umkehrbar; es verkompliziert Shard-übergreifende Abfragen und Transaktionen und kommt daher zuletzt.

Empfehlung: Caching-Muster (Cache-Aside + Write-Back)

Bei leseintensivem hohem Traffic setzt du einen In-Memory-Cache (Redis) vor die DB und bedienst die meisten Lesevorgänge, ohne dass sie die DB je erreichen. Bei hohem Schreibvolumen puffert Write-Back Schreibvorgänge und schreibt sie gebündelt in die DB, was den Primary entlastet.

Empfehlung: Pufferung mit einer Queue (Backpressure)

Damit plötzliche Schreibspitzen die DB nicht direkt treffen, schaltest du eine dauerhafte Queue (z. B. Kafka/eine Message Queue) dazwischen und verarbeitest Schreibvorgänge in dem Tempo, das die DB verkraftet. Die Queue fängt die Spitze ab; statt synchron zu scheitern, läuft das System mit kontrollierter Latenz (Backpressure).

Empfehlung: Rate Limiting (Request-Rate begrenzen)

Durch Begrenzung eingehender Requests pro Quelle (Rate Limiting) verhinderst du sowohl Missbrauch als auch, dass ein einzelner Client alle Ressourcen verbraucht. Eine Obergrenze für die Last, die die DB erreicht, hält das System vorhersehbar und fair.

Empfehlung: Bulkhead + Circuit Breaker (Isolation)

Um zu verhindern, dass eine Abhängigkeit (z. B. eine langsamer werdende DB oder ein externer Dienst) das ganze System lahmlegt, teilst du Ressourcen in Abteilungen auf (Bulkheads) und unterbrichst vorübergehend Aufrufe an eine ständig fehlschlagende Abhängigkeit (Circuit Breaker). So breitet sich ein Teilausfall nicht auf das ganze System aus.