Live data from Hacker News

The Uber Engineering Tech Stack, Part I: The Foundation

eng.uber.com

191–194 of 194 posts

Re: The Uber Engineering Tech Stack, Part I: The Foundation

#191

Earlier quoted context omitted.

Your user accounts aren't global? So does that mean if I travel to a new city I have to create a whole new account?

I've traveled to a dozen cities with Uber and didn't have to change my account, even in China. So the answer is no.

They said they were an Uber-like system, not Uber itself.

Re: The Uber Engineering Tech Stack, Part I: The Foundation

#192

Earlier quoted context omitted.

Why would having federated logins be difficult to implement?

It's just not important enough to do. Startup resources, business priorities, customer behaviour...

Surely customers travelling to new cities/countries they don't know is significant behaviour?

Re: The Uber Engineering Tech Stack, Part I: The Foundation

#193
post #166

Earlier quoted context omitted.

It sounds like you have no idea how credit card transactions were or are processed. They are almost exclusively file and batched once a day, even today. Back in the 1970s it was even worse because there was no real time authorization.

This is helpful information if accurate, but please edit incivility like "It sounds like you have no idea" out of your comments here. The site guidelines ask you to omit this sort of thing, so please post civil and substantive comments only: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newswelcome.html

He or she is correct that the cash settlements were and are batched, but authorizations, reservations etc were online - to the mainframe that's just another transaction.

The reason settlements were batched was to save on wire fees.

Re: The Uber Engineering Tech Stack, Part I: The Foundation

#194

Earlier quoted context omitted.

...so you run the servers you need for peak load 24/7? Ew. So much money just thrown away because "it's too complicated". We just scale based off of Network Out and only really spent a week finding the right threshold.

How long does your stack take to add a server. 3 minutes? I have created a lot of services that couldn't have crappy perf for 3 minutes every time the load scales. Especially since in many apps the most expensive part is storage and dbs which cannot auto scale. So say you spend 1k a month in your dbs and $100 for peak web load. You could spend a week fixing auto scaling bugs and try to save $25 by scaling web nodes d…

We're sensitive enough that we preemptively scale as traffic "appears" to be increasing. So we add 5 EC2 instances, not at crisis levels of traffic, but "Hmmm...I feel a tingling in my extremities". We then remove one instance at a time if traffic falls below "Not doing anything" levels. The time between scaling actions is 15 minutes. Since ASG's go to remove older instances first, we don't end up getting charged a full hour for instances that are up for less than an hour that often.

Admittedly, our web traffic is very US Business Hours centric and peaks predictably between 3 and 4 in the afternoon.

Also, we're operating more at a scale of $40,000/month for peak traffic capacity 24/7 and $25,000/month once I got autoscaling worked out. So...yeah. I guess the scale for savings matters. :-)

Post reply on HN