Seven Years Running a National Broadcaster’s Digital Operations: What I Learned

I spent seven years responsible for the digital operations of Channel i, a national satellite television network in Bangladesh. Most of what I learned about running high-traffic infrastructure I did not learn from documentation. I learned it from the specific way things fail when a news event breaks and every assumption in your architecture is tested simultaneously.

What follows is the part that generalises — the lessons I would give to anyone taking over a newsroom’s technical operations.

Your traffic is not a curve, it is a step function

Capacity planning literature assumes growth. News traffic does not grow, it jumps. Baseline for weeks, then twenty or fifty times baseline within minutes of a major event, sustained for hours, then back down.

This breaks autoscaling in a way that is obvious in hindsight. Autoscaling responds to load that has already arrived. By the time instances are provisioned and warm, the surge has been failing requests for several minutes — which are precisely the minutes that matter, because that is when people form a judgement about whether your site works.

The answer is not more autoscaling. It is making the common case not require the origin at all. During a breaking story the overwhelming majority of requests are for the same handful of pages, and if those are served from cache the surge never reaches your application. A ten-second cache on a story page is invisible to readers and reduces origin load by orders of magnitude during exactly the window that would otherwise break you.

The organisational difficulty is that editors hate caching, because they want corrections live immediately. That tension is resolved by tooling — a purge that fires on publish — not by disabling the cache. If you cannot give editors instant purge, they will win the argument and you will have no cache when you need it.

The homepage is the wrong thing to optimise

Newsroom instinct treats the homepage as the front door. The analytics rarely agree. Most readers arrive at an article from search or social and leave from that article. They never see the homepage.

This changes priorities. Article template performance matters more than homepage performance. Related-content placement matters more than homepage curation, because it is the only navigation most readers encounter. And a slow homepage is a smaller problem than a slow article page, which is the reverse of how most teams allocate attention.

Images are the entire performance conversation

Every performance problem I dealt with was, at bottom, an image problem. Not JavaScript, not database queries. Images uploaded straight from a camera at full resolution, embedded in an article, served to a phone on a congested mobile network.

Automated processing at upload is the only thing that works, because it is the only control that does not depend on people remembering. Resize to a set of sensible widths, convert to modern formats, strip metadata, serve responsively, and make it impossible to publish an unprocessed original. Every attempt I saw to solve this through training and guidelines failed within a month, not because journalists are careless but because they are working to a deadline and the tool allowed it.

Archives are a security problem disguised as a storage problem

A newsroom accumulates enormous quantities of material nobody revisits: unaired footage, raw interviews, contributor contact details, internal correspondence about stories that never ran. It is not classified, not indexed, and not really owned by anyone after the story closes.

It is also frequently the most sensitive data the organisation holds. Source identities — a category where long-term confidentiality genuinely matters — unpublished allegations, personal details of people who were never public figures. The retention question — what do we keep, for how long, and who can reach it — is one most newsrooms have never asked, and it is worth asking before someone else asks it for you.

Content protection is an operations problem, not a legal one

Managing copyright at scale across YouTube’s Content ID and Facebook’s Rights Manager was a large part of my role, and the thing that surprised me was how little of it was about enforcement.

Most of it is reference management: making sure the systems hold accurate, current fingerprints of your material, that the ownership metadata is right, and that the exclusions are correct so you are not issuing claims against your own licensees or against legitimate commentary. Get the references wrong and you generate false claims, which cost you goodwill and eventually your standing with the platform.

The judgement calls also cannot be delegated to a system. A competitor re-uploading a full segment is straightforward. A critic using thirty seconds to make a point about your coverage is not, and treating those identically is both legally risky and reputationally expensive.

Your uptime is a trust signal, not a metric

The technically minded framing of availability is a percentage. The audience’s framing is simpler: when something important happened, was the site there?

Nobody notices 99.9 percent uptime. Everybody notices the outage during the one story that mattered, and news organisations compete on being where people go for the truth. Failing at that moment costs more than the arithmetic suggests, because the alternative source they found instead may keep them.

This is worth saying to management in exactly those terms, because it reframes infrastructure spending from a cost centre to a defence of the thing the organisation sells.

What I would do first, taking over tomorrow

1. Get a CDN in front of everything and make sure the origin only accepts traffic from it. This one change addresses surge capacity and most volumetric attack risk at once.
2. Cache article pages briefly and purge on publish. Short TTL plus reliable purge beats a long argument with the newsroom.
3. Fix images at the upload boundary. Nothing downstream compensates for a 6 MB photograph.
4. Inventory the archive. Find out what you are holding before you need to explain it.
5. Write down the content protection policy, including what you deliberately will not claim against.

None of this is sophisticated. All of it is the difference between infrastructure that holds on the day it matters and infrastructure that does not.