Отказоустойчивость в двух дата-центрах
Система развернута в двух дата-центрах, целевой 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 и меж-ДЦ сеть.