Gemini: Database Hotspotting und eine einminütige Cache-TTL verstärken einen schweren Ausfall

Unternehmen und Produkt

Google Gemini ist Googles Plattform für KI-Assistenten, die über Web- und Mobile-Anwendungen sowie über Integrationen wie Gemini in Chrome verfügbar ist.

‍

Gemini nutzt interne Services, um Metadaten für Tool-Deployments abzurufen und zu verwalten. Während dieses Incidents störte ein Problem in diesem zugrunde liegenden Metadatenpfad die Verarbeitung von Prompts und die damit verbundenen Konversationsfunktionen über mehrere Gemini-Oberflächen hinweg.

Was war passiert?

Am 10. Juni ließ ein Anstieg der Frontend-Queries Per Second (QPS) das Datenbanksystem von Gemini über seine Kapazitätsgrenze hinauslaufen. Der Service arbeitete bereits nahe an der Maximalauslastung. Dieses zusätzliche Anfragevolumen löste extreme Read Contention in der Backend-Datenbank aus, die für die Verwaltung der Metadaten für Tool-Deployments zuständig ist.

‍

Die Hauptursache war ein Problem im Indexdesign der Datenbank. Eine Spalte zur Nachverfolgung von Deployment-Ablaufzeiten enthielt eine große Menge ähnlicher Werte, darunter bestimmte Metadatenfelder mit leeren Werten. Diese Werte konzentrierten sich auf eine kleine Anzahl von Datenbank-Shards. Dadurch entstand eine „Hot Shard“-Situation, bei der ein kleiner Teil der Datenbank einen unverhältnismäßig großen Anteil des eingehenden Traffics verarbeiten musste.

‍

Ein In-Memory-Cache mit einer TTL von nur einer Minute verstärkte das Problem erheblich. Da die zwischengespeicherten Tool-Metadaten sehr schnell abliefen, aktualisierte das System die Datenbank kontinuierlich. Mit steigendem Anfragevolumen verzeichnete der interne Tool-Management-Service einen mehr als 10-fachen Anstieg der Datenbankaufrufe, weil die Cache Hit Rate deutlich sank. Die Storage-Layer erreichte daraufhin ihre Kapazitätsgrenze für eingehende Abfragen. Die Fehlerrate der Datenbank stieg auf 60 %. Dadurch fiel die Cache Hit Rate auf 50 %.

Timeline

• 10. Juni, 10:30 UTC: Das Zeitfenster mit Auswirkungen auf Nutzer beginnt. Gemini-Nutzer erleben erhöhte Prompt-Fehlerraten über Web, Mobile und Chrome-Integrationen hinweg.
• Während des Incidents: Googles Real-Time Monitoring erkennt hohe Verarbeitungsfehlerraten. Engineering-Teams beginnen mit der Untersuchung der Database Contention.
• Während der Mitigation: Engineers wenden Rate Access Control Lists (RateACLs) auf die am stärksten betroffenen Datenbank-Shards an, sodass sich die internen Caches erholen können.
• Während der Mitigation: Das Team verteilt häufig vorkommende Datenbankindexwerte über einen breiteren Bereich, um die Last gleichmäßiger über die Shards zu verteilen.
• Während der Mitigation: Google erhöht die TTL des In-Memory-Caches von 1 Minute auf 20 Minuten und reduziert damit die Datenbanklast deutlich.
• Während der Mitigation: Engineers verkürzen die RPC-Deadlines für Datenbankabfragen, um zu verhindern, dass sich Requests bei hoher Latenz aufstauen.

• 10. Juni, 17:25 UTC: Das Zeitfenster mit erhöhten Fehlerraten endet nach etwa 6 Stunden und 55 Minuten.
• 10. Juni, 17:30 UTC: Google aktualisiert seine Statusseite und bestätigt die Lösung des Problems für betroffene Nutzer. Die vollständige Wiederherstellung des Services wurde nach 14 Stunden und 49 Minuten bestätigt.
• 12. Juni, 11:14 UTC: Google veröffentlicht einen vorläufigen Incident-Report mit einer ersten Root-Cause-Analyse.
• 16. Juni, 17:41 UTC: Google veröffentlicht den finalen Incident Report mit Maßnahmen zur Prävention.

Time to Detect (TTD): Nicht öffentlich bekannt gegeben. Google erklärte, dass internes Real-Time Monitoring hohe Verarbeitungsfehlerraten erkannt hatte.

Time to Resolve (TTR): Zeitfenster der Auswirkungen rund 7 Stunden. Google meldete außerdem die vollständige Wiederherstellung des Services nach einer Gesamtdauer von 14 Stunden und 49 Minuten.

Wer war betroffen?

Der Ausfall betraf sowohl private Nutzer als auch Enterprise-Nutzer von Google Workspace.

‍

Nutzer der Gemini-Web-App sowie der iOS- und Android-Apps erlebten anhaltende Prompt-Fehler. In der Spitze lag die Fehlerrate bei 50 %. Betroffene Nutzer erhielten beim Senden von Prompts vor allem Fehlermeldungen wie „Something went wrong“. Gemini in Chrome war von anhaltenden Timeouts im Side Panel und in integrierten Konversationsfunktionen betroffen.

‍

Enterprise-Workspace-Nutzer konnten in der Gemini-Webanwendung keine Dateien mehr aus Google Drive anhängen. Die Funktion „Add from Drive“ wurde als deaktiviert angezeigt und reagierte nicht mehr, nachdem Nutzer mit dem Prompt interagiert hatten.

Wie reagierte Google?

Google erkannte die Störung über interne Monitoring-Alarmierungen. Die Engineering-Teams konzentrierten sich sofort auf die überlasteten Datenbank-Shards, um den Druck auf das System zu reduzieren und die Wirksamkeit der Caches wiederherzustellen.

‍

Als erste Maßnahme setzte Google RateACLs ein, um den Traffic auf den betroffenen Shards zu drosseln. Dadurch gewannen die Teams Zeit, damit sich die internen Caches stabilisieren konnten. Anschließend verteilten die Engineers häufig vorkommende Indexwerte neu, um den Traffic gleichmäßiger über eine größere Anzahl von Shards zu verteilen.

‍

Um den Druck auf die Datenbank während des Incidents zu reduzieren, erhöhten die Responder die Cache-TTL von 1 Minute auf 20 Minuten. Außerdem verkürzten sie die RPC-Deadlines für Datenbankabfragen. So verhinderten sie, dass sich langsame Requests aufstauten und den Backend-Rückstau weiter verschärften. Zu Googles langfristigen Präventionsmaßnahmen gehören die Überarbeitung des Datenbankindex zur Vermeidung von Hotspotting, adaptive Cache Policies, ein verbessertes Monitoring für ungleichmäßige Shard-Verteilung sowie Smart Task Resizing und Query Coalescing.

Wie kommunizierte Google?

Google nutzte das offizielle Google Workspace Status Dashboard, um Nutzer zu informieren. Das Unternehmen veröffentlichte regelmäßige Updates zur laufenden Untersuchung, zu den Mitigation-Maßnahmen und zur anschließenden Lösung des Problems. Nach dem Ausfall veröffentlichte Google am 12. Juni einen vorläufigen Incident-Report. Am 16. Juni folgte ein umfassender finaler Incident Report mit Details zu den technischen Ursachen, den Auswirkungen auf Kunden und den Maßnahmen zur Behebung und Prävention.

Wichtige Learnings für andere Teams

• Indexe für gleichmäßige Verteilung designen: Wiederkehrende Werte und leere Identifier sollten beim Indexdesign berücksichtigt werden, um eine Traffic-Konzentration auf wenige Shards zu vermeiden.
• Cache-TTLs sorgfältig abstimmen: Eine TTL von einer Minute kann die Datenaktualität verbessern, aber auch häufigere Datenbank-Refreshes verursachen. Bei Backend-Stress können adaptive Cache Policies helfen, eine zusätzliche Lastverstärkung zu verhindern. 
• Verteilung überwachen, nicht nur Durchschnittswerte: Klassische Health-Signale verbergen oft eine ungleichmäßige Shard-Auslastung. Teams sollten Hot Partitions und ungewöhnliche Traffic-Konzentrationen aktiv überwachen.
• Load Protection frühzeitig implementieren: Rate Limits, Query Coalescing und kapazitätsbewusstes Task Sizing sollten greifen, bevor Backend-Services ihre Belastungsgrenze erreichen.
• RPC-Deadlines bei Latenz optimieren: Kürzere RPC-Deadlines verhindern, dass sich langsame Requests aufstauen und die Recovery unnötig verlängern. 

Zusammenfassung

Am 10. Juni 2026 kam es bei Google Gemini für etwa 6 Stunden und 55 Minuten zu erhöhten Fehlerraten, nachdem ein Traffic-Anstieg eine bereits stark ausgelastete Metadaten-Datenbank über ihre Kapazitätsgrenze hinaus belastet hatte. Ein Problem im Indexdesign führte dazu, dass Daten auf wenigen Datenbank-Shards konzentriert wurden. Gleichzeitig trug eine einminütige Cache-TTL zu einem mehr als 10-fachen Anstieg der Datenbankaufrufe bei. Dies verursachte eine erhebliche Read Contention, Datenbankfehlerraten von bis zu 60 % und eine Prompt-Fehlerrate von 50 % für Nutzer.

So kann ilert helfen

Incidents wie der Ausfall bei Gemini zeigen, wie schnell lokal begrenzte Backend-Engpässe kundenseitige KI-Services beeinträchtigen können. ilert hilft Engineering- und Infrastrukturteams dabei, die daraus entstehende Alarmflut zu reduzieren und schnelle Reaktionen koordiniert umzusetzen.

• Alarmierung bei Problemen mit Backend-Services: Prompt-Fehlerraten, Datenbanklatenz, sinkende Cache Hit Rates und Lastsignale auf Shard-Ebene direkt an ilert weiterleiten. So werden die richtigen Responder sofort benachrichtigt, um Probleme zu bestätigen und zu eskalieren.
• Alarmflut reduzieren: ilert AI nutzen, um ähnliche Timeouts, Datenbankfehler und Client Errors aus einer einzelnen Quelle zu gruppieren. Das reduziert die Alarmflut und hilft Respondern, sich auf zusammenhängende Symptome zu konzentrieren.
• An die richtigen Spezialisten eskalieren: Eskalationsrichtlinien und Dienstpläne erstellen, um Datenbank-, SRE- und Platform Engineers zu benachrichtigen, wenn kritische Hotspot- oder Cache-Health-Alerts ausgelöst werden.
• Service-Degradation kommunizieren: Statusseiten und KI-generierte Updates nutzen, um Nutzer während Phasen mit erhöhten Fehlerraten informiert zu halten, während sich Engineers auf die Mitigation konzentrieren.
• Incident-Daten in konkrete Maßnahmen überführen: Mit AI-gestützter Postmortem-Erstellung Incident-Kontext, Responder-Aktivitäten und Chatverläufe in strukturierte, umsetzbare Postmortem Reports übertragen.