Sempre que tiver uma conversa com uma IA potencialmente estará prestes a tomar uma das piores decisões. Infelizmente algumas pessoas já não conseguem ter essa ideia e aceitam como verdade que a IA sabe alguma coisa corretamente. Ela é só baseada em estatísticas com uma dose de aleatoriedade para não parecer mecânico demais e por isso ela só falará o que é mais falado na internet, ou seja, se o erro for muito falso é ele que você obterá. A IA não achará nada que não está presente na internet ou que esteja relativamente "escondido". Por isso é um método investigativo falho. Não quer dizer que ela não dará algum resultado e pode prestar para alguma coisa, mas o fato de poder ser falho e as pessoas acreditarem que não é um enorme problema.

Concordo totalmente, acredito que método investigativo foi um termo até que bem falho, no caso deveria ser método socrático onde na teoria eu preciso que a LLM me retorna alguma coisa (qualquer coisa) baseada no tema de entrada para dar continuidade a linha de pensamento.

A tabela tem informações inventadas, algumas eu já falei como a ideia que monólito só escala tudo. Não é algo matemático que você só faz a média e tá tudo certo.

No caso, as tabelas também seriam uma exemplificação.

Mas, a ideia de o monólito escalar tudo é que a partir do momento em que o software não pode ser mais otimizado, talvez onde a arquitetura não ajude e você comece a ter que reparticionar a aplicação em serviços menores (indo para um monólito modular).

Em vez de adotar um serviço pequeno como um lambda ou coisa assim. Já separar um domínio para outro cluster de forma que tudo relacionado a esse domínio tenha latência menor do que fazendo várias requisições entre servidor principal e outros micro-serviços.

Como se, por exemplo, o servidor não tenha que dar get em UserService para ir para Payments para ir para finalizar a lista de comprar no servidor principal e simplesmente ter uma troca entre User e o Servidor principal já que o domínio de compras está relacionado ao usuário.

Também não é verdade o que se fala sobre monólitos, sabendo fazer ele escala do jeito que precisa e temos diversas provas disso. Não conheço e já procurei bastante, parece não haver nenhuma prova que qualquer aplicação precisa de microsserviços para escalar, embora alguma pode ser um pouco mais fácil (pagando o preço geral para ter algo tão complexo, também precisaria de uma prova que os problemas compensam os benefícios).

Agora essa aqui vai depender do nível da aplicação. Vou pegar o caso mais antigo e mais absurdo que tivemos, o Twitter. Não vai se repetir, mas é bom para exemplificar.

Eles começaram com o Ruby on Rails que tinha prototipação rápida e tava indo tudo bem, até que surgiu a necessidade de recomendar coisas, e o Ruby não tinha a escala massiva para isso.

A única opção na época era migrar para Scala com o framework Akka que já tinha a arquitetura pronta para lidar com processamento paralelo massivo. Mas, obviamente, eles não iriam reconstruir todo o sistema deles em escala, então inventaram o Thrift para comunicação em protocolo binário entre subsistemas.

É um caso massivo e certamente não replicável, mas foi esse um dos pontos que o formato monólito não deu conta "a mudança de contexto em produção".

A tentativa de fazer menos serviços conseguirá o pior dos dois mundos.

Nesse caso, vai depender do estudo do caso e/ou da implementação.

A principal fraqueza dos micro-serviços é que são super-dependentes da rede para fazer seu processamento.

O monólito escapa disso mantendo tudo em um único contexto.

Dependendo da implementação, o macro-serviço teria contexto o suficiente para fazer seu processamento mesmo se a rede cair, apesar de ainda ser dependente de rede para retornar o resultado.

E de alguma forma também teria menor latência em comparação com micro-serviços, já que não depende de outras chamadas para uma resposta em determinado contexto.

Só é difícil dividir equipe por responsabilidade por incompetência gerencial, o que vai dar na mesma ou pior quando separa de forma mais forte, inclusive porque passa ter que lidar com egos mais inflados pela independência que receberam. De qualquer forma cada caso é um caso. Pode ser sim ser a melhor solução, mas depende do caso concreto.

Talvez, mas ainda sim ao nível de governança pode até ter um sentido mais interessante já que o servidor central onde as coisas mais importantes ficam fica por conta da mão de obra "permitida" a acessar.

Enquanto outras pessoas trabalham em Macro-Serviços separados. Com o nível de encapsulamento correto.

Independentemente, essa é uma ideia de arquitetura que somente com experiência e estudo possa ser usada ou não.

Não é exatamente nosso trabalho julgar qual a melhor ou qual a pior ferramenta em caso global, apenas fazer as escolhas mais sensatas com base no contexto, experiência e conhecimento que temos.