Tres microservicios .NET corriendo sin Docker

Probar la comunicación entre microservicios en local es el momento donde todo el flujo cobra sentido. Aquí verás cómo orquestar tres servicios .NET que se hablan entre sí mediante mensajería, validar que los mensajes lleguen a un topic y confirmar que la información quede guardada en SQL, sin necesidad de Docker ni contenedores. Es una guía pensada para quien arma su primer flujo de microservicios y quiere ver el end to end funcionando.

¿Cómo levantar tres microservicios .NET al mismo tiempo?

El truco está en abrir tres terminales independientes y ejecutar cada proyecto con dotnet run en un orden específico para que los servicios escuchen antes de que lleguen los mensajes.

El flujo de arranque luce así:

1. Levantar el proyecto Add Member, que expone el endpoint principal por donde entra la solicitud HTTP.
2. Levantar el proyecto Pick Age, que se queda escuchando para procesar la edad y reenviar el mensaje a un topic.
3. Levantar el proyecto Add Adult, que recibe el mensaje final y guarda en base de datos.

Cuando arranca el tercer servicio, si había mensajes encolados sin procesar, llegan de golpe. En la demo aparecieron cinco mensajes atrasados que se procesaron al instante y quedaron registrados en la base [01:05].

¿Por qué llegan mensajes atrasados al iniciar un microservicio? Porque la cola de mensajería retiene lo que no se ha consumido. En cuanto el servicio suscriptor se conecta, recibe todo lo pendiente en orden.

¿Cómo validar que el flujo de mensajería funciona end to end?

La prueba real es enviar una solicitud HTTP y rastrear su recorrido por los tres servicios hasta SQL. En la demo se usó el cliente de solicitudes HTTP del editor para mandar un POST al servicio de adultos con estos datos:

• Nombre: Óscar.
• Apellido: Barajas.
• Año de nacimiento: 1968.

La respuesta fue exitosa, lo que confirma que el endpoint procesó la entrada [01:48]. A partir de ahí, el servicio Pick Age publicó el mensaje en un topic, el suscriptor lo recibió y el servicio Add Adult ejecutó la inserción.

¿Cómo confirmar que el dato llegó a la base de datos?

La verificación final se hace directamente en el portal de Azure, abriendo la tabla Adultos y consultando los primeros 1.000 registros. El registro de Óscar Barajas con año 1968 apareció correctamente, cerrando el ciclo completo desde la solicitud HTTP hasta la persistencia [02:15].

¿Qué es un topic en mensajería? Es un canal donde un servicio publica mensajes y uno o varios suscriptores los reciben. Permite desacoplar quién envía de quién procesa.

¿Por qué probar microservicios sin Docker antes de contenerizar?

En este punto del flujo no hay Docker, ni imágenes, ni contenedores involucrados. Son simplemente tres aplicaciones .NET corriendo con dotnet run en terminales separadas. Y aquí viene lo interesante: ya tienes la orquestación completa de la comunicación entre servicios funcionando.

Esta etapa importa porque te permite:

• Aislar problemas de lógica antes de sumar la complejidad de contenedores.
• Validar que los topics, suscripciones y endpoints están bien configurados.
• Confirmar que la persistencia en SQL responde como esperas.

Una vez que el flujo corre limpio en local, el siguiente paso natural es empaquetar cada servicio como un microservicio real, donde Docker y la orquestación entran en juego. ¿Ya tienes tu flujo local funcionando? Cuéntame en los comentarios qué servicio te dio más guerra al levantarlo.