Del fichero de config al registro vivo

Después de hacer que auth reconociera el producto, el problema de configuración se volvió visible a otro nivel.

Cada servicio tenía su propia configuración estática para lo que significaba "un producto": una entrada JSON en auth, un bloque de tenant en el servicio de notificaciones, un código en la configuración de licencias. Añadir un producto significaba editar tres ficheros, coordinar un redespliegue y confiar en que nada derivara.

Para dos productos es manejable. Alrededor del tercero empiezas a cometer errores.

Note

El problema con N ficheros de configuración para el mismo concepto no es la duplicación. Es que no hay un único sitio donde preguntar "¿está este producto configurado correctamente ahora mismo?"

Lo que da un registro vivo que un fichero no da

Un fichero estático responde "qué estaba configurado cuando se hizo el último despliegue".

Un registro vivo responde "qué está configurado ahora".

La diferencia se hace real en el momento en que quieres:

  • deshabilitar un producto sin tocar ficheros de config;
  • comprobar si el dominio de email de un producto está verificado antes de salir en producción;
  • ver qué usuarios tienen acceso a qué producto;
  • añadir el logo de un producto sin hacer un cambio de código.

Nada de esto requiere un sistema sofisticado. Requiere que la definición del producto viva en algún sitio consultable en vez de en ficheros repartidos entre servicios.

La forma que tomó

El catálogo entró en el plano de control como una pequeña API — productos con una cuenta como propietaria, con referencias de integración para auth, email y licencias. Cada servicio sigue teniendo su lógica interna. El catálogo guarda las referencias que los conectan.

flowchart LR Catalog["Catálogo de productos\n(registro vivo)"] Catalog -->|"referencia integración auth"| Auth["Servicio de auth"] Catalog -->|"referencia tenant email"| Email["Servicio de notificaciones"] Catalog -->|"referencia código licencia"| License["Servicio de licencias"]

La restricción clave: el catálogo guarda referencias, no copias. Auth sigue siendo dueño de cómo funcionan los tokens. Email sigue siendo dueño de cómo se renderizan las plantillas. El catálogo solo dice qué productos están autorizados a usar qué configuración.

Qué reemplazó

Antes del catálogo, añadir un producto era tres ediciones manuales en tres servicios.

Después, se convirtió en un único flujo en la consola de administración: crear producto, establecer las referencias de integración, verificar DNS para email, marcar como activo. Cada paso es visible, auditable y reversible.

Esa última palabra importa. Con ficheros de configuración, "deshacer" significa editar el fichero de nuevo y redesplegar. Con un registro vivo, significa cambiar un campo de estado.


Parte de mis notas de plataforma. Sigue el blog o escríbeme.