Sistema de tasks em microserviços (Spring Boot)

#Contexto

Projeto pessoal para sair da teoria e sentir na mão o que arquitetura de microserviços cobra: comunicação entre serviços, limites de responsabilidade e o custo real de distribuir algo que caberia num monolito. A ideia foi um sistema de tarefas onde o usuário cria tasks e recebe notificações sobre andamento e prazo.

#O que o produto faz

Cria e gerencia tasks com prazo associado.
Notifica o usuário sobre o andamento e a proximidade do prazo.
Distribui essas responsabilidades em três serviços independentes que se comunicam entre si.

#Arquitetura

Os três microserviços

#Decisões técnicas

Por que separar em três serviços algo que caberia em um monolito?

Justamente porque cabia num monolito. O objetivo era de estudo: só separando de verdade dá para sentir o custo de comunicação, versionamento e coordenação entre serviços. Para um produto real desse tamanho, o monolito seria a escolha certa — e essa conclusão é parte do resultado.

Por que Spring Boot para o experimento?

Queria exercitar o ecossistema Java em backend distribuído, que é o padrão em boa parte do mercado corporativo. O trade-off foi mais cerimônia e configuração do que eu teria em Node, em troca de aprender a stack onde ela é mais usada.

Como os serviços se comunicam?

Por chamadas REST entre eles, com o serviço principal orquestrando o fluxo. É a opção mais direta e legível para o escopo; um passo seguinte natural seria trocar parte disso por mensageria assíncrona quando o acoplamento temporal começasse a incomodar.

#O que deu errado

A lição foi honesta e útil: microserviço tem custo antes de ter benefício. Para o tamanho do problema, três serviços adicionaram complexidade de rede e deploy que um monolito não teria. O projeto cumpriu o papel de me ensinar exatamente quando não usar essa arquitetura — o que hoje me poupa de aplicá-la por moda em trabalho de verdade.

#Resultado

Três microserviços funcionais e públicos no GitHub: main, tasks e notification.
Base concreta para decidir, em projetos reais, entre monolito e serviços distribuídos — com critério, não com hype.