soontimes

6 ms·

1.
by soontimes 8d ago
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 have luck in putting i
2.
by soontimes 1mo ago
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 — what happens
3.
by soontimes 1mo ago
> 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 journaling. If yo
4.
by soontimes 1mo ago
> 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 error out be
5.
by soontimes 1mo ago
> 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
6.
by soontimes 1mo ago
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 creates contention for
7.
by soontimes 1mo ago
> 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 to avoid rac
8.
by soontimes 1mo ago
> 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 our case), and moves
9.
by soontimes 1mo ago
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?
10.
by soontimes 1mo ago
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 to take a lock on a
11.
by soontimes 1mo ago
> Instead of having 1000 rows per shop SKU, why not just have one row per shopping cart SKU? At what point that row is inserted?
12.
by soontimes 1mo ago
Yes, the point is to spread contention across multiple rows. They also mention this in the beginning of the article
13.
by soontimes 1mo ago
Can you clarify why this involves no locking? There can still be 2 actors fighting for the same row.
14.
by soontimes 9mo ago
If that’s your website please check GitHub link - it has a typo (gitub) and goes to a malicious site
15.
by soontimes 10mo ago
I like your style - clear, on point, and no attempts to sell me anything. It’s honestly refreshing to read
16.
by soontimes 1y ago
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 spreadsheets tend to