Uber's Payments Team Rethinks Microservice Size

The microservices debate has long been settled into two camps: those who swear by them and those who swear at them. So when a team at Uber — a company that has publicly championed microservices at massive scale — signals a shift toward fewer, larger services, it warrants attention.

Gergely Orosz, an Engineering Manager on the Payments Experience Platform at Uber, recently sparked discussion by noting that his team is moving many microservices toward what Cindy Sridharan (@copyconstruct) has called macroservices — well-sized services that serve a business function rather than a single technical task. His tweets emphasized that testing and maintaining thousands of microservices is not only difficult but can create more long-term trouble than it solves in the short term.

Orosz was quick to clarify that this is not a company-wide retreat from microservices. Uber still runs thousands of them — roughly 4,000 at last count — and that number continues to grow. His comments speak only to his own org within payments, and he stresses that Uber's teams are autonomous in their architectural decisions.

From One-Person Services to Team-Owned Platforms

In the early days at Uber, engineers would spin up a microservice that did one small thing, often built and maintained by a single person. This approach was great for autonomy and iteration speed, but it came with a cost: you were oncall for what you built.

As the payments area matures, Orosz's team is taking a more deliberate approach with new services. These aren't single-purpose microservices — they serve one business function, are built and maintained by a team of 5-10 engineers, and receive significantly more investment in development and maintenance. The key difference from Sridharan's macroservice definition: at Uber, each service is owned by one team, not shared across multiple teams.

This doesn't mean the old microservices are going away. The majority remain as they are. But the critical services increasingly look less like classic microservices and more like what Orosz describes as macroservices.

The Real Cost of Thousands of Services

Running thousands of microservices introduces problems that don't exist with a smaller number of larger services:

  • Monitoring and distributed tracing across service boundaries
  • Testing complexity that requires multi-tenancy approaches
  • CI/CD pipeline overhead
  • Library version management across all services — security patches, timezone fixes, and other cross-cutting concerns
  • SLA tracking and enforcement

Uber has invested heavily in addressing these challenges, open sourcing tools like Jaeger (now a graduated Cloud Native Computing Foundation project) and sharing approaches for testing microservices at scale. But Orosz is candid: only adopt microservices at scale if you're ready to make this level of investment.

Defining the Macroservice

Sridharan's characterization of a macroservice is deliberately loose:

  • Not a monolith
  • No more than 20 developers or 3 teams working on the service
  • May or may not use a monorepo — dependency management becomes easier with fewer services and repos
  • Better observability and debugging compared to sprawling microservice architectures

The term itself is hardly novel — it resembles the plain old service architecture that predates the microservices hype. But as Sridharan notes, names serve as scaffolding for discussion. Whether you call it a macroservice, a well-sized service, or something else, the underlying point is that a Netflix- or Uber-style microservices architecture isn't required by most organizations.

Context Matters More Than Dogma

The reaction to Orosz's tweets has been predictable. Critics see confirmation that microservices were always a mistake. Proponents point to successes — one engineer reports that Bayer found microservices far easier to maintain than a large monolith.

More useful takeaways come from observers who emphasize context:

  • The tradeoffs that large companies make at scale may not apply to startups
  • Big companies make poor architectural choices too — avoid cargo culting
  • Uber adopted microservices partly to avoid coordination costs, explicitly building without much concern for reuse or consolidation

There's also a macroeconomic angle: during downturns, organizations tend to consolidate. Maintaining ten teams using ten different systems becomes untenable when budgets tighten.

None of this makes Uber's initial microservices bet wrong. With substantial funding and ambitious growth targets, microservices enabled speed and autonomy. Now that the payment platform is maturing, consolidation makes sense. That's not failure — it's adaptation.

The industry still lacks a consensus on how to build software at scale. Microservices gained traction partly because they offered a coherent theory. The backlash against them reflects the absence of a widely accepted alternative. This debate will continue, and that's probably healthy — but glee at another company's architectural evolution isn't productive. The goal should be getting things right, not being right.