Feature flags (Kill Switch)

Коротко: Перемикач, який можна змінювати під час роботи і за допомогою якого окремі некритичні функції вмикаються/вимикаються без розгортання — наприклад, щоб оперативно вимкнути їх за високого навантаження на сервер.

Докладніше: Важливе навмисне розділення між функціями «приємно мати», які можна перемикати таким перемикачем, і критичними основними функціями (оформлення замовлення, вхід), які ним ніколи не повинні вимикатися, — інакше перемикач «знизити навантаження» випадково стає перемикачем «вимкнути виручку». Якщо сама система зберігання (тут Redis) виходить з ладу, запасна поведінка має бути завжди «усе ввімкнено», ніколи не «усе вимкнено».

Наш контекст: В Emzett app/utils/featureFlags.ts навмисно використовує Upstash Redis замість таблиці site_settings у Postgres — увесь сенс kill switch у тому, щоб НЕ створювати додаткових читань Postgres, коли система під навантаженням. Наразі використовується лише для звукових ефектів і спливного вікна відгуків, з 30-секундним кешем у пам’яті на екземпляр Lambda.

Подробиці

На практиці feature flags використовуються для дуже різних цілей, що суттєво різняться за вимогами: kill switch (це поняття — швидко вимкнути щось у надзвичайній ситуації, зазвичай двійкове вкл/викл, зачіпає всіх користувачів однаково), поступові викатки (спершу ввімкнути нову функцію для 5 % користувачів, потім повільно нарощувати, щоб обмежити ризик несправного релізу) і A/B-тести (паралельно показувати два варіанти різним групам користувачів, щоб виміряти, який працює краще). У kill switch найжорсткіші вимоги до часу реакції — у надзвичайній ситуації (наприклад, несправна, що створює навантаження функція) важлива кожна секунда, доки перемикач ще не подіяв.

Кеш у пам’яті на екземпляр — навмисний компроміс між узгодженістю та швидкістю: якщо ви змінюєте прапорець, минає до 30 секунд, доки всі екземпляри сервера підхоплять нове значення (замість негайного), але натомість не кожен запит спричиняє новий обмін із Redis. Для kill switch, який за сумніву має подіяти «протягом хвилини», а не «негайно», це прийнятний компроміс — для вмикання платежів така затримка може бути неприйнятною.

Fail-open і fail-closed

Центральне проєктне рішення в будь-якій системі feature flags — як вона поводиться, коли саме джерело прапорців (тут Redis) недоступне: fail-open означає, що за сумніву функція вважається УВІМКНЕНОЮ (нормальний стан до запровадження прапорця) — розумно для некритичних функцій, де коротко активна функція безпечніша за помилково вимкнену. Fail-closed — навпаки, за сумніву ВИМКНЕНО — розумно для прапорців, пов’язаних з безпекою (наприклад, прапорця, що керує ще не готовою, потенційно несправною платіжною функцією). Система kill switch практично завжди має бути fail-open, оскільки її мета — саме вимикати наявні працюючі функції; якщо впаде сама інфраструктура прапорців, це не повинно автоматично вимкнути й УСІ функції.

Відмінність від змінних середовища

Простіша альтернатива справжній системі feature flags — звичайні змінні середовища, але їх зміна завжди потребує нового розгортання, бо вони зчитуються лише під час запуску процесу. Kill switch через Redis/базу даних можна змінювати під час роботи, без розгортання й без перезапуску працюючих екземплярів сервера — саме та економія часу, яка важлива в надзвичайній ситуації.

Див. також: Upstash Redis, Обмеження частоти запитів, Служба