event-ticket-distributed-app
Project Info
Technologies
Java
Spring Boot
RabbitMQ
MongoDB
Docker
AWS
Project Links
Project Gallery
Cover
Descrição do Projeto
Visão Geral do Sistema
event‑ticket‑distributed‑app demonstra uma arquitetura orientada a eventos em que dois microsserviços Spring Boot cooperam para oferecer um fluxo completo de criação de eventos e venda de ingressos, tudo de forma assíncrona via RabbitMQ.
| Papel | Serviço | Porta | Responsabilidade |
|---|---|---|---|
| Gestão de Eventos | event‑manager | 8080 | CRUD de eventos; publica notificações quando um evento é criado/alterado. |
| Gestão de Ingressos | ticket‑manager | 8081 | CRUD de ingressos; valida vagas disponíveis, dispara mensagem de e‑mail de confirmação. |
Diagrama de Arquitetura
Fluxo de Negócio
- Criar Evento: POST /create-event → event-manager salva o evento, publica mensagem EventoCriado no RabbitMQ.
- Sincronização Ticket‑manager: O ticket-manager consome EventoCriado, cria cache local (ou dispara busca lazily) para permitir venda de ingressos associada.
- Criar Ingresso: POST /create-ticket → ticket-manager valida evento/id, persiste ingresso e publica TicketCriado.
- Envio de E‑mail: Um consumer leve (EmailConsumer) escuta TicketCriado e envia mensagem de confirmação via SMTP/AWS SES.
Garantias
| Camada | Garantia principal |
|---|---|
| RabbitMQ | Entrega pelo menos uma vez; filas duráveis. |
| ticket‑manager | Idempotência opcional via ticketId para evitar criação duplicada em re‑delivery. |
| MongoDB Atlas | Replicação nativa ― alta disponibilidade. |
Camadas Internas
| Serviço | Stack | Organização interna |
|---|---|---|
| event‑manager | Spring Web MVC, Spring Data MongoDB | Controller → Service → Repository + Mapper (MapStruct) |
| ticket‑manager | Spring Web, Spring AMQP, Spring Data | Controller → Service → Repository; Listener separado para EventoCriado |
| EmailConsumer | Spring Boot, Spring AMQP, JavaMail | Listener Rabbit → EmailService (Strategy para SMTP, SES, etc.) |
Endpoints REST
event‑manager
| Método | Rota | Ação |
|---|---|---|
| POST | /create-event | Criar evento |
| GET | /get-event/{id} | Buscar evento |
| GET | /get-all-events | Listar todos |
| GET | /get-all-events-sorted | Listar ordenado A→Z |
| PUT | /update-event/{id} | Atualizar |
| DELETE | /delete-event/{id} | Remover |
ticket‑manager
| Método | Rota | Ação |
|---|---|---|
| POST | /create-ticket | Criar ingresso |
| GET | /get-ticket/{id} | Consultar |
| PUT | /update-ticket/{id} | Atualizar |
| DELETE | /cancel-ticket/{id} | Cancelar |
| GET | /get-tickets-event/{eventId} | Ingressos por evento |
Tecnologias & Justificativa
| Categoria | Ferramenta | Motivo |
|---|---|---|
| Mensageria | RabbitMQ + Spring AMQP | Broker leve, suporte a tópicos, fácil em Dev com imagem Docker. |
| Persistência | MongoDB Atlas | Esquema flexível para eventos/ingressos, replicação gerenciada. |
| Build | Maven | Consistente com ecossistema Spring. |
| Infra como Código | Docker Compose | Reproduz ambiente local idêntico ao CI/CD. |
| Observabilidade | Micrometer + Prometheus + Grafana | Três pilares (métricas/logs/traces) prontos para produção. |
Como foi feito o deploy
- Ambiente local e CI: O comando
docker-compose up --buildinicializa RabbitMQ, ambos os microsserviços e conecta automaticamente ao MongoDB Atlas usando a string de conexão configurada. Isso garante que o ambiente de desenvolvimento seja idêntico ao de integração contínua. - Deploy em nuvem (AWS EC2): As imagens Docker são enviadas para o ECR (Elastic Container Registry) e uma instância EC2 executa o Docker Compose, orquestrando todos os serviços. O RabbitMQ pode ser migrado para Amazon MQ/ElasticMQ para maior resiliência, e o envio de e-mails utiliza o Amazon SES.
- Escalabilidade: Cada microsserviço pode ser replicado de forma independente, permitindo que o RabbitMQ atue como buffer para picos de demanda e garantindo alta disponibilidade.