Anchored Ads

Starting a New Service

In a rapidly growing engineering organization, it can be difficult to keep track of all the efforts underway. This kind of growth demands a process to prevent duplicating work across teams. At Uber, we have solved this problem by requiring that authors of new services submit a Request for Comments (RFC), a high-level proposal of the new service that outlines its purpose, architecture, dependencies, and other implementation details for the rest of Uber Engineering to discuss. The RFC serves two purposes: 1) to solicit feedback for improving the service’s quality as it’s developed and 2) to prevent duplicate efforts or expose opportunities for collaboration.

Implementing a New Service

Tincup, our currency and exchange rate service, is a great example of how a microservice at Uber is implemented. Tincup is the interface for up-to-date currency and exchange rate data. It serves two major endpoints: one to get a currency object and a second to get the current exchange rate for a given currency (per USD). These endpoints are necessary because Uber is a global business. Exchange rates change often, and we facilitate transactions in nearly 60 currencies.

Bootstrapping Microservices

Rewriting all logic related to currencies and exchange rates while building Tincup provided a good opportunity to reevaluate some design decisions at Uber that were made long ago. We used a flurry of new frameworks, protocols, and conventions to implement Tincup.

First, we addressed the overall structure of code related to currencies and exchange rates. At Uber, we have modified the persistence layer of many datasets (like this one) several times in recent years. Each change is long and cumbersome. We have learned from this process that, if possible, it is best to separate the persistence layer specifics from the application logic.