Hacker News Reader

Comment by new299 | Hacker News Reader

These companies are not "tech" companies in my book any more than the Sears catalog was a "tech" innovation.

They are normal business that happen to be enabled by technology, but the technological challenges are not new or to be frank uncommonly challenging.

Because we're I assume mostly coders, we think they are differentiated by tech, almost everything else (marketing, sales, customer service) is likely more important.

Bad technology could certainly kill a platform, but excellent tech won't save it, and a mediocre implementation is good enough.

View on HN

If you think scaling a service like Uber is not challenging, you're vastly underestimating how large they are.

Uber especially has requirements that make it tough to scale correctly. You need to track each Uber session in near real-time, right? That means you simply cannot afford to drop or interrupt those sessions. It's a completely different problem than scaling Instagram or WhatsApp.

Hmmm... nothing like near real-time. Challenging near real-time is sub-nanosecond.

Uber real-time requirement of what < 30s? (for a viable product).

No that doesn't seem like a challenging problem. It seems like a problem that would require almost no throught for a MVP, and then incremental challenges as the problem scales.

It seems like a problem that is so comparatively easy compared to what computers are capable of that I wouldn't even class it as "difficult".

But what's telling about your answer is that your thinking about this technical challenge, this feature as being of primary importance.

Do you think if Uber was 10 times cheaper than a regular taxi real-time tracking would be as significant?

Uber's funding which has enabled them to subsidize their expansion (and rides), advertising and promotion and possibly that they plugged in to a easily accessed communications channel (mobile apps). Were likely all more important than the quality of their implementation.

Probably less than 30s between pings during a ride, but I haven't tested it tbh. I usually use the word real-time when talking about systems that operate in the ns time range, and near real-time when talking about software. Sorry for the confusion.

What I was trying to emphasize is that Uber needs to keep track of these sessions and make sure they're not interrupted, or else they lose customers.

Yes, I know building something that fits these requirements and works most of the time is trivial. But we're talking about a system that must basically work as close to always as possible. More importantly, it must do this at scale, maintaining and keeping track of perhaps millions of sessions at once.

In a nutshell, an Uber MVP is probably not difficult, but the transition from MVP to real-world product is non-trivial in my opinion.

I'm actually planning on setting up an Uber-like service for my home country, which is why I've been giving these issues some thought.

Even 1M simultaneous users reporting every ~30 seconds could average down to ~30k messages per second. And they'd be extremely trivial to segment between servers. You're right, not a weekend hack, but a few weeks of a small team's time isn't out of the question. The technical side is not the challenge here though really - the business side is.

Perhaps you're right when it comes to scaling, but you're assuming that the system was designed correctly in the first place, which would be impressive imo. There is also a lot of failure handling and recovery that needs to be done gracefully, which I think would be complicated for a session-based system.

Again, I'm no expert, just making educated guesses!

I'm not sure why you need near real-time single session for the tracking. A ping from the app every couple seconds for the available driver screen. Then for the route tracking and billing have the same pings include the GPS track that the phone is keeping track of. If the servers lose track of any of the cars the data would be stale until it comes back into connection.

Also Uber is pretty conveniently partitionable. There's a little bit of overlap in some places but that's mainly for the available drivers screen.

I agree with you completely. I think a lot more effort is required once you are running the system at scale. Since I don't have experience with running Uber, I'm simply making an educated guess as to what kind of complexity is involved.

In addition the whole "we code for a better world" is just HR marketing to attract engineers. Sure there are companies that have innovative areas and oppurtunities, but many engineers are just code monkeys fullfilling daily duty without glory.

Exactly. I would be surprised if Uber hired more than 20 developers (which I consider a lot already).

I would extremely impressed if Uber is maintained and developed by only 20 developers.

Care to explain why?

Just FYI I recently watched a tech talk from some conference where Uber guy claiming they have 2000 developers...

What the hell that's insane...

heres a youtube link for those interested

https://www.youtube.com/watch?v=kb-m2fasdDY

Does that include everybody working on autonomous driving and related 'side projects'?

Take a look at Uber's career's page. Even broken down to USA Engineering on the Engineering team hires, there are dozens and dozens of open positions. It's safe to say Uber thinks it's a > 20 person job.

https://www.uber.com/careers/list/?city=all&country=united-s...

I agree with you and parent that it is (and should) be a > 20 person job for its scale, but the career page is probably not the best example.

Many of those positions are perpetually open or rotated periodically (see: "You're leaking trade secrets" by Michael Schrenk) while the actual position was given to someone internal or someone connected to someone else internal to the firm.

Most of these pages are used for resume harvesting so that [if the firm has resources] an HR or technical recruiter can periodically evaluate the rest of the field. The firms holding out for the "rock star" often are more aggressive in recruiting them (whether at Job fairs or through LinkedIn headhunting).

They have an Android app, an iOS app, driver management system, fleet management system, ride tracking system, ride scheduling, navigation system (not sure if this is 3rd party or in-house), payment processing, profile system for both riders and drivers, price calculation system, and probably a bunch of other stuff in the background.

All this must work correctly and reliably in the 400+ cities they're operating in. To me at least, 20 developers is not enough to develop and maintain that many interconnected systems. I would say 100s at the very least.

20 people is more than enough to build and support these things...

Are you serious? With many 9s of uptime, low latency requirements and hundreds of millions of dollars in revenue on the line? Uber employs over 2k developers right now.

Don't forget cars that drive themselves

I'm not sure just because you mentioned 400+ cities they need as many developers as cities they operate in.

Did you read the article? In it, the author discusses the engineering issues that arise from trying to deal tackling problems in different languages. Now, granted, Uber in this particular thread of discussion does not have to deal with tokenization issues of Japanese/Chinese character search strings but I think it is naive to not think that the nuances of individual communities of 400+ cities intra-country, let alone dealing with separate nations, will add significant engineering overhead... (even if the relationship is not linear)

Reply on news.ycombinator.com