MicroservicePatterns.com

Suggestions

  • PagePattern catalogAll patterns by category.
  • LabCircuit Breaker and Retries labCrash a dependency and tune the breaker.
  • LabSaga labFail a step and watch the compensations run.
  • PagePractice questionsScenario questions with explanations.
  • PageDesign reviewCheck your own architecture for anti-patterns.
Teams and ownership · Core

Platform Team

The Platform Team pattern has a team build and run the shared foundations other teams build on, such as templates, libraries, pipelines and runtime, as an internal product that teams use through self-service, never by filing tickets.

Last updated

Use it when

  • Several product teams each spend a large part of their time on infrastructure and plumbing.
  • Cross-cutting concerns are solved differently by every team.

Avoid it when

  • There are only one or two product teams. A shared set of good defaults is enough for now.

Goes with

Service TemplateMicroservice ChassisApp ShellService Mesh
Try the labTest yourself

What is the Platform Team pattern?

A platform team's customers are other engineers. It provides the paved road for each layer: service and BFF templates, the microservice chassis, the app shell, CI/CD, clusters, the mesh and the gateway. It owns the cross-cutting contracts, such as log formats and the error model, and their implementation per stack. It never builds business features. In larger organisations the platform splits into several teams that mirror the layers, such as web, mobile and backend platforms.

What problem does the Platform Team pattern solve?

Asking every product team to master Kubernetes, CI, observability, OAuth and the details of each frontend stack overloads them, and each team solves the same problems differently. A platform reduces how much each team has to know. Treating it as a product, rather than a gatekeeper, keeps it focused on what teams actually need.

How do you implement the Platform Team pattern?

  1. Offer everything through self-service: templates, APIs, documentation and a developer portal, not tickets.
  2. Make the paved road the easiest path, not a mandate. If teams route around it, treat that as product feedback.
  3. Keep the platform thin: build what several teams already need, and extract shared pieces after you see duplication.
  4. Publish a tech radar with one or two blessed stacks per layer, so teams know what the platform supports.
  5. Split the platform by layer as it grows, and measure it by how fast product teams deliver.

When should you use it?

  • Several product teams each spend a large part of their time on infrastructure and plumbing.
  • Cross-cutting concerns are solved differently by every team.

When should you avoid it?

  • There are only one or two product teams. A shared set of good defaults is enough for now.

What do you gain?

  • Product teams focus on business features
  • Consistent cross-cutting behaviour
  • New teams and services start fast

What does it cost?

  • A team whose work is not visible to end users
  • Risk of building things nobody asked for
  • Can become a bottleneck if it slips into ticket queues

What are common mistakes with the Platform Team pattern?

  • Business features waiting on the platform team. If that happens, the boundary is wrong.
  • A platform built upfront for every imagined need, which nobody uses.
  • Mandating the platform instead of earning its adoption, so teams comply on paper and work around it.

Platform Team in practice

Real-world example

Spotify

Spotify's autonomous teams had produced a fragmented ecosystem of developer tooling, and engineers relied on what they called rumour-driven development to find out how things should be done.

Spotify's platform organisation created Golden Paths: the opinionated and supported way to build something, such as a backend service, a website or a data pipeline, each with a step-by-step tutorial. Paths now cover backend, client, data, machine learning and web work. They are recommended, not mandatory: engineers can leave the path, but then they do not get the same support.

Source: How we use Golden Paths to solve fragmentation in our software ecosystem (Spotify Engineering, 2020)

Example decision record
Context
Every product team maintains its own deployment, logging and infrastructure, and shared fixes take months to roll out.
Decision
Create a platform team that provides templates, a chassis, pipelines and runtime as a self-service internal product.
Consequences
  • Product teams focus on business features.
  • The platform must earn adoption and stay out of the way of business features.

Test yourself on Platform Team

Teams and ownershipcore

A stream-aligned team owns its React app, Swift and Kotlin apps, a GraphQL BFF, Java services, Kafka topics and its own Kubernetes setup. It is slow and burnt out. What is the most useful change?

5 questions involve this pattern. Practice all of them →

Done with Platform Team?

Saved in this browser only. See your progress →