Building the DreamStream Content Management System from the ground up
Architecting a full-stack cloud CMS for an inflight entertainment platform — from content provider onboarding to admin-approved deployment on PIA aircraft — where real passengers streamed content at altitude.
Entertainment at 35,000 feet runs on content — and someone has to manage it
DreamStream is an inflight entertainment platform deployed on Airfi devices — compact servers installed aboard aircraft with a fixed storage allocation. Passengers connect to a local Wi-Fi network and stream movies, music, audiobooks, and ebooks directly from the onboard server. No internet connection. No satellite latency. Just content, loaded before the flight and served locally at altitude.
The hard part isn't the streaming. The hard part is getting the right content onto the right device before the plane takes off — securely, reliably, and at scale. That requires a full content management pipeline: content providers uploading their libraries, admins reviewing and approving, and the final package deploying to Airfi servers.
None of this infrastructure existed. mParsec brought me in as the sole full-stack engineer to architect and build the entire CMS — from the React.js frontend to the AWS Lambda backend to the S3 storage layer — using the AWS Amplify full-stack framework.
The constraint that shaped everything: Airfi devices have a fixed memory ceiling. Every byte matters. The CMS had to not only manage content — it had to manage it precisely, with the right metadata, right formats, and right approval gates, so that only deployment-ready content ever reached the device.
Three actors. One pipeline. Zero tolerance for bad data on a plane.
I structured the entire system around three distinct actors and their responsibilities. Each actor has a defined scope — content providers can only see their own content, admins have full oversight, and Airfi devices only receive approved packages. This boundary design was a deliberate architectural decision, not an afterthought.
Layer 1 — Content ingestion
Layer 2 — API & processing
Layer 3 — Review & deployment
AWS Amplify was the backbone. It generates a fully-typed GraphQL API from a database schema definition — meaning the API layer, resolvers, and data models were all generated and maintained from a single source of truth. AWS Lambda functions handled all server-side logic: file validation, metadata processing, content state transitions, and the OneDrive-to-S3 transfer pipeline.
“Schema-first development with Amplify meant the frontend and backend stayed in sync automatically. Every change to the data model propagated to the GraphQL API — no contract drift, no manual mapping.”
Every layer of the stack — designed, built, and shipped by one engineer
As the sole full-stack engineer, my scope covered the entire system: frontend architecture in React.js, backend logic in AWS Lambda, API design with Amplify's GraphQL layer, and the cloud infrastructure on AWS. Here is what I built, feature by feature.
Content provider registration, authentication & authorisation
I implemented the full onboarding flow for content providers using AWS Amplify Auth (backed by Amazon Cognito). Providers register, verify their email, and are issued role-scoped credentials. Authorization rules at the GraphQL layer ensure each provider can only read and write their own content records — enforced at the API level, not the UI level.
Content creation onboarding flow — 6 content types
I designed and built a multi-step content creation form in React.js that adapts dynamically based on content type. A movie form collects IMDB rating, Rotten Tomatoes score, genre, director, and cast. An audiobook form collects author, narrator, and chapters. An ebook collects publisher and ISBN. Each form is validated client-side before a Lambda function processes the submission server-side — preventing malformed records from ever reaching the database.
OneDrive-to-S3 bulk transfer pipeline — GBs in under 60 seconds
This was the most technically demanding piece of the system. Content providers store their libraries on Microsoft OneDrive. Rather than re-uploading files manually, I built a Lambda-powered pipeline that authenticates with the provider's OneDrive via the Microsoft Graph API, streams files in parallel using S3 multipart upload, and transfers entire batches of large media files — movies, high-resolution audio, PDFs — into the DreamStream S3 bucket. The combination of async I/O, multipart chunking, and parallelised Lambda invocations brought transfer time for GB-scale batches down to 60–90 seconds.
Admin review and content approval portal
I built a separate admin-facing React.js dashboard with elevated Cognito role permissions. Admins can browse all submitted content across all providers, preview metadata, and approve or reject individual items. On approval, the content record transitions to a Deployment Ready state. Rejected content is returned to the provider with a reason. Only approved content is eligible for inclusion in the next Airfi device package.
Airfi device deployment packaging
Once content is approved, it is queued for deployment to Airfi servers. I designed the packaging layer to respect the device memory ceiling — grouping approved content into device-sized bundles and generating the manifest files that Airfi servers consume to populate their local libraries before each flight.
A complete content management platform — not a prototype
This wasn't a proof of concept. Every feature below shipped and was used by real content providers to populate real Airfi devices.
Provider registration & auth
Cognito-backed auth with role-scoped access. Providers see only their own content.
Movie content creation
IMDB rating, Rotten Tomatoes, genre, director, cast, runtime, and trailer fields.
Music & audio management
Song and album metadata, genre, artist, and audio file upload with format validation.
Ebook & audiobook ingestion
Author, narrator, publisher, ISBN, chapter count. PDF and audio file formats supported.
OneDrive → S3 bulk transfer
Multipart parallel upload via Graph API + Lambda. GBs transferred in 60–90 seconds.
Admin approval workflow
Full content review queue with approve/reject actions and status propagation back to providers.
The problems that required more than just writing code
Problem
Uploading GB-scale media files via a browser form would time out, saturate memory, and fail for any large library. A simple file input was architecturally inadequate for the scale of content providers' libraries.
Solution
Built a Lambda-orchestrated pipeline that uses the Microsoft Graph API to stream files directly from the provider's OneDrive into S3 using multipart upload — bypassing the browser entirely. Files are chunked, uploaded in parallel, and assembled in S3. The browser only triggers the operation; the heavy lifting happens server-to-server.
Problem
AWS Lambda has a 15-minute execution timeout. Large batch transfers of a full content library could exceed this, leaving transfers in an unknown partial state with no recovery path.
Solution
Designed the transfer pipeline as a fan-out architecture — a coordinator Lambda breaks the OneDrive file list into chunks and invokes individual worker Lambdas per file in parallel. Each worker handles one file independently, so no single Lambda holds the entire batch. The coordinator tracks completion and reports overall status once all workers return.
Problem
Six different content types (movies, songs, audiobooks, ebooks, PDFs, audio) each require completely different metadata fields. A single static form would either be overwhelming or incomplete.
Solution
Built a dynamic form engine in React.js where each content type maps to a schema definition object. The form renders only the relevant fields for the selected type, validates against the schema, and serialises into the correct GraphQL mutation shape before submission. Adding a new content type requires only a new schema entry — no new form component.
Problem
Airfi devices have a fixed memory ceiling. Deploying unapproved, incorrectly-formatted, or oversized content to a device mid-flight would corrupt the entertainment library with no way to roll back.
Solution
Enforced a strict three-gate content lifecycle: format validation at upload, metadata validation at submission, and admin approval before deployment eligibility. No content advances to the next gate without passing the previous one. The deployment package generator only reads from the Approved state — making it structurally impossible to deploy unreviewed content.
The stack that made it work
What shipped — and what it made possible
GB-scale content libraries transferred from OneDrive to S3
The fan-out Lambda pipeline with S3 multipart upload reduced content ingestion time from what would have been hour-long manual uploads to 60–90 second automated transfers — making it practical for providers to refresh their entire library before a flight window.
Content types supported with a single dynamic form engine
Movies, songs, audiobooks, ebooks, PDFs, and audio — all managed through one schema-driven form architecture. New content types can be added without building new form components.
Unapproved content deployable to Airfi devices
The three-gate lifecycle design made deploying unreviewed content structurally impossible — not just policy-enforced. No manual check required; the architecture enforces it.
End-to-end system: registration to deployment, built by one engineer
From provider onboarding to Airfi device packaging — every layer of the stack designed, implemented, and shipped by a single full-stack engineer using AWS Amplify's full-stack framework.
The measure of the system: A content provider with a 10GB movie library can log in, authenticate via OneDrive, trigger a transfer, and have their entire catalogue reviewed-and-deployment-ready — all from a browser, in under two minutes. That's what the architecture was built to enable.
What building for a constrained environment teaches you
Most web applications are elastic — if you need more storage, you provision it; if the page loads slowly, you optimise later. Airfi devices operate in the opposite reality. The memory ceiling is physical and fixed. You can't add storage at 35,000 feet.
That constraint changed how I thought about every design decision on DreamStream. The three-gate content lifecycle, the admin approval layer, the metadata validation at upload — all of it exists because the cost of a mistake isn't a bad user experience. It's a broken entertainment library on a six-hour flight with no recovery path.
The OneDrive-to-S3 pipeline taught me something different: the fastest code is the code that doesn't run in the browser. Moving the transfer server-to-server, breaking it into a fan-out of parallel Lambdas, letting S3's multipart API do the heavy lifting — these decisions turned a fundamentally slow problem into a 60-second operation. Constraints, it turns out, are just architecture problems with a deadline.
Interested in working together?
I build production-grade AI and full-stack systems for international clients.
Get in touch