A news organisation runs a normal publishing platform for most of the year and an entirely different traffic profile on election night. Which architecture style should the read path use, and how does that differ from the style appropriate to the newsroom's editing tools?

What is being tested

Whether you treat "architecture style" as a property of a system or of a workload. Large systems are almost never one style, and insisting otherwise is a common and expensive mistake.

The two halves

The editing side. Tens or hundreds of concurrent authors and editors. Rich interactive behaviour, workflow, permissions, drafts, embargoes, collaborative editing. Correctness matters enormously — publishing the wrong version is a serious incident — and the load is trivial. This half wants a conventional transactional application, and a modular monolith serves it well.

The reading side. Enormous read volume with step-function spikes. Nearly all readers of a given article see identical content. Staleness of a few seconds is acceptable for almost everything. This half wants pre-rendered content pushed to an edge network, where the origin is a fallback rather than a participant.

What connects them

A publish event. The editorial system owns truth; publishing triggers rendering and distribution. The critical architectural property is that the read path keeps working when the write path is down. On election night, the newsroom tooling failing is an inconvenience; the read path failing is the event people remember.

The step-function problem

Ordinary autoscaling assumes a ramp. Election-night traffic arrives as a step. Two structural answers, both required:

• Push, do not pull. Content is at the edge before the traffic arrives, so the spike is absorbed by capacity that already exists.
• Static stability. The read path must not need any control-plane action — no scaling event, no new instances, no config push — to survive the spike. Anything that must happen during the spike is a thing that can fail during the spike.

Where teams get this wrong

By deciding the organisation "is a microservices shop" or "is a monolith shop" and applying it uniformly. The result is either an over-decomposed editing tool nobody can debug, or a read path coupled to a database that cannot survive a spike. Style is chosen per workload, and the interesting architecture is the seam between them.