[battwell]

It's definitely a lot of engineers. But we cram a lot of features into the app. I expect that most people will only experience 10% of them. Consider: 1) We exist in a tonne of countries. And different counties often require different product optimizations and payment methods 2) We have our own map provider 3) We experiment with everything 4) We support countries that have terrible networking. That creates lots of challenges.

[venture_lol]

From an engineering perspective, that sounds uninteresting :)

Terrible networking? how many engineers does it take to implement a few flavors of retries? :)

Uber growth in term of getting drivers, that's what I want to know. It's not just ride subsidies, but the flow of investor honey helps, of course, but they do have some alpha growth managers.

[uberengineer]

Oh, it goes well beyond retries. You have issues like unpredictable latencies and lost network connectivity. A feature that works great when RTT is 400ms may require an entirely different approach when RTT is 30000ms. There are also issues with clocks due to both fraud and misconfigured cell towers. India for example has notoriously bad RTT times and Jakarta and several cities in LatAm have issues with clocks.

At scale, across so many different markets, with so many different features, things get complex fast. We want the user experience for both riders and drivers to be magical. More magic requires more engineering. The goal is transportation as reliable and available as running water everywhere all the time.

Here's an example of telematics engineering used to improve safety by detecting harsh braking: https://eng.uber.com/telematics/

We also use the IMU measurements to detect drivers who aren't using a phone mount and are instead holding their iPhones while driving.

Features like these allow us to advise drivers on how to be safer and get better ratings since not using a phone mount and harsh braking both correlate with negative user ratings.

A lot more goes into the Uber app to make things magical. I used to read the front page of HN daily to read about all the cool things people around are working on. Since joining Uber, I check far less often now because there are so many cool problems being worked on internally that many of the front page stories sometimes seem quaint in comparison (not that many HNers aren't working on awesome things but the quantity and quality of cool problems my colleagues work on easily captures most of my attention these days).

The best way I can describe working at Uber: it's like building that transportation component of sim-city for every city, everywhere, but it's not a simulation. Despite all the click bait negative press, its bar none the best place I've ever worked.

[uberarch]

It is easy to get lost in your work and think it is special. Prior to uber, I've seen quite a bit, and I can tell you certain some are good and certain stuff are not that good

[uberengineer]

Completely agree that not everything is sunshine and happiness at Uber. The quality is highly variable across the company, but my observation has been that this is a feature, not a bug. Some systems need to be built very well such as software defined networking and container infrastructure, so you need to take the time to build it right. Other areas are one off features where speed to market matters most. Faster, Cheaper, Better, choose two. I would say on average there is a good balance between those three across the company, with each team/project making the right trade offs for the short and long term business goals. Most systems that have proven valuable end up being rewritten. I've helped sunset two older systems thus far.

It's easy to drop in and criticize the architecture of some older systems, but it's also instructive if you were around when they were built and knew the trade offs and constraints that existed when they were first conceived. The growth we've experienced has been astronomical and it would have been non-trivial exercise to build systems 2-3 years ago that account for the scale and business needs today. Even today, it's hard to plan farther that 2-3 years out with the growth we are seeing. I work on a system doing millions of QPS and in 2-3 years, it will be handling an order of magnitude more QPS and more business needs. We might scale horizontally or decide a different solution is needed. I don't think there is a silver bullet and the microservice architecture means that rewrites and re-architectures are tractable problems.