Uber DOMA: domain-oriented microservices

01 · CONTEXT

From monolith to microservices

Around 2012 and 2013, Uber had basically two monolithic services and adopted an architecture based on microservices to solve operational problems. A single regression in the monolithic code could take down the entire company, and deployments were painful and slow, with frequent rollbacks.

With microservices, a service can go down and be rolled back without taking down the whole system. Uber also suggests a useful mental model: think of a microservice as a library that charges a performance price, network I/O and serialization, for every function called.

02 · THE PROBLEM

When complexity becomes the cost

As the company grew, Uber reached about 2,200 critical microservices. Swapping a single monolithic codebase for black boxes whose behavior can change at any moment began to cause unexpected behavior. In one reported case, investigating the root cause of a problem required going through about 50 services from 12 different teams.

1. A request enters at the edge and is handed to a service, which calls others in sequence; calls between services can go very deep.

2. A latency spike in the deepest dependency can cause a cascade of problems upstream.

3. Without the right tools, seeing what really happens in this chain is impossible, which makes debugging hard.

Another symptom: services that look independent can start needing to be deployed together for any safe change: a networked monolith is born.

03 · THE IDEA

Domains and layers

Uber's answer, called Domain-Oriented Microservice Architecture (DOMA), draws on established principles such as Domain-driven Design, Clean Architecture, and service-oriented architecture.

The first principle is to organize around collections of related microservices, the domains. A domain can bring together dozens of services or just one; map search, fares, and matching between riders and drivers are examples. The Maps organization, for example, is split into three domains with 80 microservices behind three gateways.

The second principle is layered design: a domain's layer defines which dependencies its microservices may depend on, and each layer depends only on those below it. Going up the stack, a domain affects fewer services when it fails and is more product-specific.

The order in the table goes from the most general to the most specific: each following layer is more specific and has a smaller blast radius.

04 · GATEWAYS

One entry point per domain

The third principle is gateways: clean interfaces treated as a single entry point into the collection of services. The gateway hides the domain's internal details, and the consumer ends up with a single dependency instead of several.

1. The edge layer exposes the services to the outside world and knows about the mobile app.

2. Presentation is tied to app features, while product concentrates the logic of a product category, agnostic to the app.

3. The gateway is the single entry point into the business domain; callers depend only on it.

4. The internal services are hidden behind the gateway and can change without forcing a migration upstream.

5. The lower layers have more dependents and therefore a larger blast radius; the upper ones depend only on those below them.

This matters a lot because services change all the time. Uber calculated that the half-life of a microservice was a year and a half, and two of the biggest platform rewrites happened behind gateways.

05 · EXTENSIONS

Extending without changing the core

The fourth principle is that a domain should not embed another domain's logic. Since teams still need to add logic to other domains, Uber offers well-defined extension points. Logic extensions use a variation of the provider or plugin pattern, and data extensions avoid bloating the platform's models.

1. The go-online endpoint defines the interface that each extension must follow, with predefined request and response types.

2. Each team registers an extension responsible for running its own check.

3. The endpoint iterates over the responses and checks whether any of them is false.

The result is to decouple the core code from each extension and isolate the extensions from one another, since they do not know that other logic is running.

06 · RESULTS AND LIMITS

What changed and when not to adopt it

According to Uber, 2,200 microservices were classified into 70 domains, with about half already implemented. An early consumer of the extension architecture cut the time to prioritize and integrate a feature from three days to three hours. The company itself stresses that DOMA was still young, with very positive early signs.

For small organizations, the operational benefit of microservices probably does not outweigh the increase in complexity. Uber sees the evolution of the architecture more like trimming a hedge than a full rewrite.