Se teus serviços deployam juntos, compartilham banco e não funcionam de forma independente, parabéns: tu construiu um monólito com latência de rede. Piorou tudo e chamou de arquitetura. Gênio.
Já vi esse padrão tantas vezes que dá dor física. Alguém lê o capítulo de microserviços, fica empolgadão e gasta seis meses quebrando um monólito que funcionava em 14 serviços que se chamam sincronamente via HTTP. Uma request precisa passar por outros três serviços, todos usam um banco só e deployar um sem os outros explode tudo. Passos extras e uma conta da AWS mais cara.
O ponto do microserviço é conseguir deployar de forma independente. O Serviço A shippa uma feature sem coordenar com o B. Sem isso, tu ficou com as desvantagens de um sistema distribuído e nenhuma vantagem. Complicou tudo de graça.
Compartilhar banco mantém o acoplamento na camada de dados. Muda o nome de uma coluna e assiste cinco serviços explodirem. Com chamada HTTP síncrona em toda operação, basta um cair pro sistema inteiro retornar 500. Tu colocou uma fronteira de rede onde tinha uma chamada de função. Brilhante.
Se os deploys precisam ser coordenados, o cronograma mostra o acoplamento. Agora ele roda em Kubernetes em vez de num JAR só.
Cada microserviço deveria ser dono dos seus dados e se comunicar principalmente de forma assíncrona, com evento e fila de mensagem. Deve dar pra deployar um sem quebrar os outros, e cada time precisa conseguir desenvolver sem coordenar diariamente com outro time.
Um monólito bem estruturado é perfeitamente válido e mais simples de desenvolver, deployar e debugar. Não tem vergonha em manter um. Tu não é a Netflix nem tem os problemas dela. Faz dinheiro com o monólito e refatora depois, se precisar mesmo escalar de forma independente.