7 мая 2026 года сбой Coinbase почти парализовал работу одной из крупнейших криптобирж: пользователи не могли покупать и продавать активы, а также вносить, выводить и переводить средства в течение нескольких часов. История важна не только для крипторынка: это наглядный разбор того, как локальная авария в облаке превращается в многочасовой простой, если бизнес-критичная система слишком крепко привязана к одной зоне доступности.
Coinbase опубликовала подробный постмортем, о котором сообщает InfoQ. Отправной точкой стала не ошибка приложения и не неудачный релиз, а отказ сразу нескольких систем охлаждения в одном из залов дата-центра AWS в регионе US-East-1. Из-за перегрева AWS пришлось отключать затронутые стойки, а вместе с ними стали недоступны EC2-инстансы и тома EBS. Но самое неприятное началось уже после этого: выяснилось, что собственная архитектура Coinbase сделала восстановление заметно дольше и болезненнее, чем могла бы позволить сама облачная авария.
Ключевой проблемой оказался движок сопоставления ордеров, то есть центральный компонент биржи, который сводит заявки покупателей и продавцов. Ради минимальной задержки Coinbase держала его в виде Raft-кластера внутри одного AWS Cluster Placement Group. Логика понятная: если вы строите инфраструктуру для высокочастотной торговли, каждая лишняя сетевая миллисекунда раздражает не меньше, чем бухгалтерия в конце квартала. Но у такой оптимизации оказалась цена. Когда авария вывела из строя три узла из пяти, кластер потерял кворум и перестал обрабатывать сделки. Автоматического переключения в другую зону доступности для этой архитектуры не было, поэтому инженерам пришлось идти в ручной режим: вносить экстренные изменения в код, пересобирать кластер и аккуратно восстанавливать кворум, чтобы не сломать систему уже на этапе спасения.
Из-за этого восстановление шло не одной кнопкой и не по учебнику. Торги возвращали поэтапно: сначала в ограниченных режимах вроде cancel-only и auction, а уже потом в штатном. Полное восстановление, по данным самой компании, заняло значительную часть следующего дня. Для внешнего наблюдателя это тот самый неприятный, но полезный вывод, который команды обычно формулируют уже после инцидента: распределенная система не становится отказоустойчивой просто потому, что она работает в AWS и разложена по модным сервисам. Если критический контур завязан на конкретную зону, то отказ этой зоны перестает быть частным случаем и превращается в инцидент уровня всей платформы.
На этом сбой Coinbase не закончился. Второй слой проблемы вскрылся в стриминговой инфраструктуре. Kafka-нагрузки, через которые по платформе расходились операционные данные, застряли в пострадавшей зоне доступности. В результате накопились серьезные очереди, и даже когда основная торговая система начала оживать, платформа все еще буксовала из-за backlog и нарушенного потока событий. Инженерам пришлось вручную переносить партиции и заново балансировать нагрузку, чтобы нормализовать обмен данными. Именно сочетание двух факторов, падения matching engine и затора в Kafka, превратило локальную аварию в дата-центре в платформенный сбой. Coinbase отдельно признала: по отдельности каждая из этих проблем была бы неприятной, но управляемой, а вместе они создали сценарий восстановления намного сложнее ожидаемого.
Этот кейс снова поднимает тему cloud concentration risk, о которой в отрасли говорят давно, но обычно до очередного большого простоя. Формально регионы AWS состоят из нескольких availability zone, и сама идея должна снижать риск. На практике все упирается не в маркетинговую схему региона, а в конкретные решения архитекторов: где живет кворум, как размещены stateful-нагрузки, насколько автоматизирован failover, какие сервисы могут остаться без критичных зависимостей, а какие нет. Облако дает инструменты, но не отменяет инженерную дисциплину. Более того, в высоконагруженных системах именно требования к производительности часто и толкают команды к опасной близости компонентов друг к другу. Пока все работает, это выглядит как разумная оптимизация. Когда не работает, выясняется, что низкая задержка и реальная устойчивость иногда находятся по разные стороны одного SLA.
В этом смысле история Coinbase хорошо ложится в более широкий тренд, который в последние годы прослеживается в постмортемах крупных технологических компаний. GitHub, Discord и Netflix, как напоминает InfoQ, тоже приходили к похожему выводу: крупные сбои редко объясняются одной поломкой. Обычно это цепочка из нескольких вполне понятных отказов, которые накладываются друг на друга через скрытые зависимости. Один сервис теряет доступность, второй не умеет быстро переключаться, третий добавляет очереди и ручные операции, и вот уже инцидент, который должен был ограничиться отдельным сегментом инфраструктуры, начинает бить по всей пользовательской поверхности. Для разработчиков и платформенных команд здесь нет особой романтики, зато есть практическая польза: искать нужно не только single point of failure, но и single point of recovery pain, то есть места, где восстановление завязано на редкие ручные действия, экстренные патчи и знание пары дежурных инженеров.
Coinbase уже обозначила меры после инцидента: автоматизация межзонного восстановления для matching engine, улучшение процедур возврата кворума, усиление устойчивости messaging-инфраструктуры и расширение disaster recovery testing. Это, пожалуй, самый здравый кусок всей истории. Компания прямо признает: важно не только предотвращать сбои, но и сокращать время восстановления, потому что полностью исключить отказы в сложной распределенной системе все равно нельзя. Для русскоязычной IT-аудитории вывод тоже предельно прикладной. Если ваш продукт завязан на одну облачную площадку, один регион или одну «временную» архитектурную уступку ради скорости, вопрос не в том, случится ли неприятный сценарий, а в том, насколько честно вы проверяли его до продакшена. Сбой Coinbase показал, что настоящая отказоустойчивость начинается не с мультизонной схемы в презентации, а с готовности системы пережить потерю удобных предположений о мире.