O que acontece é que microserviços é muito mais uma decisão organizacional do que técnica.
Ele surgiu para dar independência aos times.
Para o time A que cuida de um contexto X do negócio não correr o risco de quebrar funcionalidades do contexto Y mantido pelo time B.
Mas isso por si só não justifica comprar toda a complexidade que vem com microserviços (que listo abaixo).
Se sua empresa tem 3 times, cada um com 3 devs, todos trabalhando num mesmo monolito, os times estão dependentes um do outro? Sim. Mas numa escala bem pequena e fácil de resolver conflitos, orquestrar mudanças e etc.
Adotar microserviços se torna necessário ter:

• Um altíssimo entendimento do negócio para saber separar os contextos em serviços, pois voltar atrás é praticamente inviável depois.
• Um centralizador de logs, do contrário vc tem que pular de um diretório para outro entre o serviços para analisar logs, dificultando a visão do todo.
• Uma ferramenta como Service Mesh para trackear a comunicação entre os serviços para apoiar o troubleshooting
• Um orquestrador ser Serviços
• Uma ferramenta de observability centralizada para os serviços se inscrevem e te darem uma visão centralizada da saúde dos serviços
• Um API gateway para os consumidores do serviço (frontend apps) terem um único ponto de acesso aos serviços
• Entre outras coisas que não me vieram a mente agora

Olha o tanto de infraestrutura e conhecimento que vai ser preciso agregar aos times para adotar microserviços.
Tem que valer muito a pena.

E um erro comum que eu vejo como justificativa para adotar microserviços:
Poder ter linguagens diferentes rodando na empresa.
Ainda que uma linguagem diferente da "main language" adotada pela empresa resolve um problema de forma consideravelmente melhor, basta criar este serviço específico desacoplado do monolito.

Vejo gente se orgulhar de dizer que tem microserviços todando em Java, Go, Node e etc.
Achando que demonstra flexibilidade da empresa.
Pra mim isso é bagunça. A menos que seja tecnicamente justificada a aplicação de diferentes linguagens para diferentes serviços.
E o fato de um grupo de devs ser mais proficiente em uma linguagem específica não justifica.
Eu nem acho que hoje em dia um desenvolvedor Senior deveria se intitular "Dev JS", "Dev Java" ou qualquer outra linguagem. Essa deveria ser apenas a "posição" atual ocupada. Mas essa é outra conversa.