Microsserviços não precisam seguir o princípio da responsabilidade única, até porque isso é um pouco vago, só é famoso por causa do Uncle Bob e outros que se destacaram na área, e se for responsabilidade única no mesmo sentido S de SOLID, é tão pouco que teria que chamar de picosserviços, porque seria equivalente a uma função simples.
Tem-se a ideia que microsserviços precisa fazer poucas coisas, mas não há uma definição clara do que é pouco. A ideia principal é o desacoplamento, não da responsabilidade.
E é bom entender que um microsserviço não tem nada de mais. Ou que queria chamar de macrosserviço porque faz muitas coisas, mas é um serviço isolado e independente. Se você fizer um software que se comunica como o Facebook ele poderia ser um serviço (micro, midi, macro, não importa) da plataforma do Facebook. E isso é uma utilização que faz todo sentido.
O mesmo se aplica para serviços independentes e isolado dentro de uma empresa, cada unidade atua no desenvolvimento dos seus softwares do que jeito que bem entendem sem se preocupar muito com o que outras unidades estão fazendo. O que ela tem de compromisso é que se alguém precisa de uma informação que é propriedade daquela unidade será disponibilizada uma API para informar mudanças e outras unidades pegarem o que precisam ou foi mudado na sua unidade. Em tese essa API precisa ser estável, mas pode ter regras para quebrar a compatibilidade, desde que bem documentado com antecedência (geralmente).
A arquitetura de microsserviços que é mais do que apenas criar um ou mais microsserviços, é pensar que toda infraestrutura de software da empresa seja desacoplada e as se garanta que as unidades sejam livres para fazer o que quiserem dentro do seu domínio. A arquitetura é toda pensada assim. Do ponto de vista externo uma unidade só precisa garantir que todas as unidades possam ser servidas no que precisam, até mesmo envolvendo seu microsserviço em uma transação completa e talvez complexa.
Quero reforçar que nem sempre é assíncrona, embora o texto já tenha dito isso, pode não ficar claro para todos, existem situação que não pode ser assim, até porque pode não suportar consistência eventual, então ele ganha isso er abre mão da disponibilidade (a partição está lá sempre por definição no caso de microsserviços). Veja sobre Teorema CAP.
É possível ter ganho real com monólitos distribuídos pu só quebrados, só não são microsserviços.
Fazer microsserviços realmente resilientes tem uma complexidade que poucos conseguem executar, por isso é comum deixarem isso um pouco de lado, e vemos "frequentemente" quem adotou microsserviços saindo do ar.
De fato fazer a comunicação via banco de dados é um erro e acopla, o que deixa de ser microsserviços. Fazer tudo desacoplado de verdade, e pior, mantendo a coesão é um enorme desafio e o normal é encontrar arquiteturas cheias de falhas que podem aparecer com mais ou menos frequência (tem lugar que eu acesso e já sei que é microsserviços pelas falhas, geralmente momentâneas, que vejo ou pela lentidão de resposta (que pode ser outros fatores), ou não é arquitetura real de microsserviços.
Curiosamente é que a maioria dos microsserviços, se forem assim mesmo, podem rodar SQLite como banco de dados, de tão simples que fica o microsserviço em si (o problema é a integração entre eles). E por isso que muita gente usa MongoDB, ele pode não ser a melhor solução, mas é mais uma modinha a seguir, e de tão simples que fica que até ele serve muito bem, mesmo quando não for o mais adequado (tem casos que ele pode ser a melhor opção).
Não sei se o encadeamento grande faz a arquitetura deixar de ser de microsserviços, mas que é ruim eu não tenho dúvida.
No caso da observabilidade não tem relação com microsserviços, embora com eles se torna fundamental ter algo bem implementando nesse sentido.
Quase ninguém precisa de uma arquitetura de microsserviços, do ponto de vista de escala, sempre dá para escalar com arquiteturas mais simples, e do ponto de vista organizacional pode ser útil ou não. Microsserviços é complexo demais, quase ninguém faz direito, custa muito mais caro em termos financeiros seja na implementação, seja na execução e traz algumas desvantagens relevantes em muitos cenários.
Aí cabe a imagem famosa, que apesar de ser jocosa é muito real, e talvez por ser engraçada as pessoas não levam tanto a sério. Faça seu monólito bem-feito, se realmente puder provar que ainda precisa de microsserviços depois disso, então comece fazer alguns experimentos para ver se dará o resultado que espera.
Arquitetura de microsserviços é uma das maiores modinhas que já apareceu.
S2
Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente (não vendo nada, é retribuição na minha aposentadoria) (links aqui no perfil também).