Cases1 case
1 to 1 of 1
IL-0240Cloudflare API requests failed and the dashboard slowed for hours after the authentication database lost its replicasCloudflare2020- Symptoms
On 2 November 2020 the Cloudflare API and dashboard were degraded for six hours and 33 minutes. The success rate of API queries dropped at times to 75%, and the dashboard was up to 80 times slower than normal, while Cloudflare's edge network kept working.
- Trigger
At 14:43 UTC a network switch in a control plane data center partly failed: it kept LACP and BGP running but stopped forwarding some packets, and it recovered on its own six minutes later.
- Root cause
- Component
- Contributing factor
- Detection
At 14:43 UTC alerts fired because the misbehaving switch was unreachable to pings. Engineers then saw that the primary authentication database was overwhelmed.
- Remediation
- Shed load from the primary authentication database by slowing SSL certificate pushes to the edge, emails and other features
- Moved API traffic that could use read replicas to the secondary data center by hand
- Sent authentication calls fully back to the primary data center when the dashboard got worse
- Rebuilt the first database replica, which put itself back into service at 21:20 UTC and returned performance to normal
- Ramped the turned-down services back up so asynchronous processing could catch up
- Action items
- Remove the cluster management limitation that requires rebuilding all replicas after a primary is promoted
- Redesign the user sessions system so dashboard traffic can be steered between data centers
- Change the auto-remediation configuration so a database replica is not promoted so quickly
- Tune each system involved to be more resilient to failures of its dependencies
- Lessons
Every system in the chain had redundancy and none failed completely; each only degraded, which made the chain of events much harder to model and foresee. Automating replica promotion so that it could trigger on a minute's notice had been a point of pride, but for at least one database a fast promotion can do more harm than the failure it answers. Most general-purpose cluster managers use Raft or Paxos rather than Byzantine fault tolerant protocols, accepting a rare failure mode in exchange for a protocol that is simpler to implement correctly and debug.
This case involves Coordination and key-value store and Database. kubegap audits a Kubernetes cluster for gaps like these, read-only, from Claude Code or Codex; its checks cite public reports like the ones in this library.
By root cause1
DNS or network fault1 case
- Component
- Contributing factor
- Organisation