soontimes

I agree with your point about great narrowing, but I also expect complexity to increase accordingly. Yes, in the past you needed 10 engineers to solve a problem, and now you need only 2. How I see this - problems will become more complicated, so that you still need 10 engineers to maintain your business profitable and competitive.

I do not believe in PM making good engineering solutions, even with AI. Similarly to engineers, not interested in product, products have no interest in engineering. However you still need someone responsible for the decisions.

One possible future I’m considering is humanity converging to a “unit of responsibility” - in order to run a company with a certain scale you’ll need to have N humans responsible for different parts of the business.

It is common, and you can resist (risking your salary), going deeper (hardening engineering skills) or wider (doing product, analytical, etc. work). I believe that an engineer with product mindset is extremely valuable for a company, so I would encourage taking that route. However I’m also seeing engineers taking first or second path.

As long as humans are making decisions, human interaction remains important. From this perspective, PMs are still in a better position than engineers

Product managers is not just about making product features. It’s a job that requires lots of human interaction, and this part is notoriously complicated for engineers. Article states that a person coding the feature can build a product intuition, and that’s true, product is not sorcery, but from my experience most engineers are just not interested in that. That may change, of course, if engineers will be pressured by economic situation, but until that they’re happy when someone else is interacting with users and stakeholders.

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 it to skill / md files, as agent just ignores it after a couple of iterations. The solution is not perfect, sometimes it compresses too much, and I have to reread both versions, but at least I don’t have to read load bearing stuff anymore

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 if we open a new shop, raise prices, take a loan. We also generate reports: weekly overviews, anomaly detection, deviations from targets. All of this is essentially a harness for an AI agent that customizes the platform for a specific business and integrates its data sources. Large companies have dedicated teams and sophisticated tooling for this; my bet is that small and medium businesses would benefit just as much, and with recent progress in AI it's finally possible to deliver it tailored to each case at very low cost.

My primary target right now is e-commerce due to rich data streams, however if you think your business would benefit from this tool, I would be happy to connect and discuss it.

> 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 you have established workflows with MySQL and a team knowing how to work with it, throwing all that to do LMAX is not cost efficient. While there are domains where such approach is suitable and even required due to strict transaction ordering, Shopify case doesn’t look like one of them.

> 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 before the replenishment process succeeds?

They explicitly cover this in the article, saying they do reservation inline. It does increase latency for these orders, but it doesn’t result in an error

> But you can have a batch transaction whereby the transaction decreases inventory by 100 (thus touching the high-contention inventory row once) and credits each of 100 different customer cart database rows (which are not under heavy contention and can be on a different disk entirely).

They mention this as well, checkout batching increased implementation complexity.

> Arguing that "slow reservations trigger throttling and a worse buyer experience", without an actual number for what counts as "slow" to serve as an SLO and as a design target, is a cop-out inviting over-engineering.

True. The article would’ve been better if they included such numbers. However the fact that they didn’t mention this doesn’t imply they haven’t done research. I haven’t found anything related to checkout specifically, however there are in general articles, indicating that increased latency correlates with revenue drop.

> 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 creates contention for “remaining item quantity” resource. Their solution spreads this contention across several rows.

> Also, I wonder why they could not have a row status (available/reserved) and UPDATE it instead of deleting the rows.

This requires a row per item unit, doesn’t it? If you have 50k units you’ll have to track status of every item, meaning 50k rows. They also mention this as a rationale to use at most 1k rows, and treat it as a buffer.

> 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 races you need to insert reservation and decrement availability atomically. Your proposed approach is not atomic. For it to be atomic you will need to lock whole range, to make sure no new rows appeared between the points “check for availability” and “record reservation”. Actors will be effectively competing for the single aggregate row. This is the same as having a single inventory row with quantity field, which they rejected in the beginning of the article

> now let's think again, do we need to lock 900 rows to place order on 900 items? or can we insert a single row where order_quantity=900 ?

In the proposed schema nobody is waiting for these locks, they’re skipped by concurrent queries. In your schema actors would have to wait before they can insert without breaking invariants.

> 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 rows to another table. Second query scans the table, finds no rows (even if first one hasn’t finished yet, the row is locked and ignored), checks if it can increase buffer, finds out that it’s fully sold and aborts. Db guarantees that you can’t oversold.

> my design is the same, except it does not need this dance with moving rows between tables, locking them, and the cludge with replenishment process.

I can’t evaluate whether it’s the same or not, because you still haven’t clarified when exactly you’re going to insert the row. In the article they’re inserting in the same transaction. Would you also do it in the transaction? Because if you’ll introduce a separate global mechanism to resolve conflicts, on a high level it would be the same as their approach with redis (you need to have 2 systems)

EDIT: wording

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 to take a lock on a single row every time, and only do it when buffer is empty

> 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