Hacker News new | past | comments | ask | show | jobs | submit login

Ignoring the rest of your story, which is interesting and weird, I think your analogy to CAP breaks down fast. The driver cannot roll back their time spent. You called them to a spot, presumably they went there and you weren't there. They are out their time, it's gone. Any number of bad things could have happened to you, but the user agreement is that if you don't show, you pay.



Based on the assumption that he wasn't actually where he was supposed to be. I've had several cancellations from drivers, when being worse for wear, for not being where I'm supposed to be even when I've not moved and seen the car drive past without a phonecall. Probably don't want the hassle of a half-cut passenger, but it's a nuisance from their end. Do they get a cut of the charge?


I think they do -- and agreed it's a problem when it's their fault. That's what the call button is for after all.


CAP theorem doesn't address rollbacks. That's an implementation detail for the admins to work out based on the results of how a particular distributed system addresses Consistency, Availability, and Partition tolerance.

User agreements are irrelevant--or at least a cheap cop out--for defining how a distributed system behaves in failure cases. In this particular case, I was where I was supposed to be, but I had an actual network partition event. My phone died. It's not really an analogy at this point. It's an actual P partition event. And Uber's default choice in that case is to assume the rider is no longer there. That's a bad practice, in reality.

No one would tolerate a data store that behaves this way.

It should be obvious that a network of drivers and riders and a coordinating piece of software that links the two of them up has every characteristic of a distributed network.


So, you're saying the driver should have waited patiently for you to wake up, and then the network would have become consistent? While the CAP theorem says nothing about rollbacks, application of the concepts of CAP certainly involve rollbacks, eventual consistency, or data loss. Perhaps if we are to take your analogy literally, the data loss is your money? But if you don't want that, you have to present an alternative. You are doing a poor job of convincing me that you truly believe this is a literal event.

Instead of considering an abstract CS theory, let's talk about reality. Reality is that you ordered a service and then weren't Available to receive that service, so the other Party was due some of your Cash because that's the user agreement you signed. Saying this is a copout won't get you very far in the real world of law.


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."


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.


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: