Отказоустойчивость в двух дата-центрах
Система развернута в двух дата-центрах, целевой SLA выше 99.95. Какие архитектурные решения помогают не уронить весь продукт при отказе одного узла или сервиса?
Короткий ответ
Нужно убрать single points of failure, реплицировать критичные компоненты, ограничивать синхронные зависимости, вводить timeouts/retries/circuit breakers, health checks, graceful degradation и понятный failover.
Полный разбор
Начинать стоит с модели отказов: что происходит при падении instance-а, сервиса, базы, брокера, сети между ДЦ и целого дата-центра. Для каждого критичного пути надо понимать RTO/RPO, допустимую деградацию и кто принимает write-трафик.
На уровне приложения помогают timeouts, bounded retries, circuit breaker, bulkheads, health checks, rate limits и graceful degradation. На уровне данных - репликация, backup/restore, проверенный failover, разделение read/write путей и осознанный выбор consistency/availability trade-off. Для брокеров и очередей важны replication factor, in-sync replicas, acknowledgements и DLQ.
Хороший ответ обязательно упоминает, что SLA цепочки синхронных вызовов ухудшается. Поэтому критичные request paths нужно сокращать, а независимые операции переносить в async pipeline, но только там, где eventual consistency приемлема.
Теория
Высокий SLA получается не из одного паттерна, а из проектирования отказов: ограничить blast radius, быстро обнаружить отказ и иметь проверенный путь восстановления.
Типичные ошибки
- Сводить отказоустойчивость только к retries.
- Игнорировать SLA синхронной цепочки зависимостей.
- Не описывать failover для stateful компонентов.
Как отвечать на собеседовании
- Сначала назови failure model, потом паттерны.
- Раздели stateless services, DB, queues и меж-ДЦ сеть.