Inspired by Aditya's LinkedIn field note on major CDN outages and the limits of provider switching. View the original post
Every provider can have a bad day
After a major CDN incident, the immediate reaction is often to name a replacement. That can reduce one dependency, but it does not answer the harder question: can the application operate when its normal edge path is unavailable?
Resilience comes from understanding failure modes and preparing a controlled response, not assuming another logo will never fail.
Know what the CDN is doing
A CDN may provide caching, TLS termination, WAF rules, redirects, bot controls, image transformation, edge compute, and origin shielding. A backup path that covers only DNS and caching may still break important behavior.
Inventory the edge features your application depends on, then decide which are essential during a degraded mode and which can be temporarily removed.
Prepare the origin for degraded traffic
Bypassing cache can send a sudden wave of requests to infrastructure sized for a much lower miss rate. Validate origin capacity, connection limits, rate controls, and static fallback options before an incident.
A maintenance page or read-only experience can be a better resilience outcome than an automatic failover that overwhelms the database.
Keep control paths independent
Teams need access to DNS, certificates, origin configuration, and incident communication when the primary provider is impaired. Store runbooks and credentials somewhere that does not depend on the failing path.
Monitor from outside the CDN as well as through provider dashboards. Otherwise an edge failure can look like a healthy origin while users still cannot reach the service.
Test the smallest credible recovery plan
Multi-CDN architecture is not automatically justified for every lean team. It adds cost, configuration drift, and testing work. A simpler plan may combine low DNS TTLs, a validated direct-origin fallback, static status communication, and clear incident ownership.
Choose the recovery design that matches the business cost of downtime, then test it. Untested failover is only another assumption.