Modul 7: Scalability — Skalierung für Wachstum

Skalierung ist Architektur, nicht Hardware

Skalierung beginnt im Design, nicht im Server-Rack. Ein System, das nicht horizontal skaliert, ist durch die größte Maschine begrenzt. Ein System, das horizontal skaliert, ist durch das Budget begrenzt. Die Wahl der Architektur (stateless, partitioniert, asynchron) bestimmt, ob man mit Last wachsen kann.

Lesson 1: Vertikal vs. Horizontal

Vertikale Skalierung: größere Maschine (mehr CPU, RAM, SSD). Einfach, aber begrenzt und teuer. Horizontale Skalierung: mehr Maschinen. Komplexer (State muss verteilt werden), aber theoretisch unbegrenzt. Faustregel: Erst vertikal bis es weh tut, dann horizontal. Stateless Services sind die Voraussetzung für horizontale Skalierung.

Lesson 2: Load Balancing

Ein Load Balancer verteilt Anfragen auf mehrere Instanzen. Strategien: Round-Robin (einfach), Least-Connections (fair bei unterschiedlichen Antwortzeiten), IP-Hash (session stickiness). Health-Checks entfernen kranke Instanzen. Für stateless Services ist jeder Request beliebig verteilbar; für stateful Services braucht man Sticky Sessions oder externen State (Redis, DB).

# Stateless: jede Instanz bedient jeden Request — skaliert horizontal
              ┌─ Instanz 1 (kein lokaler State)
Client ── LB ─┼─ Instanz 2 (Session in Redis)
              └─ Instanz 3 (Fails ohne Redis? Nein — State extern)

# Stateful (Anti-Pattern für Skalierung):
Client ── LB ── Instanz 2 ── lokale Session-Datei
         (Sticky Session nötig — Instanz-Ausfall = Session-Verlust)

Merksatz: Wenn eine Instanz etwas weiß, das keine andere weiß, kannst du nicht beliebig skalieren.

Lesson 3: Sharding und Partitioning

Sharding teilt Daten über mehrere Datenbanken: Shard 1 (A-M), Shard 2 (N-Z). Der Shard-Key ist die wichtigste Entscheidung: gleichmäßige Verteilung, keine Hot-Spots, range-basierte oder hash-basierte. Vorsicht: Cross-Shard-Joins sind teuer, Transaktionen über Shards sind schwer (Saga). Replikation (Read-Replicas) entlastet Lese-Last, hilft aber nicht bei Schreib-Last.

Lesson 4: Caching und CDN

Caching auf mehreren Ebenen: Browser-Cache (statische Assets), CDN (geografisch verteilt), Application-Cache (Redis), Database-Cache (Buffer-Pool). Ein CDN reduziert Latenz für Nutzer weltweit und entlastet den Ursprungsserver. Cache-Keys müssen versioniert sein (z. B. user:42:v3), um Invalidierung zu vereinfachen.

Lesson 5: Asynchrone Verarbeitung

Synchron: Anfrage -> Verarbeitung -> Antwort. Asynchron: Anfrage -> Queue -> Worker -> Benachrichtigung. Asynchrone Verarbeitung entkoppelt langsame Aufgaben (E-Mail, Bildverarbeitung, Reports) vom Request-Thread. Werkzeuge: Message-Queue (RabbitMQ), Event-Stream (Kafka), Job-System (Spring @Async, Celery). Vorteil: schnellere Antworten, bessere Ressourcenauslastung.