30 356 $ en 72 heures : une ligne qui lisait toute une collection Firestore

Vaki, une plateforme colombienne de financement participatif, hébergeait une campagne politique devenue virale. Le trafic, c'était la bonne nouvelle. La mauvaise, c'était une ligne dans l'application web : un appel qui chargeait toute la collection des paiements chaque fois que quelqu'un ouvrait une page, pour calculer des totaux déjà stockés dans chaque campagne.

Avec la campagne devenue virale, chaque visite multipliait cette lecture. L'auteur estime à plus de 40 milliards le nombre de requêtes Firestore et, selon ses mots : "we had spent $30,356.56 USD in just 72 hours!" (« nous avions dépensé 30 356,56 USD en seulement 72 heures ! »)

L'équipe a corrigé le code. Google leur a permis de demander une subvention pour startups, et la subvention a payé la facture. L'article ne mentionne pas de remboursement.

• Lire uniquement ce dont on a besoin. Stocker et lire les totaux, pas toute la collection, est la vraie solution. Firebase cite "forgetting to add a limit to a database query with millions of results" (« oublier d'ajouter une limite à une requête de base de données comptant des millions de résultats ») parmi les causes courantes de factures surprises.
• Remarquer le rythme des lectures. Des lectures Firestore qui bondissent à plusieurs fois leur niveau horaire habituel, c'est visible dans Cloud Monitoring en quelques minutes. Une règle de pic sur les lectures de documents l'aurait signalé dès le premier jour, et non au bout de 72 heures.
• Se dégrader au lieu de payer. Un Soft Kill basculant les pages de la campagne vers un mode en cache, léger en lectures, aurait gardé la campagne en ligne pendant la recherche du bug.