Coordinación de Spring Batch Distribuido sin Broker de Mensajes

El problema fundamental que aborda este patrón es cómo lograr la coordinación distribuida y la tolerancia a fallos para cargas de trabajo de procesamiento por lotes (batch processing) sin introducir la complejidad operativa de un sistema de mensajería dedicado. Tradicionalmente, frameworks como Spring Batch han dependido de brokers de mensajes (Kafka, RabbitMQ) para distribuir y gestionar particiones de trabajo entre múltiples nodos. Sin embargo, para muchos equipos y escenarios de escala pequeña a mediana, la sobrecarga operativa de mantener un broker adicional es significativa, especialmente cuando ya se requiere una base de datos relacional para el repositorio de metadatos del propio Spring Batch.

Este patrón propone reutilizar la base de datos relacional existente como el único plano de coordinación. La tesis es que, mediante el uso inteligente de primitivas de base de datos como transacciones atómicas, bloqueos a nivel de fila y mecanismos de compare-and-set, es posible replicar las funcionalidades clave de un broker (distribución de trabajo, garantía de ejecución única, detección y recuperación de fallos) con una pila tecnológica más simple. Esto es particularmente relevante en un contexto donde la simplicidad operativa y la minimización de costos de infraestructura son factores críticos, y donde la escala no justifica la complejidad de un sistema de mensajería de alto rendimiento.

Arquitectura del Sistema

La arquitectura propuesta se basa en un conjunto de nodos JVM pares que interactúan exclusivamente con una base de datos relacional compartida. Esta base de datos actúa como el repositorio de metadatos de Spring Batch y como el plano de coordinación. Se introducen tres tablas adicionales: BATCH_NODES para registrar nodos activos, su estado y carga; BATCH_PARTITIONS para gestionar el ciclo de vida de cada partición de trabajo, incluyendo su asignación a un nodo y su estado (PENDING, CLAIMED, COMPLETED, FAILED); y BATCH_JOB_COORDINATION para vincular una ejecución de trabajo a su nodo maestro y estado general.

La coordinación es descentralizada. El nodo que lanza un trabajo se convierte en su 'maestro' para esa ejecución específica, evitando la necesidad de un servicio de coordinación centralizado como Apache ZooKeeper o un mecanismo de elección de líder global. Este maestro consulta los nodos vivos en BATCH_NODES para dimensionar el trabajo, escribe las particiones en BATCH_PARTITIONS y las monitorea. Cada nodo, incluyendo el maestro, ejecuta un bucle continuo que se registra en BATCH_NODES con un heartbeat, publica su carga actual y sondea BATCH_PARTITIONS para reclamar y ejecutar las particiones asignadas. La reclamación de particiones se realiza mediante una operación UPDATE con una cláusula WHERE que garantiza la unicidad de la ejecución (compare-and-set), evitando la doble ejecución. La recuperación de fallos se gestiona mediante un mecanismo de heartbeat de dos fases: un nodo que no envía heartbeats se marca primero como 'unreachable' y luego, tras un período de gracia, se 'elimina', reasignando sus particiones transferibles o marcando las no transferibles como FAILED.

UPDATE batch_partitions
SET status = ?, -- CLAIMED, then COMPLETED or FAILED
last_updated = CURRENT_TIMESTAMP
WHERE step_execution_id = ?
AND assigned_node = ?
AND status IN ('PENDING', 'CLAIMED');

Fundamentos Teóricos

Este patrón se conecta con principios fundamentales de sistemas distribuidos, particularmente en el área de la coordinación y la tolerancia a fallos. La dependencia de una base de datos relacional para la coordinación remite a los conceptos de 'shared-nothing architecture' y 'shared-disk architecture', donde la base de datos actúa como un recurso compartido para el estado. La garantía de ejecución única y la prevención de la doble ejecución mediante operaciones atómicas en la base de datos son aplicaciones prácticas de los principios de atomicidad, consistencia, aislamiento y durabilidad (ACID) inherentes a los sistemas de gestión de bases de datos relacionales. La estrategia de 'compare-and-set' para reclamar particiones es un patrón común en la implementación de estructuras de datos concurrentes y sistemas distribuidos para garantizar la exclusión mutua sin bloqueos explícitos.

Aunque no cita un paper específico, la gestión de la liveness de los nodos a través de heartbeats y un proceso de detección de fallos de dos fases es un patrón bien establecido en la literatura de sistemas distribuidos para la detección de fallos en entornos asíncronos, donde la ausencia de un heartbeat se interpreta como una posible falla. La distinción entre trabajo 'transferible' (at-least-once, idempotente) y 'no transferible' (at-most-once) es una aplicación directa de los modelos de garantía de entrega de mensajes, un concepto central en los sistemas de mensajería y procesamiento de transacciones, donde la idempotencia es clave para la resiliencia frente a reintentos y fallos.