Guardado, pero no avisado

El punto de partida

En Las áreas del banco, Cuentas aprendió a avisar en lugar de llamar: cuando registra un movimiento, publica el evento MovimientoRegistrado en el broker, y Fraude, Comunicación y Cumplimiento reaccionan cada uno a lo suyo. Cuentas no sabe quién escucha, y eso es bueno.

Y la saga del episodio anterior también depende de los avisos: cada paso se entera de que el anterior ha terminado por un evento. Si un evento no sale, la saga se queda parada sin que nadie lo sepa.

Dos escrituras

Para registrar un movimiento y avisar, Cuentas escribe en dos sitios: en su base de datos y en el broker. Son dos sistemas distintos, y no hay ninguna transacción que cubra los dos. Si el servidor se cae entre una escritura y la otra, queda una hecha y la otra no.

Elige una estrategia y un momento de caída, y registra el Bizum. Prueba primero las dos estrategias evidentes: guardar y luego publicar, y al revés.

Qué ha pasado

• Guardar y luego publicar pierde el evento si se cae en medio. El movimiento existe y nadie se entera. Es el fallo más peligroso porque es silencioso: no hay ningún error que mirar.
• Publicar y luego guardar anuncia un movimiento que no existe. Los consumidores ya han reaccionado: Laura tiene una notificación de un Bizum que no ha salido. Cambiar el orden no arregla nada; cambia qué se rompe.
• Outbox convierte las dos escrituras en una. El evento se guarda en una tabla de salida, dentro de la misma base de datos y en la misma transacción que el movimiento: se guardan los dos o ninguno. Después, un repetidor lee la tabla y publica lo que encuentre pendiente.

Al menos una vez

El outbox tiene su propio punto débil, y conviene haberlo visto: si el repetidor publica el evento y se cae antes de marcarlo como enviado, al volver lo encuentra pendiente y lo publica otra vez. El evento sale al menos una vez, no exactamente una.

No se puede evitar desde quien publica, porque es el mismo problema de la doble escritura en pequeño (publicar y marcar). Se resuelve en quien recibe: cada evento lleva un identificador, y los consumidores ignoran los que ya han procesado. Es la idempotencia del episodio 1, ahora en el lado del consumidor. Un sistema fiable se construye con avisos que pueden repetirse y receptores a los que no les importa.

El recibo que nadie avisó

Con las domiciliaciones, el aviso perdido sale del banco. Cuando Operaciones devuelve el recibo de la luz por falta de saldo, publica ReciboDevuelto, que tiene que llegar al banco del acreedor (por la conexión con los otros bancos) y a Comunicación, que avisa a Laura. Elige el caso «Recibo devuelto» en la simulación y repite las estrategias.

Si el evento se pierde, la compañía cree que la luz está cobrada y Laura no sabe que tiene un recibo pendiente. Lo descubrirán semanas después, con una reclamación. El dinero no se ha duplicado ni perdido: se ha perdido la información de que faltaba.

Para llevarse

• Guardar y avisar son dos escrituras en dos sitios. Entre las dos se puede caer cualquier cosa, y el orden solo cambia qué se rompe.
• El outbox guarda el aviso junto al dato, en la misma transacción, y un repetidor lo envía después.
• El aviso sale al menos una vez. Los consumidores tienen que ser idempotentes.

Hasta ahora, los problemas venían de una sola operación que se repite o se rompe. El siguiente episodio va de dos operaciones distintas que llegan exactamente a la vez.