Звучит как обычный кейс для роллинг апдейтов

ну изменился формат данных

Даже к гейтам не имеет отношения

изменилось взаимодействие на уровне микросервисов

Тебе нужно обеспечить работоспособность схемы на двух версиях одновременно, это обычная задача при роллинге

Без флагов можно то же подумать как откатить обатно. В чем связь?

В этом конкретном случае - ни в чем, особенно если роллинг апдейты уже есть

А если нет, то наличие гейта поощряет адекватное планирование и проверку ситуации с отъебом фичи

Из флагов пользу вижу только в а/б тестировании, накатывании фичи пользователям постепенно

Тем более надо обеспечить версионирование

типа, раньше была одна табличка с юзерами, где хранилось вообще всё. всё это было в одном сервисе

стало 3 сервиса: сервис аккаунта и по сервису на тип кастомера. при создании аккаунта должен создаваться в каком-либо из сервисов кастомеров ещё один аккаунт. при этом анкета кастомера заполняется позже на фронте, потому что больше не нужно отправлять всё одним куском данных (а для старого сервиса нужно было пачкой сразу слать всё, а если подать не всё, то ругается уникальный обязательный индекс в таблице), да ещё вы мигрировали с асп мембершипс на идентити

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

поясните мне, чо нужно в конфиге изменить, чтобы за 5 наносек всё стало заебись

А как это у тебя апдейт прошло?

желательно, без метода невидимки SdelatZaebis()

Если у тебя стала схема абсолютно несовместимая?

Без даунтайма?

Запиши ещё тот факт, что регрессии находятся раньше, пушо нет никаких отдельных веток

И то что легко выключить для любых проверок или в случае хитрого бага

заводили новую схему в бд, писали ебанутый скрипт миграций, который дербанил всё на несколько таблиц

Даунтайм был?