Microserviços na prática
TLDR
Microserviços são vários pedacinhos de sistema — cada um com uma responsabilidade (pedidos, pagamento, notificação) — que conversam entre si pela rede. O que importa na prática: quem é dono de qual dado, como um pedacinho fala com o outro (chamada na hora ou por evento) e quem quebra quando mudamos essa conversa. Não existe “um banco central”; cada pedacinho guarda sua parte da verdade. Sem mapear dono e consumidores, o requisito fica vago e o escopo explode.
Por que isso importa
Mapear dono e consumidores antes de fechar escopo evita surpresa: “mudar status do pedido” pode envolver vários pedacinhos. Entender se a jornada é na hora (cada chamada soma tempo) ou por eventos (dado pode “chegar depois”) define o que dá para prometer ao usuário.
Conceito (em linguagem simples)
- Dono do dado: Cada pedacinho é dono da sua parte da verdade. Outros consomem — recebem essa informação por chamada ou por evento.
- Chamada na hora (síncrono): Um pedacinho chama o outro e espera a resposta. Soma tempo; o usuário espera a cadeia toda.
- Por mensagem/evento (assíncrono): Um publica “aconteceu X”; outros reagem quando puderem. Desacopla; o dado pode “aparecer depois”.
Vale perguntar: quem publica e quem consome? Essa jornada é na hora (síncrona) ou por eventos (assíncrona)?
Conclusão
Saber como os pedacinhos se comunicam e quem é dono de quê evita escopo vago e expectativa errada de “um lugar só para alterar”.