System architecture for media

Broadcom is reportedly lining up as much as $100 billion in debt to finance AI chip supply for Anthropic and others (SiliconAngle). That number matters for media companies because the compute layer underneath recommendation engines, transcription, and generative tooling is being repriced in real time, and the system architecture sitting on top of it has to absorb the change without a rebuild every eighteen months.

Media platforms are where this pressure lands first. Content catalogues grow faster than the teams maintaining them, rights windows shift by region and hour, and every product surface now wants an AI feature attached. The architecture has to hold.

What is system network architecture in a media context

System network architecture describes how the compute, storage, delivery, and control layers of a platform are arranged and how they communicate. In a media platform, that means the path a video file takes from ingest through transcoding, DRM, CDN, and player, plus the metadata, entitlement, and analytics flows running alongside it.

A useful working definition: system architecture is the set of decisions about boundaries, protocols, and data ownership that determine what you can change cheaply later. Everything else, including framework choice and cloud vendor, is an implementation detail underneath those decisions.

Why media platforms are moving to decoupled architectures

The monolithic OVP, one system handling ingest, catalogue, entitlement, and playback, is not surviving contact with the current market. Three forces are pulling it apart.

First, distribution surfaces multiplied. A single title now ships to web, iOS, Android, connected TVs across four operating systems, and increasingly to social clips and FAST channels. A client-server system architecture where every client talks to one backend collapses under the schema churn.

Second, AI features are non optional. Auto tagging, scene detection, voice cloning for dubs, personalised trailers. These workloads have very different latency and cost profiles from playback, and stapling them into the core service creates outages that shouldn't exist.

Third, rights and compliance rules are getting stricter, particularly under EU regulation. Geo, device, and window logic needs to sit in a service that auditors can read without a walkthrough.

The shape most teams land on

After enough migrations, the same rough shape keeps appearing:

• A content service that owns the canonical asset and its variants
• A metadata and taxonomy service, usually the first place AI writes into
• An entitlement and rights service, isolated because it changes on legal timelines, not product ones
• A delivery layer, CDN plus edge logic, treated as replaceable
• A client BFF per major surface, so mobile does not block web
• An events backbone, Kafka or equivalent, that everything else reads from

This is not novel. It is what a workable system design and architecture for a mid sized media platform looks like in 2025, and the interesting engineering work is in the seams between these services, not inside them.

Where AI actually fits

Most media companies we talk to have an AI backlog longer than their engineering capacity. The architectural question is not whether to add AI, it is where to let it write.

Read paths are safe. Recommendations, search ranking, semantic tagging surfaced to editors for approval. Write paths need discipline. Auto generated subtitles going straight to a subscriber without a human in the loop is a rights and reputation risk that the architecture should make explicit, not implicit.

Devspace's AI and Data work with media clients usually starts by mapping which pipelines can accept probabilistic output and which cannot. That map, more than any model choice, determines whether the AI programme ships.

What good looks like for a scale up media platform

A short checklist we use when reviewing system architecture for media and entertainment clients, whether for a scale up CTO or a PE technical due diligence:

1. Can you add a new distribution surface without touching the entitlement service? If no, the boundaries are wrong.
2. Is the content ID stable across ingest, CMS, DRM, and analytics? If teams are joining on title strings, the data model is a liability.
3. Can an AI workload be turned off in ten minutes without degrading playback? Isolation of experimental features is a hard requirement, not a nice to have.
4. Are rights windows expressed as data the entitlement service reads, or as code deployed by engineers? The former scales, the latter does not.
5. Is there a single events stream that product, data, and finance all read from, or three parallel pipelines drifting apart? Drift here shows up as revenue reporting disputes eighteen months later.

A platform that answers yes to four of these five is in good shape. Two or fewer, and the next feature request will cost more than it should.

What breaks first at scale

The failure modes in media system architecture are predictable.

Metadata becomes the bottleneck before compute does. A catalogue of 200,000 assets with inconsistent taxonomy will slow every downstream team, from editorial to recommendations to ad ops. Fixing it is unglamorous and usually deferred until it blocks a launch.

Entitlement logic sprawls. What starts as a clean service accumulates special cases for one partner, one region, one promotional window, until nobody can answer whether a specific user should see a specific title without running the code.

Observability lags the architecture. Teams split the monolith into fifteen services and keep the same logging setup, then spend a quarter reconstructing what a single playback failure actually touched.

None of these are exotic. They are the standard tax on growth, and they are why senior engineers with media platform experience are worth more than the same headcount of generalists.

How Devspace approaches media platform engineering

Devspace embeds senior engineers directly into the client's team, stack, and sprint, usually within two to four weeks. For media clients, that typically means people who have shipped video pipelines, worked with DRM providers, and debugged CDN edge behaviour at 2am before.

For scale ups, the common shape is a small embedded team plus a Fractional CTO to hold the architectural line while product pressure pulls in every direction. For PE backed media businesses, the same engineers who run pre deal technology risk assessment stay on for post close execution, which shortens the gap between diligence findings and remediation.

The network is 500+ senior engineers across Europe, with 96% client retention and 60% of assignments extended. In media specifically, that means we can source someone who has actually built a rights service before, rather than someone who will learn on your platform.

The takeaway

System architecture for media platforms is no longer a one time design exercise. It is a continuous set of boundary decisions taken under pressure from new distribution surfaces, AI features, and tightening rights regimes.

The teams that stay ahead treat architecture as a product with its own roadmap, own it at a senior level, and bring in specialists for the work that only gets done well once or twice in a career. The teams that don't spend the next two years rebuilding the same platform they already have.

Photo by Tasha Kostyuk on Unsplash