Comment concevriez-vous un limiteur de débit pour une API publique ?

Choisissez d'abord la dimension de la limite, en général la clé d'API plutôt que l'IP, puis choisissez un algorithme : token bucket pour autoriser des rafales, fenêtre glissante pour une application plus lisse. Gardez les compteurs dans un magasin partagé comme Redis pour que toutes les instances soient d'accord, avec des incréments atomiques et une expiration. Renvoyez un 429 avec un en-tête Retry After et le quota restant, et laissez passer en cas d'échec si le limiteur lui-même est indisponible pour qu'il ne puisse pas faire tomber votre API.

Je commence par ce sur quoi je limite, et pour une API publique c'est la clé d'API, pas l'IP, parce que des clients derrière un même NAT ne devraient pas s'éliminer les uns les autres. Ensuite l'algorithme. Le token bucket est mon défaut, parce qu'il laisse un client faire une petite rafale, ce qui correspond au comportement des vraies intégrations : elles se réveillent, envoient vingt requêtes, puis se taisent pendant une heure. Un journal à fenêtre glissante est plus précis mais stocke davantage par clé. La partie importante, c'est que le compteur doit être partagé, parce que si chacune de mes six instances suit son propre compte, la vraie limite est six fois celle que j'annonce, donc Redis avec un incrément atomique et une expiration, ou un petit script Lua quand j'ai besoin de la vérification et du décrément ensemble. Au rejet, je renvoie un 429 avec Retry After et le quota restant dans les en-têtes, parce qu'un client capable de reculer proprement arrête de me marteler. Et je laisse passer en cas d'échec, puisqu'un limiteur qui fait tomber l'API a fait plus de mal que l'abus qu'il empêchait.