2 ms·

You're still not getting the facts correct. I apologize for not being more clear. I was at the right place at the right time. Uber assumed I wasn't because my

You're still not getting the facts correct. I apologize for not being more clear. I was at the right place at the right time. Uber assumed I wasn't because my phone ran out of juice. Reality is that in a case of a literal network partition, Uber says, "Fuck you. And by the way, pay us 5 dollars."

sulam 10y ago
Fair enough. The way I read the story you ordered an Uber, your phone died, and you don't remember anything else until you woke up the next morning. I assumed it was likely that you weren't where you ordered the car when it arrived. Since you were in the right place, you shouldn't have been charged, and I agree Uber is wrong how they treat this. The phone dying case is an interesting twist because the driver couldn't call you, but s/he shouldn't have needed to.
- ianamartin 10y ago
  That's the point I was trying to make. If you experience a literal network partition between the driver and the rider, what should be the correct response from Uber? I was definitely in the right place, but my phone died. Is it the correct response to assume the rider is either not at the right place or was and has moved on? I don't think that's the right approach. We wouldn't do that with a distributed system. A node in a network that isn't getting response from other nodes--particularly slave nodes--doesn't mean the node is down. It might just be busy with something else. You don't know. Assuming that it's not accepting data is the wrong way to handle this scenario. It's a problem. In this case, I'd call it a committed write that wasn't successfully transmitted to the rest of the system. I was told a driver was on the way. I was there, and the partition tolerance said, "Aww fuck this guy." to Uber's system. That's pretty bad. If you want to think of it in human terms or in business terms, that's fine. But I think that CAP theorem is the best way to handle these situations from a tech point of view. The driver didn't need to contact me. All the driver had to do was go to the agreed location and pick me up. But Uber prevented that by cancelling the trip when my phone was no longer in service. That seems broken to me.

sulam 10y ago

Fair enough. The way I read the story you ordered an Uber, your phone died, and you don't remember anything else until you woke up the next morning. I assumed it was likely that you weren't where you ordered the car when it arrived. Since you were in the right place, you shouldn't have been charged, and I agree Uber is wrong how they treat this. The phone dying case is an interesting twist because the driver couldn't call you, but s/he shouldn't have needed to.

ianamartin 10y ago
That's the point I was trying to make. If you experience a literal network partition between the driver and the rider, what should be the correct response from Uber? I was definitely in the right place, but my phone died. Is it the correct response to assume the rider is either not at the right place or was and has moved on? I don't think that's the right approach. We wouldn't do that with a distributed system. A node in a network that isn't getting response from other nodes--particularly slave nodes--doesn't mean the node is down. It might just be busy with something else. You don't know. Assuming that it's not accepting data is the wrong way to handle this scenario. It's a problem. In this case, I'd call it a committed write that wasn't successfully transmitted to the rest of the system. I was told a driver was on the way. I was there, and the partition tolerance said, "Aww fuck this guy." to Uber's system. That's pretty bad. If you want to think of it in human terms or in business terms, that's fine. But I think that CAP theorem is the best way to handle these situations from a tech point of view. The driver didn't need to contact me. All the driver had to do was go to the agreed location and pick me up. But Uber prevented that by cancelling the trip when my phone was no longer in service. That seems broken to me.