Comment by jordanbeiber

Say sql database:

Teams have agreed to use postgres for sql, this is by agreed convention.

A tooling team implement hashicorp vault and build a pg module/deployment that is packaged and accessible through whatever tooling you build.

This makes a datasource of type pg sql available to all teams in a couple of minutes.

These modules/deployments are governed by a bunch of conventions, but those are of no special concern to consuming dev teams.

Use “something” to keep track of service upstream/downstreams: consul, a database, or something else.

When a service is connected to a database, say using consul upstreams you have the job gen api inject the appropriate env vars according to an agreed upon convention.

Now dev teams have an option to deploy incredibly secure pg databases, and by simply setting a service as downstream it will automatically receive rotating connection strings.

There’s no configuration to be managed by dev teams except keeping a service graph up-to-date.

Lot of conventions above, and a tooling dev team with a lot of infra and tooling expertise.

I believe that for scaling dev teams you should look at tooling like a product domain and treat it as such.