PATTERN Cited by 2 sources
Golden path with escapes¶
Golden path with escapes is the platform-team design where the default service-creation / service-config flow is heavily opinionated — consistent defaults, minimal choices — but explicit customization surfaces ("escape hatches") are provided for legitimate special cases.
Failure mode it prevents¶
Two opposite failure modes converge on the same pain:
- Raw YAML for everyone. Service owners hand-author Kubernetes YAML (or equivalent). Non-platform engineers spend hours understanding the full K8s object graph to do routine things; the platform loses consistency as every service drifts into its own shape; platform maintenance suffers because there's no shared structure to update.
- One-size-fits-all rigid platform. The platform enforces a single shape with no flexibility. Legitimate special cases (a service that needs a specific resource profile, a unique init container, a custom health-check) can't be expressed, so teams either escape the platform entirely or hack around it.
Golden path with escapes is the middle posture: make the common case trivial, make the special case explicit and controlled.
Shape¶
- Opinionated defaults. The standard service shape is chosen by the platform team (resource requests, health probes, base security policies, standard observability). Users don't see it unless they opt to override.
- A small authoring surface for the common case. A Bazel config
file, a Helm-values-like struct, a
service.yaml— whatever the platform's authoring language is. 10 fields, not 200. - Explicit escape points for uncommon cases. Users can override specific fields (resource sizing, extra env vars, extra containers). Each override is intentional and visible; the platform reviews them as signals for "what to add to the golden path next."
- Platform-team ownership of what's default vs. what's escape. Centralized review of which customizations keep recurring; promote them into new golden-path primitives.
Why this wins¶
- Onboarding velocity. New engineers ship a service in hours, not days. They don't have to understand the full platform to do routine things.
- Consistency for the common case. Every default-path service looks the same → easier for on-call, easier for security audits, easier for tooling.
- Evolution isn't blocked. The escape hatches let the platform team observe what special cases actually arise and decide which to promote into the default path.
- Maintenance has a single-point-of-update. Upgrade the default and every golden-path service inherits.
Contrast with full pluggability¶
patterns/pluggable-component-architecture fully abstracts interfaces so any component can be replaced. Golden path is the platform-defaults cousin: the path of least resistance is enforced, pluggability is the escape.
Seen in¶
- sources/2024-08-08-figma-migrated-onto-k8s-in-less-than-12-months — Figma's explicit framing: "Having users define services directly in YAML can be confusing. Instead, we worked to define a golden path for users and allow customization for special cases. By being explicit about what users can and should customize—and otherwise enforcing consistency by default—you'll save users time and energy while also simplifying maintenance and future changes." Realized via single-source service definition (patterns/single-source-service-definition) with service-specific override surfaces. Layer: Kubernetes service definition.
- sources/2026-02-26-aws-santander-catalyst-platform-engineering — infrastructure-layer instance: Santander Catalyst's stacks catalog — "a library of composite resource definitions and Compositions enabling quick and standardized creation of complex environments" — is the golden-path-with- escapes pattern applied to cloud infrastructure instead of K8s service definitions (patterns/crossplane-composition). Each Composite Resource Definition is an opinionated "common case" the platform team pre-bakes; the schema fields are the controlled escape hatches app teams fill in. Layer: multi-cloud infrastructure provisioning. Same posture as Figma, different layer — confirms the pattern is substrate- independent.
Related¶
- patterns/single-source-service-definition — the authoring- surface realization of golden path at K8s-service level
- patterns/crossplane-composition — the authoring-surface realization at cloud-infrastructure level
- patterns/developer-portal-as-interface — the interface layer the golden path is typically exposed through
- patterns/platform-engineering-investment — the organizational pattern that owns the catalog
- patterns/pluggable-component-architecture — alternative posture (full pluggability) when the platform doesn't need opinionated defaults