4 ms·

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 d

by 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!

by new299 10y ago

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!