ADR-0005: Polyglotte Persistenz

Status

Akzeptiert

Kontext

Als Teil unserer Microservices-Architektur (ADR-0003) mussten wir die am besten geeignete Datenspeicherstrategie bestimmen. Verschiedene Teile unseres Systems haben unterschiedliche Anforderungen an die Datenspeicherung:

Einige Daten erfordern starke Konsistenz und komplexe Beziehungen
Einige Daten müssen mit sehr geringer Latenz abgerufen werden
Einige Daten sind ereignisbasiert und müssen in einem Zeitreihenformat gespeichert werden
Verschiedene Dienste haben unterschiedliche Datenzugriffsmuster

Ein Einheitsansatz für die Datenspeicherung würde Kompromisse erzwingen, die die Leistung, Skalierbarkeit oder Entwicklungsproduktivität beeinträchtigen könnten.

Entscheidung

Wir haben uns entschieden, eine polyglotte Persistenzstrategie zu implementieren, die verschiedene Datenspeichertechnologien für verschiedene Anwendungsfälle nutzt:

PostgresQL: Als primäre relationale Datenbank zur Speicherung strukturierter Daten mit komplexen Beziehungen
- Wird von allen Domänendiensten für ihre primäre Datenspeicherung verwendet
- Jeder Dienst hat sein eigenes Datenbankschema, um Isolation zu gewährleisten
Redis: Als verteilter Cache für schnellen Datenzugriff
- Wird für das Caching häufig abgerufener Daten verwendet
- Wird für die Sitzungsspeicherung verwendet
- Wird für Rate-Limiting verwendet
Kafka: Als Event-Store für Event Sourcing
- Wird zur Speicherung von Domänenereignissen für Event Sourcing verwendet
- Ermöglicht Event-Replay zum Wiederaufbau des Zustands
Elasticsearch (geplant): für Volltextsuchfunktionen
- Wird für erweiterte Suchfunktionen über mehrere Domänen hinweg verwendet werden

Jeder Dienst ist für die Verwaltung seiner eigenen Datenspeicherung verantwortlich, und Dienste dürfen nicht direkt auf die Datenbanken anderer Dienste zugreifen.

Konsequenzen

Positive

Optimierte Leistung: Jede Art von Daten wird in der am besten geeigneten Speichertechnologie gespeichert
Skalierbarkeit: Verschiedene Speichertechnologien können unabhängig voneinander basierend auf ihren spezifischen Anforderungen skaliert werden
Flexibilität: Teams können die beste Speichertechnologie für ihre spezifischen Anwendungsfälle wählen
Resilienz: Probleme mit einer Speichertechnologie beeinträchtigen nicht unbedingt andere

Negative

Betriebliche Komplexität: Mehrere Speichertechnologien müssen bereitgestellt, überwacht und gewartet werden
Herausforderungen bei der Datenkonsistenz: Die Aufrechterhaltung der Konsistenz über verschiedene Speichertechnologien hinweg erfordert sorgfältiges Design
Lernkurve: Teams müssen mit mehreren Speichertechnologien vertraut sein
Komplexität bei Backup und Wiederherstellung: Verschiedene Speichertechnologien haben unterschiedliche Backup- und Wiederherstellungsverfahren

Neutral

Daten-Governance: Umfassende Daten-Governance ist über alle Speichertechnologien hinweg erforderlich
Überwachungsbedarf: Jede Speichertechnologie erfordert ihren eigenen Überwachungsansatz

Betrachtete Alternativen

Einzelne Datenbank für alle Dienste

Wir haben die Verwendung einer einzelnen PostgresQL-Datenbank mit separaten Schemas für jeden Dienst in Betracht gezogen. Dies hätte den Betrieb vereinfacht, hätte aber einen Single Point of Failure geschaffen und hätte es uns nicht ermöglicht, für verschiedene Datenzugriffsmuster zu optimieren.

Datenbank pro Dienst, gleiche Technologie

Wir haben die Verwendung von PostgresQL für alle Dienste, aber mit separaten Datenbanken in Betracht gezogen. Dies hätte Dienstisolation geboten und gleichzeitig den Betrieb vereinfacht, hätte es uns aber nicht ermöglicht, für verschiedene Datenzugriffsmuster zu optimieren.

Vollständig verteilter NoSQL-Ansatz

Wir haben die Verwendung eines vollständig verteilten NoSQL-Ansatzes mit Technologien wie Cassandra oder MongoDB für die gesamte Datenspeicherung in Betracht gezogen. Dies hätte eine ausgezeichnete Skalierbarkeit geboten, hätte aber die Modellierung komplexer Beziehungen erschwert und hätte signifikante Änderungen an unseren Entwicklungspraktiken erfordert.

4.7 KiB Raw Blame History