Mensajería, escalabilidad, transacciones y tolerancia a fallos

Uno de los principios más importantes de la escalabilidad es el procesado asíncrono de datos. En una llamada síncrona, todo punto de integración constituye un nuevo riesgo, una nueva dependencia, un nuevo riesgo de quedarse bloqueado esperando por un recurso que nunca llegará o por un hueco en ese ansiado pool de conexiones que se nos ha quedado pequeño.

Por otra parte, uno de los principios más importantes de la integridad de datos es la transaccionabilidad. Si juntamos ambos conceptos, mensajería y transaccionabilidad, entramos en un nuevo mundo de retos y problemas, que unas veces serán sencillos de solucionar y que otras veces requerirán otra serie de artimañas más avanzadas para la gestión de errores.

Es sobre esto último de lo que trata un excelente artículo de Udi Dahan publicado en la MSDN. El autor recorre los problemas más comunes que nos encontramos en la integración de sistemas utilizando mensajería y como afrontarlos y resolverlos de manera robusta. Entre los temas tratados:

• Persistencia de mensajes: Es decir el configurar nuestro broker de mensajería para que almacene, normalmente en base de datos, los mensajes de modo que se puedan reenviar posterioremente en caso de algún problema.


• Consistencia transaccional: ¿Qué pasa si enviamos un mensaje y avisamos a un tercer sistema de ese cambio pero de pronto se hace un rollback del mensaje? El soporte de transacciones en los brokers y el uso del commit en dos fases resuelve este problema, pero a veces es overkilling.


• Uso de colas de errores: Enviamos un mensaje ... y falla; lo volvemos a enviar ... y falla; probamos otra vez... vuelve a fallar. ¿Qué hacemos? Podemos seguir y seguir (y en el 99.99% de los casos seguirá y seguirá fallando) lo que consumirá importantes recursos de nuestro sistema, podemos lavarnos las manos e imprimir la traza de error, o podemos enviarlo a una cola de errores, donde más tarde los revisaremos, lo cual parece una muy buena opción.


• Tamaño de los mensajes: Aquí el autor hace un excelente análisis sobre la diferencia entre procesar miles de mensajes pequeños y unos cuantos cientos de mensajes enormes.
  

  TimeToProcess(BigMessage) >> N x TimeToProcess(SmallMessage) where
  Size(BigMessage) == N x Size(SmallMessage)

  
  Los requisitos del procesado de mensajes grandes en cuanto a validación (CPU, memoria), almacenamiento en caso de mensajería duradera(CPU, disco), o congestión de red (optimización de paquetes) son mucho más exigentes y a menudo la única solución es el partir el mensaje original en mensajes mucho más pequeños y sencillos de procesar.

En resumen, en mi opinión excelente artículo para el que le gusten los temas de mensajería, procesado asíncrono de datos y transacciones, y lectura recomendada.