There is a big difference between a system that works and a system that can continue working when everything suddenly gets busy.
Most applications look healthy during normal traffic. Dashboards are green. Response times are comfortable. Infrastructure has plenty of capacity. Teams are relaxed.
Then a campaign goes live.
Traffic increases sharply. Customers arrive at the same time. Payment requests increase. APIs become busy. External dependencies start behaving differently. Monitoring alerts begin to appear.
That is when resilience stops being an architecture diagram and becomes a real business requirement.
Working around high-traffic digital platforms has taught me that resilience is not created by one technology. It is created through preparation, architecture, observability, testing, people and decision-making under pressure.
Traffic is a business event, not just a technical number
When traffic increases, the first instinct of a technology team is often to look at infrastructure: CPU, memory, database capacity, network traffic and application performance.
Those metrics matter. But high traffic is also a business event.
More visitors can mean more bookings, more revenue and more customer interactions. A failure during a major campaign is therefore not simply an IT incident. It can directly affect the customer experience and the business outcome.
When technology carries revenue, availability becomes a business responsibility.
This changes how we should prepare.
The real preparation happens before the campaign
One lesson I have learned from high-traffic campaigns is that the most important work happens before the traffic arrives.
Once customers are already waiting, there are fewer good options available.
Preparation means understanding expected traffic, identifying the critical customer journeys, checking infrastructure capacity, reviewing database behaviour, validating third-party integrations, testing payment flows and making sure the team knows who owns each part of the platform.
It also means asking uncomfortable questions.
- What happens if traffic is twice the forecast?
- Which API becomes the bottleneck first?
- What happens if a third-party service becomes slow?
- Can we identify the problem within minutes?
- Can we safely roll back a release?
- Who makes the decision during an incident?
- What is the business impact if one component fails?
These questions are much more valuable than simply saying, “The application was load tested.”
Load testing is useful — but it is not the finish line
Load testing gives us evidence. It does not give us certainty.
A test environment may behave differently from production. Traffic patterns may not perfectly match real customers. Third-party services may behave differently. A payment provider may respond differently during a real campaign. A database query that performs well at one load level may behave differently when several services compete for resources.
That does not make load testing less important. It makes it more important to combine testing with continuous observation.
The objective is not to prove that the system will never fail.
The objective is to make the system more predictable, more observable and easier to recover.
Observability changes the conversation
When a customer says, “The website is slow,” that is a business symptom.
The technology team needs to turn that symptom into evidence.
Which page is slow? Which API? Which dependency? Is latency increasing? Are error rates increasing? Is the database under pressure? Are payment requests failing? Is the issue isolated to one geography, one service or one customer journey?
Good observability helps us move from:
“Something seems wrong.”
to:
“We know where the problem is, how many users are affected, and what we need to do next.”
That reduction in uncertainty is extremely valuable during a live campaign.
Resilience is also about people
It is easy to talk about resilience as an infrastructure topic. But some of the most important resilience decisions are made by people.
During a high-pressure situation, teams need clear ownership. Developers, infrastructure teams, product owners, business stakeholders and vendors need to know their responsibilities.
Someone needs to make decisions. Someone needs to communicate. Someone needs to watch the customer journey. Someone needs to coordinate vendors and external dependencies.
And everyone needs to avoid making the situation worse.
During an incident, clarity is often more valuable than activity.
Doing ten unrelated things at the same time may feel productive. A focused team identifying the highest-impact issue and resolving it can be much more effective.
Don't optimise only for the happy path
Normal customer journeys are important. But resilient systems are designed with failure in mind.
What happens if a payment attempt times out? What happens if an API responds slowly? What happens if a downstream service is temporarily unavailable? What happens if a deployment needs to be rolled back? What happens if traffic suddenly exceeds expectations?
These scenarios should be considered during design, not only during an incident.
Graceful degradation, retries where appropriate, sensible timeouts, caching, queueing, rate controls, fallbacks and safe rollback mechanisms can all help reduce the impact of failures.
The goal is not to make every component indestructible.
The goal is to make sure that one failure does not automatically become a complete customer-facing failure.
Campaigns expose weaknesses — and that is useful
A high-traffic campaign can reveal weaknesses that normal traffic hides.
That can be uncomfortable. But it is also valuable.
Every incident or performance issue gives us information about the system. The important question is what we do with that information afterwards.
Do we fix the immediate symptom and move on?
Or do we ask why it happened, whether the same weakness exists elsewhere, and what engineering or process change can prevent a repeat?
This is where resilience becomes a continuous improvement discipline.
The business should be part of resilience planning
Technology teams should not be the only people discussing high-traffic readiness.
Business teams should understand which customer journeys are critical. Marketing teams should communicate campaign expectations early. Operations teams should know what to expect. Finance and payment stakeholders should understand possible transaction-volume changes. Vendors should know the expected load and escalation path.
A resilient platform is supported by a resilient operating model.
The technology may be excellent, but if nobody knows who should make a decision during a critical event, the organisation can still struggle.
After the campaign, the work is not finished
One of the most important practices is the post-campaign review.
What worked well? What nearly failed? Where did we see unexpected behaviour? Which alerts were useful? Which alerts were noisy? Where did manual intervention happen? Which vendor dependency created risk? Which part of the platform needs investment?
These conversations should be factual, not about blame.
The objective is to convert experience into engineering knowledge.
Every high-traffic event should leave the platform stronger than it was before.
What resilience means to me
Earlier in my career, I might have associated resilience mainly with infrastructure capacity and application performance.
Today, I see it more broadly.
Resilience is the ability of a technology platform and the people operating it to absorb unexpected pressure, identify problems quickly, protect the most important customer journeys, make good decisions under pressure and recover without losing sight of the business outcome.
Architecture matters. Cloud capacity matters. Load testing matters. Monitoring matters. Security matters.
But so do communication, ownership, preparation and calm decision-making.
The lesson I carry forward
High-traffic campaigns have reinforced one simple idea for me:
We don't build resilient systems because we expect everything to go wrong. We build them because we know something eventually will.
The goal is not perfection.
The goal is preparedness.
When the traffic arrives, the best technology teams are not surprised by the fact that the system is under pressure. They have already thought about where the pressure will appear, how they will detect it, how they will respond and how they will learn from it.
That is what turns a high-traffic event from a technology risk into an opportunity to demonstrate engineering maturity, operational discipline and leadership.
← BACK TO LEADERSHIP INSIGHTS