Medusa Under Black Friday Load

You cannot generate Black Friday on one laptop, and any benchmark claiming otherwise is inventing numbers.

But you don't have to. This is exactly what horizontal scaling is for. If one copy of Medusa handles a certain amount of work, and adding copies keeps increasing the total, then reaching Black Friday volume becomes a matter of running enough copies — a question of budget and architecture rather than a limit in the software. So the useful test isn't "can one laptop survive a million shoppers." It's "when we add copies, does the total keep going up?" That I can measure honestly.

Every copy we added finished more orders than the fleet before it. Nothing plateaued and nothing went backwards. That is the answer to the question: Black Friday volume is reachable by running more copies, so it's a matter of provisioning rather than a wall in the platform.

The one imperfection is that five copies gave 3.5× rather than a full 5×. That gap isn't Medusa falling short — it's the result of a deliberate choice we made in how we built the test, and question 5 shows exactly what it was and how to fix it.

This is the scenario every commerce engineer has a bad dream about: more buyers than stock, everyone clicking at the same instant.

The danger is overselling — taking payment for items you don't actually have. It happens because two customers can read the stock count at the same moment, before either has finished buying.

Medusa does this for you. Its checkout takes the lock, reserves the stock, and either commits the reservation when the order completes or gives it back if anything fails. We wrote none of that.

The one thing we configured was where Medusa keeps its locks. With five separate copies of Medusa running, a lock held in one copy's own memory would be invisible to the other four — and they'd happily oversell around it. So Medusa is pointed at Redis, which all five copies share. Redis is the single notebook every copy writes its locks into, so a lock taken by copy #1 is immediately visible to copy #4.

To test it, I sent 40 shoppers making 80 purchase attempts at one product holding exactly 5 units — spread across three separate copies of Medusa, so the copies genuinely had to coordinate through Redis rather than just with themselves.

Checked directly in the database afterwards: five units stocked, five reserved, exactly five order lines. The 75 unsuccessful shoppers got a proper "out of stock" response — not a timeout, and not a half-created order.

Payment is the step everyone assumes is the slow one. I timed each of the nine steps separately to find out.

The reason picking a shipping method costs so much is worth knowing, because it's the same thing that makes the whole checkout expensive. Medusa runs every checkout step as a workflow — a recorded sequence of operations. As each step runs, Medusa writes its progress to the database, so that if something fails halfway through, it knows exactly what to undo. That's what stops a failed checkout leaving a half-made order behind, and it's the machinery behind the clean rollbacks in question 7.

It isn't free. Looking at which queries consumed the most database time across the whole test, updating workflow progress was the single most expensive query of all — and the workflow table was read more than four thousand times across 126 checkouts. Roughly 36 database operations per checkout exist purely so Medusa can undo the order safely. That's a deliberate trade: some speed, in exchange for never leaving the data in a broken state.

There's also a design reason payment is so cheap here, and it's worth understanding because it holds true in production too. Medusa doesn't wait for the payment to clear before finishing the order. It creates a payment session, completes the order, and then the payment provider confirms separately a moment later. So even when the provider is slow, that slowness sits in one isolated step instead of holding the whole checkout open.

What this test does and doesn't tell you. We used Medusa's built-in test payment provider, which approves instantly without contacting anyone. So these numbers measure Medusa's side of payment — the work it does to create and record a payment — and that side is genuinely fast and well-designed. What they don't include is the trip out to Stripe or Razorpay, which typically adds a few hundred milliseconds. Adding that would push the payment step up, but it wouldn't change the ranking: payment would still be far from the most expensive part of this checkout, and thanks to the design above, a slow provider delays one step rather than everything.

Redis is a very fast store that keeps everything in memory rather than on disk. In our setup it does two jobs: it holds the inventory locks from question 2, and it caches data so Medusa doesn't have to re-fetch it. Because all five copies of Medusa share it, if Redis were slow, everything would be slow.

So the question is simply: did Redis ever struggle? One Redis instance can comfortably handle over 100,000 operations per second. Here's what we actually asked of it.

Redis was never remotely close to being a problem, and that's the right outcome. It's the one piece every copy of Medusa must share, so it needs enormous spare capacity by design. Worth monitoring; not worth worrying about.

This is the most important result, and it's a lesson about how we built the test.

We added copies of Medusa and left the database completely untouched. One PostgreSQL, two cores, default settings, from the first run to the last. Five copies of Medusa, all sending their work to the same single database.

That red bar filling up is the reason five copies gave 3.5× instead of 5×. It isn't a limitation of Medusa — it's arithmetic. Five times the traffic arrived at a database that never got any bigger.

What makes the database work so hard is that a single checkout runs about 394 database queries. Not errors — successful queries, each taking a millisecond or two. They're that numerous because Medusa is built from separate modules (products, pricing, cart, inventory, payment, orders), and each module fetches its own data rather than sharing one big combined query. Browsing 20 products alone touches products, variants, options and prices as separate lookups. On top of that, Medusa records every step of the checkout so it can undo the order safely if something fails partway. Multiply that by every copy in the fleet and the database gets busy fast.

As a quick check, I added a cache in front of the product listing so repeat browsing didn't hit the database at all. Completed checkouts rose 42% immediately. That's a useful confirmation: take load off the database, and the whole system speeds up.

The honest conclusion is that we only scaled half the system. To straighten out that curve, the database has to grow alongside Medusa.

Autoscaling means not deciding by hand how many copies to run. You set up a watcher that keeps an eye on one measurement, and when that measurement crosses a line you've drawn, it starts extra copies automatically — then shuts them down again when traffic drops. It's how a shop survives a sale without paying for a huge fleet all year.

The hard part is choosing which measurement the watcher looks at. The most common choice is database CPU — and our results show that would have been a bad decision here.

With one copy running, the database looked almost idle while customers were waiting thirteen seconds. A watcher pointed at the database would have concluded everything was fine and done nothing. Watch Medusa's CPU and how long requests are taking — those are the two that noticed immediately.

One warning that follows from question 5: every new copy also adds load to the database. So autoscaling the Medusa side without a plan for the database eventually creates the problem we hit — the extra copies meant to fix slowness are what fill the database up.

Throughput tells you how many orders you took. This tells you whether you can trust them.

A deadlock is when two operations each wait for something the other holds, and neither can ever continue — the database has to kill one of them. We had none, at any fleet size, in any run.

More importantly, the 75 shoppers who didn't get an item during the stampede were each rolled back completely. No order was created without stock behind it; no stock was set aside for an order that never existed. When I counted rows in the database afterwards, the stock and the orders agreed exactly.

That's the outcome that matters. Under heavy load this system got slower, but it never got things wrong — and those two failures are not equally bad. Slowness costs you some sales that day and is fixed by adding machines. Incorrect stock means shipping items you don't have, refunds, apologies, and customers who don't come back.