Cuándo el procesamiento por lotes es mejor que una API REST

Por qué importa esta decisión arquitectónica

En el diseño de aplicaciones, la calidad del código no es el único obstáculo a la hora de construir programas óptimos y mantenibles. En mi experiencia, el mayor reto es definir la arquitectura de un sistema y entender cómo se integra en su contexto.

Este artículo reflexiona sobre cuándo las APIs REST no encajan bien con cargas pesadas programadas.

El verdadero problema de usar APIs por defecto

No toda arquitectura funciona bien para todos los casos de uso. Las APIs suelen ser apropiadas; el problema aparece cuando se usan por defecto, sin evaluar el tipo de carga de trabajo, las necesidades de aislamiento, los patrones de tráfico y el coste de infraestructura.

Cuándo el procesamiento por lotes encaja mejor

Para algunas cargas de trabajo, exponer funcionalidad a través de una API es menos adecuado que ejecutarla como un proceso aislado, programado o bajo demanda.

Los procesos batch son muy adecuados para ejecutar grandes trabajos programados en su propio entorno de ejecución aislado. Esto reduce el número de procesos paralelos que pueden verse afectados y ayuda a contener los fallos. También reduce el acoplamiento del sistema y elimina la necesidad de mantener una interfaz disponible de forma permanente.

El procesamiento batch es útil, pero sus ventajas pueden desaparecer cuando depende de servicios compartidos en tiempo de ejecución.

Cuándo empieza el problema: un batch que depende de APIs compartidas

Reutilizar una API compartida desde un servicio batch puede ser arriesgado.

En primer lugar, estás sobrecargando un servicio que se comparte con otras aplicaciones. Esa API compartida debe ser capaz de manejar tanto su carga normal de peticiones como la carga adicional procedente del batch, que, en el caso de trabajos grandes, puede llegar a ser masiva.

Esto tiene una consecuencia evidente: si no quieres que el sistema falle, tendrás que dimensionar la infraestructura para un pico que solo ocurre de forma puntual.

Como se trata de una API compartida, otras partes del sistema dependen de ella, por lo que cualquier fallo o degradación puede propagarse a los servicios dependientes y afectar a otras aplicaciones del sistema.

En los casos en que el aislamiento de recursos es deficiente, el impacto puede incluso alcanzar procesos no relacionados en el mismo host.

También debes tener en cuenta recursos compartidos como bases de datos, cachés, sistemas de archivos, brokers de mensajería o servicios de autenticación. Aunque la propia API no falle, cualquiera de los recursos compartidos de los que depende podría convertirse en un cuello de botella o fallar bajo la carga adicional.

Posibles soluciones

Una posible solución es el escalado vertical del servicio REST, dimensionando la infraestructura para un pico que solo ocurre de forma puntual.

El escalado horizontal también es una opción sólida, pero requiere más infraestructura de soporte para enrutamiento, descubrimiento, balanceo de carga, health checks y otras necesidades relacionadas. Este tipo de infraestructura todavía no está disponible en muchas empresas.

Otra opción es usar sistemas reactivos y/o sistemas orientados a eventos para gestionar la contrapresión. Los sistemas reactivos pueden mitigar parte de la presión operativa, pero también introducen complejidad arquitectónica y pueden requerir cambios a nivel de todo el sistema que no siempre son realistas en entornos legacy. Lo mismo ocurre con los sistemas orientados a eventos basados en herramientas como Kafka o RabbitMQ.

Conclusión

Para mí, la arquitectura debe ajustarse al entorno, las restricciones y los recursos.

Tu arquitectura actual no debería dictar ciegamente todas las soluciones futuras, pero las nuevas soluciones deben seguir evaluándose en función de las restricciones existentes, los costes y las realidades de integración.

Una buena arquitectura debe dejar espacio para la adaptabilidad y para patrones de integración alternativos, de modo que no todas las cargas de trabajo se vean forzadas a pasar por un modelo de API compartida.