How Monzo structures engineering to ship hundreds of deploys a day without breaking trust

Suhail Patel is a staff engineer on Monzo's platform group, the UK digital bank with no physical branches, with 14 million customers and ongoing expansion into Europe and the United States. In a presentation at QCon London covered by InfoQ, he describes how the company reached more than 3,000 microservices in production, maintained by just a few hundred engineers, shipping changes hundreds of times a day.

The starting point of Patel's argument is a critique of a model common at regulated companies: change approval committees, made up of risk, compliance, platform, and security teams, which can stall or delay any release. According to him, these forums emerge because certain changes have a blast radius too large for the organization's trust, and the risk calculation becomes more mental than technical. The alternative Monzo chose was not to eliminate control, but to embed it into the platform.

The 2016 bet that underpins everything today

In 2016, Monzo made what Patel calls well-spent "innovation tokens": betting on Go, Kubernetes, and a microservices architecture as its foundation. Since then, the company has been deliberate about adding new technology, always encapsulating platform components behind its own libraries rather than exposing Kubernetes, Kafka, or infrastructure details directly to product engineers.

In short: the platform team doesn't ship loose tools, it ships opinionated, tested abstractions, with telemetry built in by default into every service, regardless of whether it handles one request per second or a million.

Anatomy of a microservice: everything cast from the same mold

Monzo maintains a monorepo with a bootstrap generator that creates the same folder structure for every new microservice. This removes part of the cognitive load of navigating unfamiliar code:

• Database logic always in the dao folder
• Queue consumption always in the consumer folder
• RPC layer always in the handler folder

Every engineer, veteran or newcomer, knows where to look. Most services are written in Go, and the platform team embeds security best practices directly into shared libraries, rather than relying on manual review repeated for every new service.

Proto files as the single contract

The workflow for creating a service starts with defining a proto file containing the API contract. Internal generators compile that file into Go code that already embeds the company's standard HTTP libraries and telemetry, including validation beyond protobuf's native types. The same mechanism is used to generate logic for consuming and producing events on Kafka queues: the engineer defines the payload and validation rules, and Monzo generates the transport code.

The practical payoff, according to Patel, shows up when the infrastructure or security team needs to fix a bug or apply a performance improvement: the fix goes into the generator library and propagates to all 3,000-plus services when the stubs are regenerated, without depending on each squad manually updating its code.

The "paved path" instead of the change committee

The talk's central thesis is that effective governance doesn't come from approving changes one by one, it comes from making the right path the easiest path. Patel describes a structured onboarding guide, "backend 101," which teaches the tools, Go coding conventions, and microservices architecture right when an engineer joins the company, knowledge that, he says, remains useful throughout their entire career there.

Nobody wakes up in the morning and instructs their agent to go and write bad code, just like a human doesn't wake up one day to write bad code.

Suhail Patel, staff engineer on Monzo's Core Platform

In the official summary of the presentation, InfoQ cites other pieces of this trust framework that underpin delivery speed: opinionated microservice abstractions, staging environments organized by tenancy, static code checks, and continuous profiling in production. The common idea among them is to detect behavioral drift before it becomes an incident, rather than blocking the change before it happens.

AI without hallucinating: documentation became a "skill"

The most current part of Patel's argument connects this investment in standardization to the use of tools like Claude and Cursor inside Monzo. Since all the onboarding documentation and code conventions were already written and standardized for humans, the team was able to turn that material into structured context for AI agents, rather than leaving them to guess at a service's structure.

With more than 3,000 real service examples in the same monorepo, following the same folder convention and the same proto generator, AI tools have a concrete reference to follow, rather than just generic training knowledge. Patel argues this reduces the chance of an agent inventing a service package that doesn't exist or breaking the company's standard.

He also cites the widely reported case of a Financial Times story that attributed reliability failures at Amazon to AI-assisted changes, an episode that led Amazon to publish a public correction clarifying that the changes required senior engineer approval, not that they were automatically generated by AI. For Patel, the detail of who (human or agent) wrote the change matters less than the shared goal: not breaking the system's trust.

What this changes for those building here

Few companies in Brazil will operate at the scale of 3,000 microservices, but Monzo's reasoning applies to platform squads of any size: a boilerplate generator that always creates the same folder structure costs little to implement and pays dividends with every new engineer who joins the team. The same goes for API contracts centralized in proto (or OpenAPI, for those working with REST), which allow security fixes to propagate without depending on each squad remembering to update manually.

The most relevant point for anyone already testing Claude, Cursor, or Copilot in production is the lesson about context: a coding agent performs better when it points to a base of real examples and documented conventions than when it operates over a heterogeneous set of services, each with its own structure. Brazilian fintechs and digital banks, which already face regulatory requirements similar to Monzo's in the United Kingdom, tend to find in platform standardization, more than in approval committees, the path to maintaining delivery speed without losing the reliability expected of a financial system.