Google Takvim API'si, tüm kullanıcılar tarafından adil bir şekilde kullanılmasını sağlamak için kotalara sahiptir. Takvim API'sini kullanırken göz önünde bulundurmanız gereken üç önemli sınırlama vardır:
API kullanım kotaları: Proje ve kullanıcı başına uygulanır. Daha fazla bilgi için Calendar API kullanım kotası türleri başlıklı makaleyi inceleyin.
Genel Google Takvim kullanım sınırları: Google Takvim API, Google Workspace sisteminin genel performansını korumak için sınırlamaları olan paylaşılan bir hizmettir. Daha fazla bilgi için Takvim kullanım sınırlarından kaçınma başlıklı makaleyi inceleyin.
İşletim sınırları: Bu sınırlar herhangi bir zamanda sınırlanabilir. Örneğin, tek bir takvime hızlı bir şekilde yazmaya çalıştığınızda.
Calendar API kotaları
İki tür kota uygulanır:
Proje başına dakikada: Bu, Google Cloud projenizin bir dakikada yapabileceği istek sayısıdır.
Proje başına kullanıcı başına dakika: Bu, belirli bir kullanıcının Cloud projenizde yapabileceği istek sayısıdır. Bu sınır, kullanımın kullanıcılarınız arasında adil bir şekilde dağıtılmasını sağlamanıza yardımcı olmayı amaçlar.
Kotalar, kayan pencere kullanılarak dakika başına hesaplanır. Bir dakika içinde dakika başına kotanızı aşan hızlı bir trafik patlaması, ortalama olarak kullanımınızın kotalar içinde kalmasını sağlamak için bir sonraki pencerede hız sınırlamasına neden olur.
Aşağıdaki tabloda bu sınırlar ayrıntılı olarak açıklanmaktadır:
| Kullanım sınırı türü | Sınır |
|---|---|
| Proje başına dakika | 10.000 istek |
| Proje başına kullanıcı başına dakikada | 600 istek |
Günlük faturalandırma eşiği
Bu proje başına günlük sınır, ücretlendirme uygulanmadan önce Google Cloud projenizin 24 saatlik bir süre içinde kullanabileceği maksimum istek sayısını tanımlar.
Bu eşiğin altındaki kullanım için ek ücret alınmaz ve Google Cloud hesabınız faturalandırılmaz. Faturalandırmayla ilgili tüm ayrıntılar, 2026'da değişiklikler yürürlüğe girmeden en az 90 gün önce paylaşılacaktır.
Bu günlük eşik sınırını artırma isteğinde bulunamazsınız.
Sınırla ilgili ayrıntılar aşağıdaki tabloda verilmiştir:
| Eşik sınırlama türü | Sınır |
|---|---|
| Proje başına günlük | 1.000.000 istek |
Daha fazla bilgi için Google Workspace standardized model for agent tools and APIs başlıklı makaleyi inceleyin.
Zamana dayalı kota hatalarını düzeltme
Zamana dayalı tüm hatalar (X dakika başına en fazla N istek) için kodunuzun istisnayı yakalamasını ve cihazlarınızın aşırı yük oluşturmadığından emin olmak için kısaltılmış eksponansiyel geri yükleme kullanmasını öneririz.
Eksponansiyel geri yükleme, ağ uygulamaları için standart bir hata işleme stratejisidir. Eksponansiyel geri yükleme algoritması, istekler arasındaki bekleme sürelerini üstel olarak artırarak istekleri yeniden dener. Bu işlem, maksimum geri yükleme süresine kadar devam eder. İstekler hâlâ başarısız oluyorsa istek başarılı olana kadar istekler arasındaki gecikmelerin zaman içinde artması önemlidir.
Örnek algoritma
Eksponansiyel geri yükleme algoritması, istekleri eksponansiyel olarak yeniden dener ve yeniden denemeler arasındaki bekleme süresini maksimum geri yükleme süresine kadar artırır. Örneğin:
- Google Takvim API'ye istek gönderin.
- İstek başarısız olursa 1 +
random_number_millisecondsbekleyin ve isteği yeniden deneyin. - İstek başarısız olursa 2 +
random_number_millisecondssaniye bekleyip isteği yeniden deneyin. - İstek başarısız olursa 4 +
random_number_millisecondssaniye bekleyin ve isteği yeniden deneyin. - Bu işlem
maximum_backoffkez tekrarlanabilir. - Maksimum deneme sayısına ulaşana kadar beklemeye ve yeniden denemeye devam edin ancak yeniden denemeler arasındaki bekleme süresini artırmayın.
Bu örnekte:
- Bekleme süresi
min(((2^n)+random_number_milliseconds), maximum_backoff)'dır. Her yineleme (istek) içinndeğeri 1 artırılır. random_number_milliseconds,1.000'den küçük veya 1.000'e eşit rastgele bir milisaniye sayısıdır. Bu sayede, birçok istemcinin belirli bir durum nedeniyle senkronize olup aynı anda yeniden denediği ve senkronize dalgalar halinde istek gönderdiği durumlar önlenir.random_number_millisecondsdeğeri her yeniden deneme isteğinden sonra yeniden hesaplanır.maximum_backoffgenellikle 32 veya 64 saniyedir. Uygun değer, kullanım alanına bağlıdır.
İstemci, maximum_backoff süresine ulaştıktan sonra yeniden denemeye devam edebilir.
Bu noktadan sonraki yeniden denemelerde geri yükleme aralığı süresinin artırılmasına gerek yoktur. Örneğin, bir istemci 64 saniyelik bir maximum_backoff kullanıyorsa bu değere ulaştıktan sonra her 64 saniyede bir yeniden deneyebilir. Bir noktada, istemcilerin süresiz olarak yeniden denemesi engellenmelidir.
Yeniden denemeler arasındaki bekleme süresi ve yeniden deneme sayısı, kullanım alanınıza ve ağ koşullarına bağlıdır.
Fiyatlandırma
Google Takvim API'nin tüm standart kullanımları ek ücret ödenmeden kullanılabilir. Kota istek sınırlarının aşılması nedeniyle 2026'nın ilerleyen dönemlerinde Google Cloud Faturalandırma Hesabınızdan ücret alınması planlanmaktadır. Daha fazla bilgi için Google Workspace'in aracı araçları ve API'leri için standartlaştırılmış modeli başlıklı makaleyi inceleyin.
Kota artışı isteme
Projenizin kaynak kullanımına bağlı olarak kota ayarlaması isteğinde bulunmak isteyebilirsiniz. Bir hizmet hesabı tarafından yapılan API çağrıları, tek bir hesap kullanılıyormuş gibi değerlendirilir. Ayarlanmış kota başvurusunda bulunmak onay alacağınıza dair bir garanti teşkil etmez. Kota değerini önemli ölçüde artıracak kota ayarlama isteklerinin onaylanması daha uzun sürebilir.
Her projenin kotası aynı değildir. Google Cloud'u zaman içinde daha fazla kullandıkça kota değerlerinizin artırılması gerekebilir. Kullanımın önemli oranda artacağını düşünüyorsanız Google Cloud Console'daki Kotalar ve Sistem Sınırları sayfasından önlem amaçlı olarak kota ayarlaması isteyebilirsiniz.
Daha fazla bilgi edinmek için aşağıdaki kaynakları inceleyin:
- Kota ayarlamaları hakkında
- Kota kullanımınızı ve sınırlarınızı görüntüleme
- Daha yüksek bir kota sınırı isteğinde bulunma
Sorun giderme
Kotalardan biri aşılırsa hız sınırına tabi tutulursunuz ve sorgularınıza yanıt olarak 403
usageLimits durum kodu veya 429
usageLimits durum kodu alırsınız.
Bu durumda aşağıdakileri deneyebilirsiniz:
Tüm en iyi uygulamaları uyguladığınızdan emin olun: Üstel geri çekilme kullanın, trafik kalıplarını rastgele hale getirin ve push bildirimlerini kullanın.
Projeniz büyüyorsa ve daha fazla kullanıcınız varsa kota artışı isteyebilirsiniz.
Kullanıcı başına kota sınırlarına ulaşırsanız aşağıdakileri yapabilirsiniz:
Hizmet hesabı kullanıyorsanız yükü kullanıcılara dağıtın veya birden fazla hizmet hesabı arasında paylaştırın.
Kullanıcı başına kotayı artırma isteğinde bulunabilirsiniz ancak uygulamanız genel takvim kullanım sınırları veya operasyonel sınırlar gibi başka türden sınırlara ulaşmaya başlayabileceğinden, genellikle varsayılan değerin üzerine çıkarmanız önerilmez.
Üretim projenizle benzer bir yapılandırmaya sahip, yalnızca test için kullanılan ayrı bir proje kaydederek kota sınırlarınızı test edin. Daha fazla bilgi için Test quota limit handling (Kota sınırı işlemeyi test etme) başlıklı makaleyi inceleyin.
Trafik kalıplarını rastgele hale getirme
Takvim istemcileri, birden fazla istemcinin aynı anda işlem yapmasından kaynaklanan ani trafik artışlarına eğilimlidir. Örneğin, Takvim istemcisi için yaygın bir kötü uygulama, gece yarısı tam senkronizasyon yapmaktır. Bu durum, dakikadaki kotanızın aşılmasına ve sonuç olarak sıklık sınırlaması ile geri çekilmelere yol açar.
Bunu önlemek için trafiğinizin mümkün olduğunca gün içine yayılmış olduğundan emin olun. Müşterinizin günlük senkronizasyon yapması gerekiyorsa müşterinin rastgele bir zaman belirlemesini sağlayın (her müşteri için farklı bir zaman). Düzenli olarak bir işlem yapmanız gerekiyorsa aralığı +/- %25 oranında değiştirin. Bu sayede trafik daha eşit şekilde dağıtılır ve kullanıcı deneyimi önemli ölçüde iyileşir.
Push bildirimlerini kullanma
Kullanıcının takviminde bir değişiklik olduğunda işlem yapılması, yaygın bir kullanım alanıdır. Buradaki bir anti-pattern, ilgilenilen her takvimi tekrar tekrar yoklamaktır. Bu işlem, kotanızın tamamını çok hızlı bir şekilde kullanır. Örneğin, uygulamanızın 5.000 kullanıcısı varsa ve her kullanıcının takvimini dakikada bir kez yokluyorsa herhangi bir işlem yapılmadan önce bile dakikada en az 5.000 kota gerekir.
Sunucu tarafı uygulamaları, push bildirimlerine kaydolabilir. Bu sayede, ilgi çekici bir olay olduğunda sizi bilgilendirebiliriz. Bunların ayarlanması daha fazla çalışma gerektirir ancak kotanızın çok daha verimli kullanılmasını sağlar ve daha iyi bir kullanıcı deneyimi sunar. Hangi eventType hakkında bildirim almak istediğinizi belirttiğinizden emin olun. Daha fazla bilgi için Push bildirimleri konusuna bakın.
Hizmet hesaplarıyla uygun tahsis
Uygulamanız alan genelinde yetki kullanarak istekte bulunuyorsa varsayılan olarak "proje başına kullanıcı başına dakika başına" kotaları açısından hizmet hesabı ücretlendirilir. Kimliğine büründüğünüz kullanıcı ücretlendirilmez. Bu nedenle, hizmet hesabı birden fazla kullanıcının takviminde çalışıyor olsa bile kotası tükenir ve sıklık sınırlamasına tabi olur.
Hangi kullanıcının ücretlendirileceğini belirtmek için quotaUser URL parametresini (veya x-goog-quota-user HTTP üstbilgisini) kullanarak bu durumdan kaçınabilirsiniz. Bu yalnızca kota hesaplamaları için kullanılır. Daha fazla bilgi için Kullanıcı başına istek sayısını sınırlama başlıklı makaleyi inceleyin.
Kota sınırı işleme özelliğini test etme
Uygulamanızın, pratikte kota sınırlarına ulaşmayı sorunsuz bir şekilde yönetebildiğinden (örneğin, üstel geri çekilme ile yeniden denemeler yoluyla) emin olmak ve kullanıcılarınızda olası rahatsızlıkları en aza indirmek için senaryonuzu gerçek bir ortamda test etmenizi önemle tavsiye ederiz.
Gerçek uygulama kullanımınızda herhangi bir aksaklık olmadan test etmek için Google Cloud Console'da yalnızca test için ayrı bir proje kaydetmenizi ve ardından OAuth kullanıcı rızası ekranını üretim projenize benzer şekilde yapılandırmanızı öneririz. Ardından, bu proje için yapay olarak düşük kota sınırları belirleyebilir ve uygulamanızın davranışını gözlemleyebilirsiniz.