Why does your ecommerce site break exactly when it matters?

Knowledge Note

Peak events rarely create failures; they tend to reveal a constraint that was already present — usually in checkout writes, inventory truth or a synchronous dependency nobody owns.

One current Cralgo reading of this question — based on technical reasoning, observed situations, and open to revision as context or evidence changes.

The current reading

• Scaling the storefront rarely helps, because the storefront is seldom the constraint.
• Most peak failures trace to one of four places: checkout write contention, inventory truth, a third-party synchronous call, or a shared database under mixed workloads.
• The cost of a failed peak is not the lost hour; it is the customer who does not return.
• Preparation is an operating discipline — load modelling, failure drills, degradation paths — not an infrastructure purchase.

What this usually looks like

The campaign works. Traffic arrives. Pages load, and then carts fail, or payments time out, or the catalogue shows stock that no longer exists. Engineering scales servers; the failure moves somewhere else.

Afterwards there is a post-mortem, a fix for the specific symptom, and a quiet expectation that next year will be similar.

What is actually happening underneath

Read traffic is easy to scale. Write traffic is not. A peak event compresses a month of writes — carts, orders, inventory decrements, payment callbacks — into a few hours, and writes contend on shared state.

Meanwhile, most commerce stacks contain at least one synchronous call to a system that was never designed for your peak: a tax service, a fraud check, a warehouse API, a loyalty lookup. Under normal load it adds fifty milliseconds. Under peak it adds a queue, and the queue becomes an outage.

The third pattern is inventory truth. When stock exists in three systems with eventual reconciliation, peak velocity turns a tolerable lag into oversells and cancellations — which damage the brand long after the site recovered.

• Checkout contention

  Write hotspots on orders, carts and inventory rows.

• Synchronous third parties

  Any external call in the critical path with no timeout, fallback or circuit breaker.

• Inventory truth

  No single authoritative source, reconciled too slowly for peak velocity.

• Shared workloads

  Reporting, batch jobs and transactions competing for the same database.

What the failure mode tells you

Symptom Usual cause Fix that moves the problem First move worth examining Pages fine, checkout fails Write contention or payment dependency More web servers Isolate the checkout write path and its dependencies Oversells and cancellations Inventory truth distributed Manual buffers Establish one authoritative source with explicit reservation Intermittent slowness everywhere Shared database under mixed load Caching everything Separate transactional from analytical workloads Fails ten minutes in, then recovers Queue build-up on a synchronous call Retry logic Timeouts, circuit breakers and a defined degraded mode

What preparation tends to involve

The organisations Cralgo has watched stop failing at peak tend to do three unglamorous things. They model the load in terms of writes rather than visitors. They rehearse the failure before the event. And they decide in advance what they are willing to switch off.

That last point is the one most often missing. A degraded checkout that takes orders is worth more than a complete experience that stops. Deciding that during the event is too late.

• Load model

  Orders per minute at peak, not sessions. Derive write volume from that.

• Failure rehearsal

  Deliberately fail each dependency in a controlled environment and observe the blast radius.

• Degradation path

  An agreed, pre-approved list of what is disabled and in what order.

Why it recurs annually

Because the post-mortem produces a fix rather than a standard. The specific symptom is addressed; the class is not; and next year's growth finds the next weakest link.

Peak readiness becomes durable only when it is part of how the organisation works — a standard applied to every new dependency — rather than a project that happens each autumn.

Before your next peak

List every synchronous external call in the checkout path and, for each, write down the timeout and the behaviour when it is exceeded. Where either is unknown, you have found your next failure.

If your peaks are still comfortable

If your peak is only two or three times your normal day, architecture is unlikely to be your constraint. Spend the attention on demand and merchandising instead.

What this reading rests on

technical reasoning, observed situations

Why it stays contextual

Technology × Organisations — the answer moves with the people and the environment, not only the technology.

What this note is not

A universal answer, a best-practice list, or evidence. It is a reusable reading that should be tested against your own situation.

What remains open

• Whether these four failure classes describe newer commerce architectures or only the ones observed so far.

What would change this reading

• Peak failures that trace primarily to read traffic or storefront capacity rather than to writes and dependencies.

Related reading at Cralgo

Architectures The D2C operating model

These informed the reading. They do not prove it.

Continue the reasoning

Do we need an order management system? Headless commerce, or not? Who should own your D2C technology?

This is a current reading, not a final answer.

Back to KnowledgeExplore related Research Work with Cralgo