Como evitar contas surpresa no Firebase: uma checklist

O Firebase tem uma página chamada Avoid surprise bills. É um bom ponto de partida e cobre três coisas: testar o código, acompanhar o uso e configurar orçamentos. Abaixo está o mesmo conteúdo como checklist, na mesma ordem, com o que cada passo deixa em aberto e os passos que a página não menciona.

Uma coisa a ter em mente desde o início: "Firebase pricing plans apply to the entire project, not just to individual apps registered in the project." (os planos de preços do Firebase aplicam-se ao projeto inteiro, não só a cada app registrada nele). Cada app do projeto (web, iOS, Android, uma build de teste apontando para produção) soma na mesma conta.

O Google recomenda a Local Emulator Suite, que roda Firestore, Cloud Functions, Realtime Database e mais na sua máquina, para que "you don't incur any Firebase costs that might result from testing against services in production" (você não tenha custos do Firebase por testar contra serviços de produção). Durante os testes, aponta dois padrões a observar:

• "Forgetting to add a limit to a database query with millions of results" (esquecer de pôr um limite numa consulta com milhões de resultados)
• "Combinations of Cloud Functions that cause excessive fan-out workloads or even infinite loops" (combinações de Cloud Functions que causam cargas em leque excessivas ou até loops infinitos)

O que fica em aberto: o emulador mostra o que o seu código faz, não o que usuários reais ou um estranho vão fazer com ele. Não pega um listener que se inscreve de novo em cada tela do app real, nem um bot chamando a sua função. Para os padrões de leitura que escapam aos testes, veja como descobrir o que está lendo o seu Firestore.

O segundo passo do Google: "You need to know what normal usage patterns look like for your app" (você precisa saber como é o uso normal do seu app). Cada produto tem uma aba Usage no console do Firebase, e Settings, Usage and billing mostra o projeto inteiro em relação à cota sem custo.

Duas ressalvas. Os números andam em ritmos diferentes: "Cloud Firestore and Cloud Storage usage are calculated daily" (o uso de Firestore e Storage é calculado diariamente) e "Cloud Functions usage is calculated monthly" (o de Cloud Functions, mensalmente). E o painel do Firestore é uma estimativa: "the dashboard is not an exact view of billed operations. Billed usage is likely higher." (o painel não é uma visão exata das operações cobradas, e o valor cobrado provavelmente é maior) (documentação de uso do Firestore).

O que fica em aberto: alguém precisa olhar. Um painel mostra o pico a quem o abre, e às 3 da manhã ninguém abre. Se a conta já veio mais alta do que o esperado, como descobrir o que está cobrando você percorre os relatórios de faturamento até o SKU e o dia.

Ao mudar para o Blaze, o Firebase pede que você crie um orçamento. Crie, mas saiba o que ele é: "Budget alerts do not pause services." (alertas de orçamento não pausam os serviços). Eles existem "so that you can take action, if needed" (para que você possa agir, se necessário).

O que fica em aberto: o alerta chega horas depois do gasto, e alguém ainda precisa agir. O porquê, nas palavras do Google: por que os alertas de orçamento não param a sua conta.

Os orçamentos com spend cap são a opção mais recente: quando um serviço chega a 100% do orçamento, o Cloud Billing "pauses that service for the rest of the month" (pausa esse serviço pelo resto do mês). Só cobrem Firebase AI Logic, App Hosting, Cloud Functions for Firebase e Extensions.

O que fica em aberto: Firestore, Realtime Database, Cloud Storage e Hosting não estão cobertos. E o Google avisa: "Spend caps are not "hard caps"." (spend caps não são «limites rígidos»). A aplicação "can be delayed by several minutes" (pode atrasar vários minutos), e o que for gasto nesse intervalo é cobrado normalmente.

A página do Google fala de acompanhar custos. A maioria das contas de cinco dígitos das nossas histórias de terror veio de outro lugar: algo fora do app chamando serviços pagos. Três coisas que vale a pena fazer antes de lançar:

• Restrinja as suas API keys. Limite cada chave às APIs e apps que precisam dela, e deixe a API do Gemini fora de qualquer chave que vá dentro do app: como restringir uma API key do Firebase.
• Ative o App Check e regras de segurança rígidas. Para que só o seu app chegue ao seu banco de dados e às suas funções callable: ataques de negação de carteira.
• Limite as instâncias das suas funções. Uma função descontrolada custa mais quanto mais instâncias recebe. Defina um máximo: como limitar os gastos no Firebase.

A página do Google aponta na mesma direção: sugere usar as notificações de orçamento para desativar o faturamento do projeto. Você pode montar isso com uma função no tópico Pub/Sub do orçamento (guia passo a passo), mas leia antes o que acontece quando o faturamento para: isso desliga todos os serviços pagos do projeto.

Ou deixe o FireShield fazer isso. Ele age sobre cada notificação de orçamento assim que ela chega, pode enviar um webhook de Soft Kill para o app se degradar sozinho antes de o faturamento ser cortado, e no Pro acompanha o uso de cada serviço em busca de picos, para que um gasto descontrolado apareça em menos de uma hora e não no próximo relatório de custos.

1. Teste na Local Emulator Suite, com um limite em cada consulta.
2. Conheça o seu uso normal por produto, e confira após cada versão.
3. Crie um orçamento, sabendo que ele só envia alertas.
4. Ative os spend caps em AI Logic, App Hosting, Cloud Functions e Extensions.
5. Restrinja as API keys, ative o App Check, limite as instâncias das funções.
6. Conecte algo que aja sobre o orçamento sem esperar por uma pessoa.