Audacy:
Streaming Platform Architecture

Audacy is one of the largest streaming audio platforms in the country — podcasts, live radio, news, sports, music — serving millions of listeners across web, iOS, Android, Alexa, CarPlay, Android Auto, and Roku. The engineering team was shipping features. The problem was that they were shipping without a shared architectural language.

Product wanted to add video streaming to the platform. Engineering was building features across seven different client applications. Content and advertising teams needed to understand how their systems connected. But there was no single map of how the platform worked as a system — no shared vocabulary for talking about containers, components, dependencies, or data flows. Architecture decisions happened in conversations that weren't documented.

The engagement started with a clear need: give this team a shared architectural model they can point at, plan from, and build on. Then use that model to design the video streaming roadmap. Then build.

The first step was mapping what already existed. I built C4 models of the entire streaming platform — starting at Level 1 (System Context) to show how the platform connected to content providers, advertising networks, CDN infrastructure, identity services, analytics, and the seven client applications that listeners used. Then Level 2 (Containers) to detail the internal systems: the media delivery pipeline, the API gateway layer, the search and content services, and how data flowed between them.

For the first time, product and engineering could point at the same diagram and have the same conversation. A product manager asking “what does it take to add video?” could see exactly which containers were affected, which external systems needed integration, and where the complexity lived. An engineer planning a feature could trace the data flow from content ingestion through delivery to the client apps.

With the existing platform mapped, I designed the video streaming architecture as a four-phase roadmap — each phase with its own C4 models at Levels 1, 2, and 3. Phase 1 delivered an MVP with basic video streaming and ad insertion through Brightcove. Phase 2 added enhanced player features, improved ad targeting, and deeper analytics. Phase 3 introduced personalization and social features. Phase 4 expanded monetization with subscription tiers and dynamic ad insertion.

Each phase was architecturally self-contained — it could ship independently and provide value — but designed to build on the previous phase without rework. The architecture documents included not just the diagrams but the rationale behind every decision, the data models for new entities, and the component specifications that engineering would implement.

The C4 models became the team's shared operating system for architectural decisions. When a new feature was proposed, the first question became “where does it live in the C2?” — not “let's have a meeting to figure out how the system works.” Integration bottlenecks that had slowed every cross-team project disappeared because the dependencies were visible in the diagrams before anyone wrote code.

The feature-level architecture documents — with component specs, data models, and API contracts — translated directly into Jira tickets. Engineers didn't have to reverse-engineer the intent from a requirements doc. The architecture told them what to build, how it connected to everything else, and why each decision was made. I wrote the tickets and then coded alongside the team to build the features.

Project velocity increased by 40%. Not because the team worked harder — because they stopped spending time figuring out how the system worked and started spending time building on it.