3 ms·
Uber is mentioned here as an interesting case of treating the edge device as the source of truth, which was interesting to read about a little while ago. Howeve
by dikaiosune 11y ago
Uber is mentioned here as an interesting case of treating the edge device as the source of truth, which was interesting to read about a little while ago. However, Uber has a certain amount of guaranteed control over driver phones, and even then I imagine that it represents a pretty promising attack vector into their systems.
How would this system work when treating untrusted clients executing arbitrary code as the definite source of truth for a fact? Further, it doesn't seem like this addresses (unless I'm missing something) the problem raised in the airline ticket example where split-brain systems may hand out resource reservations that they aren't actually allowed to give out. If both passengers' devices (or the plane? or some other edge device?) are sources of truth, I don't see any easier way to negotiate the resource contention than current distributed databases already have.
- GauntletWizard 11y agoSplit brain systems can easily deal with being disconnected: They don't give out new tickets, they don't modify system state, and they treat the data they do have as what it is: Out of date. An airline reservation system shouldn't be able to give out multiple conflicting tickets, because it doesn't have a lock on them; RAFT and PAXOS are designed to combat precisely this. However, in the real world, waiting for consensus before making decisions is hard, so airline systems, designed in the era before realtime communication back to the mothership was possible, faked it. They made a reservation, issued a ticket, and then the airline developed protocols to deal with the resulting overbooking. In fact, since airlines already had incentive to overbook and deal with overbooking because of no-shows, they simply built the failures of their locking system into their cost-models. There is a 'correct' solution to this: When you believe you're going to be split-brained some of the time, pre-allocate tickets to entities. Those entities can use their local tickets, but cannot make use of remote tickets without approving them with the systems that own them. Sharding the state of the plane down to individual seats has system complexity cost, but allows perfect booking.
- deleted 11y ago[deleted]
- fallous 11y agoChanging behavior in split brain systems requires an understanding of the fact that the brain is in fact split. And even if you design the system to operate in your 'correct' solution, you may still result in imperfect booking if one side of the split exhausts its pre-allocated tickets and reports as unavailable when other sections of the system still have available tickets.