Modular OTT Architecture

Buy the whole platform and it works on day one. Replace any piece with your own — billing, DRM, recommendations, analytics — and it keeps working. Modular by contract, composable in production.

10+

Independently deployable core services

Services with documented replacement boundaries

Supported deployment topologies

100%

Internal-to-external API parity

Composable, Not Monolithic

Vucos is structured as a set of loosely coupled services — identity, catalog, entitlement, billing, playback, search, recommendation, analytics, DRM, delivery — each with its own data store, API, and release cadence. Every service talks to every other service through the same public API and event contracts. That means operators can adopt the full stack, swap a single module for a vendor they already run, or build and insert their own services without forking the platform.

Why this matters

Operators rarely start from zero. Most have legacy systems — a billing platform tied to ERP, a recommendations engine with five years of training data, an identity provider that regulates single sign-on across the group. A monolithic OTT platform forces the choice between rip-and-replace or a long, expensive shadow IT project to stitch old and new together. Both outcomes end badly.

Modular architecture removes the forced choice. Each Vucos service exposes a clean contract; each can be replaced by an equivalent from the operator's existing stack or the open market. The platform still works because the contracts are public and versioned — so the recommendations service does not care whether entitlement comes from Vucos or the operator's existing CRM, as long as the entitlement contract is satisfied.

How modularity works

Service boundaries

Clear domain boundaries between identity, catalog, entitlement, billing, playback, search, recommendation, analytics, DRM, and delivery. Each service owns its data and exposes a public API.

Contract-driven composition

Services communicate through versioned REST, GraphQL, or event contracts. Implementations can be swapped as long as the contract is respected — no service has hidden knowledge of another's internals.

Independent scaling

Every service scales horizontally on its own profile. Playback entitlement scales for Sunday match kick-off; billing scales for month-end renewal bursts — without over-provisioning the whole platform.

Independent release cadence

Each service ships on its own release train. Hotfixes to DRM do not wait on analytics deployments; feature flags gate any customer-facing change for controlled rollouts.

Build-your-own-stack

Run the full Vucos stack, or pick and mix: Vucos CDN orchestration with an existing billing platform, Vucos analytics with a bespoke recommendations engine. Documented integration points for every service.

Deployment flexibility

Fully managed SaaS, operator-hosted Kubernetes, or hybrid placement of sensitive services (billing, identity) on operator premises with the rest in cloud. One deployment topology per operator.

How operators use it

Telco operator

Keep the billing, swap the rest

Deployed Vucos catalog, playback, DRM, delivery, and analytics while retaining the existing Amdocs billing platform. Vucos billing adapter translates Amdocs subscription state into the entitlement contract — no viewer sees the seam, no finance process changes.

Sports broadcaster

Bring-your-own recommendations

Operator has five years of training data in an internal ML recommendations service. Vucos pipes engagement events to that service and consumes its ranked output through the recommendation contract. The operator's data science team owns the model, Vucos owns everything else.

Regional OTT group

Federated identity across brands

Group runs six consumer brands with a shared loyalty identity. Vucos identity service is swapped for the group's existing OIDC provider; catalog and entitlement services consume the same tokens. New brands launch in weeks rather than quarters because identity is already solved.

Technical details

Core services

Identity & SSO
Catalog & metadata
Entitlement & rights
Billing & payments
Playback & delivery
Search & recommendation
Analytics
DRM key services

Contracts

REST (OpenAPI 3.1)
GraphQL gateway
Event streams (Kafka / Pulsar compatible)
Webhook callbacks
gRPC for high-throughput paths

Deployment models

Fully managed SaaS
Operator-hosted Kubernetes
Hybrid (on-prem + cloud)
Multi-region active-active
Single-region with DR

Replacement boundaries

Billing platform
Identity provider
DRM license service
Recommendation engine
Ad decisioning
Search index

Platform primitives

Service mesh with mTLS
Distributed tracing
Per-service feature flags
Blue/green and canary deploys
Per-tenant isolation

Data independence

Each service owns its schema
Event-sourced state where relevant
No shared database
Tenant-scoped data residency

Key Takeaways

Loosely coupled services with clear domain boundaries and public APIs
REST, GraphQL, and event contracts — no hidden internal protocols
Independent scaling and release cadence per service
Swap billing, identity, DRM, recommendation, or search with your own
Deploy as fully managed SaaS, operator-hosted Kubernetes, or hybrid
Per-tenant isolation with service mesh, mTLS, and distributed tracing

Frequently Asked Questions

How modular is "modular" in practice?

Very. Six Vucos services ship with documented, supported replacement boundaries: billing, identity, DRM license, recommendation, ad decisioning, and search. Beyond those, the contract-first architecture means any service can be swapped with engineering effort — it is not locked behind a runtime coupling.

Doesn't all this modularity slow things down?

Not at the hot paths. Playback entitlement, DRM license issuance, and manifest delivery are optimized end to end with sub-100ms latency budgets. Inter-service calls on those paths are pinned to the same region, use binary protocols, and are measured continuously. The modularity shows up in deployment, not at runtime.

What happens if we swap a service and later want to switch back?

Because both sides speak the same contract, the return trip is symmetrical. Operators have migrated billing adapters back onto Vucos billing after corporate restructuring, and have moved search from Vucos to Elastic and back based on operational preference. Both directions are a matter of configuration, not rebuild.

How do you guarantee coherence when services release independently?

Three mechanisms. Contract tests run in every service's CI against the versioned API specs. Feature flags gate any customer-visible behavior change. And the platform ships integration tests that exercise end-to-end user journeys on every release, catching cross-service regressions before production.

Can we deploy parts of the platform on-prem for regulatory reasons?

Yes. Hybrid is a first-class topology. Operators in regulated markets commonly run identity and billing on-premise while consuming the rest of the platform as SaaS. The deployment graph is declared in code and the platform maintains its guarantees across the boundary.

How is per-tenant isolation handled in a shared deployment?

Every request carries a tenant ID that propagates through authentication, authorization, data access, and telemetry. Database rows are tenant-scoped at the query layer; cache keys are tenant-prefixed; metrics, logs, and traces all carry the tenant ID for audit and noisy-neighbor detection. Dedicated single-tenant deployments are also available where contracts require them.

Ready to learn more?

Talk to an architect about how this fits your deployment.

Book a Call Download Whitepaper