Practice & Reference · Platform Case Studies

Platform Case Studies

Every other page in this course teaches one idea. This page is the detective’s evidence board — an index to eight full case files, each now its own deep-dive page. Some are real, named companies telling their own public story: Spotify, Mercedes-Benz, adidas and Zalando, CERN, Monzo, Netflix. Two are composites — deliberately not any single real employer — built to make an unmistakable pattern out of guardrails-as-enabler and the three failures Foxy sees everywhere. Skim the teasers below, then follow whichever case matches the domain you’re currently studying.

☺ Explain it like I’m 10

Imagine a detective’s corkboard with photos pinned up and string connecting them. This page is the corkboard — a quick look at every photo. Pull a string and you land on the full case file, with all the evidence, for that one story.

🦊Your host for this topic: Foxy — the detective who investigates why real platforms succeed or fail. She reads the evidence, names the lesson, and points you at the course page that turns each story into a skill.

How to read these case files

☺ Like you’re 10: Each story is a little mystery — what did they do, what happened, and which idea explains it?

A good detective doesn’t just collect stories; she collects patterns. Every case file on this site asks the same handful of questions: What was the starting situation? What architecture and team-design choices did they make, and why? What changed — in metrics where they’re public, in plain qualitative terms where they aren’t? What should you actually steal for your own platform? And, just as important, what doesn’t transfer, and where does the public record simply run out? A case study you can’t tie back to a principle — or that quietly papers over its own gaps — is gossip, not evidence. (Any unfamiliar term is defined in the glossary.)

Two kinds of evidence sit on this board. The named-company files — Spotify, Mercedes-Benz, adidas, Zalando, CERN, Monzo, Netflix — stick to what those organisations (or their engineers) have actually said in public: engineering blogs, KubeCon and industry talks, published case studies. No invented metrics, no fabricated quotes. The other two files are composites, labelled as such on their own pages: not any single real company, but the same shapes Foxy has watched play out again and again, stitched into short stories so the pattern is unmistakable.

The eight case files

☺ Like you’re 10: Eight photos on the corkboard. Click any one to open its full file.

Each card below is now a full page in its own right — starting situation, architecture and team decisions, outcomes, what to steal, and honest caveats, with its own cross-links back into the CNPE domains.

What’s real, what’s composite — and why it matters

☺ Like you’re 10: Some photos on the board are real people. Two are sketches drawn from lots of real people at once — and the board says so.

Six of the eight files above are single, named, real organisations, each sourced from what that organisation has actually published — engineering blogs, conference talks, official case studies — with gaps in the public record called out rather than filled in with plausible-sounding invention. The remaining two, the regulated enterprise and the three cautionary tales, are explicitly composite: no single bank or insurer is "the regulated enterprise," and no employer is hiding behind "the platform nobody used." They exist because some of the most important lessons in platform engineering — what guardrails-as-enabler feels like from inside a compliance-heavy org, or what a platform failure looks like in slow motion — are patterns Foxy has seen repeat across many real, unnamed platforms, and a composite lets the pattern speak clearly without pointing a finger at one company.

The common threads

☺ Like you’re 10: Look across all eight cases and the same handful of habits keep deciding who thrives and who stalls.

Line all eight up and the evidence board almost reads itself. The platforms that thrived treated the platform as a product and paved self-service golden paths (Spotify), leaned on GitOps so a huge surface stayed reconciled and auditable (Mercedes-Benz), let developers self-serve safely at genuinely large scale (adidas, Zalando, Netflix), kept a demanding, specialist workload legible under extreme scale (CERN), built regulatory rigor into the platform itself rather than bolting it on afterward (Monzo, the regulated enterprise), and used guardrails to enable speed rather than block it. The composite failures invert every one of those: built on assumptions, shipped blind, handed out keys to everyone. Same habits, opposite signs. Everything else in this course — the reference architecture, the tools, the best practices — is really just how you build those habits in.

CaseThe one-line patternThe lesson → domain
Spotify & BackstageGolden paths, paved but not mandatory, made self-serve by a developer portalplatform as a product · self-service
Mercedes-BenzA large cluster fleet kept declarative and reconciled with GitOpsGitOps
adidas & ZalandoSelf-service Kubernetes shared by many teams, releases as routine eventsGitOps · reference architecture
CERNBatch-heavy scientific computing pushed onto cloud-native infrastructure at extreme scaleplatform architecture
MonzoHundreds of microservices and heavy regulation, made tractable by platform tooling from the startsecurity & policy · observability
NetflixPaved roads and internal tooling let thousands of engineers deploy independently, continuouslyprogressive delivery · platform as a product
The regulated enterprise (composite)Policy-as-code admission control and supply-chain verification turn compliance into automatic "yes"security & policy
Three cautionary tales (composite)No discovery, no observability, no least privilege — three ways platforms quietly failplatform as a product · observability · security & policy · anti-patterns
🦊 Foxy’s stakeout · 15 min

Before you open any of the eight files, put your own platform on the board first. For each thread above, mark thrived or stalled in one sentence: product mindset or assumptions? Self-service or tickets? GitOps or manual snowflakes? Golden signals or flying blind? Least privilege or cluster-admin for all? The pattern of your own answers is your roadmap — then go read the case file that matches your weakest mark.

🐢 Timmy’s checkpoint

1. Which case files are composites, and why does that matter for how you should read them? 2. Name three of the six real, named organisations covered across this set. 3. What single idea connects Spotify, adidas/Zalando, and Netflix, despite very different industries? 4. Why does "the regulated enterprise" argue that guardrails enable self-service rather than block it?

Check your answers
  1. The regulated enterprise and the three cautionary tales — both are explicitly labelled composites, assembled from patterns across many real, unnamed platforms rather than one identifiable employer, so read them as pattern evidence, not gossip about a specific company.
  2. Any three of: Spotify, Mercedes-Benz, adidas, Zalando, CERN, Monzo, Netflix.
  3. Self-service on a paved path: each let developers move fast without a central team hand-holding every change, whether that's a new service, a release, or a cluster.
  4. Because when policy is enforced automatically at admission — rather than by a human reviewing every change — the platform can safely default to "yes," which is exactly what escapes Ticket Swamp in a compliance-heavy environment.