Por favor, não venha com o dogma que você prega no SOpt há anos, citando todos os seus links como se fossem lei e a maioria de 3, 5 anos atrás, ainda bem que aqui o downvote é bem diferente, não né?

Primeiro, a arquitetura de microsserviços é uma das maiores modinhas que apareceram em TI. Fique longe o quanto puder.

Errado, suponhamos que eu tenha um serviço distrbuído e uma das suas funções é escrever o output de algo processado em um bucket/banco/arquivo por exemplo. Por qual motivo eu teria o serviço X deployado em todas as minhas instancias quando eu poderia ter um serviço Y bem leve isolado lendo output de uma fila alimentada pelo serviço X fazendo isso? Utilizando assim muito menos recurso, tempo de resposta, não consumindo e alocando recurso do serviço X inteiramente.

Existem muitos e muitos casos, principalmente se você precisa lidar com API de terceiros, você vai confiar o seu serviço inteiro, que pode causar lentidão, bug dentre outras mil e uma coisas quando poderia ter essa feature de ir na API e alimentar um banco ou chamar outra API isoladamente e ter esse output pra ser processado no seu outro microserviço?

Ou que tal um serviço que lê seu banco de dados e coloca os dados em um redis para fácil acesso? Faria sentido eu fazer os dois no mesmo serviço? Eu posso ter um só pra escrever e outro só pra ler.

Microsserviços é computação distribuída, que é considerado o problema mais difícil de resolver da computação, só pessoas com extraordinário conhecimento farão corretamente.

Sim, você tem razão, isso era verdade há uns 6 ou mais anos atrás, como em seus posts.

Veja bem, dei exemplos básicos de uso, é óbvio que isso depende de caso para caso. Dizer que é certo ou errado, dificil ou fácil vale somente para você e exclusivamente você.

Sobre a dúvida do OP.

O que quero saber é como elas se comunicam, e como elas garantem que a requisição vem do serviço que a requisitou e não um hacker tentando imputar dados via api. como que eu sei que os dados do usuário que uma api está enviando ou solicitando da outra são dados válidos.

Existem diversas formas de previnir isso. Caso você só receba requisições do IP X, já é um bom começo, outro é criar um template de validação da requisição e você somente aceitará dados que deem match naquele template, você talvez possa limitar a quantidade de req/s se for o caso.

Nada nem nenhum serviço está passível a ser perfeito, vale você limitar ao máximo. Mas vamos imaginar que seguindo a ideia do amigo acima, você tenha tudo junto e seja hackeado, o estrago seria maior, né?

Enfim, não se prenda a dogmas, nem ao que eu disse, veja o que é melhor pra você, o que melhor te atende. Se você acha certo por um servidor web/api/aplicação tudo junto, vai lá, vai só disperdiçar recursos. Se você conseguir distrinchar sua aplicação em microserviços aonde cada uma é acionada por outra por algum evento, você fará algo muito melhor, mais dinamico, e caso haja falha em um processo, seu serviço inteiro não seria afetado, somente tal feature.