Про релизы и архитектуру
В 2022 году почти нет причин делать сервисы так, чтобы при выкатывании релиза что-то было временно недоступно. Также часто встречаю проекты, в которые не закладывали вариант масштабирования, хотя сделать это было очень и очень дешево на первых этапах «стройки».
Мой минимальный джентельменский набор:
1) Миграции БД должны уметь катиться без релиза кода (до релиза), который умеет с этим работать. Тогда вы сможете откатывать новый код в случае ошибок и не думать про то, что старый код будет падать при работе с новой схемой БД. Также, если вы используете Kubernetes, то у вас скорее всего будет политика плавного обновления и в какой-то момент у вас будет работать одновременно и старая и новая версия кода, поэтому думать об этом надо. Что точно я бы не делал - для каждой миграции сразу писать миграцию для отката, это - фантастика. =)
2) Всегда! Всегда! Делайте все сервисы так, чтобы они умели работать одновременно в нескольких экземплярах. Тут речь не столько про распределение нагрузки, сколько про то, какие шаблоны в коде вы сможете или не сможете использовать. Например, скорее всего в какой-то момент вам может понадобиться распределенная блокировка и классно, если у вас в коде не будет просто блокировок на основе семафоров ЯП. Когда кода будет много менять это будет очень и очень сложно.
3) Только Stateless API. Старайтесь не писать на диск «под себя» данные, поступающие в приложение. Для этого используйте современные подходы - S3 совместимые хранилища, очереди типа кафки или рэббита.
4) Не отдавайте файлы или статику с S3 напрямую. Ставьте nginx + cdn. Nginx учим сжимать картинки налету и забываем об этом в приложении. CDN снижает трафик на nginx и вы не паритесь про расход CPU на сжатие картинок. Бонусом идет то, что путем ddos-а на вашу s3 напрямую ваши конкуренты не смогут сделать так, что счет от облака за трафик на s3 будет конский. CDN вас спасет и сам скорее всего отобьется от атаки.
Как минимум учет этих пунктов во первых накладывает достаточно жесткие требования на код и архитектуру приложения, но позволяет ему без сильных переделок масштабироваться
