In October 2026 the Russian IT market witnessed an unprecedented infrastructure collapse when three Yandex data centers in Central Russia (Sasovo, Kaluga, Vladimir) were physically destroyed over four days. The outage brought down Yandex Cloud, halted services from Yandex Go to Yandex Direct, caused loss of up to seven days of data for some clients, and left the fintech vertical in an 11-day coma.
Public statements framed the event as an unavoidable military force-majeure. Architects examining the timeline, however, conclude that physical destruction was only the trigger; the scale and duration resulted from fundamental errors in distributed-system design, capacity management, and C-level risk assessment.
Chapter 1. Timeline of the Cascade: 74 Lost Hours
On 8 October at 01:31 MSK the Sasovo facility (ru-central1-b) was destroyed by drone attack and fire. By 14:00 serverless functions had failed across the platform. On 9 October the Kaluga site sustained damage. Only at 15:42, 38 hours after the first loss, did engineers provide tools to move Kubernetes control-plane nodes and clean dead database hosts from metadata. On 10 October surviving zones exhausted capacity and quota allocation was switched to manual mode.
At 04:00 on 11 October the Vladimir facility (ru-central1-a) containing the Galushkin supercomputer was destroyed. The remaining zones d and e could not maintain quorum. By 07:13 managed databases entered Read-Only, S3 stopped accepting writes, and Yandex Go, Yandex 360, Direct, Yandex Pay and external clients including CIAN, Dodo Pizza and the state VetIS system went offline.
Chapter 2. Why Raft and Multi-AZ Did Not Save the System
YDB and managed PostgreSQL clusters behaved exactly as CP systems should: they blocked writes when quorum was lost. The real failure occurred earlier. After Sasovo was lost, the Control Plane itself remained dependent on the dead zone, preventing Self-Healing and re-quorum operations for 74 hours. In addition, data-center utilization had been driven to near 100 percent in peacetime, leaving no spare servers or disks to rebuild the third replica.
All four primary sites lie within a 350 km radius of Moscow and share the same power and network backbone, forming a single correlated-failure domain. No physically isolated region such as ru-siberia existed, so a regional event became a nationwide blackout.
Chapter 3. The 11-Day Fintech Reconciliation
Fintech services remained offline far longer than ride-hailing or advertising because distributed sagas spanning Core Banking, the Split engine, payment gateways and Kafka/YDS event buses entered inconsistent states. Aggressive retry and at-least-once patterns without synchronized idempotency caches produced duplicate and phantom charges between 8 and 10 October. After 11 October engineers performed manual, transaction-by-transaction reconciliation against external ledgers and NSPK statements, a process completed only on 22 October.
Chapter 4. Root Cause at C-Level
KPIs rewarded GMV growth and CAPEX reduction while penalizing investment in remote DR regions or 35 percent spare capacity buffers. Threat models never accounted for simultaneous loss of three sites inside a single metro cluster. The result was an architecture that could survive a single rack or transformer failure but not the loss of an entire availability zone followed by a second.
