🚀 EventDriven NotifyEngine

Plataforma Distribuída de Processamento Assíncrono e Notificações em Larga Escala

O EventDriven NotifyEngine é uma plataforma distribuída desenvolvida para processar notificações, relatórios e agendamentos em larga escala de forma assíncrona, resiliente e escalável.

O projeto resolve um problema comum em arquiteturas enterprise: desacoplar o recebimento de requisições de alto tráfego do processamento pesado em segundo plano, evitando que operações demoradas bloqueiem a API.

A solução utiliza uma arquitetura baseada em microserviços, mensageria, processamento assíncrono, retry, DLQ, idempotência, observabilidade e autoscaling.

📌 Objetivos

Processar grandes volumes de tarefas de forma assíncrona.
Desacoplar a API do processamento pesado.
Garantir idempotência e evitar processamento duplicado.
Implementar mecanismos de Retry e Dead Letter Queue.
Controlar taxa de requisições com Redis.
Monitorar métricas da aplicação e da infraestrutura.
Permitir escalabilidade horizontal dos Workers.
Demonstrar práticas de arquitetura utilizadas em sistemas enterprise.

🏗️ Arquitetura

O sistema é dividido em dois microserviços principais:

                    ┌──────────────────────┐
                    │   React + TypeScript │
                    │      Frontend        │
                    └──────────┬───────────┘
                               │
                          HTTP / REST
                               │
                               ▼
                    ┌──────────────────────┐
                    │      notify-api      │
                    │ Spring Boot 3 / Java │
                    │         21           │
                    └──────┬───────┬───────┘
                           │       │
                 ┌─────────┘       └──────────┐
                 ▼                            ▼
          ┌─────────────┐              ┌─────────────┐
          │ PostgreSQL  │              │    Redis    │
          │ Transacional│              │ Cache / RL  │
          └─────────────┘              └─────────────┘
                           │
                     Publicação
                           │
                           ▼
                 ┌─────────────────┐
                 │ RabbitMQ / Kafka│
                 │  Message Broker │
                 └────────┬────────┘
                          │
                       Consume
                          │
                          ▼
                 ┌──────────────────────┐
                 │    notify-worker     │
                 │ Spring Boot 3 / Java │
                 │         21           │
                 └───────┬──────────────┘
                         │
                  ┌──────┴──────┐
                  ▼             ▼
           ┌────────────┐   ┌────────────┐
           │ PostgreSQL │   │    DLQ     │
           │  Status    │   │   Errors   │
           └────────────┘   └────────────┘

🔄 Fluxo de processamento

O cliente envia uma solicitação para o notify-api.
A API autentica a requisição utilizando JWT.
O evento é persistido no PostgreSQL com status PENDING.
A API publica o evento no Message Broker.
O notify-worker consome a mensagem.
O Worker verifica a idempotência do evento.
O processamento é executado.
Em caso de sucesso, o status é atualizado para PROCESSED.
Em caso de falha, o evento passa pelo mecanismo de Retry.
Após exceder o limite de tentativas, a mensagem é enviada para a DLQ.
O frontend pode consultar o status do processamento.

🧩 Microserviços

`notify-api`

Microserviço responsável pelo recebimento e gerenciamento das solicitações.

Principais responsabilidades:

Autenticação com JWT.
API REST.
Validação das requisições.
Persistência de eventos.
Publicação de mensagens.
Rate Limiting.
Consulta de status.
Documentação OpenAPI/Swagger.

Exemplo de fluxo

POST /api/notifications
        │
        ▼
 Validação + JWT
        │
        ▼
 PostgreSQL
 status = PENDING
        │
        ▼
 RabbitMQ Exchange

`notify-worker`

Microserviço responsável pelo processamento assíncrono.

Principais responsabilidades:

Consumo de mensagens.
Idempotência.
Processamento de tarefas.
Retry com backoff.
Circuit Breaker.
Atualização do status.
Tratamento de falhas.
Encaminhamento para DLQ.

RabbitMQ
   │
   ▼
Worker
   │
   ├── Sucesso ──► PROCESSED
   │
   ├── Falha ────► RETRY
   │                  │
   │                  └──► DLQ
   │
   └── Duplicado ──► Ignorado

🧠 Arquitetura C4 — Container

graph TD
    Client[React SPA] -->|HTTP / REST| API[Spring Boot REST API]
    API -->|Read / Write| DB[(PostgreSQL)]
    API -->|Cache / Rate Limit| Redis[(Redis)]
    API -->|Publish Event| Queue{{RabbitMQ Exchange}}
    Queue -->|Consume| Worker[Spring Boot Worker Engine]
    Worker -->|Update Status| DB
    Worker -->|Dead Letter| DLQ{{RabbitMQ DLQ}}

🛠️ Stack Tecnológica

Camada	Tecnologia
Backend	Java 21
Framework	Spring Boot 3
Segurança	Spring Security + JWT
Persistência	Spring Data JPA / Hibernate
Banco	PostgreSQL
Cache	Redis
Mensageria	RabbitMQ
Frontend	React + TypeScript
UI	Tailwind CSS
Estado assíncrono	TanStack Query
Resiliência	Resilience4j
Observabilidade	Spring Actuator
Métricas	Prometheus
Dashboards	Grafana
Containers	Docker
Orquestração	Kubernetes
Autoscaling	Kubernetes HPA
CI/CD	GitHub Actions
Testes	JUnit + Testcontainers
API Docs	Springdoc OpenAPI

O projeto utiliza RabbitMQ como broker principal. Kafka pode ser utilizado como alternativa para cenários que demandem maior throughput e retenção de eventos.

🛡️ Resiliência

O projeto implementa mecanismos para lidar com falhas e grandes volumes de processamento.

Idempotência

Cada evento possui um identificador único.

O Worker verifica se o evento já foi processado antes de executar a operação, evitando:

Evento A
   │
   ├── Processado ✓
   │
   └── Recebido novamente
             │
             ▼
        Ignorado ✓

A estratégia pode utilizar Redis para deduplicação ou o padrão Transactional Outbox para garantir maior consistência entre banco e mensageria.

🔁 Retry

Falhas temporárias não devem resultar imediatamente em uma mensagem perdida.

Exemplo:

Tentativa 1
    │
    ▼
   Falha
    │
    ▼
Backoff
    │
    ▼
Tentativa 2
    │
    ▼
   Falha
    │
    ▼
Backoff
    │
    ▼
Tentativa 3
    │
    ▼
   Falha
    │
    ▼
   DLQ

O mecanismo utiliza backoff exponencial para evitar sobrecarga de serviços externos.

☠️ Dead Letter Queue

Mensagens que não conseguem ser processadas após o número máximo de tentativas são encaminhadas para uma Dead Letter Queue.

Isso permite:

Inspeção manual.
Diagnóstico de erros.
Reprocessamento posterior.
Evitar perda de mensagens.
Separar mensagens problemáticas do fluxo principal.

⚡ Circuit Breaker

O Resilience4j é utilizado para proteger o Worker contra falhas em serviços externos.

Worker
   │
   ▼
API Externa
   │
   ├── OK ─────────► Continua
   │
   └── Falhas
          │
          ▼
    Circuit Breaker
          │
          ▼
       OPEN
          │
          ▼
 Evita novas chamadas

📊 Observabilidade

A aplicação utiliza Spring Boot Actuator, Prometheus e Grafana para monitoramento.

Entre as métricas acompanhadas:

Requisições HTTP.
Tempo de resposta.
Erros.
Uso de CPU.
Uso de memória.
JVM.
Quantidade de mensagens processadas.
Mensagens com falha.
Retries.
Tamanho da fila.
Taxa de processamento.

☸️ Kubernetes

Os manifestos Kubernetes ficam organizados em:

k8s/
├── postgres-deployment.yaml
├── rabbitmq-deployment.yaml
├── api-deployment.yaml
├── worker-deployment.yaml
├── hpa.yaml
├── configmap.yaml
├── secret.yaml
├── services.yaml
└── ingress.yaml

Health Checks

O notify-api possui:

Liveness Probe
      │
      ▼
/actuator/health

Readiness Probe
      │
      ▼
/actuator/health

Isso permite ao Kubernetes identificar instâncias indisponíveis e remover temporariamente Pods que não estejam prontos para receber tráfego.

📈 Horizontal Pod Autoscaler

O Worker pode ser escalado automaticamente conforme a utilização dos recursos.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: notify-worker-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: notify-worker
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

Exemplo:

Carga baixa
   │
   ▼
2 Workers

Carga aumentando
   │
   ▼
4 Workers

Carga alta
   │
   ▼
8 Workers

Carga máxima
   │
   ▼
10 Workers

🐳 Execução Local

Pré-requisitos

Instale:

Java 21
Maven
Docker
Docker Compose
Node.js
Kubernetes (opcional)
Minikube ou Kind (opcional)

1. Clonar o projeto

git clone <URL_DO_REPOSITORIO>
cd eventdriven-notifyengine

2. Subir a infraestrutura

docker-compose up -d

Serviços esperados:

PostgreSQL
Redis
RabbitMQ
Prometheus
Grafana

3. Executar a API

cd notify-api
mvn spring-boot:run

4. Executar o Worker

Em outro terminal:

cd notify-worker
mvn spring-boot:run

5. Executar o Frontend

cd frontend
npm install
npm run dev

☸️ Executando com Kubernetes

Com um cluster Kubernetes disponível:

kubectl apply -f k8s/

Verificar os Pods:

kubectl get pods

Verificar os Services:

kubectl get services

Verificar o HPA:

kubectl get hpa

📚 Documentação da API

A API utiliza Springdoc OpenAPI.

Após iniciar o notify-api, a documentação estará disponível em:

/swagger-ui.html

Também será disponibilizada uma coleção para testes:

docs/
└── postman_collection.json

A coleção contém exemplos de:

Autenticação.
Criação de notificações.
Consulta de status.
Listagem de tarefas.
Simulação de falhas.

🧪 Testes

O projeto utiliza:

JUnit
Spring Boot Test
Testcontainers
Testes de integração
Testes de mensageria

Executar:

mvn test

💥 Teste de Retry e DLQ

Para testar o mecanismo de resiliência:

Envie uma nova tarefa pela API.
Configure o Worker para simular uma falha.
Observe o consumo da mensagem.
Aguarde as tentativas de Retry.
Após atingir o limite configurado, a mensagem será encaminhada para a DLQ.
Verifique a mensagem no RabbitMQ.
Corrija a causa da falha.
Reprocesse a mensagem.

Fluxo esperado:

API
 │
 ▼
RabbitMQ
 │
 ▼
Worker
 │
 ├── Falha
 │
 ▼
Retry Queue
 │
 ├── Falha
 │
 ▼
Retry Queue
 │
 ├── Falha
 │
 ▼
DLQ

🔄 CI/CD

O projeto utiliza GitHub Actions para automatizar:

Build.
Testes unitários.
Testes de integração.
Build das imagens Docker.
Push das imagens.
Validação dos manifestos Kubernetes.

Pipeline:

Git Push
   │
   ▼
GitHub Actions
   │
   ├── Checkout
   │
   ├── Setup JDK 21
   │
   ├── Maven Test
   │
   ├── Docker Build
   │
   ├── Docker Push
   │
   └── Kubernetes Validation

Arquivo:

.github/
└── workflows/
    └── ci-cd.yml

📁 Estrutura do Projeto

eventdriven-notifyengine/
│
├── notify-api/
│   ├── src/
│   ├── pom.xml
│   └── Dockerfile
│
├── notify-worker/
│   ├── src/
│   ├── pom.xml
│   └── Dockerfile
│
├── frontend/
│   ├── src/
│   ├── package.json
│   └── Dockerfile
│
├── k8s/
│   ├── postgres-deployment.yaml
│   ├── rabbitmq-deployment.yaml
│   ├── api-deployment.yaml
│   ├── worker-deployment.yaml
│   ├── hpa.yaml
│   ├── configmap.yaml
│   ├── secret.yaml
│   ├── services.yaml
│   └── ingress.yaml
│
├── docs/
│   └── postman_collection.json
│
├── docker-compose.yml
├── .github/
│   └── workflows/
│       └── ci-cd.yml
│
└── README.md

🎯 Diferenciais Técnicos

O projeto foi estruturado para demonstrar conhecimentos de desenvolvimento backend e arquitetura distribuída, incluindo:

Microserviços.
Arquitetura orientada a eventos.
Processamento assíncrono.
Java 21.
Spring Boot 3.
Spring Security.
JWT.
RabbitMQ.
PostgreSQL.
Redis.
Idempotência.
Transactional Outbox.
Retry com backoff.
Dead Letter Queue.
Circuit Breaker.
Resilience4j.
Docker.
Kubernetes.
HPA.
Prometheus.
Grafana.
Testcontainers.
GitHub Actions.
CI/CD.
OpenAPI.
React + TypeScript.

🧠 Objetivo Arquitetural

O principal objetivo do EventDriven NotifyEngine é demonstrar como construir uma aplicação capaz de lidar com alto volume de requisições sem acoplar o tempo de resposta da API ao tempo de processamento das tarefas.

A arquitetura permite:

                 ALTO TRÁFEGO
                      │
                      ▼
               ┌─────────────┐
               │   notify-api │
               └──────┬──────┘
                      │
               Mensagem Assíncrona
                      │
                      ▼
               ┌─────────────┐
               │   RabbitMQ   │
               └──────┬──────┘
                      │
              ┌───────┴────────┐
              ▼       ▼        ▼
           Worker   Worker   Worker
              │       │        │
              └───────┴────────┘
                      │
                      ▼
                 PostgreSQL

Dessa forma, a aplicação pode absorver picos de tráfego, distribuir o processamento entre múltiplos Workers e escalar horizontalmente conforme a demanda.

📌 Status

🚧 Em desenvolvimento

O projeto está sendo construído de forma incremental, priorizando inicialmente o fluxo principal de mensageria e processamento assíncrono, seguido pelas camadas de resiliência, observabilidade, Kubernetes e CI/CD.

👨‍💻 Projeto

EventDriven NotifyEngine

Java 21 • Spring Boot 3 • RabbitMQ • PostgreSQL • Redis • React • TypeScript • Docker • Kubernetes

Name		Name	Last commit message	Last commit date
Latest commit History 5 Commits
.github/workflows		.github/workflows
notify-api		notify-api
notify-worker		notify-worker
README.md		README.md
docker-compose.yml		docker-compose.yml

Folders and files

Latest commit

History

Repository files navigation