Fraude: ¿esperar o avisar?

El punto de partida

Ya sabemos dónde se corta el software de New Capital Bank y qué relación tiene cada contexto con los demás. Falta lo que pasa en el día a día: cómo se hablan. Cuando Operaciones necesita algo de Fraude, ¿le pregunta y espera la respuesta, o le avisa y sigue?

El banco tiene una regla escrita desde el principio: Fraude evalúa cada pago con tarjeta en el momento de autorizarlo. Por debajo de 500 €, las transferencias y los Bizum se ejecutan y Fraude los evalúa después. Desde 500 €, la operación queda en revisión hasta que Fraude decide. Detrás de esa regla hay tres formas de comunicarse.

Tres casos, tres formas

La simulación es un diagrama de secuencia. Cada participante tiene un carril vertical y el tiempo corre hacia abajo; cada flecha es un mensaje. Las barras ámbar marcan quién se ha quedado esperando. Lanza los tres casos y compáralos. Después marca «Fraude caído» y repítelos.

Qué ha pasado

• El pago con tarjeta es síncrono. La red pregunta y espera, y Tarjetas espera a Fraude. No hay otra opción: el comercio tiene que saber ya si cobra. El precio es que si Fraude no responde, el pago se deniega. Lo síncrono hereda la disponibilidad de todo lo que llama.
• El Bizum de 600 € es un comando. Operaciones le pide algo a un destinatario concreto, en imperativo, y la respuesta puede ser un no. Pero nadie se queda bloqueado: la operación pasa a «en revisión» y espera ella. Si Fraude se cae, el comando se queda en cola y el Bizum no sale sin evaluar.
• El Bizum de 50 € es un evento. Cuentas cuenta que ha pasado algo, «MovimientoRegistrado», a quien quiera oírlo. Fraude, Comunicación y Cumplimiento reaccionan cada uno a lo suyo. Si Fraude se cae, el broker le guarda el evento y se lo entrega cuando vuelve.

Y el programa de puntos enseña la otra ventaja de los eventos: se ha añadido un consumidor nuevo sin tocar a quien publica. Operaciones y Cuentas no saben que existe.

La regla de los 500 €, por dentro

Ahora se lee de otra manera. Por debajo de 500 €, el banco acepta que Fraude se entere unos segundos (o unos minutos, si se cae) después de que el dinero haya salido, a cambio de que Laura no espere y de no depender de Fraude para cada Bizum. Por encima, el riesgo es mayor y el banco prefiere que la operación espere.

No es una decisión técnica. Es una decisión de negocio sobre cuánto riesgo se acepta a cambio de no esperar, y la arquitectura la refleja.

Cuando se añade un titular

Con la cuenta conjunta pasa lo mismo. Cuando Laura añade a Marcos, Tarjetas tiene que emitirle una tarjeta, Fraude tiene que vigilarle y Comunicación tiene que avisar a los dos. Cuentas puede llamar a cada uno y esperar, o publicar «TitularAñadido» y seguir. Pruébalo con Tarjetas funcionando, lenta y caída. Después llega un consumidor más.

Los eventos no son gratis

Con el evento, Marcos es titular al momento aunque Tarjetas esté caída. Pero durante un rato el banco no está de acuerdo consigo mismo: Cuentas dice que Marcos es titular y Tarjetas todavía no le ha emitido la tarjeta. Alguien tiene que vigilar la cola y saber qué hacer si un aviso no se procesa nunca.

Por eso la respuesta no es «eventos para todo». Se espera cuando la respuesta cambia lo que se hace a continuación (autorizar un pago); se avisa cuando no (avisar al cliente de un movimiento). En el próximo episodio, un flujo entero que cruza cuatro contextos: el alta de un cliente.

Para llevarse

• Síncrono: quien pregunta espera. Necesario cuando la respuesta cambia lo siguiente, pero hereda la disponibilidad del otro.
• Un comando pide algo a un destinatario y puede rechazarse; un evento cuenta algo que ya ha pasado a quien quiera oírlo.
• Con eventos se añaden consumidores sin tocar a quien publica, a cambio de que durante un rato no todos sepan lo mismo.