Arquitectura y Funcionamiento de un Switch Bancario (API) en Entornos Retail de Alto Volumen

 

2. El Problema de la "Torre de Babel" (JSON vs. ISO 8583)

Aquí es donde tu migración cobra sentido.

2.1. El Lenguaje del Pasado (ISO 8583)

Los bancos y mainframes tradicionales "hablan" un protocolo binario posicional llamado ISO 8583.

• Visualmente: Es una trama de bits compacta (bitmap). No es legible por humanos. Es extremadamente eficiente pero difícil de programar.

• Estructura: Campo 1 (Tipo de Mensaje), Campo 2 (Número de Tarjeta), Campo 4 (Monto), etc.

2.2. El Lenguaje del Presente (API REST/JSON)

La plataforma moderna que estás construyendo en Walmart probablemente usa Java/Spring y habla JSON sobre HTTP.

• Visualmente: Es un árbol jerárquico de texto (key: value).

• Ventaja: Fácil de depurar, flexible y estándar en la nube.

2.3. La Función del Switch (API)

El Switch actúa como un Traductor en Tiempo Real.

1. Recibe (Entrada): Un objeto JSON moderno desde tu POS.

2. Transforma (Proceso): Mapea los campos JSON a posiciones de bits ISO 8583.

3. Envía (Salida): La trama binaria al banco (vía TCP/IP sockets).

MODELO DE CONCURRENCIA THREAD-PER-REQUEST

1. Concepto y Funcionamiento

En este modelo, cuando llega una petición al servidor, un componente llamado Acceptor la recibe y le asigna un hilo disponible de un Thread Pool. Este hilo se encarga de:

1. Parsear la petición.

2. Ejecutar la lógica de negocio (tu código).

3. Esperar por I/O (base de datos, lectura de archivos).

4. Generar y enviar la respuesta.

Visión Geométrica:

Imagina una autopista donde cada vehículo (petición) tiene su propio carril exclusivo (hilo) que se construye en el momento que entra y se destruye (o libera) al salir. Si la autopista tiene 200 carriles y llegan 201 vehículos, el último debe esperar a que uno de los carriles se vacíe. A diferencia del Event Loop (como Node.js), donde un solo carril maneja a todos los vehículos moviéndolos por fragmentos, aquí el aislamiento es total por carril.

2. Parámetros del Sistema (Ejemplo en Tomcat)

Para fines de tu investigación, considera estos parámetros típicos de configuración en un entorno de producción:

Parámetro	Valor Típico	Descripción
maxThreads	200	El número máximo de hilos simultáneos (capacidad de la autopista).
minSpareThreads	10	Hilos que se mantienen "vivos" esperando carga inicial.
Stack Size	1 MB	Espacio de memoria reservado por cada hilo (en la JVM).
Accept Count	100	Longitud de la fila de espera cuando todos los hilos están ocupados.

Referencia APA (Verificada y Activa)

Abdallah, A. (2024). Thread Vs. Event Loop in a Server: Understanding Concurrency Models. Medium. Recuperado el 18 de diciembre de 2025 de: https://medium.com/@amir21abdallah/thread-vs-event-loop-in-a-server-d96a49333629

Los atributos de calidad de una arquitectura de software

 El DDD, introducido por Eric Evans en 2003, es un enfoque de desarrollo de software para sistemas complejos donde el diseño se centra en el dominio del problema. En lugar de diseñar basándonos en la base de datos o en la tecnología (Data-Driven), diseñamos basándonos en las reglas de negocio y procesos reales.

Visión Geométrica y Espacial: El Mapa de Contextos

Imagina un mapa geopolítico. Un sistema grande no es un solo país homogéneo; es un continente dividido en naciones (Bounded Contexts).

• Cada nación tiene su propio idioma (Ubiquitous Language).

• Una palabra como "Cliente" puede significar algo distinto en la "Nación de Ventas" (alguien que compra) que en la "Nación de Soporte" (alguien con un ticket abierto).

• El Sharding (que vimos antes) es una partición de datos física; el DDD es una partición lógica y conceptual que permite que cada "nación" escale de forma independiente.