The full picture
- GitOps beats config-server-as-database: config changes as PRs (review, diff, rollback, blame) flowing through the same promotion pipeline as code; Spring Cloud Config or ConfigMap re-render both work as transports — the workflow is the architecture.
- Refresh mechanics if you need them:
@RefreshScopebeans re-created on/actuator/refreshor bus events — but each refreshable bean is a mini restart with edge cases (in-flight requests, pool rebuilds). Prefer restart-on-change (rolling, fast) unless SLOs truly demand hot reload. - Flags discipline: flags are code-path config with an owner and an expiry — stale flags are dead code with runtime branching cost. Track age; make cleanup a sprint ritual. Targeting/gradual rollout (1% → 100%) is the real value over properties.
- Schema for config: shared starters export typed
@ConfigurationPropertiesso 'org standard settings' have one definition, validated in every service — the type system as fleet-wide config linting. - Observability: log the resolved config fingerprint at startup; alert on staging/prod divergence beyond the allowlist. 'What config is service X actually running?' must be answerable in one query.