#задачка #архитектура #системный_дизайн #структуры_данных #уровень_сложности

❔Задача на сплиттинг пользователей

Недавно, обсуждая подход к работе с данными в легаси, я вспомнил один классный показательный кейс. Лёгкий на первый взгляд, но отлично раскрывающий архитектурное мышление. Особенно там, где нужно аккуратно отказаться от старого кода.

Представьте, вам пришла задача — плавно перевести пользователей со старого приложения на новое, не сломав текущую бизнес-логику, не храня никаких отметок о переезде и сохранив прежнюю скорость работы. (Привет VIPChat 👋)

⛔️ Ограничения:
- Не менять клиентский опыт и не заставлять переходить на другой адрес
- Легаси лучше не трогать, любое вмешательство может всё сломать
- Новое приложение не должно зависеть от старого. После его отключения всё должно работать
- Переключение не должно накладывать дополнительных задержек, сложность O(1), лучше всего прямо на уровне маршрутизации
- Пользователь знает свой идентификатор и использует его при подключении
- Процент переводимых нужно постепенно повышать, откат не понадбится

Остановитесь тут, подумайте как бы вы решили это!

💡Решения.
Первое, что приходит в голову - давайте как-то помечать пользователей. Например, добавить столбец в БД. Но это требует правок в работающей базе, изменений в легаси, плюс при каждом запросе будет ещё один поход в БД. Это замедлит работу, а нам требуется понимать сразу.

Ок, а что если это делать на уровне инфраструктуры? Здесь тоже есть проблемы. Решение должно быть детерминированным, постоянным для конкретного пользователя. Но IP меняется, куки сбрасываются, fingerprint привязан к устройству. Единственный стабильный признак - user_id.

Нам нужен механизм, который на лету определит, попадает ли пользователь в выборку, без хранения каких-либо отметок.

💡Идея проста:
1. Представим массив из 100 бакетов (0, 1, 2, …, 99)
2. Каждый пользователь навсегда закреплён за одним бакетом.
3. Менеджер одним числом в конфиге управляет какие бакеты переехали.

Процентный сплит получается почти бесплатно. Нужна функция, которая всегда выдаёт число от 0 до 99. Уравнение: bucket = hash(user_id) % 100. Всё. Никаких таблиц, никакого состояния. Принцип похож на структуру хешмапа, только у нас нет задачи хранить значения.
В моём кейсе всё оказалось ещё проще: user_id были числовые, поэтому я просто брал последние две цифры. Если бакет входит в текущий процент — пользователь попадает в новое приложение.

Это решение имеет сложность O(1), не делает запросов к БД или другому хранилищу, не трогает старое приложение, не требует проставления флажков. Никакой зависимости от легаси-кода.

И почему я это рассказываю? Потому что видел, как команды пытались решать тот же самый сценарий через громоздкие фиче-тоглы, сервисы-прокладки, планировщики, дополнительные таблицы и тонну условий. Получалось сложнее, дороже, медленнее и главное, менее надёжно.

❕Иногда у простой задачи может быть простое решение - но принцип, на котором оно стоит, оказывается не таким уж простым.