La plateforme d'activation client.Chaque interaction devient un contact qualifié. Réserver une démo
Premiers pas

Limites de débit

Concevoir des clients OmniLab capables de gérer correctement le throttling, même lorsque les quotas exacts sont provisionnés par environnement.

Les quotas API exacts sont confirmés lors du provisioning. Cet article se concentre donc sur le comportement client à mettre en place avant le go-live.

À quoi s'attendre

  • les pics de trafic, les synchronisations bulk, et les boucles de polling serrées sont les causes les plus fréquentes de throttling
  • des endpoints de lecture comme les bookings peuvent aussi être throttlés si vous les appelez à chaque affichage au lieu de batcher ou de mettre en cache
  • les webhooks sont souvent une meilleure option qu'un polling répété lorsqu'un autre système a besoin de mises à jour rapides

Bonnes pratiques côté client

  • réutiliser les tokens d'accès jusqu'à leur expiration au lieu d'en demander un nouveau à chaque appel API
  • paginer les gros jeux de résultats au lieu de tout refetcher en boucle
  • mettre en cache les lectures lorsque quelques secondes de décalage sont acceptables
  • mettre les retries en file avec du jitter au lieu de réessayer immédiatement
  • respecter 429 Too Many Requests et toute valeur Retry-After si OmniLab l'envoie
  • automatiser surtout le retry des lectures idempotentes, et encadrer plus strictement les écritures et les annulations

Un modèle de retry sûr

  1. si une requête renvoie 429, reculez immédiatement
  2. si Retry-After est présent, attendez au moins cette durée
  3. sinon, utilisez un backoff exponentiel avec jitter
  4. limitez le nombre de workers concurrents pour éviter une tempête de retries
  5. remontez une alerte opérateur utile si le throttling devient durable
Politique simple de backoff
if response.status == 429:
  wait = retry_after_header or exponential_backoff_with_jitter
  retry_later()

Patterns qui réduisent le throttling

Cas d'usageMeilleur pattern
Afficher les bookings à venir dans un portailMettre les résultats en cache sur une courte fenêtre de session et rafraîchir à la demande
Garder un CRM à jourUtiliser les webhooks au lieu du polling
Faire un backfill historiqueLancer des batchs planifiés et paginer les résultats
Annuler une réservationFaire une lecture, puis annuler uniquement après action explicite du participant

Pour aller plus loin

Cette page vous a-t-elle aidé ?

Un commentaire optionnel nous aide à améliorer cette page pour les prochains auteurs et lecteurs.

Sur cette page