Сервис фич-флагов

Смоделируй флаги и правила таргетинга типизированной валидируемой схемой, затем отдай набор правил так, чтобы SDK могли дёшево его кешировать. У каждого флага — ключ, дефолтное значение, упорядоченные правила таргетинга (например, `email endsWith @company.com`, `country == DE`, `userId in allowlist`) и конфиг процентной раскатки. Схема валидируется zod при записи — некорректное правило отклоняется на создании, а не при оценке, когда оно бы молча неверно сработало. Отдавай GET /flags с сильным ETag (хеш версии сериализованного набора правил); SDK хранят ETag и ревалидируют через If-None-Match, получая 304 без тела при отсутствии изменений (только ~200 байт заголовков). Это делает частый поллинг дешёвым и позволяет тысячам экземпляров SDK ревалидироваться одновременно без пиков пропускной способности — правильный дефолт до стриминга.

Реализуй процентную раскатку так, чтобы один пользователь всегда получал один ответ, а включённая доля была ~X% при X% раскатки. Примитив — `hash(userId + flagKey) mod 100 < rolloutPercent`: примешивание flagKey критично — хеширование только userId помещает одни и те же 10% пользователей в первый дециль по каждому флагу, систематическое смещение, искажающее любой A/B-эксперимент, опирающийся на независимые назначения. Монотонное расширение корзин тоже важно: увеличение раскатки с 10% до 20% никогда не должно выключать уже включённых пользователей (ты расширяешь порог, а не перетасовываешь корзины). Докажи корректность на смоделированной популяции (например, 10k пользователей): при 10% включены ~1k, при 20% ~2k и исходные 1k всё ещё внутри, хи-квадрат тест показывает равномерное распределение корзин. Задокументируй, почему `Math.random()` на запрос здесь был бы неправильным.

Собери SDK, делающий оценку флага локальным типизированным вызовом без сети. `flagOn('flagKey', user)` вычисляется по кешированному набору правил в процессе: проход по правилам таргетинга в порядке приоритета, первое совпадение побеждает, переход к солёной процентной раскатке, затем к дефолту. Никакого fetch на вызов — набор правил закеширован через ETag и ревалидируется фоновым интервалом, так что горячий путь — чистая функция `ruleset × user → boolean` без I/O. Типобезопасность важна: SDK дженерик по ключу флага, так что `flagOn('nonexistent', ...)` — ошибка компиляции, а тип возврата сужается по флагу (boolean vs string vs JSON). Докажи бенчмарком: 100k оценок в процессе против наивного 'fetch набора на вызов' и покажи разницу латентности (микросекунды против миллисекунд). Задокументируй порядок оценки и что происходит, когда пользователь попадает под несколько правил.

Сделай kill-switch реальным: выключение флага должно распространиться на каждый экземпляр SDK достаточно быстро, чтобы быть полезным при инциденте безопасности. При одном поллинге и TTL 60с выключенный флаг остаётся включённым до 60с в каждом SDK — окно воздействия, скрытый SLO сервиса флагов. Добавь стриминговый канал обновлений (SSE): сервер пушит событие 'доступна версия набора правил N+1', SDK немедленно ревалидируются, и распространение падает с TTL до ~секунд (латентность SSE + одна ревалидация). Оставь поллинг как фолбэк для клиентов, пропустивших стрим. Измерь оба пути: только с поллингом переключи флаг и зафиксируй наихудшую задержку распространения (до TTL); с SSE зафиксируй p50/p95 латентности push-to-eval. Задокументируй компромисс: SSE устраняет окно ценой постоянного соединения на экземпляр SDK (стоимость fan-out); поллинг без соединений, но с ограниченным окном устаревания. Укажи, когда расщепление оценки (часть SDK на старом наборе, часть на новом) приемлемо (постепенная раскатка) и когда нет (kill-switch безопасности).

Докажи под прод-подобной нагрузкой и сделай наблюдаемым, когда оно ведёт себя плохо. Нагрузи сервис флагов множеством экземпляров SDK (например, 50 конкурентных оценщиков, смесь ключей флагов, флаги 10% раскатки, переключения kill-switch на середине теста) и найди QPS, где узким местом становится ревалидация набора правил, а не оценка (304 дёшевы, но всё равно стоят round trip). Снимай RED-метрики (rate запросов, rate выборки набора правил, доля 304, rate оценок, число SSE-соединений) и трейс-span на выборку набора правил, чтобы собственная латентность системы флагов была видна в водопаде. Затем отработай инцидент: переключи правило таргетинга флага на середине нагрузки и наблюдай расщепление оценки — часть SDK на старом наборе, часть на новом — даёт несогласованные результаты flagOn для одного пользователя. Обнаружь это по метрикам (падение доли 304 + несогласованность оценки), смягчи (принудительная ревалидация / SSE push) и напиши пост-мортем на 5 строк, чья превенция — не 'снизь TTL до 1с'.