Most web applications experience demand as a curve. Traffic rises through the morning, peaks somewhere in the afternoon, tapers overnight, and capacity planning is an exercise in smoothing.
A smaller category experiences demand as a cliff. Nothing much happens for hours, then a fixture kicks off and concurrent users multiply within a minute. Ticketing platforms know this. Live streaming knows it. And sports betting platforms live it several times a week, which has made them an unusually good place to study how systems behave when the load arrives all at once.
The Shape of the Problem
The defining characteristic is not the peak height. It is how quickly you get there and how little warning the system has.
A major match produces a login surge in the minutes before kickoff, a sustained high-write period during play as odds update and wagers land, and a second sharp spike at the final whistle when settlements process and withdrawals begin. Three distinct load profiles in ninety minutes, each stressing a different part of the stack.
Worse, the schedule is public. Everyone knows when the surge is coming, including the people who might want to cause trouble during it.
Autoscaling Is Slower Than the Spike
The instinctive answer, scale horizontally on demand, runs into an inconvenient fact: instance provisioning takes time. Container start, dependency warm-up, connection pool establishment and cache population can consume minutes you do not have when the ramp is measured in seconds.
Platforms that handle this well pre-scale against a schedule rather than reacting to load. Capacity goes up before the fixture, not in response to it, and comes back down afterwards. It costs more than pure reactive scaling and it works, which is the trade every team in this position eventually makes.
The related discipline is warm-path testing. Capacity that has never served traffic is a hypothesis, not a resource. Routing a small share of live requests through newly provisioned capacity before the surge turns the hypothesis into a fact.
Where the Real Bottleneck Lives
Stateless application servers are the easy part. The difficulty concentrates in the places that hold state: the database, the cache and whatever mediates access to them.
Read pressure is manageable through replicas and aggressive caching. Write pressure is not, because writes must be durable, ordered and consistent, and every wager is a write. This is why the interesting architecture in this sector sits around write path design: partitioning by market or event so contention stays local, queuing writes with acknowledgement to the user before full settlement, and idempotency keys so a retry from a flaky mobile connection does not create a duplicate.
Anyone who has built a payments system will recognise every one of these patterns. The domain differs and the constraints do not.
Availability Under Adversarial Conditions
A predictable, high-value traffic window is also an attractive target. Denial of service activity clusters around exactly the moments when a platform can least afford degradation, and the pattern is well documented across sectors.
The Canadian Centre for Cyber Security publishes practical guidance on defending against distributed denial of service attacks, and its core points map neatly onto this problem: understand what protection your provider actually offers before you need it, confirm your service agreement covers mitigation, maintain capacity headroom rather than running lean, and rehearse the response rather than improvising it.
The last one matters most. A mitigation plan that has never been exercised tends to be discovered as incomplete at the worst possible moment, and the worst possible moment in this sector is entirely predictable.
Graceful Degradation Beats Heroic Uptime
The design principle separating mature platforms from fragile ones is the ability to shed non-essential function without falling over.
Under severe load, a well-built system keeps the core transaction path alive and sacrifices everything else: live streaming quality drops, statistics panels stop refreshing, personalisation falls back to defaults, and secondary features go dark. The user notices something is simpler than usual. They do not notice an outage.
Building this requires deciding in advance which features are load-bearing and which are decoration, and wiring feature flags so the decision can be executed in seconds by whoever is on call. That conversation is uncomfortable because product owners rarely want to hear that their feature is in the sacrificial tier, and it is far better held in a planning meeting than during an incident.
Latency Is a Correctness Problem Here
In most applications, slow is annoying. In real-time wagering, slow is wrong, because a price that has moved is a price that should no longer be accepted.
This produces engineering constraints that read strangely from the outside. Requests carry timestamps and are rejected if stale. Price versions are checked at acceptance rather than at display. A wager submitted against an odds version the platform has already retired is declined rather than honoured, which occasionally frustrates users and is the only defensible behaviour.
A platform such as this betting website is running that check on every submission during a busy fixture, at volume, with a hard latency budget, and getting it right consistently is a genuine engineering achievement rather than a routine one.
Observability Has to Be Faster Than the Event
Monitoring built for a ninety-second incident looks different from monitoring built for a gradual degradation.
One-minute aggregation windows are useless when the whole event lasts two minutes. Dashboards that require interpretation are useless when the person reading them is also executing a runbook. What works is a small number of leading indicators at second-level granularity, alerting on rate of change rather than on absolute thresholds, and one screen that answers the only question that matters: is the core path healthy.
Everything else can be reviewed afterwards, and afterwards is when the deep analysis should happen anyway.
The Transferable Version
Strip out the domain and the pattern applies to product launches, ticket on-sales, flash sales, results days, tax deadlines and live broadcast events.
Pre-scale against known events instead of reacting. Protect the write path first. Decide in advance what you will switch off. Rehearse the failure, including the adversarial version. And measure at a granularity that matches how fast the event actually moves.
The teams that do this well are rarely the ones with the most sophisticated architecture. They are the ones who accepted early that the spike is the normal operating condition rather than an exception, and built for it deliberately.
