Elke API heeft grenzen. Stuur je te veel requests te snel, dan weigert Workspace verdere calls met een rate-limit-fout. Dat is geen bug maar een bescherming, en jouw taak is om er netjes mee om te gaan. Een goede integratie loopt niet vast bij een 429, maar herstelt automatisch. In dit artikel leer je hoe.
Hoe quota werken
Workspace-quota zijn meerlaags. Je kunt op verschillende niveaus tegen een limiet aanlopen.
- Per gebruiker per minuut: hoeveel calls je namens een enkele gebruiker mag doen.
- Per project per minuut: het totaal over al je gebruikers heen.
- Per dag: een dagelijks plafond voor sommige API's.
429 en 403 betekenen hetzelfde
Een 429-fout en een 403 met reden rateLimitExceeded of userRateLimitExceeded betekenen in de praktijk hetzelfde: je gaat te snel. De juiste reactie is niet meteen opnieuw proberen, maar wachten en dan met geleidelijk langere pauzes opnieuw proberen.
Exponential backoff met jitter
De standaardoplossing is exponential backoff: na elke mislukking wacht je ongeveer twee keer zo lang. De jitter, een willekeurige toevoeging, voorkomt dat veel clients precies tegelijk opnieuw proberen.
De formule die Google zelf aanraadt is (2 ^ poging) + willekeurig aantal milliseconden, waarbij die random component maximaal 1 seconde is. Begrens de wachttijd bovendien met een maximum (vaak 32 of 64 seconden), zodat je niet eindeloos langer gaat wachten.
import time, random
def met_backoff(actie, max_pogingen=5, max_backoff=64):
for poging in range(max_pogingen):
try:
return actie()
except HttpError as e:
if e.resp.status in (429, 403) and poging < max_pogingen - 1:
wacht = min((2 ** poging) + random.uniform(0, 1), max_backoff)
time.sleep(wacht)
else:
raise
Vergeet de jitter niet
Zonder die willekeurige component proberen alle clients precies tegelijk opnieuw, wat tot een nieuwe golf van fouten leidt, de zogenoemde thundering herd. Een kleine random toevoeging spreidt de pogingen en herstelt veel soepeler.
De druk verlagen
Backoff is genezen, maar voorkomen is beter. Verminder het aantal calls dat je doet. Drie effectieve aanpakken:
- Bundel losse calls. Doe je veel kleine, losse calls? Bundel ze met batch-requests om er een enkele HTTP-call van te maken.
- Cache herhaalde reads. Vraag je dezelfde data herhaaldelijk op? Cache het resultaat en gebruik
ETagsom alleen wijzigingen op te halen. - Spreid bulk over de tijd. Verwerk je een grote bulk in een keer? Verspreid het werk in plaats van alles tegelijk te versturen.
Een robuuste verwerkingsstrategie
Zo bouw je een integratie die niet omvalt
- Schat vooraf je volume in en vergelijk het met de quota van de API.
- Bouw backoff met jitter standaard in elke API-laag in.
- Spreid bulk-werk met een wachtrij in plaats van een burst.
- Monitor je quotagebruik in de Google Cloud Console.
- Vraag een quotaverhoging aan als je structureel tegen de limiet zit.
Blijf niet domweg opnieuw proberen
Negeer herhaalde rate-limit-fouten niet door eindeloos te blijven proberen. Dat verergert het probleem en kan ertoe leiden dat je tijdelijk harder geblokkeerd wordt. Respecteer de signalen, verlaag je tempo, en herontwerp je aanpak als je structureel tegen limieten aanloopt.
Veelgestelde vragen
Geeft de API aan hoe lang ik moet wachten?
Niet altijd expliciet. Sommige responses bevatten een Retry-After-header. Respecteer die als hij er is, en gebruik anders je eigen backoff-berekening.
Kan ik mijn quota verhogen?
Voor veel Workspace-API's kun je in de Google Cloud Console een quotaverhoging aanvragen. Onderbouw je verzoek met je verwachte volume, dan is de kans op goedkeuring groter.
Helpt het om meerdere projecten te gebruiken?
Quota gelden per project, dus werk spreiden over projecten kan in sommige gevallen helpen. Gebruik dit niet om limieten kunstmatig te omzeilen, want dat is tegen het beleid en kan tot schorsing leiden.
Tellen mislukte calls mee voor mijn quota?
Vaak wel. Daarom is het zo belangrijk om niet agressief opnieuw te proberen: elke poging telt mee en verergert het probleem. Backoff houdt je binnen de grenzen.
Wat is het verschil tussen rateLimitExceeded en userRateLimitExceeded?
rateLimitExceeded slaat doorgaans op de limiet van je hele project, userRateLimitExceeded op de limiet voor een specifieke gebruiker. De afhandeling is in beide gevallen gelijk: wachten en met backoff opnieuw proberen.
Met exponential backoff, jitter en slim quotabeheer bouw je integraties die soepel doorlopen, ook onder druk en op schaal.