Library / Case Studies
Justin.tv's Live Video Broadcasting Architecture - High Scalability -
The future is live. The future is real-time. The future is now. That's the hype anyway. And as ...
By High Scalability engineers · High Scalability · Added 2026-10-12
All content belongs to High Scalability engineers / High Scalability. We only link to it and give credit. Report a problem
Learn this case study
About 37 min left. Your work is saved as you go.
What you are about to study
High Scalability explains a real system. You should know the basics: caching, queues and replication.
Ideas you will meet
- Distributed Systems
- Consensus, time, failure and the fundamentals of scale-out.
What we already know about this
Our own lessons on these ideas. Read them here before you start, so it makes sense.
System Design Foundations · 11 minNetworking, APIs and CDNsWhat happens between a click and your server: DNS, HTTP, API styles, and how a CDN moves content closer to users.Read here
The journey of a request
Before your code runs, a lot happens. When a browser loads
https://shop.example.com:100%Figure SDA-FND-09-1 · Request journey: DNS, CDN, origin · © forcsguy.com
- DNS turns the name into an IP address. Answers are cached at several levels for a time given by the record's TTL, so changes spread gradually.
- A connection is opened (TCP) and secured (TLS). Each step costs round trips, so long distances hurt.
- HTTP carries the request and response.
Latency is mostly physics: a round trip across an ocean costs over 100 ms no matter how fast your code is. The only fixes are fewer round trips and moving data closer to the user.
Image: Syced · CC0 · Source · Wikimedia Commons: Fujikura optic fiber at Science MuseumName lookup is a short chain of questions, each answered by a more specific server:
100%Figure SDA-FND-09-2 · How a name becomes an address · © forcsguy.com
Image: Howe's Adventures & Achievements of Americans · Public domain · Source · Wikimedia Commons: Transatlantic submarine cable mapCDNs
A content delivery network is a worldwide set of servers (edges) that keep copies of your content close to users.
- Great for static files: images, video, scripts, stylesheets, and often whole pages that rarely change.
- Cuts latency, absorbs traffic spikes and shields your origin from load.
- Controlled by cache headers (
Cache-Control: max-age=...) and purge APIs when content changes. - Use a versioned file name (
app.3f9a.js) so you can cache for a year and still ship updates instantly.
100%Figure SDA-FND-09-3 · Content delivery in tiers · © forcsguy.com
Before: everyone goes to the origin
100%After: a CDN serves copies near users
100%What changed
- Users get files from a nearby location
- The origin handles far fewer requests
- Changed files need invalidation or versioned names
Choosing an API style
Style Strength Watch out for REST over HTTP/JSON Simple, cacheable, universal Over-fetching, many round trips for complex screens GraphQL Client asks for exactly the fields it needs Query cost control, caching is harder gRPC Fast binary protocol, strong contracts Needs tooling, awkward in browsers SOAP XML messages with a formal contract (WSDL) and built-in standards for security and transactions, still common in banks and older enterprise systems Verbose, heavier tooling, rarely chosen for new public APIs WebSockets / SSE Server can push live updates Long-lived connections need extra capacity and care A good default is REST for public APIs, gRPC between internal services if you need speed, and WebSockets only where live push is truly needed.
Designing good APIs
- Version them so old clients keep working.
- Paginate list endpoints (cursor-based pagination stays stable as data changes).
- Make writes idempotent with idempotency keys, so a retry does not double-charge.
- Return clear errors with correct status codes.
- Authenticate and rate limit at the edge, often in an API gateway that also handles routing, logging and TLS.
100%Figure SDA-FND-09-4 · API gateway in front of services · © forcsguy.com
More on this site
Related reading
- High Performance Browser NetworkingIlya Grigorik · O'ReillyBooks
- HTTP/3: the past, the present, and the futureCloudflareBlogs
- MDN: HTTP cachingMDN contributors · MozillaDocumentation
- Cloudflare BlogCloudflare engineers · CloudflareBlogs
Show 6 moreShow fewer
- The Road to QUICCloudflareBlogs
- Flannel: An Application-Level Edge Cache to Make Slack ScaleSlack Engineering · SlackCase Studies
- Cloudflare Learning Center: What is a CDN?CloudflareDocumentation
- Cloudflare EngineeringCloudflare engineers · CloudflareBlogs
- Justin.tv's Live Video Broadcasting Architecture - High Scalability -High Scalability engineers · High ScalabilityCase Studies
- Service Workers at SlackSlack engineers · SlackCase Studies
Go deeper on this
A path through videos, articles, other case studies and code on the same ideas as Justin.tv's Live Video Broadcasting Architecture - High Scalability -.
Warm upGet the vocabulary first.
Books · Free from the author
Concurrent and Distributed Systems (Cambridge lecture notes)
Eight lectures on time, broadcast, replication, consensus and transactions, with notes, slides and video. Free from the author under CC BY-SA.
University of CambridgeIntermediate
Books · Free from the author
Computer Networks: A Systems Approach
How networks are built and why: protocols, routing, congestion control and the internet's architecture. The authors publish it free online under CC BY 4.0.
Systems ApproachIntermediate
WatchHow others solve the same problem, on video.
Videos belong to their creators and play from YouTube. More on YouTube (opens in a new tab)
ReadEngineers explain it in their own words.
Blogs · Free from the author · Read here
Scalable Web Architecture and Distributed Systems
A full chapter on the building blocks of large websites: availability, performance, reliability, scalability, caches, proxies, indexes, load balancers and queues. Free to read here under CC BY 3.0.
The Architecture of Open Source ApplicationsBeginner40 min
Papers · Read here
Facebook’s photo storage
This paper describes Haystack, an object storage system optimized for Facebook’s Photos application. Facebook currently stores over 260 billion images, which translates to over 20 petabytes of data.
USENIXIntermediate
See it in another companyThe same ideas, a different system.
Case Studies · Read here
Aroma: Using ML for Code Recommendation at Facebook
Thousands of engineers write the code to create our apps, which serve billions of people worldwide. This is no trivial task—our services have grown so diverse and complex that the codebase contains…
FacebookIntermediate
Case Studies · Read here
Brooklin: Distributed Service for Near Real-Time Data Streaming at LinkedIn
Brooklin—a distributed service for streaming data in near real-time and at scale—has been running in production at LinkedIn since 2016, powering thousands of data streams and over 2 trillion messages per day. Today, w...
LinkedInIntermediate
Read the codeSee how it looks when it is real.
GitHub
Engineering Blogs
A huge directory of company engineering blogs to learn from real production systems.
kilimchoiIntermediate
GitHub
Awesome Scalability
Curated reading list of articles on the architecture of scalable, reliable systems.
binhnguyennusIntermediate
Keep learning
Loading community…