Выбор правильного старта для написания микросервисов?
https://microservices.io/ - много полезных мыслей про микросервисы.
По опыту - даже при огромном желании запилить микросервисы, они действительно должны быть нужны чтобы получились. И хорошо ложиться на доменную модель. 
Иначе у вас получится несколько обычных сервисов, которые вы назовете "микро". 
Оптимальную последовательность вам тут из воздуха никто не напишет - это же зависит напрямую от продукта, целей, ресурсов, приоритетов и так далее. Нормальная такая постоянная и не прекращающаяся работа продакт-менеджера, если на вас возложили эти обязанности и вы не знаете чего делать - изучите хотя бы основы, в сети куча инфы. 
Если вам не надо отвечать за продукт, а надо сделать именно архитектуру - то идете к тому кто отвечает, и составляете с ним хоть какой-то роадмап на пару лет. На его основе уже будете думать что от чего будет зависеть, в каком порядке делать, и вообще какие функциональные блоки вам нужны. 
Пока продукт не описан - архитектуры не получится, разве что какие-то совсем базовые штуки. Даже выбор БД или протокола общения между сервисами зависит от бизнес - требований Как лучше распределить нагрузку между членами команды, и т.п.
это уже про управление командой. 
Если на вас взвалили вообще все от проекта до архитектуры и управления командой, то удачи. Если не завалите все полностью - будет крутой опыт.
Очень размыт вопрос.
Порекомендую тогда почитать.
Распределенные системы Брендан Бёрнс
и
Масштабирование приложений Ли Атчисон
Читаются легко и быстро. В среднем 250 стр.
И можешь конечно же в идеале еще дополнить
site reability engineering  Бетси Бейер(есть на русском)
Вопросы отпадут сами