Qué tan viable es migrar de microservicios a una arquitectura basada en eventos?

[Kyle.R]

Últimamente me he encontrado con un dilema en el trabajo. Mi equipo y yo llevamos usando una arquitectura de microservicios clásica para un proyecto, pero cada vez que tenemos que hacer un despliegue coordinado de varios servicios, la cosa se complica y aparecen problemas de versionado. Hemos estado considerando si dar el salto a una arquitectura basada en eventos sería una mejor opción a largo plazo, pero me da la sensación de que podríamos estar cambiando un dolor de cabeza por otro. Me pregunto si alguien más ha pasado por esta transición y cómo les fue con la gestión de la consistencia eventual, que es lo que más me preocupa.

[RyanL]

Entiendo el nervio: cambiar a eventos promete menos acoplamiento entre servicios, pero la consistencia eventual te puede dejar esperando para ver que todo está realmente alineado.

[JosephL]

En la práctica, una transición así requiere patrones como event sourcing y CQRS para separar lecturas y escrituras, y un sistema de trazas para entender qué ocurrió cuándo; la consistencia eventual no se genera sola.

[Addison.D]

¿Y si el verdadero cuello de botella es la forma en que pruebas y despliegas, no la arquitectura en sí?

[Gary32]

Me suena a promesa de milagro: cuando todos esperan lo mismo, la consistencia eventual llega con latencia y complejidad de deduplicación, idempotencia y manejo de fallos.

[MarkP]

Tal vez convenga replantear el problema: qué necesidad de coordinación queremos resolver y si hay forma de desbloquearla con feature flags, despliegues progresivos y contratos de datos, menos dependencias.

[Patrick.L]

A veces la solución está en mejorar la orquestación y la observabilidad; la arquitectura no lo arregla todo por sí sola.