Por que las lecturas y las escrituras pueden divergir

Una regla que suena a contradicción con todo lo anterior: merchants puede leer directamente de varios servicios de backend, sin pasar por api-server.

Eso no es una violación de la topología en estrella, porque las lecturas y las escrituras no son el mismo tipo de operación ni cargan el mismo riesgo. Una escritura cambia estado del que otros servicios y otras peticiones dependen que sea correcto; si dos escrituras compiten, o una se aplica a medias, alguien acaba teniendo que reconciliar el desastre. Una lectura no cambia nada. Si merchants lee un número de analítica rancio durante un segundo porque preguntó al servicio de analítica directamente, no se rompió nada aguas abajo. El camino relevante para la auditoría —donde la corrección importa de verdad— es el de escritura. Mantén ese estrecho. El de lectura puede permitirse ser pragmático.

Puedes ver la división codificada directamente en qué clase de integración usa cada trozo de código. Los métodos que crean un sitio, un token o actualizan un dominio cambian algo real, así que pasan por el concentrador. Los que leen las visitas actuales o las agregaciones de un sitio no cambian nada, así que merchants llega directo al servicio de analítica. Ambas clases viven en la misma carpeta, siguen la misma forma y usan el mismo trait de reintentos. La única diferencia es de qué lado de la línea escritura/lectura caen sus métodos, y esa diferencia es visible con sólo mirar qué clase importa un controlador.

Mantener esa división explícita es todo el beneficio. Quien revisa un pull request no necesita contexto de arquitectura para saber si un método nuevo pertenece a una clase o a la otra: necesita una pregunta respondida, ¿esto cambia algo? Si sí, va por el concentrador, sin excepciones, sin «sólo esta vez porque es más rápido». Si no, puede ir directo al servicio que posee los datos, porque una lectura rancia es una molestia y una escritura divergente es un incidente.

Resumen

Entre servicios

• [X] Cada hoja habla con exactamente un proveedor externo y con el concentrador, nunca con otra hoja
• [X] Toda escritura entre servicios pasa por el único orquestador, sin excepciones por comodidad
• [X] Las credenciales de cada proveedor externo viven en exactamente un servicio, el que posee esa capacidad

En la salida de la flota

• [X] Un artefacto generado habla de vuelta con la flota por el mismo contrato estrecho y versionado que cualquier otro cliente
• [X] Las preocupaciones de gestión de la flota se quedan fuera del código horneado en un sitio generado
• [X] Una lectura rancia se tolera; una escritura divergente no, y el código hace visible esa distinción

Una sola API bien construida es un buen día de trabajo. Una docena, dispuestas de forma que ninguna tenga que pensar en las otras once, es lo que hace repetible ese buen día. Esa es toda la diferencia entre una flota y un montón de servicios que casualmente comparten una clave de despliegue.