30.356 $ in 72 Stunden: eine Zeile, die eine ganze Firestore-Collection las

Vaki, eine kolumbianische Crowdfunding-Plattform, hostete eine politische Kampagne, die viral ging. Der Traffic war die gute Nachricht. Die schlechte war eine Zeile in der Web-App: ein Aufruf, der bei jedem Seitenaufruf die gesamte Collection der Zahlungen lud, um Summen zu berechnen, die bereits in jeder Kampagne gespeichert waren.

Mit der viralen Kampagne vervielfachte jeder Besuch diesen Lesevorgang. Der Autor schätzt mehr als 40 Milliarden Firestore-Anfragen, und in seinen Worten: "we had spent $30,356.56 USD in just 72 hours!" (wir hatten in nur 72 Stunden 30.356,56 USD ausgegeben!).

Das Team korrigierte den Code. Google ließ sie ein Startup-Förderprogramm beantragen, und die Förderung bezahlte die Rechnung. Der Artikel beschreibt keine Rückerstattung.

• Nur lesen, was man braucht. Die Summen zu speichern und zu lesen statt der ganzen Collection ist die eigentliche Lösung. Firebase nennt "forgetting to add a limit to a database query with millions of results" (vergessen, eine Datenbankabfrage mit Millionen von Ergebnissen zu begrenzen) unter seinen häufigen Ursachen für Überraschungsrechnungen.
• Die Leserate bemerken. Wenn Firestore-Lesevorgänge auf ein Vielfaches ihres üblichen Stundenniveaus springen, ist das in Cloud Monitoring innerhalb von Minuten sichtbar. Eine Spitzenregel für Dokument-Lesevorgänge hätte es am ersten Tag gemeldet, nicht nach 72 Stunden.
• Herunterregeln statt zahlen. Ein Soft Kill, der die Kampagnenseiten in einen zwischengespeicherten, leseärmeren Modus geschaltet hätte, hätte die Kampagne online gehalten, während der Bug gesucht wurde.