Cuando un servicio recibe más peticiones de las que puede procesar, necesita mecanismos inteligentes para protegerse sin dejar de atender a los usuarios. Exactamente eso resuelven el throttling y las retry policies, dos conceptos que empresas como Amazon, Microsoft y Google aplican a diario en sistemas que reciben millones de requests cada segundo.
¿Qué es el throttling y por qué protege tu servicio?
El throttling consiste en establecer un límite máximo de peticiones que un servicio puede procesar en un intervalo de tiempo [01:52]. Si ese límite se supera, las peticiones adicionales se rechazan intencionalmente con un código de error. Es importante entender que no se trata de una falla real del servidor, sino de una decisión deliberada para evitar la sobrecarga.
En el ejemplo planteado, el servicio de publicación de reviews tiene un límite de una request por segundo (1 RPS) [05:40]. Si en algún momento llegan más peticiones de las permitidas, el servicio regresa un error 500 con un mensaje como "throttled" en el cuerpo de la respuesta [07:17]. Cada producto o servicio puede implementar su propia estrategia de throttling; si usas proveedores cloud como AWS o Azure, puedes investigar las policies disponibles para controlar esta limitación directamente en la infraestructura [06:30].
¿Por qué reintentar inmediatamente genera un efecto cascada?
El problema más peligroso aparece cuando los clientes reintentan sus peticiones fallidas de forma inmediata [08:16]. Imaginemos este escenario:
- Segundo 1: llegan 2 peticiones, se procesa 1, falla 1.
- Segundo 2: llegan 2 nuevas más 1 reintento, total 3 peticiones, se procesa 1, fallan 2.
- Segundo 3: llegan 2 nuevas más 2 reintentos, total 4 peticiones, se procesa 1, fallan 3.
Este patrón genera un crecimiento lineal de fallas a lo largo del tiempo [09:28]. Cada segundo acumula más peticiones pendientes hasta que el sistema colapsa por completo. Es un ciclo destructivo donde el propio mecanismo de reintento se convierte en el problema.
¿Cómo funciona el exponential backoff para evitar el colapso?
La solución se llama Exponential Backoff [07:30], un patrón de reintento donde el tiempo de espera entre cada intento crece de forma exponencial en lugar de ser inmediato. En vez de reintentar al siguiente segundo, el cliente espera 20 segundos, luego 40 segundos, y así sucesivamente.
- Reduce la presión sobre el servicio al espaciar los reintentos.
- Permite la recuperación cuando el tráfico baja temporalmente.
- Aplana la curva de fallas en lugar de dejarla crecer sin control [10:03].
Si en algún momento el tráfico se reduce, por ejemplo a cero peticiones en el segundo cinco, el servicio puede procesar las peticiones pendientes y las fallas comienzan a disminuir [10:10]. Así el sistema se estabiliza por sí mismo.
¿Dónde se implementa: en el backend o en el cliente?
El reto tiene dos partes bien diferenciadas [05:02]:
- En el backend: implementar el throttling que limite las peticiones a 1 RPS para el servicio de publicación de reviews.
- En el cliente HTTP: crear métodos como
crearReview (para POST) y opcionalmente uno de lectura (para GET) que detecten el error 500 con mensaje de throttling y apliquen exponential backoff automáticamente [06:50].
Es fundamental que el cliente que construyas encapsule esta lógica de reintento, de modo que quien lo utilice en el frontend no tenga que preocuparse por gestionar los reintentos manualmente [11:09]. Si el backoff no está implementado correctamente, la única alternativa es fallar las requests directamente.
¿Qué habilidades desarrollas al resolver este tipo de problemas?
Resolver este reto implica trabajar con conceptos de escalabilidad que se enfrentan diariamente en compañías de gran escala [11:36]. Comprender el concepto de RPS (requests por segundo) te permite dimensionar las capacidades reales de un servicio. Dominar las retry policies te da herramientas para diseñar sistemas resilientes que se recuperan solos ante picos de tráfico.
La experiencia compartida desde el trabajo en Amazon en 2018 [00:43] muestra que estos no son problemas teóricos; son situaciones reales donde productos utilizados en todo el mundo necesitan mecanismos robustos para mantenerse saludables bajo presión extrema.
Si te interesa profundizar, los recursos recomendados están disponibles en la clase y cubren en detalle las estrategias de exponential backoff y throttling policies. ¿Has enfrentado alguna vez un problema de escalabilidad similar? Comparte tu experiencia en los comentarios.
