Building IBBE Heirloom: A Multi-Channel Streaming Server Architecture
How I designed and built an automated streaming infrastructure that broadcasts pre-recorded videos as live events across multiple platforms simultaneously, eliminating manual intervention and maximizing reach for our company events.
I built this architecture diagram for IBBE Heirloom, our internal multi-channel streaming server that transforms a single pre-recorded video into simultaneous live streams across multiple platforms. The diagram I've attached visualizes every component, data flow, and integration point in the system. What started as a need to stream our annual company event has evolved into a robust broadcasting infrastructure that handles scheduling, multi-platform distribution, real-time monitoring, and post-stream analytics completely autonomously. The architecture prioritizes reliability and scalability while keeping operational costs predictable, with an estimated annual running cost of around ₹172,000 for our use case.
The user flow is intentionally simple. I log into the dashboard (hosted on AWS Amplify), upload a video file to S3 storage, configure the stream settings like title and description, select which platforms to broadcast to, and set the scheduled date and time. That's it. I can close my laptop and walk away. The system takes over from there, handling everything automatically. This simplicity on the frontend masks significant complexity on the backend, but that's exactly the point: I wanted zero operational burden on event day. No need to keep a computer running OBS, no manual triggering, no babysitting the stream. Just schedule it and trust the infrastructure.
The orchestration begins with EventBridge, which acts as the system's clock. Every minute, it checks for streams scheduled to go live and pushes jobs to an SQS queue when it finds matches. The backend API service, running as containerized tasks on ECS Fargate behind an Application Load Balancer, consumes these jobs and kicks off the streaming process. It provisions an EC2 worker instance (t3.medium for 1080p streams, t3.large for 4K), which fetches the video file from S3 and begins processing. This is where FFmpeg enters: it reads the video file in real-time mode, ensuring the stream plays at the correct speed rather than processing it as fast as possible. FFmpeg outputs to nginx-rtmp, our multi-destination fanout server.
nginx-rtmp is the heart of the multi-channel broadcasting capability. It takes the single FFmpeg output and replicates it to every configured destination simultaneously. One stream goes to Mux, which handles adaptive bitrate streaming and serves our website's embedded player with professional CDN delivery. The other streams go directly via RTMP to YouTube, Facebook, Twitch, LinkedIn, and any custom RTMP endpoints I've configured in the system. This fanout architecture means I can add unlimited streaming destinations without impacting performance or requiring separate encoding processes. Each platform receives the same high-quality stream at the same moment, maximizing our reach and ensuring consistent viewer experience across all channels. If one platform fails (say, YouTube's API rate limits us), the stream continues uninterrupted to all other destinations.
The data layer underpins everything. PostgreSQL stores all persistent data: user accounts, video metadata, stream configurations, channel credentials, and analytics. Redis caches frequently accessed data like channel configurations and platform tokens, reducing database load and speeding up API responses. AWS Secrets Manager securely stores sensitive credentials for Mux, YouTube OAuth tokens, and custom RTMP keys, ensuring nothing sensitive ever touches our codebase or logs. CloudWatch monitors infrastructure health, tracking metrics like API response times, database connection counts, and EC2 worker status. Sentry catches application errors in real-time, immediately alerting me if something breaks during a stream. This monitoring stack gives me complete visibility into system health and ensures I can respond quickly if issues arise. The entire architecture is designed to fail gracefully: if a component fails, it retries automatically, and if that fails, it notifies me with enough context to debug and resolve the issue quickly.