How Uber Built Tincup: Scaling a Global Currency Microservice

Background

Uber transitioned from a monolithic codebase to a modular microservice architecture, refactoring hundreds of services across multiple languages and frameworks to adopt a unified technology stack and SOA migration standards.

RFC Process for New Services

New services must be introduced via a Request for Comments (RFC) that describes the service purpose, architecture, dependencies, and implementation details. The RFC is reviewed by experienced engineers to gather feedback, improve quality, and avoid duplicate effort before development begins.

Tincup Service Overview

Tincup is Uber’s currency and exchange‑rate service. It provides two public APIs: GET /currency/{code} to retrieve a currency object and GET /exchange-rate/{code} to obtain the current rate against USD. The service supports roughly 60 currencies and is critical for global fare calculations.

Design Decisions

MVCS Pattern

Uber introduced an extended MVC pattern called MVCS (Model‑View‑Controller‑Service). The added service layer isolates business logic from persistence, allowing the data layer to evolve (e.g., swapping storage engines) without modifying core logic.

Persistence Layer

The original PostgreSQL store could not satisfy global replication requirements. Uber replaced it with UDR (Uber’s globally replicated, scalable data store) to provide low‑latency reads from any data center.

Asynchronous I/O

To prevent blocking I/O and thread starvation in uWSGI workers, the service is built on the asynchronous Tornado framework (Python). Tornado’s event loop enables non‑blocking network calls while preserving existing request‑handling semantics. Some components are implemented in Go for similar performance reasons.

Inter‑service Communication

Uber uses Hyperbahn together with the open‑source TChannel library for RPC:

Service discovery: producers and consumers register with Hyperbahn and are addressed by logical name.

Fault tolerance: routing tracks failure rates and SLA violations, automatically removing unhealthy hosts.

Rate limiting & circuit breaking: protects downstream services from cascading failures caused by slow or erroneous clients.

Service contracts are defined with Thrift . Thrift enforces strict interface definitions, guarantees backward compatibility, and rejects calls that do not conform to the IDL.

Deployment and Operations

Containerization

Tincup is packaged as a Docker‑based container using Uber’s uContainer platform, which extends Docker with flexible build capabilities and additional visualization tools. Resource limits and isolation are enforced at the container level.

Load Testing

Before release, Uber runs synthetic traffic against Tincup with the internal Hailstorm load‑testing tool. Tests simulate peak traffic spikes (e.g., holidays) to verify latency, throughput, and error‑rate targets.

Chaos Engineering

To validate resilience, the uDestroy chaos‑testing tool injects host crashes and network partitions. Observed failure modes are used to improve retry logic, timeout settings, and circuit‑breaker thresholds.

Lessons Learned

Service migration should be incremental; provide clear migration paths, code examples, and realistic timeline estimates.

Introduce new technology stacks on small, self‑contained services (like Tincup) to reduce cognitive load and isolate learning curves.

Invest heavily in unit and integration tests early; this reduces debugging effort during later stages.

Conduct frequent load and stress tests throughout development to catch scalability issues before they become production blockers.