Inside Hulu’s Cloud Architecture: A 1,000‑Foot View of Microservices and Scale

As the chief architect at Hulu, I aim to map our technical landscape for the tech community, providing a 1,000‑foot view of our systems and setting context for upcoming deep‑dive articles.

Hulu is a video streaming service offering a vast catalog of TV episodes, movies, original programs, and a live TV offering with 50+ channels and cloud DVR, all delivered through a highly personalized user interface.

Our backend relies on an extensive microservice architecture hosted on our proprietary PaaS called Donki, which can target both on‑premise data centers and AWS. Donki, written in Python, supports multiple languages and provides managed services such as databases and queues via our DSI infrastructure team.

Donki enables us to switch between AWS and our own data center based on agility, elasticity, cost, and workload considerations, allowing rapid scaling—for example, during a live launch we quickly provisioned AWS capacity as a backup.

We continuously run smoke tests using an internal system called Homez, which alerts on‑call teams and displays real‑time status on a dashboard mapped to our architecture diagrams.

Machine learning is central to Hulu’s business: we employ advanced models for video understanding, personalized recommendations, ad optimization, spam detection, and data science. Our scalable data pipelines process over 13 petabytes of first‑ and third‑party data, and we experiment with real‑time influence and deep learning techniques.

On the functional side, we operate a VOD architecture complemented by a live‑streaming architecture, which required rebuilding substantial parts of the system, creating a new metadata catalog for live and VOD content, and handling SCTE‑224 and SCTE‑35 markers for program timing.

Hulu offers two VOD tiers—ad‑supported and ad‑free—managed by our ad server and CMS, giving us control over ad inventory and future capabilities for live streaming.

Our services are written in various languages (Python, Java, Scala, Go, C++, etc.) and communicate via REST, described with Swagger. We have an emerging architectural process called HOOP to increase visibility of technical decisions and provide engineers with self‑service tools for consensus.

Engineering is distributed across four primary locations: Santa Monica (services), Beijing (research, data science, recommendations), Seattle (client work), and a Marin County center of excellence staffed by game‑engineering veterans supporting infrastructure for many client platforms, including iOS, Roku, VR, and even legacy devices.

We face challenges such as data encapsulation in our microservice architecture, scaling engineering teams, and empowering engineers to work effectively as we continue to grow.

This overview sets the stage for future articles on personalization, content discovery, microservice management, and other technical topics, including research‑focused posts on our most difficult engineering problems.