7 ms·

I once worked on a reasonably complex e-commerce system with millions of products, add-to-cart, taxes, promo codes, etc. Every so often, an order total changed

I once worked on a reasonably complex e-commerce system with millions of products, add-to-cart, taxes, promo codes, etc. Every so often, an order total changed between the time that the user saw the total on the confirmation screen and when they actually hit the button to place the order (which seems to be what happened here). This happened because of promo applicability changes, product price changes, products being de-listed, etc. But it was relatively easy to prevent problems with this. When the user clicked the button to place the order, we sent along the expected order total, the expected item IDs to purchase, the expected tax, etc. In the backend, one of the last validation step before the order was finalized was just to compare the final order details against those expected values. If there were any differences, the order was rejected with an error message to try again. There were then monitors on these types of errors which would go off if there was a higher-than-normal frequency of these sorts of errors, so we could track down any bugs causing price discrepancies. I'm kind of surprised that UberEats doesn't seem to have a similar validation step.

dmurray 5y ago
> Every so often, an order total changed between the time that the user saw the total on the confirmation screen and when they actually hit the button to place the order (which seems to be what happened here). I don't see any reason from the post to believe this kind of race condition is what happened here. Uber's CS says the promotional code used was not valid for this restaurant, but presumably the app accepted it anyway. That's also likely a validation error, but of a different class.
- dboshardy 5y ago
  > I'm kind of surprised that UberEats doesn't seem to have a similar validation step. That's what OP was saying.
- brodock 5y ago
  If I have to guess, something something microservices/event-system. One separate team handles code consumption which is not he same who handles the validation, and because its a distributed mess, it is eternally broken.
- teeray 5y ago
  > an order total changed between the time that the user saw the total on the confirmation screen and when they actually hit the button to place the order > …but presumably the app accepted it anyway… Not a lawyer, but I’m pretty sure things like this would constitute a contract. Of course, whether there’s squirrelly language in the Terms of Service is another question… EDIT: formatting

dmurray 5y ago

> Every so often, an order total changed between the time that the user saw the total on the confirmation screen and when they actually hit the button to place the order (which seems to be what happened here). I don't see any reason from the post to believe this kind of race condition is what happened here. Uber's CS says the promotional code used was not valid for this restaurant, but presumably the app accepted it anyway. That's also likely a validation error, but of a different class.

dboshardy 5y ago
> I'm kind of surprised that UberEats doesn't seem to have a similar validation step. That's what OP was saying.
brodock 5y ago
If I have to guess, something something microservices/event-system. One separate team handles code consumption which is not he same who handles the validation, and because its a distributed mess, it is eternally broken.
teeray 5y ago
> an order total changed between the time that the user saw the total on the confirmation screen and when they actually hit the button to place the order > …but presumably the app accepted it anyway… Not a lawyer, but I’m pretty sure things like this would constitute a contract. Of course, whether there’s squirrelly language in the Terms of Service is another question… EDIT: formatting