Template Propagation

A service template is a snapshot. Services generated from it diverge immediately, and after a year the estate contains many variants of an old template plus whatever each team changed.

The improvement the platform team just made reaches nothing, and the security fix in next month's template reaches nothing either — which is when the problem is usually discovered.

Why it matters

The template model's whole value proposition is that the platform's decisions propagate. Without propagation it delivers a good starting point once and then decays into fifty independently maintained services, which is what it was supposed to prevent.

Implementation patterns

• Automated update proposals: the platform generates a change against each service and opens it for the owning team to review and merge. The mechanism that scales, because it costs the team one review rather than one project and it fits their normal workflow.
• Move what can live outside the service into a shared library or base image, so improvements propagate on the next build without any code change.
• Convergence checks in the pipeline that detect divergence and report a fix rather than enforcing one.
• Minimise what the template writes into the repository. Every generated line must be updated fifty times; configuration referencing a shared versioned component is updated once. The instinct to generate everything so each service is self-contained is exactly the instinct that creates the maintenance problem.
• Track the version distribution across the estate, since a long tail of very old versions is the earliest signal that propagation is failing.

What does not work: asking teams to adopt improvements manually, which loses to their own delivery commitments every time.

Industry example

Developer-tools organisations such as Postman and platform teams at multi-product companies reach this point within a year of introducing templates. The consistent finding is that the shared-library route propagates and the template route does not — so the design question becomes how little can be left in the template rather than how complete it can be.

Failure scenarios

• No propagation mechanism, so the template is a one-time gift.
• Everything generated into the repository, maximising what must be updated.
• Manual adoption requests, which are ignored reasonably.
• Enforced convergence, which overwrites legitimate local changes and destroys trust.
• Version distribution unmeasured, so the drift is invisible until a vulnerability requires an estate-wide fix.

Trade-offs

A shared library couples every service to its release cadence, and a breaking change in it affects everything — which is precisely the coupling the template was avoiding.

The resolution is versioning with a supported window: services adopt on their own schedule within a stated period, with automated update proposals rather than a forced simultaneous upgrade. That preserves independence while keeping the estate within a bounded range of versions.

Interview question

"You have fifty services generated from a template and you need to change how they all handle authentication. Describe how that change actually reaches production in each of them."