Atención al cliente lo ve todo

El punto de partida

Hasta ahora, quien lee quería lo mismo que se escribe, solo que en otra máquina. Atención al cliente quiere otra cosa: una ficha con la situación de un cliente. Y esa situación está repartida: los datos de Alta, las cuentas y movimientos de Cuentas, las operaciones en revisión de Operaciones y Fraude, y las tarjetas de Tarjetas.

Cada contexto es dueño de su base de datos. Atención no puede leerla directamente ni escribir en ella. Hace falta que los cambios lleguen a la ficha. Hay dos formas obvias de hacerlo, y una tercera que casi nadie considera al principio.

Que cada uno cuente lo que hace

La primera es que cada contexto, cuando cambia algo, lo cuente también a la ficha: dos escrituras, una en su base de datos y otra en la ficha. Ya se vio en el episodio 3 de El dinero no se duplica por qué esto falla: no hay ninguna transacción que cubra los dos sitios.

La tercera es leer lo que la propia base de datos ya apunta. Antes de modificar nada, apunta cada cambio en un diario, para poder recuperarse si se cae. Ese diario tiene todos los cambios, en orden y venga de quien venga. Un conector puede leerlo y publicar cada cambio para quien lo quiera: eso es el CDC.

Tres escritores, una ficha

Cuentas la cambian tres escritores: la app (Bizum), el lote de recibos de las seis de la mañana y una corrección manual de Soporte. Solo la app sabe que existe la ficha. Haz los seis cambios con las dos formas, con y sin caída de la app tras el primer Bizum.

Qué ha pasado

• Con la doble escritura, la ficha se pierde el Bizum que se guardó justo antes de la caída, y siempre los recibos y la corrección, que no pasan por el código de la app. La agente de Atención ve un cliente que no coincide con la realidad, y no hay ningún error que lo avise.
• Con el outbox se arregla la caída, pero hay que acordarse de ponerlo en cada escritor, incluido el lote y la corrección manual de Soporte. Basta que uno lo olvide.
• Con CDC, la ficha recibe los seis. El conector lee el registro de Cuentas y no le importa quién cambió el dato. Cuentas no ha tenido que tocar nada.

El conector por dentro

Un conector no es magia: es un proceso que se puede caer. Lo que lo hace fiable es que apunta hasta qué posición del registro ha leído. En la simulación guarda su posición cada cuatro cambios. Marca la caída, lee el registro y mira qué hace al reiniciarse. Después, añade un buscador nuevo que también quiere los cambios.

Al menos una vez

• Al caerse, el conector no pierde nada, pero repite. Retoma desde la última posición que guardó (el 4), no desde donde iba (el 6), así que el 5 y el 6 llegan dos veces.
• El consumidor tiene que aguantarlo. La ficha ignora un cambio cuya posición ya tiene: es la idempotencia otra vez. Sin ella, un repetido sumaría dos veces.
• Un lector nuevo no cuesta nada al escritor. El buscador recibe los diez cambios desde el principio del flujo, y Cuentas no nota ni una lectura más. Con la doble escritura habría hecho falta cambiar a cada escritor.

El CDC no tiene la garantía de entregar cada cambio exactamente una vez, y casi ningún sistema distribuido la tiene. Tiene la de entregarlo al menos una vez y en orden, que es suficiente si el que lo recibe sabe ignorar lo que ya vio.

Para llevarse

• Para que otro lector tenga una vista de los datos de un contexto, no hay que pedir a los escritores que escriban dos veces: la doble escritura se rompe.
• CDC lee el registro de cambios de la base de datos, que ya lo contiene todo, y publica cada cambio para quien lo necesite.
• Entrega los cambios al menos una vez: el consumidor ignora lo repetido gracias a la posición de cada cambio.

Los cambios ya llegan a Atención. Falta decidir cómo guardarlos para que la ficha se pueda leer rápido, de un golpe, sin preguntar a cinco contextos.