Más de lo que cabe

El punto de partida

Hasta ahora, lo que fallaba era el otro. En este episodio no falla nadie: simplemente llega más de lo que cabe. Es el último caso de la serie y el más honesto, porque ya no hay un culpable al que ponerle un tiempo máximo. Hay un límite, y hay que decidir qué pasa con lo que lo supera.

Hay dos formas de decidirlo. La primera protege a quien recibe: limitar el ritmo al que se envía (rate limiting). La segunda protege lo importante cuando todo llega a la vez: descartar con prioridad lo que no cabe (load shedding).

Limitarse a uno mismo

Las transferencias internacionales trajeron un límite que no es nuestro: cada corresponsal acepta como mucho 5 por segundo y, si se superan, bloquea las peticiones durante 10 segundos. El día de pago de nóminas, las empresas mandan ráfagas de 40 transferencias.

Un cubo de fichas es la solución clásica: el cubo se rellena a ritmo fijo, cada transferencia gasta una ficha y, si no quedan, espera. A la izquierda, sin limitar; a la derecha, un cubo cuyo ritmo y tamaño puedes cambiar.

Qué ha pasado

• Sin limitar, la ráfaga completa llega de golpe, el corresponsal acepta cinco y bloquea. El corresponsal no ha fallado: cumple lo que dijo, y el banco no se contuvo.
• Con un cubo, el ritmo es lo que acepta quien recibe. Las transferencias esperan unos segundos en la cola de Operaciones, que para una transferencia internacional es gratis, y ninguna se rechaza.
• El ritmo lo marca el límite del otro; el tamaño es cuánta ráfaga se permite de golpe. Un ritmo por encima, o un cubo mayor que el límite de un segundo, bloquea. Un cubo demasiado pequeño desperdicia capacidad.

Limitarse a uno mismo es la versión educada de lo que haría el corresponsal a la fuerza: pasa lo mismo, pero sin pérdidas y sin bloqueos.

Cuando lo que sobra es nuestro

Ahora el límite está dentro: el core que contrata el banco atiende 100 peticiones por segundo. El día 1 llegan, además de lo de siempre (30 pagos, 30 Bizum y 30 consultas por segundo), 1.200 recibos de golpe en diez segundos. Son 210 por segundo contra 100.

Pulsa «Llega el fichero de recibos». A la izquierda, una cola única; a la derecha, una cola con prioridades según el orden de la serie: primero los pagos con tarjeta, luego los Bizum, después los recibos y, por último, las consultas, que se descartan.

Quién espera y quién se va

• En una cola única, los pagos con tarjeta esperan detrás de cientos de recibos y la red de tarjetas, que no espera más de tres segundos, los deniega. Nadie ha decidido sacrificar a Laura: nadie ha decidido nada.
• Con prioridades, los pagos y los Bizum no notan el fichero. Los recibos tardan más, y pueden: tienen una fecha de cobro. Las consultas se descartan mientras dura. Rechazar a propósito lo prescindible salva lo importante.

El orden de prioridad es, otra vez, una decisión de negocio: está escrito en el dominio y lo aplica la arquitectura. Y las consultas que se descartan no se pierden en silencio: reciben un «inténtalo en un momento», que es mejor que una espera sin fin.

Para llevarse

• Limitar el ritmo (cubo de fichas) protege a quien recibe: el ritmo lo marca su límite y el tamaño del cubo, cuánta ráfaga se admite.
• Descartar con prioridad (load shedding) protege lo importante cuando todo no cabe: se rechaza antes lo prescindible.
• Los dos son decisiones previas: no se improvisan en mitad del incidente.

Y con esto termina Lo que no controlamos. En seis episodios, New Capital Bank ha aprendido a cortar las llamadas que se alargan, a aislar lo lento, a reintentar sin ahogar, a dejar de llamar a quien no responde, a decidir qué hacer sin un sistema crítico y a elegir qué se sacrifica cuando no cabe todo. En todos los casos, la respuesta era una decisión de negocio que la arquitectura refleja.

Lo que queda abierto es cómo ve el cliente un sistema con tantas piezas. Si lo que Laura ve en su extracto viene de una lectura que llega más tarde que la escritura, ¿por qué no ve su Bizum? Esa es la serie de lecturas frente a escrituras.