Высокая доступность часто обсуждается как вопрос резервных серверов и регионов. Но есть другой вопрос: если ошибка всё же случится, скольких клиентов она затронет одновременно?
В большой общей системе один неудачный релиз, перегрузка или повреждённые данные способны повлиять на весь пользовательский трафик. Cell-Based Architecture пытается уменьшить именно этот радиус.
Какую проблему мы решаем
Система делится на несколько относительно независимых ячеек. Каждая обслуживает только часть клиентов, регионов, tenants или нагрузки.
У ячеек могут быть отдельные вычислительные ресурсы, очереди и даже хранилища. Общие компоненты стараются оставлять минимальными.
Если одна ячейка деградирует, остальные продолжают работать. Архитектура не предотвращает все ошибки, но не позволяет каждой ошибке автоматически стать глобальной.
Что получает бизнес
Главная выгода — ограничение максимального ущерба одного инцидента. Вместо «продукт недоступен всем» компания может столкнуться с проблемой только у части аудитории.
Ячейки также позволяют масштабировать продукт порциями и вводить разные требования для сегментов или регионов.
Но цена заметна: инфраструктура дублируется, ёмкость используется менее эффективно, а операционная модель становится сложнее.
Что получает команда
Команда получает понятную единицу отказа и масштабирования. Инциденты легче локализовать, а rollout можно проводить по ячейкам.
Сложность появляется в маршрутизации: нужно надёжно знать, в какую ячейку направить клиента, как переносить его между ячейками и что делать с общими данными.
Что получает клиент
Большинство клиентов вообще не замечает проблему, если авария произошла в другой ячейке. Это и есть главный пользовательский эффект.
Для затронутой группы ситуация не становится магически лучше, поэтому всё равно нужны восстановление и graceful degradation.
Чем мы за это платим
Дублирование инфраструктуры, меньшая эффективность использования ресурсов, сложные операции миграции и дополнительные требования к наблюдаемости.
Появляется риск, что скрытый общий компонент всё равно останется глобальной точкой отказа и сведёт преимущество ячеек на нет.
Когда Cell-Based Architecture не нужна
Для небольшого продукта цена дублирования и операционной сложности обычно выше потенциального выигрыша.
Подход оправдан, когда аудитория велика, цена глобального инцидента высока, а продукт уже умеет работать с чётким разделением tenants, регионов или сегментов.
Что стоит спросить перед решением
- Какой максимальный blast radius мы готовы принять?
- По какому признаку делить клиентов на ячейки?
- Какие компоненты всё ещё останутся общими?
- Можно ли безопасно переносить клиента между ячейками?
- Сколько дополнительной инфраструктуры мы готовы оплачивать ради изоляции?
В итоге
Cell-Based Architecture не обещает систему без аварий. Она делает более важную вещь: заранее ограничивает масштаб аварии.
Для бизнеса это способ купить меньший максимальный ущерб ценой дублирования и более сложной эксплуатации.