[ok_dad]

You can definitely run Uber-scale systems with <100 engineers. Whatsapp was famously run by like 30 people or something. The problem is when you expand your business at the rate Uber has, or any VC-funded startup, in which case you gain massive (absolutely massive) amounts of tech debt in the form of bandaging new features onto old code without proper refactoring. Then you start doing "microservices" and you hire 10k engineers and now you have even more problems, and your infrastructure and codebase expand exponentially.

I think for a good scaled architecture, the keys are: having at most ~30-50 developers, good planning by a few key architects, controlling what's in your database with an iron fist, knowing exactly which bits of data are where and what they are used for, and having strict codebase standards.

However, to really be successful in the goals above, the business needs to support a rigorous software process. Normally, this is where things fall apart, since business people and sales people (who are otherwise great people) will push you to work faster and cut corners to get things done. In the end, they also pay the bills, so if the business isn't run by people who understand why software development has to be strict, then you get sloppy software processes.

[azylman]

You can only run Uber with <100 engineers if you cut out a substantial amount of the systems Uber requires to actually function as a company. Goodbye Fraud, Risk, Safety, Insurance, Compliance, etc. That may be true for things like Whatsapp with a simpler feature set, but is certainly not generally true. For instance, people often underestimate the amount of ongoing engineering effort to stay up to date on changes in tax law in all the countries Uber operates in.

[yrgulation]

> Fraud, Risk, Safety, Insurance, Compliance, etc.

Should all be externalised. I mean what is uber processing payments itself too? A bit like stripe building its own taxi app for their own employees.

[azylman]

> I mean what is uber processing payments itself too?

https://underhood.blog/uber-payments-platform

https://underhood.blog/assets/images/uber_payments/overview....

Usually the way these kinds of things evolve is it will start with some business requirement: "We want to launch in country <X> but our existing PSP <Y> doesn't support the country's most common payment method <Z>" (Uber operates in 71 different countries).

So you build out a system to abstract over multiple different PSPs (such as Stripe, though Stripe isn't listed in that graphic so not sure if Uber uses it at all) to unlock new business growth. Then you find out that some PSPs are cheaper than other PSPs, so you can save the business money by supporting additional PSPs. Then you find out that some PSPs are more reliable than others so you can increase availability by dynamically selecting PSPs based on availability and transaction costs etc. etc., layering on complexity over time.

All these things are actually built for very good reason (in this example, built to grow the business and reduce costs), but the reasons aren't obvious to the outside observer. But the work easily pays for itself many times over.

So could you run Uber with <100 engineers? Probably, if you were okay running in just a single country instead of 71. But that would be a very different Uber.