Fastly is an edge cloud platform commonly used to deliver HTTP content closer to viewers. In a live-video system, that usually places it after the packager or origin: it can distribute manifests, segments, player files, and APIs, while contribution protocols, switching, monitoring, recording, and stream recovery remain separate jobs.
Fastly’s place in a live workflow
Think of the path as two connected systems. The production side receives and controls live feeds. The delivery side serves the resulting HTTP media to an audience. Fastly can be part of the second system; it is not automatically the SRT receiver, encoder, packager, origin, or production control plane. Callaba can handle contribution, routing, monitoring, failover, recording, and other production operations before a compatible delivery origin or platform serves the output.
The moving markers represent media advancing from contribution to audience delivery. A CDN changes where HTTP responses are served; it does not remove the need to operate the upstream live workflow.
Start with the job, not the vendor name
A CDN answers a delivery problem: many viewers need HTTP responses, often from locations far from the origin. The edge can reuse cacheable responses and avoid sending every request back to the origin. That can improve consistency for viewers and reduce repeated work upstream, provided the cache keys, freshness rules, authentication, and media packaging are designed correctly.
A production platform answers a different problem. It receives live sources, shows operators whether they are healthy, changes routes, starts recordings, switches to backup feeds, and prepares outputs. These tasks happen before a viewer asks for an HLS playlist or segment. A video architecture may use both systems, but substituting one label for the other creates blind spots during an incident.
A good Fastly-shaped problem
Large or geographically distributed audiences request the same cacheable player assets, manifests, media segments, thumbnails, or APIs from an HTTP origin.
A Callaba-shaped problem
Remote encoders send SRT or RTMP feeds that operators need to inspect, route, record, fail over, restream, or watch in a browser Multiview.
A combined problem
The team needs a controlled contribution path and scalable HTTP delivery. Define the handoff explicitly: format, URL ownership, authentication, cache policy, health checks, and escalation owner.
Follow one viewer request from player to origin
When a player requests an HTTP object, the request reaches a Fastly point of presence. If a fresh matching object is available in cache, the edge can serve it without returning to the origin. If it is not available, Fastly fetches from a configured backend, applies the service’s caching behavior, and returns the response. Fastly’s documentation describes this as a read-through HTTP cache and notes support for features such as request collapsing, revalidation, streaming miss, and purging.
For live video, the object type matters. A player application and long-lived graphic can tolerate a long cache lifetime. A media segment is often immutable once published, so a versioned segment URL can also be cached confidently. A live manifest changes frequently and usually needs a much shorter freshness policy. A personalized or access-controlled response may need special cache-key logic or may not be cacheable at all.
This is why “put a CDN in front” is not a complete design. Write down the expected behavior for a hit, a miss, an expired object, an unavailable origin, a late segment, a purge, and an authenticated viewer. Then test those behaviors with the real player and real packaging cadence rather than only loading a static test file.
| Object | Typical concern | Question to answer before launch |
|---|---|---|
| Player application | Versioning and rollback | Can a new build be purged or referenced by a new immutable URL without stranding active viewers? |
| Live manifest | Freshness | How quickly must the player see a new segment or discontinuity, and what happens when the origin is briefly late? |
| Media segment | Cacheability and naming | Is the URL immutable, and can many viewers safely receive the same response? |
| Authorization response | Privacy and cache key | Could one viewer ever receive another viewer’s personalized response? |
| API or telemetry | Staleness | Is the response safe to cache at all, and is its freshness visible to the client? |
Cache policy is part of the broadcast design
Fastly follows HTTP caching semantics with documented platform behavior. The origin’s response headers, service configuration, cache key, and VCL or Compute logic determine whether an object is reusable and for how long. Treat those rules as production configuration, not a late performance tweak.
Avoid embedding black-box assumptions in the player. Instead, record which team owns segment naming, manifest headers, token validation, purge behavior, and origin failover. Test a real program transition and an encoder restart. A cache may be behaving exactly as configured while still delivering a stale manifest because the application’s freshness policy was wrong.
Fastly also documents request collapsing: simultaneous requests for the same missing object can wait behind one origin fetch. That can protect the origin from a cache stampede, but uncacheable responses and slow backends require careful handling. The feature is not a reason to let an origin run at its limit. It is one control in a larger capacity and failure plan.
Streaming miss relays bytes as Fastly receives them instead of waiting for the complete origin response. The name can sound like a live-video ingest feature, but Fastly describes it as behavior for a standard HTTP request and response. It does not turn an edge cache into an SRT listener, video encoder, or production switcher.
Shielding can reduce repeated work at the origin
Without shielding, edge locations can independently fetch missing objects from the origin. Fastly’s shielding model routes those backend requests through a selected shield point of presence, giving the service another place to find or consolidate an object before reaching the origin. Fastly says shielding can reduce origin load and improve cache-hit probability, while also noting that configuration and bandwidth accounting need to be understood.
For a live service, the shield choice belongs in an end-to-end latency and resilience review. Place it with awareness of the origin location, expected audience, backend connection behavior, and failure procedures. A shield is not an origin replica. If the packager stops publishing new media, the edge cannot manufacture the next segment. If a manifest points to a missing segment, the audience still has a media continuity problem.
Contribution fails
The encoder, venue link, or SRT session becomes unhealthy. Inspect the production feed, transport statistics, alternate input, and failover state before blaming HTTP delivery.
Packaging or origin fails
New manifests or segments stop appearing. Check the handoff from production, packager health, storage, timestamps, and backend response before changing edge cache rules.
Audience delivery fails
The origin has valid current media, but a region or device cannot play it. Inspect cache status, response headers, DNS, TLS, token behavior, player logs, and regional reachability.
A preflight for teams joining production and CDN delivery
Draw the ownership boundary
Name the contribution receiver, processing and routing layer, packager, origin, Fastly service, DNS owner, player, and on-call contact. Put the handoff URL and expected media format in the runbook.
Classify every HTTP object
For manifests, segments, player assets, authorization responses, and APIs, document whether the object is public or personalized, mutable or immutable, and how quickly a change must reach viewers.
Prove cache behavior
Record response headers and cache status for first request, repeat request, expiry, revalidation, and purge. Test more than one region when regional delivery is part of the promise.
Load the origin realistically
Model cache misses, manifest request frequency, startup bursts, token checks, and event concurrency. Confirm that request collapsing or shielding is helpful without treating either feature as unlimited capacity.
Rehearse stale and missing media
Delay a segment, stop the packager, restart the origin, and force a production source change. Observe what viewers see, how long recovery takes, and which system raises the first useful alert.
Correlate both sides of the handoff
Use common timestamps. Keep Callaba input and route health beside origin logs, Fastly delivery data, and player errors so the incident commander can identify the first failing stage.
Where Callaba continues the architecture
Callaba sits on the live-production side of this design. A team can receive SRT and RTMP contribution feeds, inspect live transport health, watch sources in Multiview, route media, and record the event. For supported SRT PULL recovery workflows, operators can also prepare primary and alternate upstream routes. The appropriate downstream output depends on the delivery stack: some workflows restream to an external platform, while others feed a separate packager and HTTP origin.
The practical value is separation of evidence. If the Callaba input and controlled output remain healthy while viewer playback fails, the team can investigate packaging, origin, edge delivery, or the player with an intact upstream record. If transport health deteriorates before the output, the team can protect the program with a tested alternate SRT source where that recovery workflow has been configured.
Design the interface rather than assuming it. Confirm supported protocols and media formats at each boundary, decide who creates the HTTP presentation, and test the exact integration before promising production availability. Callaba’s role is not to make every downstream vendor interchangeable; it is to give operators control and visibility over the live feeds they hand to the next system.
Primary references
Prove the production path before scaling delivery
Build one complete rehearsal from contribution input to final player, make every ownership boundary observable, and test the failure that each team is expected to recover.
