https://microservices.io/ - много полезных мыслей про микросервисы.
По опыту - даже при огромном желании запилить микросервисы, они действительно должны быть нужны чтобы получились. И хорошо ложиться на доменную модель.
Иначе у вас получится несколько обычных сервисов, которые вы назовете "микро".
Оптимальную последовательность вам тут из воздуха никто не напишет - это же зависит напрямую от продукта, целей, ресурсов, приоритетов и так далее. Нормальная такая постоянная и не прекращающаяся работа продакт-менеджера, если на вас возложили эти обязанности и вы не знаете чего делать - изучите хотя бы основы, в сети куча инфы.
Если вам не надо отвечать за продукт, а надо сделать именно архитектуру - то идете к тому кто отвечает, и составляете с ним хоть какой-то роадмап на пару лет. На его основе уже будете думать что от чего будет зависеть, в каком порядке делать, и вообще какие функциональные блоки вам нужны.
Пока продукт не описан - архитектуры не получится, разве что какие-то совсем базовые штуки. Даже выбор БД или протокола общения между сервисами зависит от бизнес - требований
Как лучше распределить нагрузку между членами команды, и т.п.
это уже про управление командой.
Если на вас взвалили вообще все от проекта до архитектуры и управления командой, то удачи. Если не завалите все полностью - будет крутой опыт.
