How Uber Built the Tincup Microservice: Lessons in Scalable Backend Architecture

Several months ago Uber began replacing its monolithic codebase with a modular microservice architecture. Engineers invested thousands of hours to evolve the ecosystem, using multiple languages and frameworks, and adopted new microservice building techniques.

Start a New Service

At fast‑growing engineering companies, tracking ongoing tasks is hard, so Uber requires new service authors to submit an RFC (Request for Comments). The RFC details purpose, architecture, dependencies, and other details, inviting discussion from the rest of Uber’s engineering department.

The RFC serves two purposes: (1) gather feedback to improve service quality; (2) avoid duplicate work and create collaboration opportunities.

Execute a New Service

Uber’s currency and exchange‑rate service “Tincup” illustrates a successful microservice. It provides two main endpoints: obtaining currency targets and fetching the current exchange rate against USD for about 60 currencies.

Regardless of location, riders can request a ride and Tincup ensures the fare is paid in the local currency.

Guide Microservices with New Tech

Building Tincup required refactoring all currency‑related logic, prompting a review of long‑standing design decisions. Uber introduced a “MVCS” approach, extending MVC to include the service layer, allowing the persistence layer to be swapped without touching business logic.

For persistence, Uber replaced PostgreSQL with UDR (Uber’s globally replicated scalable database) to support all‑active data‑center replication.

Predict Microservice Growth Issues

To avoid blocking I/O, Uber adopted Tornado, an event‑loop‑based Python async framework, after extracting much code from a Flask monolith. Go is also mentioned as an alternative for high‑throughput services.

Uber uses TChannel on top of Hyperbahn for RPC multiplexing, providing service discovery, fault tolerance, and rate‑limiting/circuit‑breaker capabilities.

Thrift is employed as the IDL to enforce strict interface definitions and backward compatibility across rapidly growing service calls.

Prepare Services for Production

Before launch, Uber runs load‑testing with the internal Hailstorm tool to verify Tincup under peak traffic (e.g., New Year’s Eve, Halloween).

uContainer, Uber’s Docker‑based container system, isolates resources so multiple services can share a machine without interfering with each other.

uDestroy simulates failures to test system resilience by deliberately causing outages.

Reflections After Implementation

Key lessons from building Tincup and expanding the SOA include: simplify user migration, keep the technology stack small per service, develop generic units and run integration tests early, and perform frequent load testing to catch capacity issues before they impact users.

Uber’s Microservices

Uber’s migration to SOA offers engineers of all experience levels the chance to own a service, benefit from a knowledge‑sharing culture, and experiment with new technologies.