Pinwheel.
All Articles
Headless CommerceFloristPerformanceNext.jsPeak Traffic

Valentine's Day and Mother's Day: How Headless Florists Handle Traffic Spikes Without Crashing

Peak periods can be 10x your normal order volume — compressed into 48 hours. Most florist platforms weren't built for this. Here's how headless architecture handles it, and what happens to sites that aren't ready.

PinwheelEngineering Team, Pinwheel Media Ltd
·1 June 2026·5 min read

Valentine's Day doesn't ramp up slowly. At midnight on the 13th of February, florist websites go from normal background traffic to their highest volume of the year. In the space of 36 hours.

For businesses on modern infrastructure, this is unremarkable. For businesses on shared WordPress hosting with a WooCommerce installation, it can be the most stressful 48 hours of the year — slow pages, failed checkouts, and orders that disappeared into a processing queue and never confirmed.

This post explains why the gap exists and what headless architecture actually does differently.

What Happens to WordPress Under Peak Load

WordPress and WooCommerce are synchronous, server-rendered applications. Every page request triggers a database query. Every product load, every cart update, every checkout step: database in, page out, browser waits.

Under normal traffic, this is fine. Under 10x normal traffic, the database becomes the bottleneck. Query queue length increases. Response times go up. For customers on slow connections or mobile (the majority of florist traffic), a 3-second page load becomes 8 seconds. A 2-second checkout step becomes a timeout.

The consequences are direct:

  • Cart abandonment increases — customers who waited and got a timeout don't come back. Valentine's Day is time-sensitive. If your site is slow at 11pm on the 13th, they'll order from a competitor.
  • Inventory oversells — under database stress, race conditions in WooCommerce's stock management logic can result in the same item being sold to two customers simultaneously.
  • Orders fail silently — payment confirmation pages that time out sometimes result in a charge being processed but no order being created in WooCommerce. The customer thinks they have an order. You don't have it.

Hosting upgrades help but don't solve the underlying architecture. You're still making the same database calls; you're just making them from a faster server.

How Headless Architecture Handles It

A headless storefront built on Next.js with a Medusa.js backend works differently at every layer.

Pre-rendered Pages

Product pages, category pages, and the homepage are generated at build time as static HTML. There is no database query at page load time. A customer visiting your Valentine's Day collection page gets a file that was generated once and is now served from a CDN — the same file, instantly, to every visitor simultaneously.

This is the core difference. A WordPress product page under load degrades linearly — more visitors means more database queries means slower responses. A pre-rendered headless page doesn't degrade at all. It's a file. Files don't slow down.

Edge Caching

Vercel's edge network distributes your static pages across data centres globally. A customer in Manchester and a customer in London get the same product page served from their nearest edge node. There is no single origin server that can become a bottleneck.

API Calls Only Where Needed

The only parts of a headless checkout that hit the Medusa backend are the operations that genuinely require live data: adding to cart, checking stock, processing payment. Everything else — browsing, searching, reading product descriptions — is static.

This means your backend infrastructure handles a fraction of the requests that a WordPress installation would handle under equivalent traffic, because most of the site never touches the backend at all.

Stock Management That Doesn't Race

Medusa v2 handles inventory transactions at the database level using proper write locking. When two customers attempt to buy the last unit of a product simultaneously, the second transaction fails cleanly and the customer receives a sold-out message — rather than both transactions succeeding and you having to call one of them to explain that their Valentine's Day gift isn't actually coming.

What Florist Platform Users Experience

If you're on Florist Touch, Florist Pro, or Florist Window, your architecture sits between hosted WordPress and a shared SaaS platform. The characteristics vary by provider, but the shared pattern is: more load means more contention for shared resources.

Most of these platforms have improved their infrastructure significantly in recent years. The question isn't whether they work under normal load — they do. The question is what happens when your particular account gets 500 visitors simultaneously at 11pm on Valentine's Eve, and whether the platform's shared infrastructure was resourced for that scenario.

The answer depends on your plan tier, your provider's current infrastructure investment, and whether their other customers are also having a peak at the same time (they are — it's Valentine's Day for everyone).

The advantage of owning your own infrastructure, even at modest Railway costs (£80/month for Medusa + PostgreSQL), is that your headroom is your own. You're not competing with other florists on the same server during the most valuable 48 hours of your year.

The Practical Checklist for Peak Periods

Regardless of your platform, these are the checks that matter in the two weeks before a major peak:

Performance:

  • Run your homepage and top product pages through PageSpeed Insights. Anything below 70 on mobile is a risk.
  • Load test your checkout flow — even a simple one using a friend with a mobile connection in a different location.

Stock management:

  • Set up low-stock alerts if your platform supports them, so you know before you sell out.
  • Build a buffer — decide in advance what inventory threshold triggers "sold out" on your site versus your actual zero-stock point.

Order notifications:

  • Know exactly where your order notifications go and test that they arrive. If your notification email lands in a spam folder during a 2am order wave, you won't know until morning.

Contingency:

  • Have a plan for what to tell customers if something goes wrong. A short banner that says "High demand — allow up to 2 minutes for order confirmation" is better than silence.

If your platform has let you down during a previous peak, that's worth taking seriously. A site that fails under Valentine's Day traffic isn't failing because of the traffic — it's failing because the infrastructure wasn't built for it.

Our ROI calculator will show you what a Medusa.js headless build costs versus your current platform, including the payback period. If you want to understand what a purpose-built florist platform looks like, start here.

About the author

Pinwheel

Engineering Team, Pinwheel Media Ltd

Pinwheel is a UK web design and engineering agency specialising in headless e-commerce, bespoke website builds, and business automation systems. Based in Surrey, we've delivered 100+ projects for UK businesses since 2015 — from local service websites to complex multi-tenant commerce platforms.

● Ready to Build?

Let's Build SomethingRemarkable.

Whether it's a headless commerce platform, a bespoke automation system, or a high-performance web presence — we'd love to hear about it.