When one platform runs everything

A regulated business with no legacy estate decides to make every part of its software identical, then spends a decade discovering what identical costs. This is a single-company dig: the subject is Monzo, and the question is which structural changes were forced, and by what.

The problem, stated without any product name in it: you are building a regulated service where a handful of operations must keep working at all times, you have no existing systems to protect, and you have to choose how much variety your software is allowed to contain. Variety is how a system limits damage, because unlike things fail at unlike times. Variety is also what makes a fleet of services unchangeable, because every migration has to be negotiated with every exception. Monzo chose almost no variety, published most of the consequences, and in 2025 bolted on the one piece of variety it could afford.

Three findings worth the reader's time before the detail. First, both of Monzo's published platform-wide outages came through the change path rather than the request path: a planned expansion of a coordination cluster in 2017, a planned migration of a database cluster in 2019. Neither was triggered by traffic. Second, the 2017 incident got worse because of the remediation: restarting several hundred service-mesh instances at once surfaced a version incompatibility that turned a partial failure into a total one, which is the shape the systems literature calls a sustaining effect. Third, and least expected, Monzo's own argument for a second platform on a second cloud provider is not that clouds fail. It is that its own software fails at least as often, and that a second copy of its software would fail the same way.

A bug in our code or processes is at least as likely to cause an outage as a cloud provider failure. Monzo, Tolerating full cloud outages with Monzo Stand-in, February 2025

That sentence is the hinge of the whole decade. If the risk you are hedging is your own code, then a hot replica of your platform in another region hedges almost nothing, and the only useful standby is one that shares no code with the thing it is standing in for. The size of Monzo's standby (18 services against roughly 2,800) follows from that, and so does its weakest property: it cannot make the decisions the primary platform makes, so it issues advice and lets the primary reconcile later.

One uniform platform on AWS, one deliberately unlike standby on Google Cloud, and a one-way join between them. Every box below is attributable; the two marked open are where the public record stops.

Start with what has not changed. Monzo's 2016 account of its backend describes a system that was already microservices, already in Go, already on Kubernetes, and already near 100 services at beta launch. The 2024 account of running fleet migrations describes 2,800 services in one monorepo, in Go, on Kubernetes. The shape is the same; only the count moved. That continuity is the single most important fact about this architecture, because every capability described below depends on it.

The in-house parts of 2015 are still visible in the repository record, and they have diverged in an instructive way. typhon, the wrapper around Go's net/http that Monzo's clients and servers are built on, was created in February 2015 and took substantive commits in August 2026, including a switch to the standard library's HTTP/2 client and idle-connection health checking. phosphor, the tracing system from the same month, has no such life; tracing moved to OpenTracing and then, under a deadline Monzo did not set, to OpenTelemetry. The surviving in-house component is the thin one that wraps a standard; the retired one is the one that substituted for a standard that later arrived.

Between the services sits the part that was replaced. Until 2019 inter-service traffic went through linkerd 1.x, and Monzo's own measurement put it at the top of the p99 budget under normal load. The replacement with Envoy was justified on performance (at 15,000 requests per second, lower 99th percentile latency and less than half the CPU) but its structural consequence was different: Envoy ran as a sidecar in each pod rather than as a shared proxy, which meant traffic finally had per-pod identity. That is what made the network isolation work of late 2019 possible at all, covering roughly 1,500 services and more than 9,300 service-to-service interactions whose dependency graph Monzo recovered by static analysis of its own monorepo rather than by observing traffic.

Egress went the same way, and the design is worth copying. Monzo's egress-operator rejects the obvious approach of inspecting outbound protocols. Instead each external dependency gets an internal cluster IP, DNS is rewritten to point at it, an Envoy gateway fronts it, and a network policy admits only pods carrying the label for that dependency. The README is blunt about the limit: the operator blocks nothing by itself, and the cluster needs default-deny egress for any of it to mean anything.

The data side is a mirror of the same instinct. Analytics is not fed by reading the operational store; services emit events into Kafka and NSQ, and the feed lands in append-only BigQuery projects where dbt compiles a model graph that Airflow executes. In 2021 that was over 4,700 models and about 600,000 lines of SQL; by May 2026, InfoQ reports 12,000 models across 100 teams, governed as a data mesh. The interesting artefact here is the one that died: Monzo wrote ddbt, a Go reimplementation of the dbt command line, because dbt "gets very slow on large projects (3000+ data models)". It was archived in May 2023 with the note that it is "left here for historic purposes". Why it was abandoned is not published.

The part an architect usually underestimates is how much of this platform is an interface for humans rather than for traffic. Monzo's tooling is pitched deliberately above Kubernetes, biased, in its own words, towards a simple and opinionated experience over configurability, so that engineers ship without touching the orchestrator; the published rate was over a hundred deploys a day in 2022 and hundreds of production changes a day by March 2026. The same uniformity shows up in the authorisation model, where staff access is granted per remote procedure call rather than per system, and sensitive calls can require multi-party approval. And it shows up in a constraint that would stop most organisations: by 2026 Monzo's platform group says around 250 services are already impractical to run on a laptop, which is why development happens in partial-stack environments it calls tenancies rather than locally. The latest turn in that story is the one worth watching. The house conventions that eleven years of enforced sameness produced are now encoded as skills for coding agents, so that generated services come out in the same shape as the handwritten ones. Uniformity, bought in 2016 to make migrations possible, turns out to be the thing that makes machine-written code reviewable.

Four forks with the reasoning Monzo published, and the condition under which the rejected option becomes the right one. Monzo publishes no decision records, so the rejected options below come from blog posts, repository READMEs and archive banners.

One pattern runs through that table. Monzo builds when the standard does not exist yet and retires its own work when the standard arrives, and the retirement is visible in the repository before it is visible anywhere else. etcd3-terraform archived in May 2024, ddbt archived in May 2023, phosphor left behind by OpenTelemetry; against that, typhon still being modernised in 2026 because nothing in the ecosystem replaced a thin wrapper around the standard library. If you are deciding what to build, that is the test worth stealing: build the wrapper, not the substitute.

The build-versus-hand-over question was asked out loud, and the answer has moved in both directions at once. A trade-press interview with the platform team describes it weighing whether to keep running Kubernetes, Kafka and Cassandra itself or pass them to AWS, which is the question the 2019 incident put on the table in public when an AWS principal engineer praised Monzo's write-up and then asked whether running Cassandra yourself really makes you a better bank. Since then the self-operated artefacts have been retired quietly while, in the opposite direction, Monzo started building against its provider's tooling where verifiability mattered: its enclave images are built from source with Nix because the vendor's builder produces timestamped, blob-dependent images that cannot be reproduced. Read together, those two movements are not inconsistent. The commodity parts went to the provider; the parts where Monzo has to be able to prove something to a regulator stayed in-house, and in the enclave case moved further in-house than the vendor's own path allows.

Five cards covering three Monzo incidents, grouped by class rather than by date: two published post-mortems (the 2017 outage appears twice because its remediation is a separate lesson), the ecosystem's unresolved version of the same fault, and the standby failing to fully stand in.

Both of Monzo's platform-wide outages belong to the same class: a planned change to shared infrastructure, made by the platform team, that altered what the fleet believed about cluster membership. Neither came from a traffic spike. In a platform where every service uses the same coordination layer and the same datastore, there is no such thing as a contained change to either, and the public record contains no example of a Monzo incident that stayed inside one service.

One pattern in this corpus is about disclosure rather than architecture, and it is a reconstruction rather than a reported fact. In 2017 the head of engineering published a minute-level analysis on the customer forum three days after the outage. In 2019 the same-day note said only that some data had not been processed properly for about two hours, and the mechanism arrived 40 days later as a blog post detailed enough to be useful to other engineers. For the August 2026 incident, no root cause has been published at all beyond a statement that the core issue was fixed, and what is publicly known about how the standby behaved comes from press reports and customer comments. The trajectory is towards less published mechanism as the bank grew, which is the normal direction of travel for a regulated company, and it means the most useful material in this dig is also the oldest. If you are relying on another organisation's published failures to validate your own design, collect them while the organisation is still small enough to write them down.

Service counts, incident durations, the standby's cost ratio and the load the platform now carries. Everything here is self-reported by Monzo unless the source column says otherwise.

One ratio is worth carrying into a budget conversation. A standby that covers the handful of operations customers cannot live without costs roughly one per cent of the platform it protects, by the operator's own figure, and it covers 18 services out of thousands. That is the number to put next to the usual proposal, which is an active-active replica of everything at something closer to one hundred per cent. The difference is not a discount on the same product; the replica protects against infrastructure loss and the minimum viable standby protects against your own software, and only one of those two is the risk Monzo says dominates.

One lesson, stated so it transfers to a system that is nothing like a bank.

Monzo made the same decision twice, eight years apart, and the second one is only intelligible as a correction to the first. In 2016 it decided that its software would contain almost no variety: one language, one datastore, one deploy path, one mesh, one coordination cluster, tooling that hides all of it. That decision is why one team can now migrate 2,800 services, why automated rollback could be switched on across 2,100 of them, why hundreds of changes a day are routine, and why the house conventions are now clean enough to hand to a coding agent. It is also why there is no public example of a Monzo failure that stayed inside one service, and why both published platform outages arrived through a planned change to something every service shared.

You cannot fix that by adding variety back. A second datastore, a second language, a second deploy path: each one subtracts from the changeability that the uniformity bought, and the failure domains stay correlated anyway because the code is still the same code. The hedge Monzo eventually built is the only one that does not eat its own premise. One deliberately different, deliberately small system, on a different provider, sharing no services, fed one-way, covering four operations, costing about one per cent, and incapable of making the decisions the real platform makes. It does not reduce the chance of an outage at all. It reduces what an outage means.

Two caveats that the evidence will not let this dig drop. The standby is not proven: three activations are reported, and in August 2026 some customers still could not transact while it was running, with no published root cause. And the whole model rests on a property most organisations do not have, namely that Monzo had no legacy estate and could impose uniformity from the first commit. If you are retrofitting, the cheap version of this lesson is to stop adding variety, name the handful of operations that cannot wait, and build the small separate thing for those, in that order.

Thirty-one of the fifty-seven ledger rows, graded and filterable. The full ledger, including the rows that only corroborate, is in sources.md beside this page.

Six rungs that reproduce the pattern at a scale you can hold in your head. The crossing from toy to real happens at rung four, where the standby starts running all the time.

The searches that produced this page, including the ones that produced nothing, which is how two of the open questions above were established.

Two queries returned nothing useful, repeatedly, and that is recorded here because it is the cheapest finding on the page: searches for a Monzo account of moving to a managed Kubernetes control plane, and searches for any Cassandra detail after 2021. If you need either, the next move is the conference programmes rather than the blog, and failing that, job postings for the platform group.

Checked 13 October 2026. This session's network policy permitted direct fetches to github.com only, so GitHub rows were read first-hand and the rest through search-engine retrieval; the verifier's link check could not run.

1. Monzo, Building a Modern Bank Backend Monzo blog, 19 September 2016.
2. Monzo, Very Robust etcd Monzo blog, 29 November 2017.
3. Monzo community, Major outage 27/10/2017 post-mortem thread Monzo community forum, October 2017.
4. InfoQ, Monzo Outage Post Mortem InfoQ, November 2017.
5. The Register, Kubernetes bug ate my banking app The Register, 31 October 2017.
6. Techerati, Lessons learned from Monzo's Kubernetes outage Techerati, 3 May 2018.
7. Kubernetes issue #47131, apiserver timeouts after rolling-update of etcd cluster GitHub, opened 7 June 2017, closed 12 February 2018.
8. Linkerd issue #1730, linkerd continues to talk to old endpoint GitHub, opened 6 December 2017, closed 18 May 2018.
9. Monzo, We deployed Envoy Proxy to make Monzo faster Monzo blog, 3 April 2019.
10. Monzo, We built network isolation for 1,500 services Monzo blog, November 2019.
11. InfoQ, How Monzo Isolated Their Microservices Using Kubernetes Network Policies InfoQ, December 2019.
12. monzo/egress-operator GitHub, created 11 December 2019, updated 15 June 2026.
13. Monzo, Why Monzo wasn't working on July 29th Monzo blog, 8 September 2019.
14. Monzo, We had issues with Monzo yesterday Monzo blog, 30 July 2019.
15. The Downtime Project, Monzo's 2019 Cassandra Outage Podcast episode, 2021.
16. Ben Kehoe, post on the 2019 incident X, 9 August 2019.
17. Monzo, How we deploy to production over 100 times a day Monzo blog, 16 May 2022.
18. Monzo, Argo Rollouts at scale Monzo blog, 2 November 2022.
19. Monzo, How we run migrations across 2,800 microservices Monzo blog, August 2024.
20. CNCF, CNCF archives the OpenTracing project CNCF blog, 31 January 2022.
21. Monzo, How we secure Monzo's banking platform Monzo blog, 31 March 2022.
22. Monzo, Humans who can RPC Monzo blog, 26 May 2022.
23. Monzo, Securing admin access to Monzo's platform Monzo blog, 14 December 2023.
24. Monzo, Securing our software supply-chain better with reproducible builds for enclaves Monzo blog, 2024 to 2025.
25. monzo/aws-nitro-util GitHub, created 13 February 2024, updated 28 July 2026.
26. monzo/etcd3-terraform GitHub, created 28 November 2017, archived 16 May 2024.
27. monzo/ddbt GitHub, created 11 September 2020, archived 4 May 2023.
28. monzo/typhon GitHub, created 12 February 2015, commits through 12 August 2026.
29. monzo/calico-accountant GitHub, created 22 September 2019.
30. monzo/response GitHub, created 13 April 2019, 403 commits, not archived.
31. Index Ventures, incident.io raises $62M Index Ventures, 2025 to 2026.
32. Monzo, An introduction to Monzo's data stack Monzo blog, 14 October 2021.
33. InfoQ, Monzo builds governed data mesh across 100 teams and 12,000 dbt models InfoQ, May 2026.
34. Monzo, Tolerating full cloud outages with Monzo Stand-in Monzo blog, February 2025.
35. Monzo, Processing payments in Monzo Stand-in Monzo blog, 2025.
36. InfoQ, How Monzo Bank Built a Cost-Effective, Unorthodox Backup System InfoQ, 24 February 2025.
37. LeadDev, How Monzo built a Stand-in platform to sidestep costly outages LeadDev, 2025.
38. AWS, Monzo Bank success story AWS customer case study, undated.
39. AWS, Monzo case study (PDF) AWS, September 2020.
40. Finextra, Monzo develops backup bank to cover outages Finextra, 2024.
41. Crowdfund Insider, Monzo highlights backup system Crowdfund Insider, January 2026.
42. Finextra, Monzo deploys backup bank in face of outage Finextra, August 2026.
43. StatusCake, Monzo's Stand-In held up on Wednesday StatusCake, August 2026.
44. PYMNTS, Monzo steers customers to backup bank amid technical outage PYMNTS, August 2026.
45. FCA, Operational resilience: insights and observations for firms Financial Conduct Authority, 2024 to 2025.
46. AWS re:Invent 2025 session HMC201, community write-up dev.to, 3 December 2025.
47. QCon London, Banking on Thousands of Microservices QCon London, March 2023.
48. InfoQ, Modern Banking in 1500 Microservices InfoQ presentation, 2020.
49. InfoQ, QCon London 2026: Shipping Constantly with Humans and beyond at Monzo InfoQ, March 2026.
50. InfoQ, Monzo's Recipe for Developer Experience InfoQ, April 2025.
51. The Register, How does Monzo keep 1,600 microservices spinning? The Register, 9 March 2020.
52. Monzo, Annual Report 2026 Monzo, 19 May 2026.
53. Bronson, Aghayev, Charapko, Zhu, Metastable Failures in Distributed Systems HotOS '21, 2021.
54. Huang et al., Metastable Failures in the Wild USENIX OSDI '22, 2022.
55. Performance Comparison of Service Mesh Frameworks: the MTLS Test Case arXiv preprint, November 2024.
56. Container Solutions, How Monzo's opinionated platform and tools support their developer experience Container Solutions, 2022.
57. diginomica, Monzo Bank eyes AWS managed services diginomica, 2020 to 2021.
58. Tigera, Conversation with Monzo on compliance with Calico Tigera, undated.