Breweries: engineering a release drop that does not fall over

Nothing else on this list has a traffic curve like a can drop. The audience knows the hour, they arrive inside the same minute, and they all try to do the single most expensive thing a website can do at the same moment.

The good news is that most of that crowd is doing something cheap. Reading the release page, looking at the beer list, checking the shipping bands — all cacheable, all served without touching PHP. A cached response never reaches the application, so a browsing surge is close to free.

The expensive part is small and concentrated: the basket, the checkout and the stock decrement. That is where a drop succeeds or fails, and it is where the measuring should be pointed.

Cart, checkout and account pages exclude themselves from caching, correctly. During a drop that means every simultaneous buyer is running real PHP and real database work, and each one is trying to decrement the same stock row, which serialises whether you want it to or not.

Two things reduce the load per buyer: fewer queries and less contention. A current PHP release and Redis object caching handle the first; a per-customer quantity limit and a handful of simple products rather than a matrix of variations handle the second. Time an add-to-basket and a checkout submission on a quiet afternoon, and you will know what each costs before a hundred of them happen at once.

In the last day, stop shipping changes. A theme edit purges the cache you spent the week warming. Take a backup, confirm you know how to restore it from the panel in minutes, and have the support route to hand — cover runs at every hour, which is the point of it on a Friday evening drop.

Afterwards, review. Cache hit rate, checkout timings, where the failures clustered. Write it down. The next release is the same problem with better information, and a brewery that keeps notes gets a smoother drop each time.