Você trouxe pontos muito válidos e provocativos, mas gostaria de oferecer uma perspectiva adicional sobre o que é, de fato, um microsserviço e como ele se encaixa no que chamamos de "responsabilidade única".

Primeiramente, eu concordo que o tamanho do microsserviço não deve ser a principal preocupação. A ideia de que ele precisa ser pequeno é uma concepção errada que se popularizou sem muita análise. O mais importante é que o microsserviço seja independente e isolado, sem dependências diretas e sem ser acoplado a outros serviços. Então, a grande questão aqui não é "quantas coisas o serviço faz", mas sim o nível de desacoplamento que ele oferece.

Quando você fala sobre o uso do SQLite, por exemplo, achei um ponto interessante. Se um microsserviço for realmente autossuficiente e isolado, é possível usar um banco de dados simples e até local, sem a necessidade de algo complexo como MongoDB ou bancos distribuídos. A questão aqui não é a tecnologia, mas como os serviços se comunicam entre si e como garantimos a resiliência sem perder a independência.

Agora, concordo com a crítica de que muitos microsserviços acabam falhando na prática. Quando os serviços dependem de encadeamentos pesados e de um único banco de dados compartilhado, você está essencialmente voltando ao modelo de monólito, só que de forma distribuída. Essa integração mal feita é o que gera problemas de latência, falhas momentâneas e até mesmo aumento da complexidade.

E quanto à questão da observabilidade e monitoramento, acredito que o maior erro que vejo no mercado é achar que dividir o sistema em microsserviços resolve todos os problemas de escalabilidade e manutenção. O custo real dos microsserviços vai muito além de implementar a arquitetura, envolve uma série de ferramentas, processos e integração contínua que muitas empresas não estão preparadas para manter. Então, sim, fazer microsserviços é mais caro e mais complexo. Muitas vezes, um bom monólito bem estruturado e desacoplado pode oferecer tudo o que um microsserviço faria, mas com muito menos overhead.

Finalmente, queria reforçar que, ao adotar microsserviços, o ponto central é garantir que cada unidade seja livre para evoluir de forma independente, sem se preocupar com o que outras unidades estão fazendo. E para que isso aconteça, a infraestrutura e os processos de comunicação (principalmente via API) precisam estar bem definidos, para não acabar criando um sistema em que os microsserviços não são realmente independentes, mas sim apenas "endpoints" desacoplados artificialmente.

Microsserviços são uma ótima solução, mas não são uma bala de prata. Como você mesmo mencionou, é preciso avaliar se o benefício real vale o custo e o nível de complexidade.

O que você acha dos 12 fatores pra uma apliacação web ?