A news organisation's publishing pipeline runs rarely during quiet periods and intensely around major events, performing image processing, rendering and distribution. Where does serverless fit, and where would it be a mistake?

Where serverless fits well

Event-driven, bursty, stateless work with variable volume — which describes most of a publishing pipeline's asynchronous half:

• Image derivative generation. An upload triggers a function producing crops, formats and resolutions. Idle cost is zero; a breaking-news photo burst scales instantly; each invocation is independent.
• Content transformation and validation on publish.
• Webhook receivers and integration glue, where traffic is low and unpredictable and running a permanent service is mostly paying for idle.
• Scheduled jobs replacing a cron host that exists solely to run a script twice a day.

The economics are decisive for these: paying per invocation for a workload with a very low duty cycle is far cheaper than paying for provisioned capacity that is idle most of the time.

Where it is a mistake

The read path. Serving articles is the highest-volume, most latency-sensitive part of the system, and it is dominated by traffic spikes. Serverless here is wrong for two independent reasons: cold starts add latency exactly when a spike begins, and per-invocation pricing at that volume is far more expensive than static content on a CDN. The correct answer for the read path is pre-rendered content at the edge, where the marginal cost of a request approaches zero.

Long-running or heavyweight processing. Functions have execution time limits and constrained resources. A large video transcode or a full-site rebuild belongs in a container or batch job.

Anything requiring a persistent connection or in-memory state. Serverless is stateless by design; fighting that is expensive.

High-frequency database access. Function concurrency and database connections interact badly — a thousand concurrent functions each opening a connection exhausts the database's connection limit. This requires a connection proxy, which is extra machinery that partly negates the simplicity that motivated the choice.

The architectural picture

The publishing platform splits cleanly:

• Write side — editorial tooling, workflow, embargoes — a conventional long-running application. Modest load, rich interaction, correctness critical.
• Asynchronous processing — serverless functions triggered by publish events. Bursty, stateless, parallel.
• Read side — pre-rendered, edge-distributed, static. Absorbs the step function without any computation per request.

The seam is a publish event, and the property that matters is that the read path survives the write path being down. On a major event night, editorial tooling failing is an inconvenience; the read path failing is what people remember.

The judgement

Serverless is an excellent answer for the asynchronous, event-driven parts of a system and a poor answer for its highest-volume serving path. Teams that adopt it as a platform-wide philosophy discover the second half expensively; teams that use it where the duty cycle is low get most of the benefit with none of the pain.