6 ms·

> Shopify incorrectly formulated the very problem they are trying to solve. That’s a bold overconfident statement. Cart abandonment is real. People never clea

> Shopify incorrectly formulated the very problem they are trying to solve. That’s a bold overconfident statement. Cart abandonment is real. People never clear their carts they just walk away Shopify purposefully chooses to do it at payment time because doing it earlier results in lost sales as people “reserve” items and then walk away causing other to see out of stock and then also walk away Whoever puts up the money first gets the item That’s the design constraint they chose you can’t just say “their solution is wrong because they solved the wrong problem”. Each design is a different user experience and I think it’s safe to say they chose which experience they want consciously.

bijowo1676 1mo ago
that's why I mentioned active carts in my post, there are ways to define active cart to get rid of abandoned carts ( ignore carts where last user action was > N seconds ago). Ok, let's accept the design goal that whoever paid first wins. You can use the same metric (how many milliseconds ago did user click PAY) and impose a global monotonic non-decreasing counter to distribute the scarce inventory. This is how order matching engines work at stock exchanges with HFT orders (FIFO logic). the goal is to know with 100% certainty, before sending payment request to payment processor, who will have item and who won't, and you dont need to move mountains of rows for that. the payment processor should be just a binary answer: payment succeeded or not, but currently it combines Inventory availability check & payment processing, which is the root cause of confusion. For clarity it is better to make that stage of order processing an explicit separage stage, instead of coupling it with payment stage. some stores split payment into two stages: Payment and Final order confirmation. at the Payment stage you can pre-authorize money at cc and do inventory availability, and at final confirmation you capture $$
- hanikesn 1mo ago
  Most payment methods in the world don't support separate authorization and capture.
  - deleted 1mo ago
    [deleted]
  - bijowo1676 1mo ago
    i dont know about the world, by authorize.net and Stripe, which work globally and work with global credit cards, they do support separate authorize and separate capture, which seems to be part of PCI standard https://docs.stripe.com/payments/place-a-hold-on-a-payment-method https://docs.stripe.com/payments/place-a-hold-on-a-payment-m... https://support.authorize.net/knowledgebase/Knowledgearticle/?code=000001346 https://support.authorize.net/knowledgebase/Knowledgearticle...
    - deleted 1mo ago
      [deleted]
    - hanikesn 1mo ago
      You'll quickly realize PCI mainly applies to the credit card industry and not to something like Europe's psd2 and sepa instant.
- admax88qqq 1mo ago
  why a non-decreasing counter? Looking at your solution, if i understand it, is instead of decreasing the inventory count for each sku as orders are processed, you are comparing the current warehouse quantity against the sum of all carts to see if there's availbale quantity. You'll have to also include the sum of all completed orders so far. Honestly seems almost worse? Arn't you trading contention on a single counter (inventory) for a large read across all pending and completed orders? Even indexed you're ingesting a ton more data? And you'll still need a lock here as you have to ensure two orders do this check at the same time. Naive design - Single inventory row per warehouse sku - All orders compete on a lock for all inventory sku rows in their order to deduct/claim their items Shopify design - Unroll warehouse inventory to thousands of rows per sku - Order processing races to find sufficient unlocked rows for all items in order - If insufficient rows are found then orders block behind slower "restock" process that creates more rows Your design - Warehouse inventory row is static/read-only (restocking out of scope for now that's fine). - Order processing computes the sum of all completed orders to ensure there is sufficient quantity - This would have to be under a lock as well, otherwise two or more racing orders will think there is quantity left. So sounds like in your solution, you still have a single point of contention for who is computing the sum of completed orders, and while holding that lock you are doing a sum of all completed orders for each sku in your order. That sounds... worse?

bijowo1676 1mo ago

that's why I mentioned active carts in my post, there are ways to define active cart to get rid of abandoned carts ( ignore carts where last user action was > N seconds ago). Ok, let's accept the design goal that whoever paid first wins. You can use the same metric (how many milliseconds ago did user click PAY) and impose a global monotonic non-decreasing counter to distribute the scarce inventory. This is how order matching engines work at stock exchanges with HFT orders (FIFO logic). the goal is to know with 100% certainty, before sending payment request to payment processor, who will have item and who won't, and you dont need to move mountains of rows for that. the payment processor should be just a binary answer: payment succeeded or not, but currently it combines Inventory availability check & payment processing, which is the root cause of confusion. For clarity it is better to make that stage of order processing an explicit separage stage, instead of coupling it with payment stage. some stores split payment into two stages: Payment and Final order confirmation. at the Payment stage you can pre-authorize money at cc and do inventory availability, and at final confirmation you capture $$

hanikesn 1mo ago
Most payment methods in the world don't support separate authorization and capture.
- deleted 1mo ago
  [deleted]
- bijowo1676 1mo ago
  i dont know about the world, by authorize.net and Stripe, which work globally and work with global credit cards, they do support separate authorize and separate capture, which seems to be part of PCI standard https://docs.stripe.com/payments/place-a-hold-on-a-payment-method https://docs.stripe.com/payments/place-a-hold-on-a-payment-m... https://support.authorize.net/knowledgebase/Knowledgearticle/?code=000001346 https://support.authorize.net/knowledgebase/Knowledgearticle...
  - deleted 1mo ago
    [deleted]
  - hanikesn 1mo ago
    You'll quickly realize PCI mainly applies to the credit card industry and not to something like Europe's psd2 and sepa instant.
admax88qqq 1mo ago
why a non-decreasing counter? Looking at your solution, if i understand it, is instead of decreasing the inventory count for each sku as orders are processed, you are comparing the current warehouse quantity against the sum of all carts to see if there's availbale quantity. You'll have to also include the sum of all completed orders so far. Honestly seems almost worse? Arn't you trading contention on a single counter (inventory) for a large read across all pending and completed orders? Even indexed you're ingesting a ton more data? And you'll still need a lock here as you have to ensure two orders do this check at the same time. Naive design - Single inventory row per warehouse sku - All orders compete on a lock for all inventory sku rows in their order to deduct/claim their items Shopify design - Unroll warehouse inventory to thousands of rows per sku - Order processing races to find sufficient unlocked rows for all items in order - If insufficient rows are found then orders block behind slower "restock" process that creates more rows Your design - Warehouse inventory row is static/read-only (restocking out of scope for now that's fine). - Order processing computes the sum of all completed orders to ensure there is sufficient quantity - This would have to be under a lock as well, otherwise two or more racing orders will think there is quantity left. So sounds like in your solution, you still have a single point of contention for who is computing the sum of completed orders, and while holding that lock you are doing a sum of all completed orders for each sku in your order. That sounds... worse?