Referenzarchitektur: dreistufige OLTP-Anwendung
Klassische Geschäftsanwendungen (Bestellungen, Zahlungen, Lager) führen viele kurze, einzeilige, konsistenzkritische Transaktionen aus (OLTP). Dieser Baum zeigt Schritt für Schritt, ausgehend vom Lastprofil, wann die primäre relationale Datenbank, ein Connection Pooler, Read Replicas, eine Cache-Schicht, Backup + PITR und Monitoring ins Spiel kommen. Ziel ist nicht, „alles von Anfang an hinzuzufügen“, sondern die richtige Komponente dann zu ergänzen, wenn der jeweilige Engpass nachgewiesen ist.
Wie sieht dein Lastprofil aus: Transaktionsmix und Konsistenzanforderungen?
Die erste Entscheidung in einer OLTP-Architektur ist, ob die Workload wirklich transaktional ist (ein kurzer, ACID-pflichtiger Mix aus Schreib- und Lesevorgängen). Sind die Daten naturgemäß relational und ist Konsistenz kritisch (Geld, Bestand, Bestellungen), besteht die Workload überwiegend aus Lesevorgängen, oder ist die Last noch sehr gering?
- Kurze Transaktionen, starke Konsistenz (Geld/Bestand/Bestellungen)
- Lesevorgänge dominieren stark, wenige Schreibvorgänge, und der Traffic wächst
- Die Last ist sehr gering; reicht das einfachste Setup?
Hast du die primäre Datenbank-Engine gewählt, und sorgst du dich um die Skalierung?
Eine relationale Engine ist die richtige Grundlage für den transaktionalen Kern (PostgreSQL, MySQL/InnoDB, Oracle, SQL Server). Steht die Engine fest, ist die nächste Frage die Skalierung: Reicht vorerst eine einzelne Instanz, oder steigen Verbindungsanzahl und Leselast?
- Engine steht fest; eine einzelne Instanz reicht vorerst
- Die Verbindungsanzahl ist sprunghaft gestiegen, die Ressourcen gehen zur Neige
- Die Leselast wächst und belastet die primäre Schreibinstanz
Wie skalierst du Lesevorgänge: Replica oder Cache?
Belastet die Leselast die primäre Instanz, gibt es zwei sich ergänzende Optionen. Lesevorgänge, die leicht verzögerte Daten tolerieren, etwa Berichte/Listen, lassen sich an eine Read Replica leiten; werden dieselben „heißen“ Daten immer wieder angefragt, entlastet ein Cache mit Mikrosekundenlatenz (Redis) die DB.
- Viele Berichts-/Listen-Lesevorgänge; leichter Verzug ist akzeptabel
- Dieselben beliebten Daten werden immer wieder gelesen
Empfehlung: Mit einem einzelnen Primary + Pool + Backup beginnen
Halte die Architektur anfangs einfach: Eine einzelne relationale Primary-Instanz, ein Connection Pool davor und regelmäßige Backups reichen. Füge Komplexität erst hinzu, wenn ein gemessener Engpass es erzwingt.
Empfehlung: Connection Pooler hinzufügen
Öffnet bei OLTP jede Anwendungsinstanz eigene Verbindungen, erstickt die primäre DB bei Tausenden Verbindungen an Speicher- und Scheduler-Overhead. Ein Pooler dazwischen teilt wenige echte DB-Verbindungen auf viele Anwendungsrequests auf.
Empfehlung: Read Replica hinzufügen
Schreibvorgänge bleiben auf dem Primary, während Read-only-Traffic (Berichte, Listen, Suche) an eine oder mehrere vom Primary gespeiste asynchrone Replicas geleitet wird. Das macht den Primary frei für Schreibvorgänge und konsistenzkritische Lesevorgänge.
Empfehlung: Cache-Schicht hinzufügen (Redis)
Werden dieselben beliebten Daten (Sessions, Katalog, Profile, Seitenfragmente) wiederholt gelesen, setze einen In-Memory-Cache vor die DB und bediene die meisten Lesevorgänge, ohne die DB überhaupt zu erreichen. Die Latenz sinkt und die primäre DB wird entlastet.