MS Orders

Plataforma de pedidos distribuída com microserviços e comunicação assíncrona.

Tecnologias

• Java (Spring Boot)
• Kotlin (Spring Boot)
• PostgreSQL
• RabbitMQ
• Docker & Docker Compose
• Makefile (automação de tarefas de desenvolvimento)

Arquitetura

Arquitetura baseada em microserviços com comunicação assíncrona via mensageria (RabbitMQ), garantindo desacoplamento entre os serviços de pedidos, processamento e catálogo.

Como rodar localmente

1. Subir a infraestrutura

docker compose -p ms-orders -f infra/composes/docker-compose-dev.yml up -d

2. Acessos

RabbitMQ Dashboard http://localhost:15672

• user: guest
• password: guest

PgAdmin http://localhost:5050

• email: admin@admin.com
• password: admin

---

Swagger

Orders Service (Swagger)

http://localhost:8081/swagger-ui/index.html

Processing Service (Swagger)

http://localhost:8082/swagger-ui/index.html

Menu Service (Swagger)

http://localhost:8083/swagger-ui/index.html

Mensageria

A comunicação entre os serviços é feita via RabbitMQ, utilizando o padrão Direct Exchange.

Exchange	Queue	Routing Key	Produtor	Consumidor
order.exchange	order.created	order.created	Orders Service	Processing Service
order.exchange	order.processed	order.processed	Processing Service	Orders Service
order.exchange	order.updated	order.updated	Orders Service	Processing Service
order.exchange	order.cancelled	order.cancelled	Orders Service	Processing Service

• order.created — publicada quando um novo pedido é criado, disparando o fluxo de processamento.
• order.processed — publicada após o processamento, atualizando o status do pedido no Orders Service.

• order.updated — disparada quando um pedido é atualizado, para o Processing Service reprocessar com os novos dados (revalidando no Menu Service também).
• order.cancelled — disparada quando um pedido é cancelado, para o Processing Service interromper ou reverter o processamento caso ainda esteja em andamento.
• order.cancel.processed — disparada pelo Processing Service de volta ao Orders Service, confirmando que o cancelamento foi efetivado.

Tipos de eventos

Tipo de Evento	Descrição
ORDER_CREATED	Pedido criado com sucesso após validação dos itens no cardápio. Dispara o fluxo assíncrono de processamento via RabbitMQ.
ORDER_CANCELLED	Pedido cancelado pelo cliente ou pelo sistema. Notifica o Processing Service para interromper ou reverter o processamento caso ainda esteja em andamento.
ORDER_PROCESS	Pedido em processamento pelo Processing Service. Atualiza o status do pedido no Orders Service com o resultado do processamento.

Fluxo do sistema

1. Recebimento do pedido O cliente faz uma requisição HTTP (POST) que chega ao Orders Service.
2. Validação dos itens no cardápio Antes de qualquer outra ação, o Orders Service consulta o Menu Service via HTTP GET para verificar se todos os produtos do pedido existem e estão disponíveis no cardápio vigente. Essa validação é obrigatória e ocorre a cada pedido recebido.
3. Decisão pós-validação

• Produtos não encontrados → o pedido é rejeitado imediatamente, sem persistência e sem publicação de evento.
• Produtos válidos → o pedido é persistido no OrdersDB e o evento order.created é publicado no RabbitMQ.

4. Consumo assíncrono O Processing Service consome o evento da fila de forma assíncrona, desacoplando o processamento da criação do pedido.
5. Processamento As regras de negócio são aplicadas e o resultado é persistido no ProcessingDB. O status do pedido é atualizado no OrdersDB (ex: CONFIRMED, REJECTED).
6. Consulta pelo cliente O cliente pode consultar o status do pedido a qualquer momento via HTTP GET, recebendo o estado atual diretamente do Orders Service.

Objetivo

Este projeto tem como objetivo demonstrar na prática a construção de sistemas distribuídos utilizando microserviços, mensageria e boas práticas de arquitetura moderna.