Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Uber Engineering Tech Stack, Part I: The Foundation

eng.uber.com

Post reply on HN
Print view View original

111–120 of 194 posts

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

#111

Post by rantanplan »

brianwawok wrote: post #108
rantanplan wrote: post #106

Earlier quoted context omitted.

The above is good as a rule of thumb indeed. Another one that I'd add is: - "Are the records in each table in the hundred of millions? Then most probably you'll do fine with an RDBMS". If you go above that, or you have operations that will extrapolate that number in the billions then you can offload them into whatever non-RDBMS storage you want and do your thing. But that's the thing with RDBMS, you can always move(o…

Does row count matter that much compared to data size? I.e. if I have a billion rows but they are 2 32-bit ints, that isn't a lot of data (2 GB + index). I guess the index starts to get pretty big.. but I always just think of raw data size vs # of rows.

Remember, it's just a rule of thumb. Now... tables with 2 32-bit ints as columns are not exactly typical RDBMS data.

Also, data in RDBMS are... well relational :) Meaning, the rows of just one table are not that important. The data are going to be queried and combined with data from other tables. And I know that typical relational data that consist of hundreds of millions of entries in each table is something that most DBs can handle.

Again, rule of thumb :D

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

#112

Post by gaius »

ricardobeat wrote: post #52
Animats wrote: post #29

Earlier quoted context omitted.

I have to admit, I could see this running for a city the size of SF on a desktop machine under the table at the taxi depot. Uber has 11,000 drivers in SF, but probably only a few thousand are on at any one time. A ride takes a few minutes, so if you figure 3,000 active drivers and 4 rides per hour, that's only about 3 ride transactions per second. You have a transaction at ordering, one at ride start, and one at ride…

It's easy to imagine the simplest stack that can serve the core features of any service, and that is well served by a single box. What's missing from the picture is the infrastructure to replicate this 500 times by separate teams, monitoring all of it, backup, auditing, aggregating customer and business metrics, back-office systems, and more. Plus the fact that these things always grow organically and embed a host of…

We saw this in the 90s, people with a whole rack of machines running Java or Perl CGIs to serve a site with less traffic than we were doing with a single, ordinary box running NSAPI. You need loads of scaffolding that you mention, only if you are trying to fit a square peg into a round hole.

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

#113

Post by mooted1 »

ryanlm wrote: post #107

I just got rejected from them. I applied for a SE position, but they didn't like me I guess. They send you this really condescending rejection letter. I showed them my programming language that I built in C from scratch, and also my data structure library where I implement all the common data structures found in high level languages that I built from scratch in C, among the many projects I have. It must have been my…

When I first started interviewing, I got turned down at a lot of companies because they were concerned about my self taught background, often in spite of strong project work and interviews. In spite of so many rejections (2 offers after 17+ interviews), I've been wildly successful in my current job—I received a promotion in the first 6 months and have since held down tech lead roles.

Look, the bottom line is that companies optimize for false negatives. In order to achieve a high accuracy rate, [tests must have exceptionally low false positive rates](https://www.math.hmc.edu/funfacts/ffiles/30002.6.shtml), just based on stats. I won't work out the math for you—you sound like you're perfectly capable of plugging numbers into bayes theorem—but that implies that even very good engineers are likely to get false negative rejections at many companies. It does not mean, however, that those companies are necessarily judging you based on unfair criterion, and I don't thin it's fair, thoughtful, or mature to indicate otherwise—(especially because some of my strongest coworkers at Uber are from less prestigious schools in the midwest...)

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

#114

Post by gaius »

UK-AL wrote: post #50
dkarapetyan wrote: post #23

Earlier quoted context omitted.

That's all bloat. Pure and simple. At the end of the day Uber just does routing and basic allocation. It's a simple operations problem that has been solved since the 70s and no one back then needed ELK, Docker, Cassandra, etc. I've seen this bloat everywhere. It is usually a result of internal politics and posturing by management types. The kinds of people Steve Jobs would have called B and C players. Now the actual…

Docker and Cassandra don't solve basic routing. They solve the fact you have have millions of people hitting you site, and many servers to manage. You didn't have that problem in the 1970s

Credit card processors and airlines did millions of transactions a day in the 1970s, and they managed it with CICS.

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

#115

Post by jdavis703 »

Animats wrote: post #25

It's interesting that they don't break the problem apart geographically. It's inherent in Uber that you're local. But their infrastructure isn't organized that way. Facebook originally tried to do that, then discovered that, as they grew, friends weren't local. Uber doesn't need to have one giant worldwide system. Most of their load is presumably positional updates. Uber wants both customers and drivers to keep their…

Riders and drivers are also not local. I travel a lot and yet my star rating, profile picture and payment details work regardless of if I'm in the Bay Area, Berlin or DC. Further I've heard of Uber drivers giving rides to other regions, e.g. SFO airport to Sacramento (apparently fairly common as the Sacramento airport has limited service and is expensive).

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

#116

Post by mooted1 »

Animats wrote: post #25

It's interesting that they don't break the problem apart geographically. It's inherent in Uber that you're local. But their infrastructure isn't organized that way. Facebook originally tried to do that, then discovered that, as they grew, friends weren't local. Uber doesn't need to have one giant worldwide system. Most of their load is presumably positional updates. Uber wants both customers and drivers to keep their…

Sharding your application geographically is a quite a bit of complexity and requires a lot of work developing support infrastructure to manage load balancing, failover, and placement. One of the advantages of SOA is that different services can have different architectures.

To be precise, we do do geographic sharding in the services that benefit from it, but avoid it in the services that don't.

Also note that the assumption of region based partitioning doesn't extend to all applications. Analytics, for example, may want to dice and slice the data along different dimensions. Partitioning is a convenient abstraction for managing marketplace scale, as you mentioned, but inconvenient elsewhere :).

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

#117

Post by carterehsmith »

zer0gravity wrote: post #38
Animats wrote: post #25

It's interesting that they don't break the problem apart geographically. It's inherent in Uber that you're local. But their infrastructure isn't organized that way. Facebook originally tried to do that, then discovered that, as they grew, friends weren't local. Uber doesn't need to have one giant worldwide system. Most of their load is presumably positional updates. Uber wants both customers and drivers to keep their…

You know that saying : "I didn't have time to write a short letter so I wrote a long one". With this kind of technology stack you end up when you try to move fast. I'm sure that if more time and thought would have been put into it, it would have been more elegant and simple. But has time these days ?

According to the article, this is not their first take at the architecture. There are links that point to their older setups.

So the current architecture is what they came up with after some time and some thought have been put into.

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

#118

Post by cwilkes »

sandGorgon wrote: post #35

What I'm really wondering about is their app. The UI of the app can be impacted without an app update. For example the UI during the pride parade. Or minute of silence ( http://gizmodo.com/uber-makes-riders-take-a-moment-of-silenc... ) I wonder what's the architecture of the app and the API for this.

The UI for their app can be changed without a deploy? You mean like an HTML page from yesteryear? :)

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

#119

Post by jdavis703 »

orf wrote: post #89
danpalmer wrote: post #81

Earlier quoted context omitted.

Couldn't agree more. It's all the invisible details that cause the load. It's a much more trivial example, but highlights the point well I think - we have pages in the app I work on that would respond in ~100ms, but might have a single sentence on them that takes another 100ms to generate because of the complex data relationships involved in figuring out what that sentence needs to say. The 'request handler' might be…

> No armchair architect will ever take into account things like that An armchair architect would say it's not needed. They would question whether spending 50% of your response time generating a single sentence is in any way worth it, and wonder what kind of architectural mistakes led to that.

The problem with this line of reasoning is that it implies the business exists to serve the software. Unless you work at a tech-focused non-profit, the software actually exists to serve the business.
Post reply on HN