19 karma · joined March 18, 2009
I am currently leading the fulfillment org @ Uber - shopping, logistics, frameworks, Integration, indexing, signals, visualization, and storage teams.
Our teams build systems that are the beating heart of Uber, mapping the real-world to the digital world. If you are excited to solve technical problems with challenging product complexity, race conditions, high read/write volume, and scaling bottlenecks, please do connect!
One one user talking own all APIs, the system has ability to skip unmountable APIs, but we catch it during user interactions with tons of test and validations.
- Most of the tech described in the article is something you will have to do whether you choose gRPC or websockets. Most of the tech was about sharding and maintaining sticky connections and load balancing those connections across servers based on load.
- The heartbeat introduced on top of HTTP was needed to detect the broken connection faster and recover quickly as some of the payloads were very latency sensitive. Note that these connections are not 1:1 connections but have multiple hops across low bandwidth mobile networks.
- At the time we developed this initially in 2014, most of the WebSockets libraries would fallback to longpolling when the network connections were unstable. We explicitly went away from long polling. Since server->mobile payloads are the larger of the volumes, we settled in on SSE. Netty and the netty libraries provided most of the implementations of SSE out of the box.