Un switch transaccional que no sabe qué es ISO 8583

English Português

fluxrig 0.7 incorpora Conductor, que rutea cada solicitud sobre un árbol de destinos y devuelve cada respuesta a la terminal que la originó. Rutea mensajes estructurados sin saber qué protocolo hay debajo, así que el mismo diseño sirve mucho más allá de los pagos.

Ya está disponible fluxrig 0.7.0, con el código en GitHub y la documentación completa. El centro del release es Conductor, el gear que convierte un Rack de fluxrig en un switch transaccional.

Conductor rutea cada solicitud sobre un árbol de estrategias (failover, round_robin, least_loaded), correlaciona la respuesta con la terminal que la originó y expone los timeouts en un puerto de error dedicado, en lugar de descartarlos en silencio. Una solicitud puede salir por un Conductor y su respuesta volver por otro, lo que habilita topologías activo/activo entre regiones sin estado de sesión compartido.

Hay dos decisiones de diseño que un practicante pregunta enseguida, y las dos son configurables en lugar de estar fijas. El ruteo es una tabla ordenada de predicados sobre campos decodificados: gana la primera coincidencia y hay un catch-all explícito. La correlación se hace sobre una tupla de campos que se declara, así que en ISO 8583 se la apunta a iso8583.field.11 y queda correlacionando por STAN.

Por qué no es un problema de pagos

Eso último explica el título. Conductor no sabe qué es ISO 8583: rutea mensajes estructurados y el códec es el que habla el protocolo. Cambiando el códec y apuntando la tupla de correlación a otro campo, la misma máquina sirve para telemetría de campo, protocolos industriales o un dialecto interno para el que no existe herramienta.

Los pagos fueron el primer objetivo porque es donde los modos de falla son más implacables, no porque sean el techo de lo que resuelve.

Conviene entonces ser explícito con el límite, porque las palabras “switch de pagos” prometen muchísimo. No hay settlement, no hay clearing, no hay conciliación ni certificación de esquema, y no hay intención de competir con los switches establecidos que sí los resuelven.

Un ejemplo trabajado

La forma más clara de verlo es el tutorial de switch de pagos en dos regiones: terminales POS y dos esquemas de tarjeta independientes en cada región, tráfico que prefiere su región local y failover entre regiones cuando un enlace de esquema se degrada. Es la topología de la imagen que abre esta nota.

El release trae además TLS y mTLS nativos sobre el camino de entrada y salida de ISO 8583, y manifiestos autodescriptivos para cada gear, con los que la documentación de referencia se genera sola.

Validado, y reproducible

La sección de validación del tutorial trae la evidencia y no la afirmación. Suites de carga y de caos en Robot Framework verifican el invariante que importa, que una respuesta siempre vuelve a la terminal que la originó y nunca a otra, bajo concurrencia y bajo fallas de enlace inyectadas. El comando es público y las cifras salen de una corrida real, no de un objetivo.

El diagrama se genera, no se dibuja

fluxrig scenario viz produce un modelo de topología LikeC4 desde el mismo archivo de escenario que ejecuta el switch. No es una ilustración del sistema: es el sistema, leído de otra manera. Se cambia un cable en el escenario y el diagrama cambia con él, o el build falla.

La validación y el diagrama responden al mismo criterio, desarrollado en la evolución de architecture-as-code: la descripción de un sistema debería generarse desde el sistema, y una afirmación sobre su comportamiento debería venir acompañada de la forma de comprobarla. El diagrama cubre la primera mitad de esa frase; la validación, la segunda.

Por qué esto importa para la modernización

Reemplazar una plataforma que lleva décadas en producción rara vez está limitado por el sistema nuevo. Está limitado por el período en que el viejo y el nuevo tienen que convivir: tráfico real espejado, respuestas comparadas, el corte acotado, y evidencia para quien firma el riesgo. Ese trabajo es de ruteo y correlación, y es lo que este release resuelve.

El argumento más amplio está en obsolescencia tecnológica y en un caso real de modernización de legacy en América Latina junto a EBS.

Y hay una lectura complementaria, más larga y escrita desde la práctica, sobre dónde se ubica esto respecto de las herramientas ya establecidas en el mundo ISO 8583, y por qué el trabajo incómodo alrededor de un switch suele ser más difícil de resolver que el switch mismo: Routing ISO 8583 Without Pretending to Be a Payment Switch (en inglés).

Etiquetas
  • fluxrig
  • architecture
  • payments

← Volver al blog

Agendar una reunión