¿Mi arquitectura de microservicios está sobreingenierizada?

Photographer

Estoy rediseñando un monolito legacy a microservicios. He dividido el sistema en 8 servicios (usuarios, pedidos, pagos, inventario, notificaciones, análisis, autenticación, gateway) y estoy usando RabbitMQ para comunicación asíncrona. Cada servicio tiene su propia base de datos. Pero ahora me pregunto si no estoy cayendo en overengineering. ¿Realmente necesito separar análisis y notificaciones? ¿O debería fusionarlos? El equipo es pequeño (3 devs). ¿Alguien ha pasado por esto? Agradezco críticas constructivas.

Retro

Con 3 devs mantener 8 servicios es una locura. Te sugiero empezar con 2 o 3 servicios grandes y luego dividir si es necesario. El costo de comunicación y despliegue es alto. ¿Has considerado usar un enfoque modular dentro del mismo monolito primero?

Politics

No estoy de acuerdo. Depende del contexto. Si el monolito ya es grande y el equipo tiene experiencia, 8 servicios no es excesivo si están bien acotados. Pero coincido en que notificaciones y análisis podrían ser módulos dentro de otro servicio. ¿Qué tecnologías usas para el gateway?

Photographer

Gracias por los comentarios. El gateway es en Go con Kong. La razón de separar notificaciones es porque planeamos usar WebSockets en tiempo real, y análisis porque tiene consultas pesadas que no queremos que afecten a otros servicios. ¿Creen que eso justifica la separación?

Transit

Si análisis tiene consultas pesadas, sí tiene sentido separarlo para no bloquear. Pero notificaciones con WebSockets podría ser un módulo asíncrono dentro del servicio de gateway o usuarios. Revisa si realmente necesitas RabbitMQ para todo; a veces un simple Redis pub/sub basta.

Manga

Estoy con el primero. Con 3 devs, la sobrecarga de mantener pipelines CI/CD, monitoreo y comunicación entre servicios te va a consumir tiempo. Mi recomendación: usa una arquitectura de módulos bien definidos dentro de un monolito, pero con boundaries claros. Luego, si hay cuellos de botella, extraes a microservicio. Es más pragmático.

Photographer

Entiendo el punto. Tal vez reduzca a 5 servicios: fusiono notificaciones con gateway, y análisis con un servicio de reportes. RabbitMQ lo dejaré solo para eventos críticos (pedidos, pagos). El resto con llamadas REST síncronas. ¿Mejor así?

OpenSource

Eso suena más equilibrado. Solo cuidado con las llamadas síncronas entre servicios: pueden crear acoplamiento temporal. Si un servicio cae, el otro falla. Siempre prefiere asincronía para operaciones que no requieren respuesta inmediata.