[onlyrealcuzzo]

For a simplified version of the app with arguably no worse user experience, it's not THAT farfetched.

Uber has an absurd amount of logging & analytics.

If the app was simply drop a pin, get a ride - it wouldn't be that crazy.

Uber has 3.9M drivers world wide. There's probably very rarely more than 1M drivers active at any time. Probably less than 300k people looking for a ride at the vast majority of times.

Assuming you can update the driver's location 1 time per minute - that's ~1.5B requests per day - less than 25k requests per second (including user bookings).

That's like ~2TB of bandwidth per day. That's less than $200 per day. Almost everyone spends more than 5% of their cloud bill on bandwidth. Meaning, the rest of a drastically simplified (but nearly equally useful) Uber could run for ~$4000 per day in server expenses.

That's a $1.4M / year data center. Uber has revenues of >$11B.

They could be making a lot of money. They just aren't because they're spending AT LEAST 50x more on servers and product engineering than they NEED to.

They paid for growth for a long time. They have a monopoly now. There's not a lot of growth left to get. At some point the axe will come down.

Lyft is even worse. They're ~1/3rd the size.

[isatty]

It just does not work that way. I was an SRE at a similar company. You need driver locations, passenger locations, cost calculators (including ML models), ads serving, respect user preferences, geofencing, ride sequencing, analytics, compliance, fraud detection (you'd be surprised at the amount of fraud and clever tactics people employ). This is just a very minimal set of services (I'm guessing <10% of what you need) and you need to run this somewhat reliably.

Cost of revenue in just terms of infrastucture was measured in $/ride and minimizing it reliability is difficult, especially if you're a fast growing startup and on cloud providers. Unfortunately, if you're a fast growing startup you also don't usually run bare metal (even though I'm a fan of colo/OVH/Hetzner).

Don't forget that money used to free, with the way interest rates and investors were. It's far more difficult cutting down, than it is to throw money around, obviously.

[DeathArrow]

You need all of that if you try to complicate things. Otherwise you can get 90% of the money for 10% of the effort.

You can have a fixed rate. Fraud detection is a problem that thousands of apps requiring in app payments solved it somehow.

You don't need to have 1 million features, you only need to have the features demanded by the people who will make you most of the money.

[frankfrankfrank]

It’s also a denial strategy. The bleeding edge that also forces your competitors out of the market because they cannot get past the network effect and name recognition hurdle is worth its weight in gold.

Most people will say they’re going to get an Uber, even if they end up having to use Lyft, no? Ubers, as well as others’, expressed strategy has long been not only first mover, but also monopolization of all aspects of their space, expressly anti-competitive. Part of that is not only being the leader, first to mind, but also draining the enemy/competitor’s resources and undermining their efforts to even challenge you. It’s a total market domination strategy that shouldn’t even be allowed, but they’ve also paid off politicians and captured government in other ways too, so don’t expect anything from there either. There used to be other ride sharing services, I don’t even know if they exist anymore, but even before the Great Monopolization, aka COVID, they were barely scraping by on crumbs in a few local markets while the likes of Uber worked in basically every market, especially in the high spending business travel and entertainment segments.

[DeathArrow]

Maybe that was their thinking? Have massive loses while killing all competition including taxi drivers and capture the market and after that just cut features and jack up the prices while paying less money to drivers?

Fortunately it haven't worked. But could it work assuming the VC investors would be able and willing to pour much more money into it?

[GauntletWizard]

You're way overoptimistic in your expenses calculation - Maintaining a "real-time" app is 100x more complex than that.

100x, bringing their opex to hundreds of millions on billions of revenue. They should still be able to cut the fat and actually turn a handy profit, but they won't.

[onlyrealcuzzo]

No one needs real-time (above 1 minute) driver locations.

Riders never see the driver's location before booking.

Uber doesn't need the exact location to get a decent match.

And anyway - they send the ride to several drivers and the lowest / first bidder wins.

[edmundsauto]

What is the set of information that makes you say this? Because I would put money that Uber's data team has run an experiment with lower realtime status updates (realtime is expensive, these companies aren't filled with idiots, they test things). And based on that, I think it's reasonable to assume that critical metrics are negatively impacted by not having realtime updates.

So I'm curious if you have any knowledge, or if what you are saying is "I don't need realtime", or perhaps more charitably, "I can't imagine realtime being valuable to users". I push back on the 2nd, and I strong push back on the idea that someone with can reach the conclusion that Uber is wasting money on things that don't drive user value.

Unless, of course, you work/worked there and worked on these projects, and saw firsthand that Uber decided to waste a bunch of money internally.

[DeathArrow]

Taxi apps in my country have real time updates. I can see the taxi on the map and every turn in makes to get to me. The driver can also see if I move.

And it's clear they didn't employ anything like Uber massive work force to do that.

[lumost]

In a major metro like Boston 1 minute further down the road could mean a 5 minute longer wait. I think your point stands however with 6x traffic increase to once every 10 seconds.

[onlyrealcuzzo]

You only need to update the location if the driver is moving. IIUC, most drivers are stagnant while they wait for rides.

They're in the business of saving gas. Not cruising around idly while they wait for a ride.

Sure - some drivers are finishing a trip nearby. But you know the route they are taking...

[noirbot]

I'm not sure that's true. Almost every rideshare I've gotten in the last few years outside of an airport pickup has been in motion when they got assigned to me, and usually already on another ride. Even many of my airport rides were being picked up by someone who was dropping off someone else at the airport right before.

You also don't know for-sure what route they're taking. Almost every driver I've had was using Waze or some other mapping app that usually took a different reasonable route than whatever Lyft was showing when I booked it.

[nathanvanfleet]

Surely you don't think a modern and complex app requires just a single API endpoint that triggers once a minute? And that it's that simple a thing for the driver/ passenger?

[onlyrealcuzzo]

Surely you don't think there's another endpoint that's getting hit an order of magnitude more to change the point?

Multiply by 3 for redundancy & availability. Multiply by 3 for other endpoints. You're not even 10x...

And this was not Uber as it exists. This is a simplified version of Uber that gives the user a nearly equal experience.

[DeathArrow]

I wonder why all backends are now web based even if the frontend apps are not web based?

If someone does a mobile or desktop chat app (think Whatsapp or teams) he will use web technologies on the backend. But IRC is very old and still works like a charm without using web technologies.

Likewise, if email was invented today, it would be just calling some REST api instead of using SMTP.

When I worked as a game developer, the server side of our games was a slow and ineficient PHP crap becouse the founders were friends with a PHP programmer. I had to jump through many hoops to mask huge latencies from web server or even the web server not replying at all.

I think using web for anything can add a massive overhead.

I can see the advantage of the web, though. You don't need to implement a server, you just think in terms of HTTP requests and the framework will transform those for you in data and transform the data back into replies.

But if you need something real-time you have to use web sockets, and at that time the simplicity goes away and you can use OS sockets just as good.

I am arguing that using web frameworks for an app which won't have a web fronted adds almost the same kind of overhead as using Javascript for mobile and desktop apps. It's doable, yes. It's the best usage of resources, no.

Normally I should be the last one to complain since I architect and develop web apps for living.

But I do like efficiency, I think that sometimes many layers of virtulization, abstraction, indirection, protocol encapsulation are hurting both the performance and the speed of the development.

And I also know how to develop a server side app without using an HTTP server and a web framework.

I wonder if the root of the problem is that apart from the the people doing mobile apps, the rest are mainly learning a frontend or backend framework and they can't do or are not willing to do anything besides that. Or, even worse, new developers are just learning dynamic laguages such as Javascript or Python or PHP which catters mostly to the Web.

If you only have a hammer, everything looks like a nail.

When I had to design a tool to masquerade the real people data in our microservice based app, everyone from my team was amazed I wrote a console app instead of a Web based application. But since there it wasn't a need for that tool to be called through an API, why should I have made it a web app? Just to use curl instead of command line arguments?