Firebase Harcama Limiti (Spend Caps): Gemini API ve Cloud Functions İçin Sürpriz Fatura Koruması

Hangi sorunu çözüyor? (Why Firebase spend caps?)

Kullandıkça öde modelindeki bulut hizmetlerinin en korkulan senaryosu sürpriz faturadır. Sonsuz döngüye giren bir Cloud Function, yanlışlıkla herkese açık bırakılmış bir yapay zekâ uç noktası ya da bir botun sayfayı dakikada binlerce kez çağırması, bir gecede aylık bütçeyi aşan fatura çıkarabilir. Bugüne kadar Firebase'in Blaze planında yalnızca bütçe uyarısı vardı: e-posta gelir, ama hizmet çalışmaya devam ederdi. Gece yarısı gelen uyarıyı sabah görene kadar zarar çoktan oluşmuş olurdu.

Yapay zekâ çağrılarının uygulamalara yaygın biçimde girmesiyle risk büyüdü. Mobil uygulamadan doğrudan Gemini modellerini çağırmaya izin veren Firebase AI Logic gibi hizmetlerde, kötü niyetli biri uygulamanızın anahtarıyla binlerce istek gönderebilir. Firebase ekibinin deyişiyle harcama limiti, bu tür durumlar için bir "devre kesici".

Harcama limiti nasıl çalışır?

Limit proje bazında değil, hizmet bazında tanımlanıyor. Böylece örneğin yapay zekâ çağrılarına sıkı bir sınır koyarken veritabanı ve kimlik doğrulama gibi temel hizmetleri etkilemeden bırakabilirsiniz. Şu an desteklenen hizmetler:

Bütçe dönemi aylık ve her ayın ilk günü başlıyor. Bütçenin %50 ve %80'inde otomatik e-posta uyarısı geliyor. %100'e ulaşıldığında Cloud Billing ilgili hizmeti o ayın geri kalanı için duraklatıyor. Yeni ay başladığında limit, ayarladığınız ilk haline kendiliğinden dönüyor.

Adım adım kurulum

1. Firebase konsolunda projenizi açın.
2. Usage and Billing (Kullanım ve faturalandırma) bölümüne, oradan Account & Budgets sekmesine gidin.
3. Desteklenen her hizmet için aylık harcama limitini girin.
4. Değişiklikleri kaydedin.

Ayarı yapabilmek için yetki gerekiyor: ya Faturalandırma Hesabı Yöneticisi rolü, ya da Proje Sahibi rolü, ya da Faturalandırma Hesabı Maliyet Yöneticisi ile Proje Düzenleyicisi rollerinin ikisi birlikte. Ekipte yalnız geliştirici rolü olanlar limiti göremeyebilir; kurulumu faturalandırmadan sorumlu kişiyle birlikte yapmak en kolayı.

Limit dolunca ne olur?

Hizmet duraklatıldığında yeni istekler hata ile dönüyor. Bu yüzden uygulama tarafında bu hataları düzgün karşılamak şart: model çağrısı başarısız olursa kullanıcıya "şu an bu özellik kullanılamıyor" demek, uygulamanın çökmesinden ya da sonsuz yükleme ekranından çok daha iyi. Firebase belgeleri de çağrıları try/catch ile sarmayı öneriyor:

try {
  const sonuc = await model.generateContent(istem);
  gosterCevap(sonuc.response.text());
} catch (hata) {
  // Harcama limiti dolmuş ya da hizmet geçici olarak kapalı olabilir
  gosterUyari("Bu özellik şu anda kullanılamıyor, lütfen daha sonra deneyin.");
}

Duraklatılan hizmeti ay bitmeden açmanın iki yolu var:

• Limiti kaldırmak: Hizmet ay sonuna kadar sınırsız çalışır.
• Limiti kaldırıp daha yüksek bir bütçe girmek: Yeni tutar o ayın o ana kadarki harcamasından büyük olmalı.

Firebase blogunda, duraklatılan hizmetin Google Cloud konsolundan yeniden açılmasının tam olarak devreye girmesinin bir saate kadar sürebileceği belirtiliyor. Canlı bir uygulamada bu bir saatlik kesintiyi hesaba katmak gerekiyor.

Sınırlamalar ve tuzaklar

• Kesin tavan değil. Kullanım raporlaması birkaç dakika gecikebildiği için limit, hizmet durdurulana kadar aşılabilir ve bu aşım normal şekilde faturalanır. Limiti gerçek üst sınırınızın biraz altına koyun.
• Brüt maliyet esas alınıyor. Hesaplamada kredi, ücretsiz kullanım kotası ve indirimler düşülmeden önceki tutar kullanılıyor. Ücretsiz kotası olan bir hizmette limit beklediğinizden erken dolabilir.
• Her hizmette yok. Firestore, Realtime Database, Storage, Authentication gibi hizmetler şimdilik kapsam dışında. Bunlar için klasik bütçe uyarıları ve kota ayarları kullanılmaya devam ediyor.
• Public Preview. Davranış ve kapsam genel kullanıma geçene kadar değişebilir.
• Hizmet durması da bir maliyet. Ödeme ya da sipariş akışında kullanılan bir fonksiyonun ay ortasında durması, faturadan daha pahalıya patlayabilir. Kritik ve kritik olmayan iş yüklerini ayrı fonksiyonlara bölmek mantıklı.

Önerilen ayarlar

Pratik bir başlangıç noktası şöyle olabilir:

• Yapay zekâ çağrıları (AI Logic): En sıkı limit burada. Geçen ayların ortalamasının 1,5–2 katı makul. Ayrıca App Check ile yalnızca gerçek uygulamanızdan gelen istekleri kabul edin.
• Cloud Functions: Zamanlanmış ve arka plan işleri için limit koyun; kullanıcı akışının parçası olan kritik fonksiyonları ayrı tutun.
• App Hosting: Sitenin durması ciddi bir kesinti anlamına geldiği için limiti cömert tutup asıl korumayı uyarılara bırakmak daha güvenli olabilir.

Alesta WEB olarak mobil uygulama projelerinde yapay zekâ özelliği eklerken maliyet tavanını işin en başında konuşuyoruz. Kullanıcı başına istek sınırı, sunucu tarafında ara katman ve fatura uyarısı birlikte kurulmadan bir yapay zekâ özelliğini yayına almıyoruz. Firebase'in bu adımı, küçük ekiplerin bu korumayı kendi kodlarını yazmadan kurmasını kolaylaştırıyor.

Sık sorulan sorular

Firebase harcama limiti ücretsiz mi?

Evet. Özelliğin kendisi için ek ücret yok; Blaze (kullandıkça öde) planındaki projelerde kullanılıyor.

Limit dolunca uygulamam tamamen mi kapanır?

Hayır, yalnızca limit konan hizmet duraklatılır. Veritabanı, kimlik doğrulama gibi diğer hizmetler çalışmaya devam eder.

Limit tam olarak belirlediğim tutarda mı durur?

Hayır. Raporlama birkaç dakika geciktiği için bir miktar aşım olabilir ve bu aşım faturalanır.

Duraklayan hizmeti nasıl açarım?

Limiti kaldırarak ya da kaldırıp daha yüksek bir bütçe girerek. Tam olarak devreye girmesi bir saate kadar sürebilir. Yeni ay başında limit kendiliğinden sıfırlanır.

Firestore için de limit koyabilir miyim?

Şimdilik hayır. Kapsam AI Logic, Cloud Functions, App Hosting ve Extensions ile sınırlı; Google kapsamın genişleyeceğini söylüyor.

İlgili yazılar: Claude Sonnet 5.5 ve Opus 5.5 fiyat rehberi · Mobil uygulama geliştirme · İletişim

Kapak fotoğrafı: Stephen Dawson / Unsplash