Você é um desenvolvedor Backend Java Sênior especializado em...

Prompt

Você é um desenvolvedor Backend Java Sênior especializado em Java 25, Spring Boot 4, PostgreSQL, Redis e sistemas distribuídos. Implemente o backend de uma plataforma de processamento de pedidos chamada OrderFlow. Requisitos O sistema deve possuir: - Java 25 - Spring Boot 4 - Spring Web - Spring Data JPA - PostgreSQL - Redis - Spring Security - JWT - Bean Validation - Flyway - Docker Compose Funcionalidades 1. Autenticação Implemente: - POST "/api/auth/register" - POST "/api/auth/login" - POST "/api/auth/refresh" - POST "/api/auth/logout" Utilize access token + refresh token. O refresh token deve ser revogável. Não armazene senhas em texto puro. --- 2. Produtos Implemente: - POST "/api/products" - GET "/api/products" - GET "/api/products/{id}" - PUT "/api/products/{id}" - DELETE "/api/products/{id}" Um produto possui: - id - name - description - price - stock - createdAt - updatedAt A API deve possuir paginação. --- 3. Pedidos Implemente: - POST "/api/orders" - GET "/api/orders/{id}" - GET "/api/orders" - POST "/api/orders/{id}/cancel" Um pedido possui: - id - user - status - total - createdAt - updatedAt Cada pedido possui vários itens. --- Regra crítica Considere o seguinte cenário: O produto possui apenas 1 unidade em estoque. Dois usuários fazem uma requisição simultaneamente tentando comprar essa unidade. O sistema NÃO pode permitir estoque negativo. Implemente uma solução correta para concorrência. Explique por que sua solução funciona. --- Idempotência O endpoint de criação de pedidos deve aceitar: "Idempotency-Key" Se o cliente enviar a mesma chave duas vezes, a operação não pode criar dois pedidos. Implemente isso corretamente considerando duas requisições simultâneas. --- Redis Utilize Redis para: - cache de produtos - rate limiting - controle de idempotência Explique quais dados devem possuir TTL e quais não. --- PostgreSQL Crie as entidades e migrations necessárias. Utilize constraints do banco quando elas forem importantes para garantir integridade. Não dependa exclusivamente da aplicação para garantir regras críticas. --- Arquitetura Utilize uma arquitetura organizada em camadas. No mínimo: - Controller - Service - Repository - Domain/Entity - DTO - Mapper - Exception - Security - Configuration Evite colocar regra de negócio dentro dos Controllers. --- Tratamento de erros Crie um tratamento global utilizando "@RestControllerAdvice". A API deve retornar erros estruturados, por exemplo: { "timestamp": "...", "status": 409, "error": "CONFLICT", "message": "Insufficient stock", "path": "/api/orders" } Utilize corretamente HTTP 400, 401, 403, 404, 409 e 422 quando aplicável. --- Segurança Implemente: - autenticação JWT - autorização baseada em roles - senha com algoritmo apropriado - proteção dos endpoints administrativos - validação dos JWTs - expiração dos tokens Não coloque secrets diretamente no código. --- Observabilidade Adicione: - logs estruturados - métricas - correlation/request ID - informações úteis para debugging Explique quais métricas você monitoraria em produção. --- Docker Crie um "docker-compose.yml" contendo: - aplicação Spring Boot - PostgreSQL - Redis A aplicação deve conseguir iniciar corretamente após os serviços necessários estarem disponíveis. --- O que você deve entregar 1. Estrutura completa do projeto. 2. Código Java das principais classes. 3. Entidades JPA. 4. DTOs. 5. Controllers. 6. Services. 7. Repositories. 8. Security/JWT. 9. Exception Handler. 10. Migrations Flyway. 11. Configuração PostgreSQL. 12. Configuração Redis. 13. Docker Compose. 14. Exemplos de requests/responses. 15. Testes automatizados para as partes críticas. Parte mais importante do benchmark Depois de implementar, faça uma análise crítica da própria solução. Responda: 1. Onde existem condições de corrida? 2. O que acontece se a aplicação cair durante uma transação? 3. O que acontece se Redis ficar indisponível? 4. O que acontece se PostgreSQL ficar indisponível? 5. O que acontece se duas requisições utilizarem a mesma "Idempotency-Key" simultaneamente? 6. Como você evitaria overselling? 7. Quais índices PostgreSQL você criaria? 8. Onde existe risco de N+1 query? 9. Como você escalaria horizontalmente essa aplicação? 10. O que você mudaria se o sistema passasse de 100 requisições por segundo para 10.000? Não apresente apenas código que "parece funcionar". Explique as garantias de consistência e concorrência da implementação e diferencie claramente uma solução teoricamente correta de uma solução realmente segura em produção.