¿Cómo diseñarías un limitador de tasa para una API pública?

Elige primero la dimensión del límite, normalmente la clave de API y no la IP, y luego el algoritmo: token bucket para permitir ráfagas, ventana deslizante para una aplicación más suave. Guarda los contadores en un almacén compartido como Redis para que todas las instancias coincidan, usando incrementos atómicos con expiración. Devuelve 429 con una cabecera Retry After y la cuota restante, y falla en abierto si el propio limitador no está disponible, para que no pueda tumbarte la API.

Empiezo por qué estoy limitando por unidad, y para una API pública eso es la clave de API, no la IP, porque los clientes detrás de un mismo NAT no deberían tumbarse entre ellos. Después el algoritmo. Token bucket es mi opción por defecto, porque deja que un cliente haga una ráfaga pequeña, que es como se comportan las integraciones reales: se despiertan, lanzan veinte peticiones y luego se callan una hora. Un log de ventana deslizante es más preciso pero guarda más por clave. La parte importante es que el contador tiene que ser compartido, porque si cada una de mis seis instancias lleva su propia cuenta el límite real es seis veces el que anuncié, así que Redis con un incremento atómico y una expiración, o un script Lua pequeño cuando necesito la comprobación y el decremento juntos. Al rechazar devuelvo 429 con Retry After y la cuota restante en cabeceras, porque un cliente que puede echarse atrás bien deja de machacarme. Y fallo en abierto, porque un limitador que tumba la API ha hecho más daño que el abuso que evitaba.