Про релизы и архитектуру В 2022 году почти нет причин делать сервисы так, чтобы при выкатывании релиза что-то было временно недоступно. Также часто встречаю проекты, в которые не закладывали вариант масштабирования, хотя сделать это было очень и очень дешево на первых этапах «стройки». Мой минимальный джентельменский набор: 1) Миграции БД должны уметь катиться без релиза кода (до релиза), который умеет с этим работать. Тогда вы сможете откатывать новый код в случае ошибок и не думать про то, что старый код будет падать при работе с новой схемой БД. Также, если вы используете Kubernetes, то у вас скорее всего будет политика плавного обновления и в какой-то момент у вас будет работать одновременно и старая и новая версия кода, поэтому думать об этом надо. Что точно я бы не делал - для каждой миграции сразу писать миграцию для отката, это - фантастика. =) 2) Всегда! Всегда! Делайте все сервисы так, чтобы они умели работать одновременно в нескольких экземплярах. Тут речь не столько про рас