Designing Edge Gateway, Uber’s API Lifecycle Management Platform

Designing Edge Gateway, Uber’s API Lifecycle Management Platform

  • September 25, 2020
Table of Contents

Designing Edge Gateway, Uber’s API Lifecycle Management Platform

In October 2014, Uber had started its journey of scale in what would eventually turn out to be one of the most impressive growth phases in the company. Over time we were scaling our engineering teams non-linearly each month and acquiring millions of users across the world. In this article, we will go through the different phases of the evolution of Uber’s API gateway that powers Uber products.

We will walk through history to understand the evolution of architectural patterns that occurred alongside this breakneck growth phase. We will speak of this evolution over three generations of the gateway systems, exploring their challenges and their responsibilities. A 2014 survey of Uber’s architecture would have resulted in two key services: dispatch and api.

The dispatch service was responsible for connecting a rider with a driver and the api service was our user and trip’s long term store. Besides these there were a single digit number of microservices that supported the critical flows on our consumer app.

Source: uber.com

Share :
comments powered by Disqus

Related Posts

Millions of tiny databases

Millions of tiny databases

The Physalia configuration store for chain replication of EBS is implemented as key-value stores maintained over a large number of these cells. They built a test harness, called SimWorld, which abstracts networking, performance, and other systems concepts. The goal of this approach is to allow developers to write distributed systems tests, including tests that simulate packet loss, server failures, corruption, and other failure cases, as unit tests in the same language as the system itself.

Read More