Microsserviços vs Componentes
Publicado em: sábado, 25 de jan de 2025

Uma dúvida frequente na adoção de microserviços é sobre a diferenciação entre o “microserviços” e os “componentes” que ele pode conter.

Muitas pessoas imaginam que um microserviço seja apenas uma API, implementada em um projeto monolítico, mas a realidade (e a prática) mostram que ele pode sim ser composto por diversos elementos internos (como APIs, workers, jobs em segundo plano etc.) desde que todos compartilhem o mesmo propósito de negócio/bounded context.

O que é um microserviço?

Em linhas gerais, um microserviço é uma unidade de software autônoma e independente, responsável por um contexto de negócio bem definido. Ele deve ser:

  1. Separado por domínio (ou bounded context): cada microserviço cuida de um conjunto específico de regras de negócio.
  2. Implícita ou explicitamente desacoplado de outros microserviços: ele evolui e escala de forma independente.
  3. Responsável por gerenciar seus próprios dados (idealmente).

Quando dizemos “microserviço de pagamentos” ou “microserviço de catálogo” (no caso de um e-commerce), estamos nos referindo a toda a responsabilidade daquele domínio (pagamentos ou catálogo de produtos) e não apenas a um único processo/servidor que expõe uma API.

Componentes dentro de um mesmo microserviço

É comum — e muitas vezes necessário — que um microserviço possua diferentes componentes internos para atender a demandas específicas:

  • API (REST, gRPC, GraphQL etc.): Interface principal de comunicação para receber requisições síncronas.
  • Worker/Consumidor de Fila (job workers, message consumers etc.): Responsável por processar tarefas em segundo plano, muitas vezes disparadas de forma assíncrona via mensageria (RabbitMQ, Kafka, etc.).
  • Scripts de migração (ou processos de migrate): Para manter o banco de dados ou outros recursos atualizados.
  • Tarefas Agendadas (cron jobs) ou processos de scheduler: Para executar rotinas periódicas.

Por que quebrar em componentes?

  • Melhor organização de código: separar responsabilidades no que tange a processamento em segundo plano, interface web etc.
  • Escalabilidade independente: a API pode precisar de mais réplicas para lidar com altas requisições HTTP, enquanto o worker pode escalar separadamente com base em volume de mensagens na fila.
  • Isolamento de falhas (até certo ponto): se o worker tiver um problema, não necessariamente afeta a interface da API (embora ambos ainda façam parte de um mesmo microserviço).

Mas não vira um novo microserviço?
Não. Se esses componentes compartilham o mesmo domínio, regras de negócio e banco de dados (ou gerenciam dados do mesmo contexto), ainda é um único microserviço. A delimitação principal continua sendo o “bounded context” de negócio, não a quantidade de processos implantados.


Exemplos de Cenários

1. Microserviço de Pagamentos

  • API (REST) de Pagamentos: Recebe requisições para criar uma cobrança, consultar status de pagamento etc.
  • Worker de Processamento:
    • Consome mensagens de uma fila com instruções de “capturar pagamento”, “confirmar pagamento” ou “cancelar”.
    • Pode se comunicar com gateways de pagamento externos.
  • Tarefas Agendadas (Scheduler):
    • Rotinas de reconciliação dos pagamentos diários.
    • Envios de e-mails de lembrete de pagamento atrasado.

Mesmo que a API, o worker e o scheduler sejam deployados em contêineres diferentes e escalem de forma distinta, todos fazem parte do “Microserviço de Pagamentos” e cuidam do mesmo domínio.

2. Microserviço de Catálogo de Produtos

  • API de Catalogação: Para gerenciar (CRUD) produtos, categorias, estoques, preços etc.
  • Job Worker:
    • Processa em segundo plano importações/exportações massivas de dados de produtos (por exemplo, via arquivo CSV ou integração com fornecedor).
    • Pode atualizar dados de estoque de forma assíncrona.
  • Scheduler:
    • Roda tarefas noturnas de limpeza de produtos obsoletos ou sincronização com sistemas externos.

Novamente, são vários componentes, mas todos pertencem ao domínio “Catálogo” (o que chamamos de “bounded context de catálogo”).

3. Microserviço de Notificações

  • API de Notificações: Recebe requisições para enviar e-mails, SMS, push notifications etc.
  • Worker de Envio:
    • De fato, processa em segundo plano o envio de grandes quantidades de e-mails, dispara SMS via fornecedores terceirizados e envia push notifications.
    • Trata filas e eventuais retentativas (retries) em caso de falha.
  • Scheduler de Limpeza:
    • Remove ou arquiva logs de notificações antigas.

Todos juntos formam o Microserviço de Notificações.

Como diferenciar componentes de microserviços?

  • Se o contexto de negócio é o mesmo (mesmos modelos de domínio, mesmas regras de negócio, mesmo “bounded context”), são componentes do mesmo microserviço.
  • Se lidam com contextos de negócio distintos (como “Usuários” vs. “Pagamentos”), aí sim estamos diante de microserviços diferentes.
  • Compartilhamento de banco de dados: idealmente, um microserviço é dono do seu modelo de dados (um DB ou esquema próprio). Se outro componente usa exatamente o mesmo modelo, é parte do mesmo microserviço. Se demanda lógica e dados totalmente diferentes, provavelmente justifica ser outro microserviço.
  • Visão de time/projeto: muitas vezes, cada microserviço é gerido por um time (ou parte do time) focado naquele contexto de negócio. Mesmo nesse cenário, dentro de um único microserviço podem existir várias aplicações auxiliares (API, worker, etc.).

Benefícios de projetar um microserviço com vários componentes

  1. Manutenção do código mais simples: você separa em módulos internos (ou projetos que se comunicam por filas/eventos) que tratam aspectos diferentes do mesmo problema de negócio.
  2. Independência de escalabilidade: em picos de requisições, apenas a parte de API precisa escalar; se há aumento de tarefas em segundo plano, basta escalar os workers, e assim por diante.
  3. Separação de preocupações: se cada componente foca em um tipo de “trabalho” (HTTP vs. batch vs. background tasks), fica mais fácil evoluir e dar suporte a cada um deles.

Conclusão

Um microserviço não precisa ser restrito a um único processo ou código monolítico. Ele pode (e muitas vezes deve) ter múltiplos componentes internos, cada um responsável por um tipo específico de tarefa — desde que todos estejam dentro do mesmo contexto de negócio e mantenham a coesão de domínio.

  • Não confundir: ter “várias partes” não significa que você criou “vários microserviços”.
  • O que define se estamos falando de um ou mais microserviços é o contexto de negócio (bounded context), e não a quantidade de aplicações/processos.

Desse modo, quando você ou seu time quebram um microserviço em API + Worker, estão apenas criando componentes distintos para um mesmo microserviço, e não criando outro microserviço.

O Cloud Native .NET é meu principal projeto.

Onde empenho energia para ajudar, acompanhar, direcionar Desenvolvedores, Líderes Técnicos e jovens Arquitetos na jornada Cloud Native.

Conduzo entregando a maior e mais completa stack de tecnologias do mercado.

Ao trabalhar com desenvolvedores experientes, eu consigo usar seu aprendizado com .NET, banco de dados, e arquitetura para encurtar a jornada.

Ao restringir à desenvolvedores .NET eu consigo usar do contexto de tecnologias e problemas do seu dia-a-dia, coisas que você conhece hoje, como WCF, WebForms, IIS e MVC, por exemplo, para mostrar a comparação entre o que você conhece e o que está sendo apresentado.

É assim que construímos fundamentos sólidos, digerindo a complexidade com didática, tornando o complexo, simples.

É assim que conseguimos tornar uma jornada densa, em um pacote de ~4 meses.

Eu não acredito que um desenvolvedor possa entender uma tecnologia sem compreender seus fundamentos. Ele no máximo consegue ser produtivo, mas isso não faz desse desenvolvedor um bom tomador de decisões técnicas.

É preciso entender os fundamentos para conseguir tomar boas decisões.

0 comentários

Enviar um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Este site utiliza o Akismet para reduzir spam. Saiba como seus dados em comentários são processados.


4x Microsoft MVP

Categorias

Assine

Luiz Carlos Faria

Mensagem do Autor

Espero que goste desse post. Não deixe de comentar e falar o que achou.

Se acha que esse post pode ajudar alguém que você conheça, compartilhe!

 

Lives

Fique de olho nas lives

Fique de olho nas lives no meu canal do Youtube, no Canal .NET e nos Grupos do Facebook e Instagram.

Aceleradores

Existem diversas formas de viabilizar o suporte ao teu projeto. Seja com os treinamentos, consultoria, mentorias em grupo.