I have such hook, and it works well. It increases time, but it’s negligible if agent works for 10+ mins before the final output. The hook is only on stop event, so agent is not interrupted during the session. I didn’t…
I'm working on a platform that aggregates a business's operational and financial data and builds a causal model on top, deriving target metrics like FCF or EBITDA. With that model we can forecast different scenarios —…
> re concurrency, it is not a big issue at all > LMAX Disruptor If anything this article shows that concurrency is a big issue. It is such a big issue you have to write in-memory single threaded processor with custom…
> But if a seller has 5k inventory in one location, has a spike of 2k orders, but only 1k of the orders can successfully reserve inventory, then isn't that an argument that you lost the revenue of the 2nd 1k orders that…
> re concurrency, it is not a big issue at all I would really appreciate it if you could write this up as an article. It would be an extremely interesting and valuable read
They never said they don’t shard it, however this doesn’t solve the problem they were facing. Even if they have a single store (therefore a single shard), the burst demand may be high for the item in that shop, which…
> if I were to solve the problem, I would have solved it differently, at the Checkout state, before user clicks PAY. This removes the race condition at the user UI level, before any request lands in backend/db: In order…
> how does current design resolve concurrent actors fighting for the last item ? It resolves with skip locked. Assuming we have only 1 item left. First query scans the buffer table, locks as many rows as needed (1 in…
I don’t understand how this should prevent oversold. You have a check that reports empty or oversold inventory. But how does that check prevent 2 concurrent actors fighting for the last item from inserting 2 rows?
Ok, but before inserting you must ensure that inventory is not depleted, which means you need to know the count and you need to lock the row. So you still have contention on that item. Them having a 1k buffer allows not…
> Instead of having 1000 rows per shopSKU, why not just have one row per shopping cartSKU? At what point that row is inserted?
Yes, the point is to spread contention across multiple rows. They also mention this in the beginning of the article
Can you clarify why this involves no locking? There can still be 2 actors fighting for the same row.
If that’s your website please check GitHub link - it has a typo (gitub) and goes to a malicious site
I like your style - clear, on point, and no attempts to sell me anything. It’s honestly refreshing to read
I noticed this for some companies: there are 10+ spreadsheets which should have the same structure, but different data. For example one spreadsheet per country for purposes of budgeting, modeling, or just inputs. These…
I have such hook, and it works well. It increases time, but it’s negligible if agent works for 10+ mins before the final output. The hook is only on stop event, so agent is not interrupted during the session. I didn’t…
I'm working on a platform that aggregates a business's operational and financial data and builds a causal model on top, deriving target metrics like FCF or EBITDA. With that model we can forecast different scenarios —…
> re concurrency, it is not a big issue at all > LMAX Disruptor If anything this article shows that concurrency is a big issue. It is such a big issue you have to write in-memory single threaded processor with custom…
> But if a seller has 5k inventory in one location, has a spike of 2k orders, but only 1k of the orders can successfully reserve inventory, then isn't that an argument that you lost the revenue of the 2nd 1k orders that…
> re concurrency, it is not a big issue at all I would really appreciate it if you could write this up as an article. It would be an extremely interesting and valuable read
They never said they don’t shard it, however this doesn’t solve the problem they were facing. Even if they have a single store (therefore a single shard), the burst demand may be high for the item in that shop, which…
> if I were to solve the problem, I would have solved it differently, at the Checkout state, before user clicks PAY. This removes the race condition at the user UI level, before any request lands in backend/db: In order…
> how does current design resolve concurrent actors fighting for the last item ? It resolves with skip locked. Assuming we have only 1 item left. First query scans the buffer table, locks as many rows as needed (1 in…
I don’t understand how this should prevent oversold. You have a check that reports empty or oversold inventory. But how does that check prevent 2 concurrent actors fighting for the last item from inserting 2 rows?
Ok, but before inserting you must ensure that inventory is not depleted, which means you need to know the count and you need to lock the row. So you still have contention on that item. Them having a 1k buffer allows not…
> Instead of having 1000 rows per shopSKU, why not just have one row per shopping cartSKU? At what point that row is inserted?
Yes, the point is to spread contention across multiple rows. They also mention this in the beginning of the article
Can you clarify why this involves no locking? There can still be 2 actors fighting for the same row.
If that’s your website please check GitHub link - it has a typo (gitub) and goes to a malicious site
I like your style - clear, on point, and no attempts to sell me anything. It’s honestly refreshing to read
I noticed this for some companies: there are 10+ spreadsheets which should have the same structure, but different data. For example one spreadsheet per country for purposes of budgeting, modeling, or just inputs. These…