🛡️ Resilient Payment Gateway API

---

📄 Sobre o Projeto

Microsserviço de Pagamentos focado em Resiliência e Tolerância a Falhas.

Diferente de APIs tradicionais que quebram quando dependências externas falham, este projeto implementa padrões de estabilidade robustos para garantir que o sistema continue respondendo, mesmo quando o Gateway de Pagamento real (simulado via WireMock) está instável ou fora do ar.

O sistema utiliza estratégias de defesa em camadas: Cache Distribuído, Retries Inteligentes e Circuit Breakers.

---

🏛️ Arquitetura de Resiliência

O fluxo de decisão foi desenhado para proteger o núcleo da aplicação e economizar recursos.

flowchart TD
    A[Cliente] -->|POST /payments| B(Payment Controller)
    B --> C{Existe no Cache?}
    
    C -- SIM --> D[Retorna do Redis ⚡]
    C -- NÃO --> E{Circuito Fechado?}
    
    E -- NÃO (Aberto) --> F[Fallback: PENDING 🛡️]
    E -- SIM (Normal) --> G[Retry Mechanism 🔄]
    
    G -->|Tentativa 1..3| H[Feign Client]
    H -->|Http Request| I[External API / WireMock]
    
    I -- Sucesso (200) --> J[Salva no Redis]
    J --> K[Retorna Sucesso]
    
    I -- Erro/Timeout --> L[Conta Falha]
    L -->|Falhas > Limite| M[Abre Circuito]
    L --> F

Loading

⚙️ Funcionalidades Enterprise (O Kit de Sobrevivência)

• ✔️ Circuit Breaker (Resilience4j): Impede o efeito cascata. Se a API externa falhar 50% das vezes, o circuito abre e para de enviar requisições, retornando um erro controlado instantaneamente.
• ✔️ Retry Pattern: Tenta processar o pagamento automaticamente até 3 vezes em caso de oscilação de rede.
• ✔️ Fallback Method: Implementação de degradação graciosa. Se tudo falhar, o usuário recebe um status PENDING em vez de um Erro 500.
• ✔️ Distributed Caching (Redis): Armazena respostas de sucesso. Se o serviço cair, consultas repetidas são respondidas em milissegundos direto da memória.
• ✔️ OpenFeign: Cliente HTTP declarativo para comunicação limpa entre serviços.
• ✔️ WireMock: Container dedicado para simular latência de rede (delay) e erros 500 reais para testes de caos.

---

🛠 Tecnologias

• Java 21 & Spring Boot 3.5
• Spring Cloud OpenFeign
• Resilience4j (Circuit Breaker, Retry)
• Spring Data Redis (Jedis/Lettuce)
• Docker & Docker Compose
• WireMock (Simulação de API externa)
• Spring Boot Actuator (Monitoramento do estado do circuito)

---

🚀 Como Rodar e Testar o Caos

1️⃣ Subir a Infraestrutura (Redis + WireMock)

docker-compose up -d

Isso iniciará o Redis (porta 6379) e o WireMock (porta 8081) já configurado com delays.

2️⃣ Executar a Aplicação

./mvnw clean spring-boot:run

3️⃣ Testar os Cenários

Cenário A: Sucesso com Delay (WireMock Ativo) Envie um POST. A resposta demorará ~1s (simulado), mas retornará 200 OK. O dado será salvo no Redis.

Cenário B: O Poder do Cache Envie o mesmo POST novamente. Resposta Instantânea (0ms). O sistema nem bateu na API externa.

Cenário C: Teste de Destruição (Circuit Breaker) Pare o container do WireMock para simular uma queda total:

docker stop payment-wiremock

Envie requisições com dados novos.

1. As primeiras 3 tentarão reconectar (Retry).
2. Após algumas falhas, o Circuit Breaker ABRE.
3. As próximas respostas serão Instantâneas com status PENDING_PROCESSING (Fallback), protegendo sua thread pool.

---

🔌 Exemplo de Requisição (JSON)

POST /v1/payments

{
  "cardNumber": "4444-5555-6666-7777",
  "cvv": "123",
  "expirationDate": "12/30",
  "cardHolder": "LUCAS ARAGAO",
  "amount": 1500.00
}

---

👨‍💻 Autor

Lucas Aragão — Backend Developer (Java / Spring)
📩 LinkedIn • GitHub