Golden Paths & Paved Roads
Making the Right Thing the Easy Thing
Golden paths (Spotify's term) or paved roads (Netflix's term) sound simple on paper: provide a well-lit, well-maintained path through your infrastructure that developers naturally want to follow. The key word is "naturally." If you have to force people onto the path, the path is wrong.
What a Golden Path Includes
A production-ready golden path for a new microservice typically bundles several things together: a service scaffold with language-specific best practices, a pre-configured CI/CD pipeline (build, test, security scan, deploy), infrastructure-as-code for the service's dependencies (database, cache, queue), observability setup (structured logging, metrics, distributed tracing), and a Backstage catalog entry with ownership and documentation.
The developer runs one command, something like platform create service --type=api --lang=go, and gets all of this wired together, deployed to a staging environment, and registered in the service catalog within minutes. That is the bar you are aiming for.
Guardrails, Not Gates
The difference between a golden path and a locked-down platform comes down to guardrails. Guardrails use policy-as-code (OPA, Kyverno, Sentinel) to provide feedback loops: "This Terraform plan would create a publicly accessible S3 bucket, are you sure?" rather than silently blocking the deployment with a cryptic error.
Save hard gates for genuine security boundaries: production database access, PII handling, compliance requirements. Everything else should be a nudge with an escape hatch. Developers who feel trapped will build around your platform. Developers who feel guided will stay on the path.
Template Strategy
Maintain a small number of high-quality templates rather than trying to cover every possible use case:
- API Service - REST or gRPC service with database, deployed on Kubernetes
- Event Consumer - Queue/stream processor with dead letter handling
- Scheduled Job - Cron-based batch processing with observability
- Frontend App - SSR or SPA with CDN configuration
Each template should be versioned. When you release v2 of a template, provide automated migration tooling (codemods, upgrade scripts) so existing services are not stranded on legacy patterns. Nobody wants to maintain two generations of templates indefinitely.
Measuring Success
Track these metrics for golden path adoption: percentage of new services created via the golden path (target above 80%), time from code commit to production deploy for golden-path services vs off-path services, incident rate comparison between on-path and off-path services, and developer satisfaction scores from quarterly surveys.
If adoption is low, resist the urge to mandate. Instead, investigate why developers are going off-path. They are telling you something important about gaps in your platform. Listen to that signal.
Key Points
- •Golden paths make the right thing the easy thing. They are opinionated defaults, not enforced mandates.
- •Start with service templates (cookiecutters/scaffolds) that include CI/CD, observability, and security out of the box
- •Guardrails over gates: use policy-as-code to warn and nudge rather than hard-blocking developers
- •Measure adoption rate organically. If less than 80% of new services use the golden path, improve the path rather than forcing compliance.
- •Version your golden paths and support migration tooling so existing services can upgrade to new standards
Common Mistakes
- ✗Making golden paths mandatory without making them better than the alternative. Developers will route around bad abstractions.
- ✗Creating a single golden path when your organization has fundamentally different workload types (APIs vs event processors vs ML pipelines)
- ✗Neglecting Day 2 operations. A template that creates a service but does not help with debugging, scaling, or upgrading is only half the story.
- ✗Not involving application developers in designing the paths. Platform engineers often optimize for infrastructure elegance rather than developer ergonomics.