Entendendo na Prática: o que e Microservico

O que e microservico

Um microservico e um serviço autônomo com uma única responsabilidade de negócio.

Microservico e um estilo de arquitetura onde o sistema e construído como um conjunto de serviços pequenos e independentes, cada um responsável por uma funcionalidade específica de negócio. Cada serviço roda em seu próprio processo, tem seu próprio banco de dados e se comunica com os demais por meio de APIs ou mensageria. A ideia central e que cada serviço possa ser desenvolvido, deployado e escalado de forma completamente independente dos outros. Isso contrasta com o monolito, onde todo o código roda em um único processo. Microservicos permitem que diferentes equipes trabalhem em diferentes partes do sistema sem interferência, usando inclusive tecnologias distintas para cada serviço.

Como decompor um sistema em microservicos

A decomposição deve seguir os limites naturais do negócio, não os módulos técnicos.

O maior erro ao migrar para microservicos e decompor o sistema por camada técnica: criar um serviço de banco de dados, um de validação, um de autenticação. A decomposição correta e por dominio de negócio, usando o conceito de Bounded Context do DDD. Em um e-commerce, os candidatos naturais são: Pedidos, Pagamentos, Catálogo de Produtos, Estoque, Entrega, Notificações. Cada um desses contextos tem suas próprias regras, seus próprios dados e seu próprio ciclo de vida. Um serviço bem decomposto pode ser reescrito em duas semanas por uma pequena equipe. Se um serviço exige coordenação com muitos outros para funcionar, provavelmente não foi decomposto corretamente.

Comunicação síncrona vs assíncrona

REST e gRPC para comunicação imediata; Kafka e RabbitMQ para desacoplamento e resiliência.

Microservicos precisam se comunicar, e a escolha do mecanismo tem impacto direto na resiliência do sistema. Comunicação síncrona, como REST ou gRPC, exige que o serviço chamado esteja disponível no momento da chamada. Se ele estiver fora do ar, a operação falha imediatamente. E simples de entender e debugar, mas cria acoplamento temporal. Comunicação assíncrona, via mensageria como Kafka ou RabbitMQ, permite que o serviço publique um evento e continue sem esperar resposta. O serviço consumidor processa quando estiver disponível. Isso aumenta a resiliência e o desacoplamento, mas adiciona complexidade: mensagens fora de ordem, deduplicação e consistência eventual precisam ser tratados.

Database per service

Cada microservico tem seu próprio banco, sem compartilhamento direto de dados.

Um dos princípios fundamentais de microservicos e que cada serviço seja dono de seus dados. Bancos de dados compartilhados criam acoplamento forte: uma mudanca no schema feita por um serviço pode quebrar outro. No padrão Database per Service, cada microservico tem seu próprio banco, que pode inclusive ser de tecnologia diferente: o serviço de catálogo usa PostgreSQL, o de sessões usa Redis, o de logs usa Elasticsearch. A comunicação entre serviços e sempre via API ou eventos, nunca por acesso direto ao banco do outro. Isso exige lidar com consistência eventual, pois não há transações distribuídas simples. Padrões como Saga ajudam a coordenar operações que envolvem múltiplos serviços.

Exemplo em e-commerce

Cada dominio do e-commerce vira um serviço independente com banco próprio.

Em um e-commerce com microservicos, o fluxo de compra envolve vários serviços independentes. O cliente adiciona um item ao carrinho (serviço de Carrinho). Ao finalizar, o serviço de Pedidos cria o pedido e pública um evento "PedidoCriado". O serviço de Pagamentos consome o evento, processa o pagamento e pública "PagamentoConfirmado". O serviço de Estoque consome esse evento e reserva os itens. O serviço de Entrega consome e agenda o envio. O serviço de Notificações consome e envia o email de confirmação. Cada serviço opera de forma autônoma. Se o serviço de Notificações cair, os pedidos continuam sendo processados e os emails são enviados quando ele voltar.

Exemplo em fintech

Microservicos permitem escalar a parte de pagamentos independentemente do restante.

Em uma fintech, microservicos fazem sentido porque diferentes partes do sistema tem demandas completamente diferentes. O serviço de Transações precisa de alta disponibilidade, baixa latência e escalabilidade horizontal para picos. O serviço de Compliance precisa de auditoria rigorosa e regras complexas. O serviço de Relatorios pode ser mais lento e processar em batch. Com microservicos, cada um pode ser escalado, deployado e evoluido de forma independente. O serviço de Transações pode rodar em 50 instâncias durante horário de pico enquanto o de Relatorios roda em 2. Isso seria impossível em um monolito onde tudo escala junto.

Quando usar microservicos

Microservicos fazem mais sentido para times grandes com dominios bem definidos.

Microservicos são uma boa escolha quando: o sistema tem dominios de negócio claros e bem separados; o time e grande o suficiente para ter equipes por dominio; diferentes partes do sistema precisam escalar de forma independente; diferentes tecnologias são necessárias para diferentes problemas; e o time ja tem maturidade operacional para lidar com sistemas distribuídos. A Netflix, Amazon e Uber migraram para microservicos porque seus monolitos não conseguiam mais ser mantidos por times de centenas de pessoas. O tamanho e a complexidade do time foi o principal driver, não a tecnologia.

Quando não usar microservicos

Para sistemas simples ou times pequenos, microservicos adicionam complexidade sem beneficio.

Microservicos trazem custos reais: infraestrutura distribuída, service discovery, tracing distribuído, gestão de versões de API, consistência eventual, orquestração de containers. Para um time de 3 pessoas construindo um SaaS em fase inicial, esse overhead operacional e alto demais. O conselho de Martin Fowler e Sam Newman e começar com um monolito bem estruturado e migrar para microservicos apenas quando o monolito começar a ser um obstaculo real. Microservicos não resolvem problemas de organização ou de qualidade de código. Um microservico mal projetado e pior que um monolito bem organizado.

Vantagens e cuidados

Autonomia de times e escalabilidade independente são as grandes vantagens. Complexidade distribuída e o grande custo.

As principais vantagens são: deploys independentes (um serviço pode ser atualizado sem afetar os outros), escalabilidade granular (escalar apenas o que precisa), autonomia de times, diversidade tecnológica e resiliência melhorada com padrões como Circuit Breaker. Os cuidados são igualmente importantes: teste de integração entre serviços e mais complexo, rastrear uma requisição atraves de 10 serviços exige tracing distribuído, debugging e mais difícil, e a consistência de dados requer padrões avançados como Saga e Outbox. Equipes que adoptam microservicos sem maturidade operacional frequentemente criam um "distributed monolith": todos os problemas do monolito mais todos os problemas da distribuição.

Resumo

Microservicos aumentam a autonomia e a escalabilidade, mas exigem maturidade operacional.

Microservicos são uma arquitetura poderosa para sistemas complexos com times grandes. Cada serviço tem responsabilidade única, banco próprio e pode ser deployado de forma independente. A decomposição correta segue dominios de negócio, não camadas técnicas. A comunicação pode ser síncrona via REST ou assíncrona via mensageria. Os padrões como Database per Service, Circuit Breaker e Saga resolvem os desafios de consistência e resiliência. Para times pequenos ou sistemas em fase inicial, um monolito bem organizado e frequentemente a escolha mais inteligente. Microservicos devem ser adotados quando o monolito se tornar um obstaculo real para o crescimento do time e do produto.