Nikki Asteinza
Contact

From config file to live registry

After making auth product-aware, the configuration problem became visible at a different level.

Each service had its own static config for what "a product" meant: a JSON entry in auth, a tenant block in the notification service, a code in the licensing config. Adding a product meant editing three files, coordinating a redeploy, and hoping nothing drifted.

For two products this is manageable. Around the third you start making mistakes.

Note

The problem with N config files for the same concept is not the duplication. It is that there is no single place to ask "is this product configured correctly right now?"

What a live registry gives you that a file does not

A static file answers "what was configured when this was last deployed."

A live registry answers "what is configured now."

The difference becomes real the moment you want to:

  • disable a product without touching config files;
  • check whether the email domain for a product is verified before going live;
  • see which users have access to which product;
  • add a product logo without a code change.

None of these require a sophisticated system. They require that the product definition lives somewhere queryable rather than in files scattered across services.

The shape it took

The catalog went into the control plane as a small API — products owned by accounts, with integration references for auth, email and licensing. Each service still owns its internal logic. The catalog holds the references that connect them.

flowchart LR Catalog["Product catalog\n(live registry)"] Catalog -->|"auth integration ref"| Auth["Auth service"] Catalog -->|"email tenant ref"| Email["Notifications service"] Catalog -->|"license code ref"| License["Licensing service"]

The key constraint: the catalog holds references, not copies. Auth still owns how tokens work. Email still owns how templates render. The catalog only says which products are allowed to use which configuration.

What it replaced

Before the catalog, adding a product was three manual edits across three services.

After, it became a single flow in the admin console: create product, set the integration references, verify DNS for email, mark as active. Each step is visible, auditable and reversible.

That last word matters. With config files, "undo" means editing the file again and redeploying. With a live registry, it means changing a status field.

Part of my platform notes. Follow the blog or contact me.