Die DocDB-Architektur zeigt, wie man 5 Millionen QPS und 5,5 Neunen ohne Ausfallzeiten erreicht. Der Schlüssel ist die Zero-Downtime-Datenbewegung und strenge Kontrolle auf Plattformebene.
Das Problem zeigt sich nicht sofort — bis der Anstieg der Last nicht mehr in vertikale Skalierung passt. Die Datenbank von Stripe begann mit einer kleinen Anzahl von MongoDB-Shards, zu denen die Anwendungen direkt verbunden waren. Mit dem Wachstum erreichte das System Dutzende von Shards, bei denen Wartungsoperationen manuell über Ad-hoc-Skripte durchgeführt wurden. Dies schuf einen Engpass: Jegliche Änderungen — von Indizes bis hin zu Resharding — wurden riskant und schlecht skalierbar. Bei einem Anstieg auf Millionen von Anfragen pro Sekunde (QPS) und Petabyte an Daten begann dieses Modell, die Zuverlässigkeit zu gefährden.
Die nächste Grenze sind die physischen Einschränkungen der vertikalen Skalierung. Einzelne Shards wuchsen auf Dutzende von Terabyte. Dies löste vorübergehend das Problem des Durchsatzes, erhöhte jedoch den Blast-Radius bei Ausfällen und komplizierte die Operationen. Bei Anforderungen auf dem Niveau von 5,5 Neunen wird selbst eine kurzfristige Degradation kritisch. In Zahlungssystemen hat dies direkte Auswirkungen auf das Geschäft: Eine Transaktionsablehnung kann zum Verlust eines Kunden führen. Das System stieß nicht nur an seine Skalierungsgrenzen, sondern auch an seine Handhabbarkeit.
Die Lösung war evolutionär: der Übergang zu horizontaler Skalierung über eine eigene Datenplattform. Im Zentrum steht die DocDB-Architektur, die auf MongoDB aufgebaut ist, jedoch mit strenger Zugriffskontrolle und Verhaltensregeln. Ein Schlüsselelement ist der Datenbank-Proxy, der als einzige Eingangsquelle fungiert. Er erfüllt mehrere Aufgaben: Connection Pooling, Routing, Admission Control und Durchsetzung von Richtlinien. Dies beseitigt die direkte Kopplung zwischen Anwendungen und Shards und ermöglicht eine zentralisierte Verwaltung.
Zusammen mit dem Proxy kamen zwei kritische Komponenten hinzu. Die erste ist der Routing-Metadatenservice, der logisch Partitionen dynamisch mit physischen Shards abgleicht. Dies beseitigt die statische Routenführung und ermöglicht einen transparenten Datentransfer. Die zweite ist die Steuerungsebene, die den Lebenszyklus der Shards automatisiert: Erstellung, Löschung, Indizierung und Wartung. Ein solcher Wandel versetzt das System von einem Modus der „manuellen Pflege von Haustieren“ in ein Modell der „verwalteten Herde“, in dem die Operationen standardisiert und automatisiert sind.
Die Schlüsseltechnologie ist die Zero-Downtime-Datenbewegung. Sie ermöglicht horizontales Sharding, Migrationen und Updates ohne Systemstillstand. Dies ist entscheidend bei 5 Millionen QPS, wo selbst kurze Ausfallzeiten inakzeptabel sind. Architektonisch wird dies durch eine CDC-Pipeline unterstützt: Daten aus dem Oplog von MongoDB werden an Kafka und dann an S3 weitergeleitet. Dies ermöglicht die Synchronisierung des Zustands zwischen alten und neuen Shard-Konfigurationen und gewährleistet Konsistenz.
Die Implementierung beschränkt sich nicht auf das Hinzufügen von Komponenten — die Hauptschwierigkeit liegt in der Konsistenz. Bei der Datenbewegung muss das System strenge Konsistenz (strong consistency) aufrechterhalten, was besonders wichtig für Finanztransaktionen ist. Dies schränkt die Auswahl der Migrationsstrategien ein und erfordert eine präzise Kontrolle der Reihenfolge der Operationen. Darüber hinaus stellt die Multi-Tenancy mit Quoten Anforderungen an die Isolation: Ein Kunde darf keinen Einfluss auf andere haben, selbst bei Spitzenlasten.
Eine separate Schicht ist die Einschränkung der Möglichkeiten von MongoDB. Anstelle einer vollständigen API bietet die Plattform eine minimale Menge an geprüften Operationen. Dies verringert das Risiko ineffizienter Anfragen, die die Latenz verschlechtern oder kaskadierende Ausfälle verursachen können. Dieser Ansatz ist ein Kompromiss: weniger Flexibilität für Entwickler, aber höhere Vorhersehbarkeit des Systems.
Das Ergebnis ist eine Plattform, die in der Lage ist, mehr als 5 Millionen Anfragen pro Sekunde auf Petabyte von Daten mit einer angegebenen Zuverlässigkeit von 5,5 Neunen zu verarbeiten. Es wurde auch die Möglichkeit erreicht, umfangreiche Änderungen — Sharding, Migrationen, Updates — ohne Ausfallzeiten durchzuführen. Konkrete Metriken zu Latenz oder Betriebskosten werden nicht offengelegt, aber die architektonischen Entscheidungen weisen auf die Priorität von Stabilität und Handhabbarkeit über maximale Flexibilität hin.
Die DocDB-Architektur demonstriert ein typisches Muster für Highload-Systeme: den Verzicht auf direkten Datenbankzugriff zugunsten einer Plattformschicht, in der Kontrolle und Automatisierung wichtiger sind als rohe Leistung. Dies ist keine universelle Lösung, sondern für Systeme mit hohen Fehlerkosten und strengen Konsistenzanforderungen eine pragmatische Wahl.