Что такое feature flags и как реализовать их на бэкенде

Feature flags (они же feature toggles) — это механизм, который позволяет включать и выключать функциональность приложения без деплоя кода.

Вместо того чтобы:

• выкатывать новый релиз,
• ждать подтверждения,
• откатываться при ошибке,

мы можем управлять поведением приложения через конфигурацию или данные, зачастую — в реальном времени.

Сегодня feature flags используются:

• для безопасных релизов,
• A/B-тестирования,
• постепенного rollout,
• экстренного отключения фич в продакшене

Базовая идея feature flags

Упрощённо:

if (feature_enabled) {
    новая логика
} else {
    старая логика
}

Но в реальности флаги — это:

• не просто boolean,
• а управляемое состояние, привязанное к окружению, пользователю или сегменту.

Зачем feature flags нужны на бэкенде

На фронтенде флаги часто управляют UI.
На бэкенде они особенно ценны, потому что позволяют:

• отключить проблемный код мгновенно;
• выкатывать изменения без downtime;
• тестировать бизнес-логику на части трафика;
• управлять поведением API для разных клиентов.

Основные типы feature flags

Release flags

Используются для:

• безопасного выкатывания новой функциональности;
• быстрого rollback.

Как правило:

• временные,
• удаляются после полного релиза.

Operational flags

Используются для управления поведением системы:

• включение кеширования;
• переключение внешнего сервиса;
• изменение таймаутов.

Могут жить долго.

Experiment flags

Используются для:

• A/B-тестов;
• canary-релизов;
• gradual rollout.

Часто зависят от:

• пользователя,
• процента трафика,
• сегмента.

Где хранить feature flags

В конфигурации

Пример:

• env-переменные,
• config-файлы.

Плюсы:

• просто.

Минусы:

• нужен рестарт;
• неудобно для экспериментов.

В базе данных

Один из самых популярных подходов.

Пример структуры:

features
--------
key
enabled
conditions
updated_at

Плюсы:

• динамическое управление;
• гибкие условия.

Минусы:

• нужен кэш;
• флаги становятся частью бизнес-логики.

В распределённом хранилище

Например:

• Redis,
• Consul,
• etcd.

Плюсы:

• быстрый доступ;
• можно менять в реальном времени.

Минусы:

• появляется дополнительная зависимость.

Пример простой реализации на бэкенде

Структура данных

{
  "new_checkout": {
    "enabled": true,
    "rollout": 30
  }
}

if feature.enabled:
    if user_hash % 100 < rollout:
        enable feature
    else:
        disable feature

Таким образом:

• 30% пользователей видят новую функциональность;
• остальные — старую.

Кэширование feature flags

Никогда не читайте флаги из базы на каждый запрос.

Обычно используют:

• in-memory кэш;
• Redis с TTL;
• локальный cache + background refresh.

Важно:

• быстрый доступ;
• возможность обновления без рестарта.

Feature flags и миграции

Одна из самых частых ошибок — ломающие миграции.

Правильный подход:

1. добавить новый код под флагом;
2. задеплоить;
3. включить флаг;
4. только потом удалить старый код.

Это особенно важно для:

• схемы БД,
• контрактов API.

Типичные ошибки

• слишком много флагов без контроля;
• забытые release-флаги;
• сложные условия, которые никто не понимает;
• отсутствие документации.

Feature flags требуют дисциплины.

Когда feature flags — плохая идея

• для одноразовых hotfix’ов;
• если команда не готова поддерживать порядок;
• когда логика превращается в if-else ад.

Итоги

• Feature flags позволяют управлять поведением бэкенда без деплоя.
• Они незаменимы для безопасных релизов и экспериментов.
• Лучший вариант — хранение в БД или кэше с TTL.
• Важно вовремя удалять временные флаги.
• Feature flags — это инструмент, а не магия.

Грамотно реализованные feature flags сильно повышают устойчивость и управляемость продакшена.