microsserviços são uma abordagem arquitetural para desenvolver uma única aplicação como um conjunto de pequenas aplicações independentes. o foco é a decomposição baseada em capacidades de negócio (business capabilities).
“é uma abordagem para desenvolver uma única aplicação como um conjunto de pequenos serviços, cada um sendo executado em seu próprio processo e se comunicando com mecanismos leves.” — Martin Fowler e James Lewis
“microsserviços são pequenos serviços autônomos que funcionam juntos.” — Sam Newman
características
- autonomia: cada serviço é responsável por uma parte específica da lógica de negócio.
- deploy independente: é possível implantar alterações em um serviço sem redistribuir todo o sistema.
- escalabilidade: permite escalar apenas os serviços que demandam mais recursos, em vez da aplicação inteira.
- information hiding: o serviço consumidor não precisa saber como o outro foi construído, apenas conhecer seu contrato (API). isso reduz o acoplamento.
gerenciamento de dados (data sovereignty)
microsserviços possuem seus próprios estados e não devem compartilhar dados diretamente.
database per service (padrão)
cada microsserviço deve gerenciar seu próprio banco de dados, garantindo o desacoplamento.
shared database (anti-padrão)
embora a arquitetura de software seja feita de trade-offs, e exceções existam, o compartilhamento de banco de dados cria um acoplamento forte na camada de dados, dificultando a evolução independente.
“não compartilhe banco de dados a menos que você realmente precise. e mesmo assim faça tudo o que puder para evitar isso. na minha opinião, compartilhar banco de dados é uma das piores coisas que você pode fazer se estiver tentando obter deploy independente.” — Sam Newman*
comunicação e isolamento
em uma arquitetura distribuída, a comunicação ocorre via rede.
- contratos: devem ser explícitos, estáveis e promover baixo acoplamento.
- assincronismo: priorizar comunicação assíncrona (ex: via eventos) sempre que possível, para aumentar a resiliência.
- dependências: evitar dependências diretas e cíclicas entre serviços.
resiliência e tolerância a falhas
como microsserviços operam em rede, as falhas são inevitáveis. projetar para a resiliência não é opcional, é um pré-requisito para garantir disponibilidade, estabilidade e confiabilidade.
estratégias
- monitoramento contínuo: observabilidade é essencial para detectar falhas e responder rapidamente.
- defesa: várias técnicas devem ser aplicadas para impedir que uma falha derrube todo o sistema (ex: circuit breaker, retry pattern, bulkhead).
mindset de falha
em microsserviços, não se projeta um sistema assumindo que ele nunca vai falhar, mas sim assumindo que ele vai falhar e definindo como ele deve se comportar quando isso acontecer.
escopo e granularidade
microsserviços são componentes pequenos e coesos.
- tamanho ideal: pequenos o suficiente para serem entendidos, modificados e reescritos por uma equipe pequena, mas grandes o suficiente para entregar valor de negócio completo.
- coesão: projetados em torno de uma capacidade de negócio.
- risco de fragmentação: não fragmentar ao extremo (criação de “nanosserviços”) se isso gerar um excesso de dependências de rede.
flexibilidade tecnológica (polyglot)
ao contrário de um monolito, que obriga uma única stack, microsserviços permitem flexibilidade tecnológica. é possível escolher a linguagem e o banco de dados mais adequados para o problema específico daquele serviço.