Cases2 cases

1 to 2 of 2

1. IL-0353 Fly.io edge proxies in US west coast regions were overloaded and flapping, with lazy loader delays of seconds

   Fly.io2026

   Symptoms

   On 28 May 2026, Fly.io's edges in US west coast regions began flapping, first mainly in SJC. Logs and metrics of fly-proxy, the userspace L4 and L7 load balancer on the edges, showed lazy loader latency of 500 ms to several seconds, so many new requests waited that long or longer, while proxy CPU usage and the inbound connection rate were not especially high.

   High latency

   Root cause

   Capacity exhaustion

   Component

   CDN and edge networkService discovery

   Contributing factor

   No capacity planningUnknown limitOverlapping failures

   Detection

   Fly.io noticed flapping in its US west coast regions, and proxy logs and metrics showed high lazy loader latency.

   Remediation

   • Deployed the proxy in SJC with a temporary mitigation for one app with very large state in Corrosion, which helped only briefly
   • Shifted Anycast traffic from SJC to LAX
   • Lowered Airtime's bandwidth limit, which reduced softirq CPU usage and host load average
   • Bounced the proxy and hard-killed all proxy processes pending shutdown, which cleared the lazy loader problem

   Action items

   • Provision significantly more edge capacity
   • Fixed the bug that let multiple proxy instances coexist
   • Changed Airtime so that, for now, it applies a much stricter limit when it is not the expected active proxy instance
   • Fixed load shedding in the lazy loader so request latency has a reasonable upper bound
   • Shard the in-memory service catalog and move to finer-grained locking, tested with Antithesis
   • Rework Airtime to react to overall system load instead of only the proxy
   • Look into better monitoring for when the proxy is not in its expected configuration

   View case
2. IL-0270 Discord's ScyllaDB authentication cluster overloaded during an OS upgrade, and logins failed for about 50 minutes

   Discord2023

   Symptoms

   On 6 November 2023 at 10:52 AM PST, when an upgrade script drained all connections from zone [c] of the scylla-authentication ScyllaDB cluster, Discord's availability, measured as the share of HTTP requests that return a 200-level response, fell at once to about 25%. Users could not connect, log in, read or send messages.

   Service outageDatabase overloadHigh latency

   Trigger

   During an OS upgrade that takes one zone of a ScyllaDB cluster offline at a time, the upgrade script drained all connections from zone [c] of scylla-authentication at 10:52 AM, while one node in the just-upgraded zone [b] had a degraded NVMe Local SSD.

   Root cause

   Capacity exhaustion

   Component

   Database

   Contributing factor

   No headroomOverlapping failuresDependence on a warm cacheUnverified assumptionIgnored early signalRetry storm

   Detection

   An incident response call had already started when the first alerts fired at 10:56 AM, four minutes after the start. The time spent by downstream service graph showed the authentication service spending far more time on user requests than normal, and the authentication alerts fired moments later.

   Remediation

   • Turned off sending typing events and marking messages as read to shed load from the authentication cluster
   • Waited for the zone [c] RAID rebuild instead of restarting nodes, and the two zone [c] nodes came back online at 11:41 AM
   • Restarted the two zone [b] nodes one at a time

   Action items

   • Double the size of the scylla-authentication cluster so each node takes half as many requests
   • Rebuild scylla-authentication-b-2 with new, non-degraded disks
   • Build a way to detect disk degradation that is too subtle to affect overall latency but still threatens reliability
   • Move upgrade operations into a more automatic control plane for the Scylla clusters that analyses cluster state, such as cache hit rate
   • Increase the redundancy of the scylla-authentication cluster; the options being explored, not yet decided, are a higher replication factor or a hot-standby cluster in another region

   Lessons

   Taking a whole zone out of a three-zone cluster leaves no margin, so one additional slow node in another zone was enough to overload it. For some Scylla clusters the row cache hit rate of restarted nodes must reach a safe level before the next zone goes down, and a short zonal test beforehand gave false confidence. The small but critical authentication cluster needs to be run differently from Discord's much larger Scylla clusters, with more redundancy.

   View case

By root cause1