(Не)очевидные советы про архитектуру:

Пачка случайных советов людям, недавно проектирующим сложные штуки:

Попробуй предварительно нарисовать команду:

Если в твоем продукте три экрана – это не значит, что тебе нужно три микросервиса. Если все три делают два человека – им будет нормально и в одном. А если над продуктом будут работать три команды по 5 человек – лучше резать.

Учитывай этап развития бизнеса:

Сервис, "создающий заказ", для одного rps, для 1000 rps и для 100000 rps – это три разных архитектуры. Проектировать несвоевременно вредно как в большую, так и в меньшую сторону

Выбирая технологию, думай об уровне результата

Если твоя цель – сделать сервис "не хуже", чем другой известный тебе (или другой, который ты делал раньше) – можно брать те же технологии и подходы, что используются в другом сервисе

Если нужно "строго лучше" – это может быть хорошим поводом попробовать что-то поменять

(дисклеймер для ковбоев: если у тебя космические требования надежности – это, скорее всего, означает подход "не хуже")

Расскажи об архитектуре не-техническим руководителям

Например, своему CPO. Он, конечно, не научит тебя быть более отказоустойчивым, но, как минимум поймет, почему это так долго, а как максимум – пока будешь объяснять ему, что означает воон тот квадратик, поймешь, что система не расширяется важным сценарием

Оформи дизайн-документ

RFC/RFD/C4/в пэйнте, не важно. Артефакт, который, во-первых, могут поревьюить (в том же смысле, что и код, а не на словах!) другие инженеры, и который у вас останется – это почти что лучшая документация для технарей, которым лень писать документацию

Погугли как у конкурентов и спроси у GPT

Нет, не для того, чтобы не думать самому и просто скопипастить. А чтобы быстро увидеть, в каких направлениях вообще можно подумать, проектируя такую систему, и не забыл ли ты очень важный кусок. Зачем ограничиваться ревью дизайн-документов от людей?)