Entegrasyon rehberleri · 2026-09-22

Gemini API mobil uygulamalarda rate limit ve kota yönetimi

Android veya iOS uygulamasından doğrudan Gemini API çağırmanın neden risk taşıdığını ve backend proxy üzerinden rate limit, kota ve maliyet kontrolünün nasıl kurulacağını anlatır.

Mobil uygulamadan gelen isteklerin doğrudan değil bir backend proxy üzerinden Gemini API'ye yönlendirildiğini, aradaki kimlik ve kota katmanını gösteren şema.

Mobil istemciye gömülü anahtar neden sorun çıkarır

Google AI Studio ile üretim geçişini anlatan rehberde de vurgulandığı gibi, bir API anahtarı derlenmiş uygulama paketinin içine konduğunda gizli kalmaz; tersine mühendislikle çıkarılabilir. Mobil bir uygulamadan Gemini API'ye doğrudan istek atmak, tek bir kullanıcının anahtarı çıkarıp kendi amacı için kullanmasını veya kotanızı tüketmesini mümkün kılar.

Rate limit ve kota, sağlayıcı tarafında anahtar başına uygulanır; anahtar tek ve paylaşılan olduğunda tüm kullanıcı tabanınız aynı sınırı paylaşır. Bir kullanıcının aşırı istek göndermesi, o anda uygulamayı kullanan herkesin isteğini etkileyebilir.

Backend proxy ile merkezi kota kontrolü

Doğru mimari, mobil istemcinin kendi sunucunuza (veya LLMTR gibi bir gateway'e) kimlik doğrulamalı bir istek atması, gerçek model çağrısının sunucu tarafında yapılmasıdır. Bu katman üç şeyi aynı anda çözer: sağlayıcı anahtarı istemciye hiç ulaşmaz, kullanıcı başına rate limit sizin kontrolünüzdedir ve toplam harcamayı kullanıcı, oturum veya özellik bazında izleyebilirsiniz.

Kullanıcı başına limit uygularken sabit bir sayı yerine özelliğe göre farklılaştırmak daha sürdürülebilirdir; örneğin ücretsiz kullanıcı için dakikada birkaç istek, ücretli katmanda daha yüksek bir sınır tanımlamak.

  • Sağlayıcı anahtarını istemciye asla gömmeyin; yalnızca sunucu tarafında tutun.
  • 429 yanıtını istemcide üstel geri çekilme (exponential backoff) ile karşılayın, sabit aralıkla tekrar denemeyin.
  • Kullanıcı başına ve özellik başına ayrı limit tanımlayın; tek global sınır kötüye kullanımı geç fark ettirir.

429 hatasını istemci tarafında ele almak

Sunucu tarafında kota aşımı bile olsa, mobil istemcinin 429 yanıtını kullanıcıya ham hata metniyle göstermek yerine anlaşılır bir mesajla karşılaması gerekir. Yeniden deneme mantığı sabit bir aralıkla değil, artan bekleme süresiyle (üstel geri çekilme) kurulmalı; aksi halde çok sayıda istemci aynı anda tekrar deneyerek sunucudaki yükü daha da artırabilir.

Sık sorulan sorular

Gemini API anahtarını mobil uygulama içinde şifreleyerek saklasam yeterli olur mu?

Hayır. Cihazda çalışan bir uygulama kendi şifre çözme mantığını da taşımak zorundadır, bu yüzden anahtar er ya da geç açık biçimde bellekte belirir ve çıkarılabilir. Tek güvenilir çözüm, anahtarı hiç istemciye göndermemek ve isteği sunucu tarafında yapmaktır.

Backend proxy eklemek gecikmeyi artırır mı?

Ek bir ağ sıçraması gecikme ekler, ancak bu maliyet merkezi kota kontrolü, anahtar güvenliği ve kullanım analitiği karşılığında genellikle kabul edilebilir düzeydedir. Proxy'yi model sağlayıcısına coğrafi olarak yakın bir bölgede çalıştırmak farkı azaltır.

İlgili yazılar