#Simple helix server name indication drivers#

In a large app like the Uber app, the variation of the rate of change is very wide ranging from seconds to hours. The frequency of the polling of these apps depends on the rate of change of the data that they are polling for.

The rider app can poll the server every few seconds to check if a driver is assigned. The driver app can poll the server every few seconds to check if a new offer is available. Now everyone (rider, driver, backend) should be synchronized with each other’s intent. Uber’s matching system in the backend identifies a match and provides a trip offer to a driver. These two entities need to stay updated with backend systems and each other as the trip progresses.Ĭonsider a scenario where a rider has requested a ride and a driver is online to provide a service.

#Simple helix server name indication drivers#

Polling for updatesĪn Uber trip is an orchestration between participating entities like the riders and drivers moving in the physical world. This article describes how we went from polling for refreshing the app to a gRPC-based bi-directional streaming protocol to build our app experience. This creates the need to keep all active participants and apps synced with real-time information, whether it’s through pickup time, arrival time, and route lines on the screen, or nearby drivers when you open the app.Ī key dimension of growth was feature explosion in critical user screens and the need for developers across the company to build real-time mobile features in a decentralized way on a shared app screen. Over the course of a trip, there are multiple participants that can modify and view the state of an ongoing trip and need real-time updates. The nature of real time marketplaces make them very lively. We strive to build real-time experiences for all our users.

Uber builds multi-sided marketplaces handling millions of trips every day across the globe.