How Uber Tamed Microservice Chaos with Domain‑Oriented Architecture

Introduction

Recent discussions have highlighted the drawbacks of microservice architectures, especially the increased system complexity they can introduce. While microservices once promised benefits such as independent deployment, clear ownership, and improved stability, many now criticize the overhead they add.

Uber now runs about 2,200 critical microservices and has spent the past two years trying to reduce this complexity while preserving the advantages of microservices. This post introduces Uber's general approach, called Domain‑Oriented Microservice Architecture (DOMA).

What Is a Microservice?

A microservice is an extension of service‑oriented architecture, representing a small set of functions exposed via a well‑defined interface over the network. Compared to monoliths, microservices increase deployment flexibility but also add performance overhead and operational costs.

Motivation

Uber adopted microservices around 2012‑2013 to address availability risk, deployment risk, and poor separation of concerns in its monoliths. As the engineering organization grew, microservices provided flexibility and autonomy, but also introduced new challenges such as increased complexity, difficult debugging, and coordination across many services.

Domain‑Oriented Microservice Architecture

DOMA borrows principles from domain‑driven design, clean architecture, and service‑oriented architecture. Core concepts include:

Domain: a collection of related microservices.

Layer: a set of domains that defines allowed dependencies.

Gateway: a single entry point for a domain.

Extension: mechanisms (logical or data) to extend domain functionality without changing core services.

By structuring services into domains, layers, and gateways, DOMA aims to make a large microservice system understandable, reusable, and layered.

Uber’s Measures

Domain : Groups of microservices serving a logical function (e.g., maps search, pricing, matching).

Layer Design : Defines which services may call which others, providing scaled separation of concerns. Uber uses five layers: Infrastructure, Business, Product, Presentation, and Edge.

Gateway : Acts as the API gateway for a domain, reducing upstream dependencies.

Extension : Provides logical and data extensions to add functionality without modifying core services.

Benefits

DOMA has improved reliability, clarified ownership, and accelerated development. Teams now often need to call only one service instead of many, reducing integration time by 25‑50 %. Uber has partitioned its 2,200 microservices into about 70 domains, with roughly half already implemented.

DOMA also eases migration by isolating changes behind gateways, preventing “migration hell” as services evolve.

Practical Advice

Adopt microservices gradually, considering organization size. Start with clear motivations, avoid premature rewrites, and use domain‑oriented thinking to group services. For startups, weigh operational benefits against added complexity; for medium and large companies, focus on layering, dependency management, and platform‑product separation.

Final Thoughts

DOMA treats a microservice architecture as a large distributed program, applying familiar design principles to its evolution. Uber continues to refine DOMA and hopes others find it useful.