Middleware de mensajería en C++, de la replicación a AWS

En abril de 2025 diseñé y construí solo, de extremo a extremo, un middleware orientado a mensajes. Es un cluster líder-seguidor escrito en C++17, con replicación, manejo de fallos y recuperación, y lo probé en AWS con pruebas de carga distribuidas.

Un middleware de este tipo se pone en medio de otros programas y mueve los mensajes de quien los manda a quien los tiene que recibir. El mío maneja dos patrones. En las colas punto a punto cada mensaje le llega a un solo consumidor, mientras que en los tópicos publish-subscribe cada suscriptor recibe su propia copia. Con eso el mismo cluster trabaja con dos ideas distintas de para quién es un mensaje.

Si todo eso viviera en una sola máquina, perder la máquina sería perder los mensajes. Por eso el cluster usa un diseño líder-seguidor, pensado para la alta disponibilidad, la tolerancia a fallos y la persistencia de los datos. El líder es el nodo que manda y los seguidores guardan copias, de modo que perder un nodo no debería significar perder los datos.

Todo ese comportamiento lo implementé yo: el líder y los seguidores, la replicación entre ellos, lo que pasa cuando un nodo falla y cómo se recupera el cluster después.

Para optimizar la comunicación entre nodos usé gRPC con Protocol Buffers. Protocol Buffers convierte cada mensaje en un formato binario compacto con un esquema fijo, y gRPC se encarga de llevar esos mensajes de un nodo a otro. Hacia afuera hay una API REST hecha con Crow, un framework web para C++, así que a un cliente le basta con HTTP para hablar con el cluster. El ciclo de vida del proyecto lo manejé con CMake, y en el repositorio público están los servicios en C++17, los archivos de build de CMake y el código generado de protobuf y gRPC.

Lo probé en AWS con pruebas de carga distribuidas. Después revisé los logs del sistema para ver qué habían hecho realmente los nodos bajo esa carga.

Cuatro meses después, en agosto de 2025, entré a APOLO. Ahí pasé de escribir software distribuido a trabajar con los clusters donde corren los workloads distribuidos.