Firebase faturası neden artar? Okuma, listener ve trafik maliyetini analiz edin

Kimler için?

Firebase kullanan mobil geliştiriciler ve ürün bütçesini yöneten ekipler.

Başlamadan önce

Son fatura, ürün bazlı kullanım raporu ve uygulamanın en yoğun üç ekranı.

1. Faturayı ürün ve iş akışına ayırın

Firestore, dosya depolama, ağ trafiği ve sunucu işlerini tek bir kullanıcı sayısına bölmek kök nedeni gizler. Aynı aktif kullanıcı, bir sohbet ekranında birçok sorgu yaparken bir profil ekranında tek istek gönderebilir. Önce her ekranın yaptığı işlemi çıkarın. Ölçüm dönemini faturayla aynı tarihlere sabitleyin; günlük toplamlarla aylık tutarı karıştırmayın.

Gerçek test cihazında ekranı açma, yenileme, arka plana alma ve tekrar açma akışlarını izleyin. Aynı veri birkaç bileşenden ayrı ayrı isteniyorsa maliyet ile gecikme birlikte büyür. Üretim raporunda sürüm değişikliklerinin tarihlerini işaretleyin; artışın kullanıcı büyümesi mi, yeni bir sorgu mu olduğunu böyle ayırabilirsiniz.

• Her sorguya ekran ve işlem adı verin; kullanıcıya ait hassas veriyi loglamayın.
• Okuma, yazma, depolama ve çıkış trafiğini ayrı takip edin.
• FCM gibi ücretsiz ürünleri ücretli kullanım kalemleriyle aynı varsayımda değerlendirmeyin.

2. Örnek iş yükünü doğru yorumlayın

Aşağıdaki sayılar bir fiyat teklifi veya gerçek müşteri ölçümü değildir. Bir liste ekranının istek hacmini modellemek için varsayımsal bir başlangıçtır. Günlük 1.000 kullanıcı ekranı dört kez açıyor ve her açılış 25 belge getiriyorsa ilk liste yüklemeleri yaklaşık 100.000 belge dönüşü oluşturur. Listener güncellemeleri, yeniden bağlantılar ve diğer sorgular buna eklenebilir.

1.000 kullanıcı × 4 açılış × 25 belge = 100.000 belge dönüşü / gün
Bu sayı faturalanan toplam işlemin kesin hesabı değildir.

3. Sorguları ve listener ömrünü azaltın

Görünmeyen ekranın aboneliğini açık tutmayın. Liste için sayfalama tasarlayın; her kaydırmada tüm veri setini tekrar istemeyin. Kullanıcının son gördüğü durumu yerel olarak tutarken güncelliğin ne kadar önemli olduğunu belirleyin. Örneğin ürün açıklaması gecikmeli güncellenebilirken ödeme yetkisi sunucudan doğrulanmalıdır. Cache politikasını veri türüne göre kurmak maliyet kararını güvenlik kararından ayırır.

• Tek bir ekranın aynı sorguyu iki kez açıp açmadığını kontrol edin.
• Çevrimdışı/yeniden bağlantı davranışını gerçek cihazda test edin.
• İndirme boyutunu ve liste uzunluğunu ölçmeden cache eklemeyin.

4. Hibrit mimariyi tam geçişle karşılaştırın

Firestore’dan ayrılmak Auth, güvenlik kuralları, realtime davranışı ve offline veri modelinin yeniden kurulmasını gerektirebilir. Yalnızca ağır raporları kendi API’nize taşımak daha küçük bir değişiklik olabilir. FCM gibi ihtiyaçlarınıza uygun servisleri kullanmaya devam edebilirsiniz. Hangi parçanın taşınacağını açıkça listeleyin; veritabanını değiştirmek tüm SDK davranışlarını otomatik karşılamaz.

5. Tasarrufu toplam bütçe üzerinden doğrulayın

Yeni hosting tutarına bakım, izleme, yedekleme, SMS/e-posta ve medya giderlerini ekleyin. Taşıma ve test için harcanan zamanı tek seferlik gider olarak yazın. Eski ve yeni çözüm aynı iş yükünü, gecikme hedefini ve kurtarma gereksinimini karşılamıyorsa iki aylık tutar doğrudan karşılaştırılamaz. Maliyet hesaplayıcısı bu girdileri toplar; gerçekleşmiş tasarruf veya eşdeğer kapasite garantisi üretmez.

6. Değişikliği küçük bir deneyle yayınlayın

Önce bir ekran veya sınırlı bir kullanıcı grubuyla çalışın. Hata oranı, kullanıcı başına işlem sayısı, veri güncelliği ve aylık tahmini gider için bir başlangıç ölçümü alın. Deney sırasında veri kaybı ya da yetki hatası oluşursa geri dönülecek yolu hazırlayın. En ucuz görünen tasarımı değil, ölçtüğünüz iş yükünde kabul kriterlerini sağlayan tasarımı genişletin.