Getting content to the right eyes

The VOD home page pulls its feed from an API. That feed has two sources: (1) videos from channels the user follows, and (2) videos matched to the user's watch behavior (plus trending/popular). Both compute their results into a feed cache; the API reads from that cache on request.

Start with source (1). When a channel uploads a video, a row lands in VideoMetadata — but how does the system know a row was added? That's Change Data Capture (CDC): monitoring a data source for changes and streaming them in real time to another service. The lesson weighs four ways to do it:

Store each user's feed in a key-value store for O(1) access: key = UserId, value = a list of VideoRecommendation objects.

class VideoRecommendation {
  int id;
  List<Integer> videoIds;
  boolean polledByUser = false;
  // ...other fields
}

When the Channel Subscription Feed pulls, say, 25 videos to recommend to a user, it adds them to videoIds, sets polledByUser = false, wraps it in a VideoRecommendation object, and appends it to that user's list. When the user requests recommendations, one or more objects are returned, polledByUser flips to true, and once sent they can be discarded from the cache to free space.

The second source: watch behavior

A Recommendation Engine computes videos from viewing behavior (trending/popular included). It ingests VideoMetadata via the same CDC-into-Kafka flow for new videos. To surface trending content it must re-query the table for updated views/likes/comments — so keep a copy of VideoMetadata the engine queries continually, sparing the origin table load. The engine writes its results into the same VideoRecommendation list. (The actual matching is machine learning, out of scope.)

[+] Swap "video" for "image" and this is exactly how a Pinterest or Instagram feed works too.

The notification workflow mirrors the feed's: a new VideoMetadata row triggers an event → Kafka queue → a Notification Service polls it, takes the ChannelId, looks up subscribers in the key-value store, and generates a notification object per subscriber:

class Notification {
  int id;
  String notificationMessage;
  Integer videoId;
  String videoURL;
  // ...other fields
}

These land in each user's notification feed in a key-value store (key = UserId, value = list of Notification objects). The crucial difference from the feed: notifications are pushed, not pulled.

On a sports site, content is videos (already covered) plus articles with images. The CMS has two sub-services: a Content Storage Service (takes content from writers, persists it) and a Content Delivery Service (serves it to readers). An article has a title, summary, content, images, categories, tags, and one or more authors — with one-to-many relationships to categories (sport, tournament), tags (club, country, game type), and authors.

Which database? The lesson eliminates two candidates:

A graph model has nodes, node properties, directed relationships, and labels. Authors (Ron, Jim, Nancy…), categories (Baseball, Football, Cricket, Boxing), tags (India, Ashes, Yankees, Cubs…), and articles all become nodes with directed edges between them. In Neo4j, nodes are created/queried with the Cypher query language (Cypher is to Neo4j what SQL is to a relational DB).

Two query types

• Query 1 — "all articles by author Ron / in category Baseball / with tag Yankees." Locate the node and traverse its edges (AUTHORED, HAS AN ARTICLE, etc.).
• Query 2 — "articles by Ron and in Baseball and tagged Yankees." Locate Ron, traverse to his articles, then scan those articles' relationships to the category and tag nodes.

Tuning the graph

• Redundant properties — if Query 2 is very frequent, add categories/tags as properties on article nodes (as well as separate nodes), shrinking scan depth. Writes update multiple places, fine since tags rarely change.
• Relationship properties — edges carry metadata too: an Author —WRITES ABOUT→ Baseball edge can note long-form / summaries / tweets.
• Labels — group nodes by role (e.g. label all clubs playing football in Asia) to speed frequent queries.
• Node properties — authors carry id/name/designation/experience; articles carry id/length/content/image URLs. In Neo4j properties are stored key-value (node id → properties). If property data is large/complex, keep it in a document or relational DB and store a pointer in the node — a polyglot model.

Authors write in a UI and hit publish. The article goes to an Article Processor, which:

1. Triggers a serverless event that, via a Kafka queue, sends the images to an Image Processing Service — the queue loosely couples the two so image processing works at its own pace.
2. Persists the article to the graph database.
3. Meanwhile the Image Processing Service compresses/enhances images and stores them in a cloud object bucket.
4. On success, another serverless event updates the image URLs as properties on the article node in the graph DB.
5. Once all events succeed, the Article Processor returns a publish-success response, and published content is cached per business logic.

Content delivery reuses the VOD pattern exactly: reader → edge cache (hit → served) → regional cache → content-serve service at the origin. No need to reinvent it.

Both external references resolve live. The author's own course cross-links (message queues, persistent connections, document/graph DBs, polyglot persistence) are omitted.