Where RDI Fits in Media and Entertainment (and Where It Doesn't)

Streaming platforms have a data shape that suits change data capture almost perfectly. A modest amount of editorially managed content, read an enormous number of times, by clients that will not forgive a slow catalogue screen.

They also contain several workloads where CDC is precisely the wrong tool, and the two categories look similar enough on a whiteboard that they end up in the same pipeline. The result is a project that works beautifully for the catalogue and then quietly fails on watch progress, which is usually discovered late.

So this is a use-case-by-use-case verdict, tested against the criteria in the [RDI architecture post](/blog/rdi-architecture-and-fit). Briefly, those were: one source database, the application never writes to that source, eventual consistency measured in seconds is acceptable, and changes arrive as frequent small increments rather than large batches.

The shape that works

Content catalogue and metadata

The obvious fit, and the strongest one. Titles, synopses, cast, artwork references, genre taxonomy, episode ordering. All of it authored in a CMS, and read on every home screen render, every search, every "more like this" row.

It clears every criterion without argument. The CMS owns the data and applications never write to it. A synopsis correction arriving three seconds late affects nobody. Changes come in as one title update, one new episode, one corrected credit. And catalogue metadata is measured in gigabytes rather than hundreds of gigabytes, so the initial sync finishes inside a sensible cutover window.

The transformation step earns its keep here too. A title in a relational schema is spread over half a dozen tables, and what you want in Redis is one JSON document per title, so rendering a home screen is a single round trip instead of a join.

Availability windows and regional rights

Which titles are playable, in which territory, between which dates. Read constantly, since every catalogue render filters on it, and written rarely, by rights management.

Same profile as the catalogue, with one operational wrinkle. Rights changes are usually scheduled rather than immediate, so when a window opens at midnight the row changes at midnight and RDI propagates it within seconds. That is fine. What is not fine is expecting RDI to enforce the window. The read path still has to compare dates itself, and I have seen that assumption cause a title to appear in a territory a day early.

Entitlements and plan lookups

Read on every playback start: does this account have this tier, is it in good standing. Written by billing, which is a system you badly do not want sitting in the hot path of a play request.

This fits, with a caveat worth designing for up front, because the upgrade case is the one that bites. A customer pays for a higher tier, immediately tries to watch the 4K stream, and the cache is three seconds behind. Both mitigations are cheap. You can fall through to the source once on a negative entitlement result before denying, which costs nothing at steady state because negative results are rare. Or you can have the billing flow write a short-lived override key straight into Redis on upgrade, which has the advantage of being a write your own application owns rather than a pipeline concern.

Doing both is not excessive.

Search and browse indexes

Feeding the Redis query engine from the same catalogue source, so search and faceted browse run at the same freshness as the catalogue itself, with the transformation mapping editorial fields onto an index schema.

This is where the lack of joins into nested JSON starts to matter. If your search document needs to denormalise a one-to-many relationship across several tables, test that specific case early rather than assuming the pipeline will assemble it for you.

Now the ones that do not fit

These matter more than the list above, because they are the workloads that look like a fit and are not.

Watch progress and resume points

The most common mistake I see. The application writes progress every few seconds during playback and needs it back instantly on another device. That is write-behind, not change data capture, and RDI is one-directional so it does not implement it. Write to Redis directly and drain onward to your database with your own worker or a stream consumer.

Concurrent stream limits and session state

This one inverts the question. Counting active streams per account to enforce a three-device limit is state that is born in Redis, lives in Redis and expires in Redis. There is no source database to capture changes from. If you find yourself asking how to get session state into Redis via RDI, the architecture diagram is pointing the wrong way.

Live scores and event feeds

Live data feels like CDC because it changes constantly, but it usually arrives as a feed rather than as rows in a database, and no writes to a source database means no change log to tail. Write feed events to Redis directly. Inserting a database in the middle purely so that RDI has something to read is architecture for the tool's benefit rather than yours.

Nightly recommendation batches

A documented failure case rather than a judgement call: RDI will fail processing the long, large transactions that batch ETL produces. Load those with a bulk import, or have the batch write to Redis itself.

Multi-region active-active viewing state

Settled before any performance conversation starts, because Active-Active is not a supported RDI Cloud target topology.

Use case	Fit	Deciding factor
Content catalogue and metadata	Strong	One source, read-heavy, editorial writes only
Availability windows and rights	Strong	Same profile; read path still enforces dates
Entitlements and plan lookups	Good, with care	Upgrade lag needs a fallback read
Search and browse indexes	Good	Check nested-JSON denormalisation first
Watch progress and resume	No	Write-behind, and RDI is one-directional
Concurrent stream limits	No	Redis is the system of record here
Live scores from a feed	No	No source database, so no change log
Nightly recommendation batch	No	Long ETL transactions are a documented failure
Active-active viewing state	No	Not a supported RDI Cloud target topology

What you actually get

The real win is that the invalidation problem disappears. Catalogue caching without CDC means every content service remembering to invalidate on every write path, and the bug is always the one path somebody forgot about eighteen months ago. RDI turns that from application discipline into infrastructure, which is a much better place for it to live.

After that, read load comes off the source database. A streaming home screen can be dozens of reads, and moving them off the CMS database removes read replicas you were paying for and scaling. Launch spikes land on Redis rather than on a relational database that was never sized for a premiere.

You also get to choose the target shape, so one JSON document per title instead of a six-table join, without writing and maintaining sync code. And freshness becomes a bounded number you can write in a design document and defend, rather than a TTL somebody picked years ago to stop complaints.

What it costs you

It is another moving part: two VMs or a Kubernetes deployment, plus an RDI database consuming memory on a cluster you sized for your application. Small, but it needs monitoring like anything else.

Source configuration is a dependency you do not control. CDC needs log retention, replication slots and privileges on the CMS database, and if the DBA will not grant them then the design is finished. Settle that question before you plan around it, not after.

Schema changes at the source become a coupling you now own. A migration that renames a column is a change nobody told the pipeline about, so somebody on the database side has to know a pipeline is watching. That is an organisational fix as much as a technical one.

Drift is silent. At-least-once delivery with idempotent writes should converge, but "should" is not monitoring. Decide early how you would detect divergence, whether that is a periodic count comparison or checksums over a sample, because nobody builds it before the first incident and everybody wishes they had.

Initial sync sizing surprises people. The published envelope is a sub-hour full sync at up to 200 GB, and catalogue metadata sits comfortably inside that. Measure it against production volume anyway rather than against the 5 GB you tested on.

And it does not solve the write path at all. Half of the interesting state on a streaming platform is written by the client, and RDI covers the read side only.

Scoping a proof of concept

Two weeks, and measure three things.

Freshness under editorial load: change a title in the CMS and measure time to visible in the app, while a bulk metadata update is running rather than on a quiet system. Initial sync against the real catalogue rather than a sample, because that number sets your cutover window. And the entitlements upgrade path: buy a tier, immediately try to play, and find out whether you need the fallback read before you ship rather than after.

If those three come out clean, the rest is configuration.

Sorting them quickly

For media and entertainment, RDI suits editorially managed, read-dominated reference data. Catalogue, rights windows, entitlements, search indexes. Within that shape it removes an entire class of cache-invalidation bugs, which is worth a lot more than the latency numbers people usually lead with.

Outside it, the failures are not subtle. The question that sorts most cases in about ten seconds is simply who writes this data, and is it a database. If the answer is the client application, stop. If it is a feed, stop. If it is editorial, into the CMS, keep going.