Nortik

Case Study · ProSieben Joyn

Streaming atOlympic scale.

Joyn is where Germany and Austria watch television. Discover how we successfully optimized the system to handle 450K concurrent streams for sixteen days of live Olympic coverage without dropping a frame.

Peak concurrent streams
450KPeak concurrent streams
Of live Olympic coverage
16 daysOf live Olympic coverage
Monthly viewers
12MMonthly viewers

Engagement Overview

Joyn GmbH is a joint venture between Discovery and ProSiebenSat.1 Media, and it runs the streaming service of the same name. Joyn puts ad-supported catch-up, a paid subscription tier and dozens of live TV channels in one app, across Germany and Austria, for around twelve million people every month.

Behind that app sits a fleet of microservices, each with one job: mapping asset metadata, calculating what to suggest next, working out the EPG schedules, exporting catalogues to partners like Apple TV and Google TV. Every client, phone, browser or television, reaches all of it through a single GraphQL endpoint. Nortik engineers joined on the platform side and worked inside that fleet.

450K
Peak concurrent streams
16 days
Of live Olympic coverage
12M
Monthly viewers
Engagement
Embedded engineering team
Team
2 Software Engineers
Focus
Microservices, GraphQL API, personalization & EPG
Working model
Inside Joyn's engineering team, timeline and sprints

Stack

Backend & APIs

  • Node.js
  • GraphQL
  • Apache Kafka

Data & storage

  • PostgreSQL
  • Redis
  • Elasticsearch

Infrastructure & DevOps

  • AWS
  • Terraform
  • Multi-CDN
A wall of Joyn poster tiles, rows of films and series side by side

The Challenge

Joyn is three products wearing one coat. Ad-supported catch-up, a paid subscription tier, and dozens of live channels, all in the same app, in two countries, for around twelve million people a month. Every surface asks the backend a different question, every question arrives through the same GraphQL endpoint, and dozens of media partners feed the catalogue underneath it, each with its own metadata shape and its own rules. A slow answer anywhere is a slow app everywhere.

Then there is the peak. Streaming load is not a curve, it is a cliff. An Olympic final puts hundreds of thousands of people on the same stream inside about ninety seconds, and every one of them expects the picture to start instantly. Build for that all year and you pay for capacity nobody uses. Build for the average and the one night that matters is the night you go down. Underneath both sits the schedule, because something has to say what is on air at 20:15 on every channel, with rights windows opening and closing, and be right in the app, in the guide, and in the recording that starts the moment the show does. Feeds arrive late. Feeds arrive wrong. Matches run long anyway.

The Solution

The platform is a fleet of small services, each with one job, all of them answering through one endpoint. Four parts of that fleet did the most work for viewers.

Joyn channel tiles rushing toward a screen, the platform's channel wall

One endpoint over a fleet of services

Every Joyn client, whether it is a phone, a browser, a smart TV or a set-top box, asks for what it needs through a single GraphQL endpoint. Behind that endpoint sits a fleet of microservices, each owning exactly one job and nothing else. That shape is what makes a peak survivable: the services under pressure on an Olympic night are not the ones serving the catalogue, so they scale on their own and they fail on their own. Origin shielding keeps a surge on cache instead of the packagers, multi-CDN steering moves viewers off a struggling edge before they feel it, and capacity warms ahead of a known kickoff and drains again after. Four hundred and fifty thousand people watched at once, and the app in their hands never knew anything unusual was happening.

  • Microservices
  • GraphQL API
  • Live-Event Architecture
  • Multi-CDN
The Joyn home screen: rows of series and film posters grouped into lanes

Personalized content, lane by lane

The home screen is not a fixed page. Content is grouped into lanes, and the lanes themselves are calculated: a dedicated layout service works out which lanes a given viewer sees, in what order, and what belongs inside each one. Editors and product teams can change the shape of the page per market and per tier without anyone shipping a client release, because the clients stay deliberately simple and render whatever layout data they are handed. Redis sits in front of the whole thing, so a home screen assembled per viewer still opens the instant the app does.

  • Personalization
  • Layout Service
  • Content Lanes
  • Redis
Joyn's programme grid: channels down the side, the evening's schedule across

On-demand and live, in one guide

The unusual thing about Joyn is that series, films and live channels sit next to each other, and viewers move between them without ever thinking about which is which. Making that feel effortless takes a service whose only job is calculating EPG schedules. Programme feeds arrive from many sources and none of them agree, so each one is normalised into a single timeline per channel, conflicts resolve by source priority, and rights windows are applied before anything reaches a viewer. Programme managers get a grid they can correct by hand, and the correction propagates in seconds rather than waiting for the next import. When a live event overruns, the timeline shifts and the guide, the catch-up and the recordings all shift with it.

  • EPG Scheduling
  • Programme Timeline
  • Rights Windows
  • Live TV
The Joyn app with its media libraries navigation above a featured banner

A media library for every partner

Joyn carries content from dozens of media partners, and each of them gets its own media library inside the app. Every partner also arrives with its own metadata shape, its own artwork rules and its own idea of what counts as a season, so a mapping layer normalises all of it into one asset model before a viewer ever sees it, with Elasticsearch on top so any of it can be found. The same model feeds the other direction too: catalogue data is exported out to partners like Apple TV and Google TV, which is how a Joyn title turns up on the platforms people already search on.

  • Asset Metadata
  • Partner Libraries
  • Catalogue Export
  • Elasticsearch
Joyn on a television, a tablet, a phone and a laptop, all showing the same mark

Business Impact

Joyn carried sixteen straight days of Olympic coverage. The peak was 450,000 concurrent streams, and the platform held. For everyone watching, it was simply television that worked.

The lasting result is what happened after. In the two years that followed, Joyn grew from ten million monthly users to twelve and a half million, all of it carried on the same architecture, with no rebuild and no migration in between. Peak capacity that had been proven once became headroom the business could keep selling into.

That night is still the bar the platform is measured against. The same fleet carries an ordinary Tuesday, the same single endpoint answers every client from a phone to a television, and the same schedule service still gives one answer to what is on air, in two countries, right now.

View it from our angle.

Get In Touch
Filip ĆurčićNortik logo
Filip Ćurčić
Sr. Software Engineer, Nortik
Working on Joyn was my first encounter with a Netflix-level software architecture, and the EPG was one of the hardest parts of it. The app has to know what is playing on every channel at any minute, but that schedule comes from dozens of partners who rarely agree. Today I look at live streaming platforms differently.

Nortik’s Impact

The EPG scheduling service behind Joyn's live TV: many partner feeds normalised into one timeline per channel, rights windows applied before anything reaches a viewer, and corrections live in seconds.

Your AI team is ready.Are you?

Let's shape the future of AI, together.