VOD: Building a High-Performance Streaming Platform -

The Backbone of Modern OTT

If you are building a streaming platform, your Middleware is the unsung hero. It is the critical orchestration layer that sits between your chaos of content sources (XMLTV feeds, VOD CMS, Live Encoders) and the pristine experience your users expect on their Apple TV or Android app.

In this guide, we break down the exact architecture required to build a high-performance video middleware. We will cover Unified Ingestion, High-Availability API Design, and the caching strategies necessary to serve millions of EPG requests without crashing your database.

Key Architectural Goals:

Aggregation: Seamlessly ingest data from disparate sources (Gracenote, XMLTV, JSON feeds).
Normalization: Clean and standardize metadata into a single, queryable internal schema.
Prestaties: Achieve sub-50ms API response times using aggressive caching (Redis).
Beveiliging: Robust entitlement checks, DRM token generation, and Geo-blocking.

2. High-Level System Architecture

A monolithic application won’t cut it for modern streaming. We recommend a Microservices of Modular Monolith approach behind a robust API Gateway. This ensures that a failure in your EPG ingestion worker doesn’t take down your login service.

The Architecture Diagram

graph TD
    subgraph "External Sources"
        EPG[EPG Provider (Gracenote/XMLTV)]
        CMS[VOD CMS (Assets/Metadata)]
        LIVE[Live Stream Encoders]
    end

    subgraph "Middleware Core"
        GW[API Gateway / Load Balancer]
        
        subgraph "Ingestion Layer"
            ING_EPG[EPG Ingest Worker]
            ING_VOD[VOD Metadata Syncer]
        end
        
        subgraph "Service Layer"
            SVC_EPG[EPG Service]
            SVC_VOD[VOD Catalog Service]
            SVC_USR[User & Entitlements]
            SVC_DRM[DRM Signer]
        end
        
        subgraph "Data Persistence"
            DB[(Primary DB - PostgreSQL)]
            CACHE[(Cache - Redis)]
            SEARCH[(Search Engine - Elasticsearch)]
        end
    end

    subgraph "Clients"
        WEB[Web App]
        TV[Smart TV / STB]
        MOB[Mobile App]
    end

    EPG --> ING_EPG
    CMS --> ING_VOD
    ING_EPG --> DB
    ING_VOD --> DB
    ING_VOD --> SEARCH
    
    WEB --> GW
    TV --> GW
    MOB --> GW
    
    GW --> SVC_EPG
    GW --> SVC_VOD
    GW --> SVC_USR
    
    SVC_EPG --> CACHE
    SVC_EPG --> DB
    SVC_VOD --> DB
    SVC_VOD --> SEARCH
    SVC_USR --> DB
    SVC_USR --> SVC_DRM

3. Mastering the EPG (Electronic Program Guide)

The EPG is the heaviest component of any IPTV/OTT system. Linear schedules change frequently, and client devices request this data constantly. If you query your SQL database for every user who opens the guide, your platform will go down during prime time.

3.1 The Ingestion Strategy

You cannot rely on real-time fetching from providers. You must ingest and store locally.

Format Handling: Build parsers for standard XMLTV and provider-specific JSON schemas.
Updatefrequentie: Run full ingestions every 6-12 hours. Run “Delta” updates every 15 minutes to catch last-minute schedule changes (e.g., overtime in sports).
Normalization: Map external Genre IDs (e.g., “ProviderA-Comedy”) to your internal Genre IDs (e.g., “Internal-101”) to ensure UI consistency.

3.2 Optimized Database Schema

We use PostgreSQL for relational integrity but serve data to clients via Redis.

3.3 The “Windowing” Caching Technique

Clients never need the full 7-day schedule at once. They typically view the EPG in blocks (e.g., “What’s on now?”).

The Redis Strategy:

Key Structure: epg:{channel_id}:{date_bucket}
Value: A compressed JSON array of programs for that specific time block.
De stroom: Middleware checks Redis first. If missing (Cache Miss), it performs a heavy SQL query, populates Redis (Cache Set), and returns the data. This reduces DB load by 95%.

4. Building a Scalable VOD Module

Video op aanvraag (VOD) requires a different approach than Live TV. It focuses on metadata richness, deep search capability, and strict access control.

4.1 Metadata Hierarchy

Don’t flatten your data. Maintain a strict hierarchy to support “Watching” UI features:

Series: The top-level container (e.g., “Breaking Bad”).
Season: Child of Series.
Asset/Episode: The playable entity. Contains technical metadata (Video Codec, Audio Tracks, Duration).

4.2 Search & Discovery

SQL LIKE queries are too slow for VOD. Replicate read-only metadata to a dedicated search engine (Elasticsearch of MeiliSearch). This enables:

Fuzzy matching (handling typos).
Weighted results (boosting “New Releases”).
Facet filtering (Year, Genre, Actor).

4.3 Secure Stream Generation (DRM)

Never store static stream URLs in your database or frontend code.

Client requests POST /vod/play/{asset_id}.
Middleware validates the user’s Subscription (Entitlements).
Middleware calls the DRM Provider (Widevine/PlayReady) to generate a short-lived license token.
Middleware returns a signed URL: https://cdn.service.com/movie.mpd?token=xyz...

5. API Design Patterns

Your API is the product. Design it to be RESTful, versioned, and predictable.

5.1 High-Performance EPG Endpoints

Get Channel List

GET /api/v1/channels

Get Program Guide (Grid) Inputs: start (ISO Date), end (ISO Date)

GET /api/v1/epg?start=2023-10-27T10:00:00Z&end=2023-10-27T14:00:00Z

Optimized Response Structure:

{
  "channels": [
    {
      "id": "ch_101",
      "name": "Movies 24",
      "programs": [
        {
          "id": "prog_999",
          "title": "Inception",
          "start": 1698400800,
          "end": 1698408000,
          "is_catchup_available": true
        }
      ]
    }
  ]
}

5.2 VOD & Playback Endpoints

Get VOD Details

GET /api/v1/vod/assets/{asset_id}?expand=related,cast

Get Playback Context (Secure)

POST /api/v1/vod/play
Body: { "asset_id": "12345", "device_id": "tv_living_room" }

6. Your Roadmap to Production

If you are ready to build, follow this phased execution plan to ensure stability.

Phase 1: Core Foundation

[ ] Deploy PostgreSQL and Redis clusters.
[ ] Run initial Database Migrations (Channels, Programs, VOD Assets).
[ ] Build the Authentication Service (JWT based).

Phase 2: Ingestion & Data Flow

[ ] Develop the XMLTV Parser (Python or Node.js).
[ ] Implement “Diffing” logic to only update changed programs (saves DB writes).
[ ] Configure VOD CMS webhooks to trigger real-time metadata updates.

Phase 3: Client API & Security

[ ] specific Implement the EPG Grid API with the Redis caching strategy mentioned above.
[ ] Implement the Search API using Elasticsearch.
[ ] Integrate DRM Token signing logic for secure playback.

Phase 4: Operational Excellence

[ ] Set up centralized logging (ELK Stack or CloudWatch).
[ ] Configure CDN (CloudFront/Akamai) caching rules to offload static assets.

Middleware Architecture: Integrating APIs for Custom EPG and VOD Management

2. High-Level System Architecture

The Architecture Diagram

3. Mastering the EPG (Electronic Program Guide)

3.1 The Ingestion Strategy

3.2 Optimized Database Schema

3.3 The “Windowing” Caching Technique

4. Building a Scalable VOD Module

4.1 Metadata Hierarchy

4.2 Search & Discovery

4.3 Secure Stream Generation (DRM)

5. API Design Patterns

5.1 High-Performance EPG Endpoints

5.2 VOD & Playback Endpoints

6. Your Roadmap to Production

Phase 1: Core Foundation

Phase 2: Ingestion & Data Flow

Phase 3: Client API & Security

Phase 4: Operational Excellence

Laat een reactie achter Reactie annuleren

Snelle links

Restitutie- en Retourbeleid

Privacybeleid

Servicevoorwaarden

Neem contact met ons op

Gelicentieerde en legitieme IPTV-service

Nieuwsbrieven