Algo que achei curioso foi a decisão de separar cada serviço em bancos diferentes, mesmo todos parecendo ser relacionais. Ao meu ver, essa separação adiciona uma complexidade que pode não ser necessária, principalmente em projetos que ainda não lidam com alta escala.
Com um único banco, você consegue manter rollback transacionais de forma muito mais simples, sem precisar de um mecanismo compensatório como o SAGA logo de início. Além disso, se em algum momento o sistema realmente exigir mais performance, é sempre possível evoluir: usar réplicas de leitura, particionamento ou até migração para diferentes tecnologias de banco por domínio específico. Ou seja, você não perde a capacidade de escalar futuramente, mas ganha simplicidade no começo do projeto e uma manutenção bem mais tranquila.
Entendo que um dos principais argumentos para separar bancos é o alinhamento com a filosofia de microsserviços: cada serviço teria total autonomia sobre seu domínio e dados, evitando acoplamento. Também faz sentido em termos de bounded contexts (DDD), já que cada equipe pode focar no seu pedaço sem se preocupar com o schema de outro serviço.
Mas, na prática, muitos sistemas começam menores e não precisam dessa independência toda. O custo de manter múltiplos bancos, gerenciar consistência distribuída, lidar com falhas e implementar mecanismos compensatórios (como SAGA) pode ser alto demais comparado ao benefício imediato. Pessoalmente, nesse trade-off, eu priorizaria a simplicidade: começar com um banco único, aceitar um acoplamento inicial (administrável) e só separar quando houvesse uma necessidade real, seja por performance, compliance ou evolução tecnológica.
Em resumo, faz sentido separar bancos quando o contexto do projeto realmente exige isolamento, auditoria e evolução independente de cada domínio. Mas se o cenário não demanda isso, a decisão pode acabar antecipando complexidade sem ganho real. Vale repensar junto ao time (se tiver) e se essa é uma necessidade de agora ou algo que pode (e deve) ser adiado para o momento certo.