Engenharia de Software · Arquitetura
Arquitetura de Microsserviços
Do monolito à decomposição — o que se ganha, o que se paga e como decidir com critério de engenharia.
Prof. Dr. Ciro J. A. Macedo
Instituto Federal de Goiás · Câmpus Cidade de Goiás
ciro.macedo@ifg.edu.br
Abertura
A pergunta desta palestra
Programar vocês já sabem — ou estão aprendendo. Esta palestra é sobre a parte que não é programar: a que decide se o sistema continua de pé no terceiro ano de vida, com outra equipe cuidando dele.
Microsserviços resolvem o meu problema — ou criam um problema novo que eu ainda não sei operar?
O percurso
Primeiro o vocabulário de arquitetura; no fim, as competências que o mercado cobra de quem trabalha com isso.
Um caso só
Uma loja virtual, do primeiro sistema “tudo junto” até a divisão em serviços.
O compromisso
Nenhuma tecnologia sem o preço ao lado. Arquitetura é escolha sob restrição, não catálogo de soluções.
📖 Termos desta tela — em português claro
MonolitoUm sistema que é uma peça só: todo o código vira um único programa, que vai para o ar de uma vez.
MicrosserviçosO mesmo sistema dividido em vários programas pequenos e independentes, que conversam entre si pela rede.
OperarManter o sistema funcionando depois de pronto: no ar, monitorado, atualizado, socorrido quando cai.
Bloco 1 · O que é arquitetura
O difícil não é escrever o código — é mudá-lo
Custo de software é custo de mudança: a primeira versão é a parte barata. Caro é alterar, dois anos depois, um sistema que já está em uso — e quem altera quase nunca é quem escreveu.
Design de código · zoom de perto
Como cada parte é escrita
As classes, o que cada uma faz e como conversam. Perguntas: esta classe depende de quantas outras? Está acoplada demais?
Ferramentas: princípios SOLID, DRY, KISS e padrões de projeto.
Arquitetura de software · zoom de longe
Como as partes se organizam
Os grandes blocos do sistema e como se relacionam. Perguntas: quais são os módulos? Quem pode chamar quem? Onde ficam as fronteiras?
Ferramentas: camadas, módulos, estilos como arquitetura limpa e hexagonal.
Dominar a linguagem é pré-requisito, não diferencial. O que distingue o profissional experiente é saber onde traçar fronteiras — e quando não traçá-las.
📖 Termos desta tela — em português claro
AcoplamentoO quanto uma parte depende de outra. Muito acoplado: mexeu num lugar, quebrou em outro.
SOLID · DRY · KISSPrincípios para escrever código organizado: cada classe com uma responsabilidade; não repetir código; manter simples.
Padrões de projetoSoluções já testadas para problemas que se repetem — catálogo clássico de 1994, conhecido como GoF.
MóduloUm pedaço do sistema com responsabilidade própria e fronteira clara — como um departamento numa empresa.
Bloco 1 · O que é arquitetura
O critério: custo de reversão
A diferença entre os dois níveis não é de importância. É de quanto custa desfazer — pense numa casa.
Design de interiores · reversível
Errar custa um fim de semana
Sofá, iluminação, quadro na parede. Em software: o nome de uma classe, um trecho reorganizado, a troca de uma biblioteca.
Decida rápido — deliberar demais aqui é desperdício.
Planta da casa · cara de reverter
Errar custa obra
Paredes estruturais, acessos. Em software: as fronteiras entre partes, o modelo de dados, o contrato da API, uma base de dados ou várias.
Decida com evidência — pergunte que problema isso resolve.
Se a decisão errada custa um trimestre e um plano de migração, é arquitetura. Se custa uma tarde, é design. Monolito ou microsserviços é parede estrutural: separar um módulo vira mais um servidor, mais um banco e uma rede no meio.
📖 Termos desta tela — em português claro
Modelo de dadosComo as informações são organizadas no banco: que tabelas existem e como se ligam.
APIA “porta de atendimento” de um programa: o conjunto de pedidos que outros programas podem fazer a ele.
Contrato da APIO combinado sobre essa porta — o que se pode pedir e o que volta. Mudar o contrato quebra quem usa.
MigraçãoMover sistema ou dados de um formato para outro sem parar o que está funcionando.
Bloco 2 · O monolito · caso condutor
A loja virtual, versão 1
Navegador, aplicativo e parceiros enviam requisições. Um balanceador de carga reparte o movimento entre cópias de uma única aplicação, que faz tudo, sobre um único banco.
Navegadorweb
App móvelcelular
Parceirooutro sistema
→
Balanceador de cargareparte o movimento
→
Aplicação da loja · vai para o ar de uma vez
CatálogoCarrinhoPedidos
PagamentoEstoqueNotificação
Relatórios
→
banco de dados único · todas as tabelas juntas
Um código, uma implantação, um banco. E isto não é “como não fazer”: é como quase todo sistema de sucesso nasceu — inclusive os que hoje são exemplo de microsserviços.
📖 Termos desta tela — em português claro
RequisiçãoO pedido que o navegador ou o app envia ao servidor: “me mostre este produto”. O servidor devolve uma resposta.
Balanceador de cargaUm “porteiro” que distribui os pedidos entre várias cópias do sistema para nenhuma ficar sobrecarregada.
Implantação (deploy)Colocar uma nova versão do sistema no ar, para os usuários.
Bloco 2 · O monolito
O monolito não é o vilão
Antes dos problemas, o que se perde ao sair dele. Tudo isto some no primeiro dia de sistema distribuído.
Transação “tudo ou nada”
Gravar o pedido, baixar o estoque e registrar o pagamento numa transação ACID: ou tudo dá certo, ou nada acontece. De graça.
O compilador ajuda
Mudou o nome de um conceito? O compilador aponta cada lugar que quebrou. Ele não atravessa a rede.
Um código, uma implantação
Uma versão no ar. A operação inteira cabe na cabeça de uma pessoa.
O erro vem com endereço
O rastro da pilha mostra o caminho completo da falha. Depurar é ler uma lista, não investigar sete sistemas.
Não confunda monolito com “grande bola de lama”: o primeiro é um sistema que vai para o ar como peça única; o segundo é código sem organização interna. Microsserviço não cura bagunça — espalha a bagunça pela rede.
📖 Termos desta tela — em português claro
Transação ACIDGarantias do banco: Atomicidade (tudo ou nada), Consistência (regras sempre válidas), Isolamento (uma não atrapalha a outra), Durabilidade (gravou, não perde).
CompiladorO programa que traduz o código para a máquina — e reclama antes de rodar quando algo não bate.
Rastro da pilha (stack trace)A lista que o programa mostra no erro: qual função chamou qual até chegar à falha.
Grande bola de lamaTradução de big ball of mud: apelido de sistema onde tudo depende de tudo, sem divisão clara.
Bloco 2 · O monolito
Onde o monolito começa a doer
Cinco dores, todas na nossa loja. Nenhuma é sobre código feio: todas são de tamanho — de movimento, de negócio ou de equipe.
01 Tudo sobe junto
Mudar só o texto de um e-mail exige recompilar, testar e implantar a loja inteira.
02 Uma falha derruba tudo
Um vazamento de memória nos relatórios consome o programa e derruba a compra junto.
03 Cresce tudo ou nada
Na Black Friday o gargalo é Pedidos, mas é preciso escalar a loja inteira — pagando por máquina ociosa.
04 Uma tecnologia só
Preço em tempo real e página simples presos à mesma linguagem e ferramentas.
05 Equipes na fila
Seis times disputando o mesmo dia de publicar. Coordenar custa mais que programar.
Com quatro desenvolvedores e três mil usuários, nenhuma dessas dores aparece. É a primeira pergunta antes de dividir qualquer coisa.
📖 Termos desta tela — em português claro
Vazamento de memóriaDefeito em que o programa vai ocupando memória e nunca devolve, até travar.
EscalarAumentar a capacidade para atender mais gente — em geral, rodando mais cópias do sistema.
GargaloA parte mais lenta, que segura todo o resto — como o caixa único de um supermercado lotado.
Bloco 3 · Microsserviços
A definição, e o que ela realmente exige
“Microsserviços são uma abordagem arquitetônica e organizacional do desenvolvimento de software na qual o software consiste em pequenos serviços independentes que se comunicam usando APIs bem definidas. Esses serviços pertencem a pequenas equipes autossuficientes.”
Definição da AWS (nuvem da Amazon) · leitura complementar: Sam Newman, Building Microservices
Técnica e organizacional
Muda também como as equipes se organizam. Ignorar essa metade é a causa mais comum de fracasso.
Independentes
Cada um vai para o ar sozinho. Se dois sempre sobem juntos, são um serviço só — com rede no meio.
APIs bem definidas
A API é a única porta. Nada de ler direto a tabela do vizinho “só desta vez”.
Divididos pelo negócio
O recorte segue o domínio — Pedidos, Catálogo, Pagamento — e não a parte técnica.
📖 Termos desta tela — em português claro
ServiçoUm programa que fica no ar atendendo pedidos de outros programas.
DomínioO assunto do negócio que o sistema atende: numa loja, produtos, pedidos, pagamentos.
Equipe autossuficienteUm time que cuida do seu serviço do código até o ar, sem depender de outros times.
Bloco 3 · Microsserviços · caso condutor
A mesma loja, decomposta
Cada parte do negócio vira um programa pequeno (micro) com uma responsabilidade clara (serviço) — e seu próprio banco.
Portão de entradaAPI Gateway
→
Catálogoprodutos
banco · catálogo
Pedidosfechar a compra
banco · pedidos
Pagamentocobrança
banco · pagamento
Estoquedisponibilidade
banco · estoque
Notificaçãoe-mail · celular
banco · notificação
Se Pedidos cair, o cliente ainda navega no catálogo e a loja segue aparecendo no Google. O prejuízo deixa de ser loja fora do ar e vira degradação parcial. Sistema cai — a diferença é que agora cai um pedaço.
📖 Termos desta tela — em português claro
Portão de entrada (API Gateway)Um ponto único por onde todos os pedidos entram antes de seguir para o serviço certo. Volta no slide 16.
Degradação parcialO sistema funciona “pela metade”: uma parte para, o resto continua atendendo.
Bloco 3 · Microsserviços
O que se ganha
Falha isolada
A falha fica no serviço que a causou — desde que quem chama tenha tempo-limite e disjuntor. Senão, ela atravessa a fronteira.
Publicação independente
Corrigir o texto do e-mail vira uma publicação de minutos, sem encostar na compra.
Cresce só o que precisa
Três cópias de Pedidos na Black Friday, uma de Catálogo. Paga-se pela capacidade onde está o gargalo.
Tecnologia sob medida
Cada serviço na ferramenta certa — com moderação: cada linguagem nova é mais uma coisa para socorrer às 3h da manhã.
Equipes donas do seu pedaço
Times pequenos, do código ao ar, sem fila. É o ganho que mais aparece na prática.
Atenção: Lei de Conway
O sistema acaba espelhando a organização. Dividir o sistema sem dividir os times dá o pior dos dois mundos.
📖 Termos desta tela — em português claro
Tempo-limite (timeout)“Se não responder em 2 segundos, desisto” — evita esperar para sempre por um serviço travado.
Disjuntor (circuit breaker)Como o da sua casa: depois de várias falhas seguidas, para de chamar o serviço doente por um tempo.
Lei de ConwayObservação de Melvin Conway (1968): equipes que não conversam produzem partes de sistema que não conversam bem.
Bloco 3 · Microsserviços
O que se paga
O que antes era uma chamada dentro do mesmo programa agora atravessa a rede. E a rede tem opinião própria.
A rede não é confiável
As falácias da computação distribuída (1994) seguem valendo: a rede falha, a latência não é zero, o caminho muda.
Adeus, “tudo ou nada”
Não há transação ACID que atravesse cinco bancos. Entra a consistência eventual.
O erro perde o endereço
Aparece no serviço E, foi causado no B, começou no A. Sem rastreamento, investigar é arqueologia.
Mais infraestrutura
Mais servidores, mais publicações automáticas, mais certificados, mais conta da nuvem — e alguém mantendo tudo de pé.
Cada conversa é uma decisão
Esperar a resposta ou não? E se demorar? Cada ligação entre dois serviços tem consequência.
Monitorar vira obrigação
Sem saber o estado de cada serviço, não há como operar — nem como dormir.
📖 Termos desta tela — em português claro
Falácias da computação distribuídaOito suposições erradas que todo programador faz ao distribuir um sistema — listadas na Sun Microsystems.
LatênciaO tempo que a mensagem leva para ir e voltar pela rede. Nunca é zero.
Consistência eventualOs dados ficam certos depois de um tempo, não no mesmo instante — por alguns segundos, partes do sistema discordam.
Bloco 3 · Microsserviços
O prêmio do microsserviço
“Prêmio” no sentido de seguro (Martin Fowler): abaixo de um certo tamanho, a equipe com microsserviços produz menos que a equipe com um monolito bem organizado. Paga o seguro e não usa.
Ainda não é hora
- Equipe única — não há fila de times para resolver.
- Negócio ainda mudando — mover fronteira entre serviços é caro.
- Publicar já é sofrido — com quinze serviços, dói quinze vezes.
- Sem monitoramento — você não conseguirá explicar a própria falha.
O patamar chegou
- Várias equipes disputando o mesmo dia de publicar.
- Partes com exigências diferentes — a compra não pode cair; o relatório pode esperar.
- Negócio maduro, com fronteiras que já se provaram estáveis.
- Cultura de operação: publicação automática, métricas, plantão.
Com três sinais da coluna esquerda, a resposta certa é não. E dizer não com esse argumento é engenharia, não conservadorismo.
📖 Termos desta tela — em português claro
Patamar de complexidadeO ponto a partir do qual o sistema e a equipe ficaram grandes o bastante para a divisão compensar.
PlantãoEscala de quem atende se o sistema cair fora do horário — inclusive de madrugada.
Bloco 4 · Como se faz direito
Monolito primeiro
Recomendação de Martin Fowler. O motivo surpreende: é o sistema junto que permite descobrir onde ficam as fronteiras. Dentro dele, mover fronteira é reorganizar código; entre serviços, é migrar dados e negociar entre times.
Monolitonegócio em descoberta
→
Monolito modularfronteiras explícitas
→
Extração gradualuma parte por vez
→
Serviçossó onde compensa
A parada que basta para a maioria
O monolito modular: fronteiras claras, um sistema só no ar. Ganha a organização sem pagar a rede. Para muitos sistemas, é o ponto final — e está tudo certo.
Por que não começar dividido
Fronteira desenhada antes de conhecer o negócio sai errada — e corte errado se paga em lentidão, em dado inconsistente e em reunião.
“Comece com um monolito, migre para microsserviços.” Quase todos os casos de sucesso seguiram esse caminho; quase todos os fracassos começaram divididos.
Martin Fowler · MonolithFirst
📖 Termos desta tela — em português claro
Monolito modularUm sistema só no ar, mas dividido por dentro em módulos que não invadem uns aos outros.
ExtraçãoTirar uma parte de dentro do monolito e transformá-la num serviço separado.
Bloco 4 · Como se faz direito
O corte é pelo negócio, não pela parte técnica
O critério vem do Projeto Orientado ao Domínio: cortar no contexto delimitado — o limite dentro do qual as palavras do negócio têm um só significado.
Errado · por camada técnica
Serviço das
telas
→
Serviço das
regras
→
Serviço do
banco
- Toda mudança atravessa os três: três publicações combinadas.
- Ganhou a lentidão da rede sem ganhar autonomia.
Certo · por parte do negócio
Catálogoproduto, preço
Pedidoscarrinho, compra
Pagamentocobrança, fraude
- Uma mudança, um serviço, uma publicação.
- “Produto” no Catálogo é foto e preço; no Estoque é código e quantidade. Modelos diferentes — e tudo bem.
Teste prático: se toda alteração exige mexer em três serviços ao mesmo tempo, o corte está no lugar errado.
📖 Termos desta tela — em português claro
Projeto Orientado ao Domínio (DDD)Método de Eric Evans (2003): modelar o software a partir da linguagem e das regras do negócio.
Contexto delimitado (bounded context)Uma “região” do negócio com vocabulário próprio — candidata natural a virar um serviço.
Camada técnicaDivisão por função de programação — tela, regra, banco — e não por assunto do negócio.
Bloco 4 · Como se faz direito
Figueira-mata-árvore — extração gradual
A figueira cresce envolvendo a árvore hospedeira até substituí-la. É a metáfora de Fowler (Strangler Fig) para migrar sem parar o negócio — nada de reescrever tudo de uma vez.
Passo 1 · interceptar
Todo pedido passa a entrar por um portão na frente do monolito. Nada muda para o usuário — mas agora há onde desviar.
Passo 2 · extrair a ponta
Começa-se pela parte menos ligada às outras e de menor risco. Só os pedidos de Notificação vão para o serviço novo.
Passo 3 · migrar e desligar
Os dados mudam de casa, o código antigo sai do monolito. Repete-se com a próxima parte.
- Volta atrás a cada passo: se o serviço novo falhar, o desvio é desfeito — o monolito nunca saiu do ar.
- O negócio não espera: funcionalidade nova continua saindo durante a migração. Reescrever tudo de uma vez é a receita de fracasso mais documentada da área.
Bloco 4 · Padrões estruturais
Duas decisões estruturais: a entrada e os dados
Portão de entrada · API Gateway
Clientes
→
Portãorota · login · limites
→
Serviços
Resolve
É o padrão Fachada um nível acima: manda cada pedido ao serviço certo, confere o login uma vez só, limita abusos e esconde do cliente as mudanças internas.
Ameaça
Se regra de negócio for morar nele, você reconstruiu o monolito — agora como ponto único de falha.
Um banco por serviço · e o mundo real
- É o que torna o serviço independente de verdade: se o time A muda uma tabela, os times B e C não quebram.
- Se o banco compartilhado for inevitável (sistema antigo, relatório geral): trate como separado — cada tabela tem um dono, ninguém consulta tabela alheia. E com data para acabar.
📖 Termos desta tela — em português claro
Padrão Fachada (Facade)Padrão de projeto clássico: uma porta única e simples na frente de algo complicado — como uma recepção.
Ponto único de falhaUma peça que, se parar, para tudo. É o que toda arquitetura tenta evitar.
TabelaOnde o banco guarda um tipo de informação — pedidos, clientes — em linhas e colunas, como uma planilha.
Bloco 4 · Padrões estruturais
Esperar a resposta × deixar recado
Nem tudo se resolve na hora. A análise antifraude de uma compra pode levar minutos — o cliente não pode ficar com a tela travada.
Síncrono · como um telefonema
- Pergunta e espera na linha: simples, resposta na hora.
- Se o outro cai ou demora, quem ligou trava junto. Tempo-limite, nova tentativa e disjuntor são obrigatórios.
Assíncrono · como deixar recado
Pagamento
→
Fila de mensagensRabbitMQ · Kafka
→
Antifraude
- Deixa o recado na fila e segue; a fila segura picos e quedas temporárias.
- Custo: o pedido nasce “em análise” e muda depois; e a mesma mensagem pode chegar duas vezes — exige idempotência.
Regra prática: síncrono quando o usuário está olhando a tela esperando a resposta; assíncrono quando o resto do mundo pode saber daqui a alguns segundos.
📖 Termos desta tela — em português claro
Nova tentativa (retry)Falhou? Tentar de novo, com intervalo — porque muita falha de rede é passageira.
Fila de mensagensUma caixa de recados entre serviços; quem recebe lê quando puder. RabbitMQ e Kafka são as ferramentas mais conhecidas.
IdempotênciaFazer duas vezes dá o mesmo resultado que fazer uma. Essencial para não cobrar o cliente em dobro.
Bloco 4 · Operação
Observabilidade — o rastro do erro que você perdeu
No monolito, os registros já saem juntos. Dividido, cada serviço fala sozinho: é preciso reconstruir a visão de sistema único — em três frentes.
Registros (logs)
O diário de bordo de cada serviço, num formato único para todos — qualquer que seja a linguagem — e reunido num só lugar.
Métricas
Números ao longo do tempo: tempo de resposta, erros, saturação. Permitem antecipar: “às 19h a carga sobe — aumente as cópias meia hora antes”.
Rastreamento distribuído
Um identificador de correlação que acompanha a compra por todos os serviços. Substitui o rastro da pilha perdido.
No monolito, observabilidade é desejável. Em microsserviços, é infraestrutura crítica: sem ela você não tem um sistema — tem um conjunto de caixas-pretas que às vezes conversam.
📖 Termos desta tela — em português claro
ObservabilidadeA capacidade de entender o que está acontecendo dentro do sistema olhando só o que ele registra.
SaturaçãoO quanto um recurso está perto do limite — memória, processador, conexões.
Identificador de correlaçãoUm “número de protocolo” dado ao pedido na entrada e carimbado em cada serviço por onde passa.
Bloco 5 · O que isso exige de você
“Eu sei programar.” Isso resolve?
Não — e é boa notícia, porque mostra o que estudar. Quem sabe criar uma API já sabe escrever um microsserviço. O trabalho está em operar dezenas deles.
Contêineres e orquestração
Empacotar cada serviço e gerenciar as cópias no ar.
Docker Kubernetes
Redes
Endereços, balanceamento, tempo-limite: o espaço entre dois serviços.
Segurança
Dado protegido viajando e guardado; quem é você × o que pode fazer.
Entrega
Publicação automática, ambientes de teste e como voltar atrás.
Observabilidade
Registros, métricas, rastreamento e alertas — ver antes do cliente.
Quatro das cinco frentes são de infraestrutura e operação — por isso microsserviços e DevOps aparecem juntos nas vagas. E na entrevista, explicar por que não usar microsserviços num caso concreto impressiona mais do que dez tecnologias no currículo.
📖 Termos desta tela — em português claro
Contêiner (Docker)Uma “caixa” com o programa e tudo de que ele precisa, que roda igual em qualquer máquina.
Orquestração (Kubernetes)Software que liga, desliga, multiplica e reinicia contêineres sozinho.
Publicação automática (CI/CD)Uma esteira que testa e coloca cada versão no ar sem passos manuais.
DevOpsCultura em que quem desenvolve também cuida de pôr e manter o sistema no ar.
Fechamento
Três ideias para levar
01
Arquitetura é o conjunto das decisões caras de reverter. Trate-as com mais evidência e menos opinião.
02
Microsserviço não é evolução do monolito — é uma troca. Troca-se complexidade de código por complexidade de operação, e só compensa acima de um certo tamanho.
03
O corte é pelo negócio e a extração é gradual. Uma parte por vez, nunca reescrevendo tudo.
- NEWMAN, Sam. Building Microservices. 2. ed. O'Reilly, 2021. — comece por este
- RICHARDSON, Chris. Microservices Patterns. Manning, 2018.
- EVANS, Eric. Domain-Driven Design. Addison-Wesley, 2003.
- FOWLER, Martin. MonolithFirst; Microservice Trade-Offs; StranglerFigApplication. martinfowler.com — artigos curtos e gratuitos
Prof. Dr. Ciro J. A. Macedo
Instituto Federal de Goiás · Câmpus Cidade de Goiás
ciro.macedo@ifg.edu.br github.com/ciromacedo