El pico de la noche
Nada está roto
A las ocho de la tarde empiezan las ofertas nocturnas. Antifraude está sano. Cuentas está sano. No hay nada que ralentizar, ningún servicio al que dejar de llamar. Y aun así Tarjetas se ahoga.
Por la entrada de Tarjetas pasa todo: los pagos de los TPV de cada comercio, las consultas de movimientos que la gente hace desde la app para ver cuánto lleva gastado y, de vez en cuando, un bloqueo de tarjeta. Esta noche llega más de lo que Tarjetas puede atender. En parte porque hay más compras, y en parte por una tienda online cuya integración, cuando algo tarda, reintenta en bucle: el antipatrón del episodio 3, visto desde el otro lado.
Luis, por cierto, ha encontrado la cartera. Pero no la tarjeta.
Qué dejar pasar
Cuatro comercios mandan pagos y la app manda consultas. Tarjetas tiene 12 trabajadores: en una noche normal va al 70 %. A la izquierda, todo entra y hace una sola cola. A la derecha, dos defensas: un cubo de fichas por comercio (las casillas verdes: entran 20 por segundo y cada petición gasta una) y una cola por prioridades: bloqueos primero, luego pagos, y las consultas se descartan en cuanto la espera pasa de 0,4 s.
Pulsa Arrancar, desboca la tienda online y mira el porcentaje de pagos que salen bien en cada comercio. Luego prueba la sobrecarga general y pulsa L.
Qué ha pasado
Un comercio desbocado: rate limiting
La tienda online manda 80 peticiones por segundo en lugar de 6.probar en el laboratorio Sin protección, entran todas en la misma cola que los pagos de la librería y del súper. La cola crece, cada petición espera más que la anterior y, cuando la espera pasa de cinco segundos, los TPV de todos los comercios empiezan a dar pagos por fallidos. Un solo cliente mal integrado ha tumbado el servicio para todos.
Con un límite por comercio, cada uno tiene su cubo de fichas: entran 20 por segundo, hasta un máximo de 20, y cada petición gasta una. La tienda online vacía el suyo enseguida, y el resto de sus peticiones se rechazan en la puerta con un 429 Too Many Requests, sin llegar a Tarjetas. Los demás comercios ni se enteran.
La tienda online también sufre: sus compras de verdad compiten por las fichas con sus propios reintentos, y muchas se rechazan. Pero el problema se queda con quien lo causa. La respuesta lleva una cabecera Retry-After que le dice cuándo volver; una integración bien hecha la respeta y reintenta con backoff. Esta no lo hace, y no depende de nosotros arreglarlo: sí depende de nosotros que no afecte a nadie más.
Sobrecarga general: load shedding
Ahora nadie hace nada mal: simplemente hay un 80 % más de todo.probar en el laboratorio Los límites por comercio no ayudan, porque cada uno está dentro del suyo. Sin protección, pasa lo peor que le puede pasar a un servicio sobrecargado: la cola crece sin freno, la espera supera los cinco segundos y, a partir de ahí, Tarjetas trabaja para TPV que ya se han ido. Está al 100 % y no autoriza casi nada. Es un colapso: con un poco más de carga de la que aguanta, no atiende un poco menos, atiende casi nada.
La alternativa es decidir qué no hacer. Con descarte por prioridades (load shedding), la entrada estima cuánto va a esperar cada petición y rechaza al momento lo que menos importa:
- Consultas de movimientos: prioridad baja. Si la espera pasa de 0,4 s, se descartan con un
503. La app enseña los movimientos de hace un rato, o un «inténtalo en un momento». Molesta, pero no se pierde una venta. - Pagos: prioridad alta. Solo se descartan si la espera ya es de tres segundos, porque entonces no llegarían a tiempo de todas formas.
- Bloqueos de tarjeta: prioridad máxima. Pasan delante de todo y nunca se descartan. Luis bloquea su tarjeta aunque Tarjetas esté al límite.
Rechazar deprisa es mejor que aceptar y no cumplir: una consulta rechazada en 60 ms libera sitio para un pago; una consulta aceptada que espera 8 segundos ocupa un trabajador para nada.
Cuándo hace daño: un límite mal calibrado
El gran almacén tiene su pico legítimo: 24 pagos por segundo. Si el límite por comercio está en 10/s, se rechazan más de la mitad de sus pagos, con Tarjetas medio vacía.probar en el laboratorio No ha hecho nada mal: vende más porque es más grande, y esa noche es cuando más vende. El límite, que existía para protegerle de otros, le está haciendo perder ventas a él.
Un límite igual para todos casi nunca sirve. Se calibra por cliente, a partir de su tráfico real y con margen para su pico, y se revisa. Y conviene vigilar los 429: un comercio legítimo que los recibe a menudo es un aviso de que su límite se ha quedado corto.
Criterio
| Problema | Defensa | Cómo se decide |
|---|---|---|
| Un cliente manda más de lo que le toca | Rate limiting por cliente (token bucket, ventana deslizante…) | Por cliente, con su tráfico real y margen para su pico. Responder 429 con Retry-After |
| Llega más de lo que el servicio puede atender, de todos | Load shedding por prioridades | Qué es lo último que el negocio dejaría de atender: aquí, las consultas antes que los pagos |
| Hay operaciones que no pueden esperar ni perderse | Prioridad máxima, nunca se descartan | Bloqueos de tarjeta |
| La cola crece sin freno | No encolar lo que no llegará a tiempo | Descartar por espera estimada o por plazo (ep. 1) |
Las dos defensas se complementan: el límite por cliente protege a unos clientes de otros; el descarte por prioridades protege al servicio de sí mismo cuando todos a la vez piden demasiado.
En el mundo real
Casi todas las APIs públicas de pagos tienen límites por cliente y responden 429. Stripe, por ejemplo, documenta sus límites por cuenta, distingue entre el modo de pruebas y el real, y recomienda reintentar con backoff exponencial cuando se reciben. Los API gateways (Kong, NGINX, Envoy, los de los proveedores de nube) traen rate limiting por clave o por cliente, en local o con un contador compartido en Redis.
Sobre load shedding, la Amazon Builders' Library tiene un artículo que cuenta cómo sus servicios estiman el coste de cada petición y rechazan pronto para no caer en el colapso por sobrecarga, y Google describe en el libro de SRE cómo sus servicios usan la criticidad de cada petición para decidir qué descartar primero. Stripe explicó en su blog cómo combina limitadores por usuario con descarte de tráfico no crítico para proteger la API en picos.
Y el colapso de la izquierda tiene nombre en la literatura: congestion collapse o metastable failure, cuando un sistema queda atascado en un estado malo aunque la causa inicial desaparezca, porque el trabajo inútil (atender peticiones que ya nadie espera, reintentos) lo mantiene saturado.
Final de la serie
Un solo día de Black Friday y cinco fronteras: un timeout que acota cuánto se espera, compartimentos que acotan cuántos esperan, reintentos que no añaden carga cuando más duele, un breaker que deja de llamar a lo que no contesta y una entrada que elige qué no atender. Ninguna evita que algo falle; todas deciden hasta dónde llega el fallo. Y cada una tiene su precio: rechazar trabajo, responder algo peor, esperar menos.
Hay una decisión que ha atravesado toda la serie sin nombre: el riesgo acotado. Cuando Antifraude no contesta, BCPS Bank prefiere autorizar hasta 50 € sin saber si es fraude antes que dejar a Ana sin pagar. Elegir entre estar disponible y estar seguro de tener la información correcta tiene nombre, y un teorema detrás.
Siguiente serie · Consistencia y concurrencia CAP, aislamiento y consistencia El cajero sin conexión, las cuentas conjuntas y por qué el riesgo acotado de 50 € es una elección entre disponibilidad y consistencia.