Desacoplar antes de que las dependencias frenen.

Aclarar la responsabilidad y la propiedad de los datos antes de la división técnica

Un servicio necesita un cometido de negocio comprensible. Analizamos los procesos, la propiedad de los datos y las dependencias de cambio antes de extraer componentes. Si varios servicios comparten las mismas tablas y siempre deben publicarse juntos, a menudo solo se genera una dependencia distribuida sin la ventaja deseada.

Distinguimos entre las consultas síncronas y los pasos de proceso asíncronos. Para los procesos de negocio que abarcan varios servicios, se modelan de forma explícita los estados intermedios y la compensación. Una reserva cancelada, por ejemplo, es una acción de negocio y no un simple rollback técnico sobre todas las bases de datos.

Hacer visibles y gestionables los errores distribuidos

Con varios servicios surgen rutas de red adicionales y posibles fallos parciales. Planificamos los tiempos de espera, los límites y los reintentos de forma que un servicio lento no bloquee toda la aplicación. El reintento automático exige que una acción no se ejecute varias veces de forma involuntaria.

La implantación se realiza en un ámbito delimitado con un beneficio medible. Unos estándares comunes para registros, trazas, despliegue y guardias evitan que cada servicio invente sus propias reglas de operación. Si el beneficio esperado no justifica el esfuerzo, una aplicación modular claramente estructurada puede seguir siendo la solución más adecuada.