Configuration governance for microservices

A tool-agnostic guide to deciding what shared configuration to centralise, who owns it, how changes get reviewed, and what you give up. It applies whether you use OneEnv, a secrets manager, or a Git repository.

1. Decide what is actually shared

Not every value needs governance. Sort configuration into three buckets: values private to one service (leave them in that service), values shared by a few services (candidates), and values that define a contract between services — an API path, a column, a validation rule (strongest candidates, because breakage is silent). Start with the third bucket and the shared values that have already caused an incident.

2. Separate secrets from shared settings

Secrets need rotation, narrow runtime access and leak detection; shared settings need visibility and change control. These are different problems, and one tool rarely excels at both. A common split is a secrets manager for credentials and a governance layer for shared non-secret settings and contracts.

3. Pick an ownership model

• Central owner. A platform team owns each shared value; consumers request changes. Simple, but a bottleneck.
• Producer owner. The service that defines a thing (an API route) owns it; consumers subscribe. Scales better; needs consumers to be known.
• Consumer veto. Anyone may propose; every affected consumer must accept before the change is live for them. Slowest to roll out, safest for contracts.

4. Make dependencies explicit

The question "who depends on this?" must be answerable from data. That means consumers reference the shared definition (inheritance, a link, an import) rather than copying it. Anything copied by hand will drift, and you will not know where.

5. Review changes the way you review code

• Stage changes in a batch, so related edits are reviewed together.
• Detect concurrent edits and force a rebase rather than last-write-wins.
• Score risk: breadth of consumers, breaking vs additive, secrecy, and whether an owner exists to act.
• Keep a record of who approved what; it is the first thing you want during an incident.

6. Roll out without freezing everyone

Let consumers accept at their own pace, but make non-acceptance visible. A service that stays on an old value on purpose is fine; a service that stays on it because nobody saw the notification is an incident waiting to happen. Pair this with a deadline convention and a report of unresolved decisions.

Tradeoffs

• More process means slower changes to shared values. Reserve it for values with real fan-out.
• Per-consumer approval can stall if owners are unreachable; define who may act on their behalf.
• A governance layer is metadata about your systems. It is only as accurate as the dependencies recorded in it.
• Centralising configuration creates a high-value target; apply least-privilege and audit access.