4 ms·

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 to

by Cyph0n 10y ago

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.

new299 10y ago
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.
- Cyph0n 10y ago
  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.
  - problems 10y ago
    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.
    - Cyph0n 10y ago
      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!
rtkwe 10y ago
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.
- Cyph0n 10y ago
  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.
deleted 10y ago
[deleted]

by Cyph0n 10y ago

new299 10y ago

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.

Cyph0n 10y ago
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.
- problems 10y ago
  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.
  - Cyph0n 10y ago
    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!

rtkwe 10y ago

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.

Cyph0n 10y ago
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.

deleted 10y ago

[deleted]