Lección 210: Refactorizando aplicaciones monolíticas hacia una arquitectura orientada a eventos

Las aplicaciones monolíticas son buenas y sencillas — como un vaso de leche. Pero la leche tiene fecha de caducidad, y tarde o temprano tu sistema monolítico puede enfrentarse a varios problemas:

1. Complejidad para escalar: si necesitas añadir capacidad solo para un módulo (por ejemplo, el procesamiento de pedidos), tendrás que escalar todo el monolito.
2. Tolerancia a fallos: un error en un módulo puede provocar la caída de toda la aplicación.
3. Dependencias entre equipos: los cambios en un módulo requieren coordinación con otros equipos y pueden afectar a todo el sistema.
4. Dificultad para adoptar nuevas tecnologías: todo el monolito está ligado a una única base tecnológica, lo que complica experimentar con nuevas herramientas.

La arquitectura orientada a eventos ayuda a solucionar estos problemas, permitiendo extraer microservicios independientes que interactúan mediante eventos. Pero pasar de un monolito a microservicios no es un hechizo mágico, es un proceso de ingeniería que requiere paciencia, planificación y un entendimiento profundo de la lógica de negocio concreta.

Principales etapas del paso del monolito a la arquitectura orientada a eventos

1. Análisis del monolito existente

Antes de sacar el hacha y partir el monolito, necesitas entender exactamente qué vas a cortar:

• Identifica los módulos y sus responsabilidades: aclara qué partes de tu aplicación se encargan de cada lógica de negocio.
• Analiza las dependencias: estudia qué módulos interactúan entre sí y qué datos se pasan entre ellos.
• Encuentra los puntos críticos: determina dónde suelen aparecer los cuellos de botella (bottlenecks), errores o problemas de rendimiento.

Por ejemplo, imagina una tienda online. En tu monolito pueden existir módulos para procesamiento de pedidos, gestión de usuarios, catálogo de productos y cálculo de descuentos. Encuentra los módulos más autónomos — esos son los primeros candidatos para extraerse como servicios independientes.

Consejo: usa herramientas visuales para el análisis, como diagramas de dependencias o incluso tablas simples en Excel. Tener una visión clara del estado actual facilitará el resto del proceso.

2. Definir los límites de responsabilidad de los servicios

El siguiente paso es separar los límites de los futuros microservicios. Para ello:

• Divide la lógica de negocio según el principio Single Responsibility Principle: cada servicio debe ocuparse solo de lo suyo.
• Aísla los datos: asegúrate de que cada servicio opere solo sobre su porción de datos.

Por ejemplo, el servicio de procesamiento de pedidos (Orders) puede encargarse de crear, actualizar y cancelar pedidos, pero no debería saber cómo se calculan los descuentos o qué productos hay en el almacén. Esas tareas pueden delegarse a otros servicios, como Discounts e Inventory.

3. Introducción de eventos

Ahora empieza la magia de los eventos. En lugar de que los módulos llamen métodos directamente entre sí, usamos un broker de mensajería (por ejemplo, Kafka) para publicar y suscribirse a eventos. Ejemplo:

1. El usuario realiza un pedido.
2. El servicio Orders publica el evento OrderCreated.
3. El servicio Inventory está suscrito a ese evento y comprueba si hay los artículos necesarios en stock.
4. El servicio Notifications está suscrito al mismo evento y envía un correo de confirmación del pedido.

Ejemplo de implementación de la clase de evento:

public class OrderCreatedEvent {
    private String orderId;
    private String userId;
    private List<String> itemIds;

    // Constructores, getters y setters
}

Publisher del evento:

@Component
public class OrderService {
    private final KafkaTemplate<String, OrderCreatedEvent> kafkaTemplate;

    public OrderService(KafkaTemplate<String, OrderCreatedEvent> kafkaTemplate) {
        this.kafkaTemplate = kafkaTemplate;
    }

    public void createOrder(Order order) {
        OrderCreatedEvent event = new OrderCreatedEvent(order.getId(), order.getUserId(), order.getItemIds());
        kafkaTemplate.send("orders-topic", event); // Publicación del evento en Kafka
    }
}

Manejador del evento:

@Component
public class InventoryService {

    @KafkaListener(topics = "orders-topic", groupId = "inventory-group")
    public void handleOrderCreated(OrderCreatedEvent event) {
        // Comprobación de disponibilidad de artículos en inventario
        System.out.println("Processing order: " + event.getOrderId());
    }
}

4. Paso a paso: aisla los servicios

No intentes extraer todos los servicios de golpe. Empieza por los módulos más autónomos, que tengan dependencias mínimas con el resto. Por ejemplo, en una tienda online los primeros candidatos suelen ser:

1. Notifications — servicio para el envío de mensajes.
2. Payments — servicio para el procesamiento de pagos.
3. Catalog — servicio para la gestión del catálogo de productos.

5. Manejo de datos y migración de clientes

Al pasarte a microservicios surge un problema: los clientes antiguos pueden seguir apuntando al monolito. La transición se puede facilitar usando un API Gateway que enrute las peticiones entre el monolito y los microservicios:

• Si las peticiones tocan la lógica antigua en el monolito, se procesan ahí.
• Si las peticiones corresponden a microservicios ya extraídos, el API Gateway las redirige directamente.

6. Añadir monitorización y testing

El paso a una arquitectura orientada a eventos exige monitorización y depuración cuidadosas. Sin buenas herramientas puedes no darte cuenta de dónde se pierden o retrasan los eventos.

• Usa Kafka Metrics para monitorizar el estado del broker de mensajes.
• Configura logging distribuido con ELK (Elasticsearch, Logstash, Kibana) o Splunk.
• Activa tracing de peticiones (por ejemplo, con Zipkin).

Problemas con los que te encontrarás (y cómo solucionarlos)

La migración a una arquitectura orientada a eventos rara vez es suave. Entre los problemas más comunes están:

1. Consistencia de datos: en una arquitectura asíncrona es difícil garantizar que todos los datos se procesen al mismo tiempo. Usa el patrón "Eventual Consistency" (consistencia eventual).
2. Gestión de errores: ¿qué pasa si uno de los eslabones de la cadena falla? Configura retries (reintentos) y fallback (acciones de respaldo).
3. Aumento de la complejidad: la interacción de muchos servicios vía eventos puede volverse más complicada de lo esperado. Revisa la arquitectura de manera periódica.

Ejemplo ilustrativo de refactorización

Toma una aplicación monolítica sencilla para una tienda online. Con la refactorización decidimos extraer dos servicios principales:

1. Orders (procesamiento de pedidos).
2. Notifications (notificaciones).

Configuración inicial (monolito):

public class OrderController {
    public void placeOrder(Order order) {
        // Lógica de pedido
        notifyUser(order);
    }

    private void notifyUser(Order order) {
        // Envío de notificación
    }
}

Después de la refactorización:

1. El servicio Orders publica el evento OrderPlaced, en lugar de llamar directamente al método de notificación.
2. El servicio Notifications escucha el evento OrderPlaced y envía el correo al usuario.

Pasar de un monolito a una arquitectura orientada a eventos es un proceso que requiere paciencia y disciplina, pero los resultados pueden ser muy potentes: mayor escalabilidad, mejor tolerancia a fallos y rapidez para desarrollar nuevas funcionalidades.