The difficult part was not only getting a title approved and delivered. The difficult part was handling everything that could change afterwards.

A title could receive a new subtitle or dubbing version. A display period could be extended. Rights could change. A piece of content could be removed. A technical specification could require another file order. Any of those changes could affect licensing, file preparation, or delivery.

That meant the platform could not behave like a simple linear order system. It had to support a continuous operational lifecycle across rights, licensing, content metadata, and delivery workflows.

The scale also mattered. The platform had to support more than 15 airlines, more than 200,000 content items, and more than 250,000 rights records. Account teams needed to work quickly across large content selections without turning the approval process into a single large bottleneck.

Working closely with the client, we chose a microservices architecture with an event-driven approach.

The reason was not architecture for its own sake. The business areas had different users, responsibilities, scaling needs, and change patterns. Account managers, operations teams, licensing teams, delivery teams, and content specialists all needed to work with the same content lifecycle, but not in the same way.

Microservices allowed us to separate those business areas while keeping them connected through events. The event-driven model helped the system react to changes in rights, content, licenses, and file orders without forcing every process into one tightly coupled application.

Azure was a natural platform choice because the client already operated there. The platform used Azure services including Service Bus, Event Grid, Container Apps, Azure Functions, Cosmos DB, Azure AI Search, and Azure B2C. The application stack included Node.js, TypeScript, React, Next.js, Fluent UI, Elasticsearch, Docker, Terraform, Azure DevOps, and infrastructure as code.

We started by building the Core service: a shared foundation for data that multiple parts of the platform depended on.

This included client configuration, airline-specific setup, and language management. Language handling is especially important in IFE, where subtitles, dubbing, regional requirements, aircraft configuration, and content versions all influence what can actually be shown onboard.

By creating a dedicated Core service, we avoided duplicating shared configuration across the system and gave the other services a reliable base to build on.

The Rights area was designed to help airline account teams decide what should go onboard.

Fast and reliable search was essential. Although a Content service already existed, we decided to decouple the rights workflow from it. The two areas used similar data, but they served different users and different operational needs. We did not want the Content service to be pulled in two directions: content library management on one side and account-team operational workflows on the other.

A key product decision was to move approval down to the single-title level. Account teams could not efficiently approve thousands of titles as one large batch. Title-level approval made the process easier to distribute, easier to track, and better suited to the delivery phases that followed.

Approval was performed by airline account teams. Once a title was approved, the platform could trigger the next steps: license creation and file order creation.

But approval was not the end of the lifecycle. Rights could change. Subtitles or dubbing could be added. Content metadata could be updated. Each of those changes could affect licensing or delivery.

The system therefore treated rights approval as part of a larger operational process, not as a static final state.

For the Licensing service, we started by mapping the business process in detail.

The key question was how a license should react to changes happening in Rights and Content. A rights update could affect the license. A new language version could influence what needed to be tracked. A changed play period could require an update. A removed title could change the status of an existing licensing process.

This workflow was more complex than it first appeared. Licensing movies and TV content is not comparable to a standard e-commerce order. It involves contractual conditions, play periods, approvals, operational exceptions, payment status, and dependencies across several teams.

The File Delivery service allowed teams to fulfill, track, and investigate file orders that were automatically created.

Its role was to connect approved rights, airline requirements, technical specifications, and media preparation workflows. When a title was approved, file orders could be created. When subtitles or dubbing changed, a new file delivery workflow could be required.

Actual encoding was handled by external systems based on technical specifications established in the platform. Some of those systems could be integrated through APIs. Others could not. The platform therefore had to support both automated integrations and operational workflows for cases where full system-to-system integration was not possible.

This made File Delivery both a technical service and an operational control layer. It helped teams understand what had been ordered, what had been fulfilled, what was blocked, and where investigation was needed.

Because the platform coordinated several services and external systems, failure handling was an important part of the design.

Some issues could be handled automatically through retries. When retries were exhausted, monitoring and notification mechanisms informed the relevant team that manual investigation was needed.

This was especially important in file delivery and licensing workflows, where a failed update could block downstream work. The goal was not to hide operational complexity, but to make it visible, trackable, and recoverable.

The rebuilt platform is live in production and continues to be expanded by our team.

It replaced a legacy operational system with a cloud-native platform designed around the realities of IFE: large content catalogues, changing rights, language versions, licensing status, file delivery workflows, and airline-specific configurations.

The system supports more than 15 airlines, more than 200,000 content items, and more than 250,000 rights records. It also supports licensing workflows representing millions of dollars in business value.

Most importantly, it gave the client a platform that could keep evolving. New workflows, integrations, operational rules, and business changes could be added without forcing every part of the system into the same release cycle or the same scaling model.