Problem Statement: A Multi-Tenant Streaming Platform, Not Another Netflix
Frames the product as a B2B2C platform where tenants are the customers and subscribers never see the platform brand.
Problem statement
Design a white-label streaming backend platform that smaller networks, local broadcasters, churches, sports leagues, and educational publishers can rebrand and launch as their own direct-to-consumer service. Each tenant gets custom branding, their own domain or subdomain, an isolated content library, their own subscriber base, and their own billing relationship with their viewers. We host the underlying technology in a multi-tenant environment and charge tenants a platform fee, a usage-based fee, or a revenue share.
This is not a consumer streaming design. Netflix optimizes one brand, one catalog, one identity system, one recommendation surface, at planetary scale. A white-label platform optimizes a different axis entirely: safe multiplexing. The hardest problems are not ABR ladders or CDN failover in isolation; they are guaranteeing that tenant A can never see tenant B's subscribers, that a premiere event on tenant C cannot starve tenant D's playback, that a custom domain gets a valid TLS certificate without a human touching it, and that the same encoder farm, packager fleet, and CDN contracts serve 120 different brands with different entitlement rules, ad policies, and rights windows.
Why the problem is distinctive
A consumer service treats tenancy as a non-issue: one user database, one catalog, one theme. A white-label service treats tenancy as the primary architectural dimension. Every request carries a tenant context. Every storage key, cache key, JWT, CDN path, webhook, and metric label is namespaced by tenant. Every quota is per-tenant. Every failure question starts with "which tenant, and can it cross the boundary?"
The second distinction is who pays and who is liable. The subscriber's contract is with the tenant, not with us. The tenant owns content rights, age ratings, and regional licensing. We own availability, isolation, and correctness of the machinery. That split shows up everywhere: per-tenant DRM policies, per-tenant geo-blocks derived from the tenant's rights (not ours), per-tenant data processing agreements under GDPR, and an offboarding workflow that must prove complete data separation when a tenant leaves.
Public operating baseline versus design assumptions
Public evidence establishes that this category is a real, scaled business. Disney's streaming stack descends from MLB Advanced Media, whose BAMTech spin-out powered HBO Now, WWE Network, NHL.tv, and PGA Tour streaming before Disney bought the majority stake for $1 billion in 2016 and used the same platform to launch ESPN+ in 2018 and Disney+ in 2019. Brightcove, a publicly traded video platform-as-a-service company, reports roughly one thousand customers in more than seventy countries. Mux reports that its data product monitors billions of video plays per month across its customer base. Vimeo OTT markets itself as powering thousands of subscription streaming services. These are cited public figures for context, not our design targets.
For capacity planning, this answer explicitly assumes a mature mid-size platform with 120 tenants (100 small networks, 15 mid-size, 5 enterprise), 25 million total subscribers across all tenants, 3 million daily active viewers, 600,000 peak concurrent streams, a 150,000-title VOD library, 200 concurrent live channels, and a 5x event peak for premieres. Unless tied to a citation, every number in this answer is a stated design assumption, target, or budget.
The four architectural planes
- Tenant control plane: tenant lifecycle, branding configuration, custom domains, feature flags, plan tiers, API keys, webhooks, and billing metering.
- Content plane: ingest, validation, encoding, packaging, catalog versioning, and rights metadata, all tenant-namespaced.
- Identity and entitlement plane: per-tenant subscriber realms, authentication, subscriptions, entitlements, and playback authorization.
- Delivery plane: origin packaging, signed URLs, DRM licensing, CDN distribution, ad insertion, and playback telemetry.
A strong answer keeps these planes separate. The delivery plane must keep playing even when the control plane degrades. A tenant's configuration error must never poison another tenant's delivery. The learning feedback loop (analytics, QoE) feeds tenant dashboards but never crosses tenant boundaries into another brand's data.
Key Highlights
- •The product is safe multiplexing: every key, token, quota, and metric is tenant-namespaced.
- •Disney's BAMTech lineage (HBO Now, WWE Network, ESPN+, Disney+) proves the white-label platform model at scale.
- •Assumed mature platform: 120 tenants, 25M subscribers, 3M DAU, 600K peak concurrent streams.
- •Four planes: tenant control, content, identity/entitlement, delivery. Degradation order protects delivery first.
- •The subscriber's contract is with the tenant; we own isolation, availability, and machinery correctness.
Section Rescue Kit
Buzzwords to use:
Safe statements:
- "I will separate the platform's customers (tenants) from the tenants' customers (subscribers) before drawing any service."
- "Before choosing technologies, let me define what isolation means for data, identity, delivery, and cost."