Inside a breaking-news WordPress + AWS architecture
Jaafar Abazid
When a story breaks, traffic doesn’t grow. It detonates. A page that served a few hundred concurrent readers at breakfast can be facing tens of thousands within minutes. And the cruel part: the page that matters most, the breaking story itself, is exactly the one that goes down.
This is the problem we spent years solving inside a working newsroom. The architecture below isn’t a whiteboard exercise; it’s the approach that ran a leading pan-Arab news broadcaster’s digital properties in production for five years, load-tested to 50,000 concurrent readers, absorbing spikes of 20× normal traffic with no spike-driven outages.
Why a single origin fails
A standard WordPress build (one server, one database, page cache in front) behaves well right up until the moment it doesn’t. Under a breaking-news spike, three things happen almost simultaneously:
- The database saturates. Every cache miss becomes a query storm. The database that comfortably handled the morning’s traffic hits its connection ceiling in seconds.
- Caches stampede. The story is new, so it isn’t cached yet, and ten thousand readers request it in the same instant. They all miss, and they all hit the origin together.
- Editorial freezes. The same server that’s failing to serve readers is the one your editors are trying to publish updates on. The newsroom slows down at the exact moment it needs to speed up.
Scaling the server up doesn’t fix this; it just moves the ceiling. The fix is architectural: separate the editorial system from the delivery system.
The split: WordPress holds the newsroom, AWS holds the load
The principle is simple. WordPress is excellent at what newsrooms need: editorial workflow, roles, revisions, the publishing experience editors already know. It should never have been asked to also absorb national-scale read traffic. So we don’t ask it to:
- CloudFront serves readers from the global edge. Pages and media are cached close to every reader, pre-warmed, so the spike lands on edge caches, not on WordPress.
- S3 holds media and assets. A video or image gallery is uploaded once and served from object storage, never from the WordPress server’s disk.
- Lambda handles the dynamic work that scales with traffic: serverless compute that fans out when the spike arrives and quietly scales back down after it passes.
- SNS and SES carry breaking-news push notifications and newsletter email, so a million alerts don’t queue behind a struggling web server.
- API Gateway takes request ingress for headless consumers (native apps, OTT front-ends) without exposing the WordPress runtime to the public internet.
WordPress remains the single source of truth and the place editors work. But the day’s load lands on infrastructure that’s designed to absorb it, and billed only when it does. No over-provisioned fleet idling between news cycles; the cost curve follows the traffic curve.
What it held up to
Numbers from production, anonymised but real:
- 50K concurrent readers, load-tested
- 20× normal traffic absorbed during breaking news
- 100% uptime: no spike-driven outages
- 5 years in production
The quietest endorsement is the one the newsroom never had to give: in five years, no editor ever had to stop publishing because the site was down.
The principles, if you build this yourself
- Pre-warm the edge. Don’t let the first ten thousand readers race to an uncached page. Publish should mean cached at the edge, not *available at the origin*.
- Keep editors off the read path. The system your journalists type into should not be the system your readers hammer.
- Make the expensive things event-driven. Notifications, transcodes, syndication: fan them out asynchronously. Nothing user-facing should wait on them.
- Pay for traffic, not for fear. If your infrastructure bill is flat while your traffic is spiky, you’re paying for idle hardware as insurance. Serverless inverts that.
This architecture, and the team that ran it, is what ManTek’s WordPress + AWS practice is built on. If your traffic spikes exactly when it matters most, we should talk.