Desafio para a IA: 1 milhão de requests por segundo em Java

TL;DR - Peguei o desafio “1M req/s” feito em Node (node-1m-rps) e pedi pra IA portar pra Java. Deixo aqui o prompt pronto pra colar e conto como cheguei no java-1m-rps, com Java 21 e Spring Boot 4, dando contexto em três rodadas em vez de um prompt gigante.

O desafio

O repo agile8118/node-1m-rps, que acompanha o vídeo “Handling 1 Million Requests per Second”, tem uma API em Node com Express, Fastify ou Cpeak, Redis (standalone ou cluster), Postgres e a opção de rodar em cluster com PM2. A ideia é aguentar carga alta usando Redis como cache, Postgres pra persistir e vários processos pra escalar. O desafio que propus pra IA foi levar essa mesma arquitetura pra Java.

O prompt

Dá pra colar no Cursor, no Claude Code ou em qualquer agente que consiga criar projeto e rodar comando. Se quiser Kotlin ou outra stack, é só trocar no texto.

Quero um projeto em Java que replique a lógica e a arquitetura do projeto Node.js "Handling 1 Million Requests per Second": https://github.com/agile8118/node-1m-rps

Objetivo:
- API HTTP que atenda a alta carga (meta: suportar 1M+ req/s em cenário de benchmark).
- Cache em Redis (standalone e, se possível, cluster).
- Persistência em Postgres; mesma modelagem de dados que o projeto de referência (ex.: tabela de códigos/benchmark).
- Possibilidade de rodar em modo cluster (múltiplas JVMs ou workers) para escalar horizontalmente.

Requisitos:
- Usar um framework web leve e adequado a alta performance (ex.: Vert.x, Micronaut, Spring WebFlux ou similar).
- Configuração por variáveis de ambiente (ex.: REDIS_CLUSTER, PG_CONNECT, portas).
- README com: como rodar localmente, como subir Redis e Postgres, como rodar o benchmark (ex.: ferramenta tipo wrk ou JMeter).
- Manter a mesma "história" do projeto Node: mesmo fluxo de dados (request → cache? → Postgres → response), seed do banco e, se fizer sentido, script de migração de dados do Postgres para o Redis.

Não preciso de Docker obrigatório; pode ser instruções para instalação local de Redis e Postgres. O código deve ser mínimo e direto ao ponto, sem camadas desnecessárias.

Se o objetivo for só um esqueleto que bata a meta de RPS num ambiente controlado, vale dizer isso no prompt. Normalmente a IA volta com projeto Maven ou Gradle, cliente Redis, driver Postgres, servidor HTTP reativo, endpoints espelhando os do Node, configuração e um README explicando como subir tudo e rodar o benchmark.

Por que Java

O original é Node. Levar pra Java obriga a IA a trabalhar em outro ecossistema, com outro modelo de concorrência (threads e NIO em vez de event loop) e a fazer escolhas de stack, como qual framework e qual cliente Redis usar. Pra Kotlin o mesmo prompt funciona trocando o nome da linguagem.

Como montei o java-1m-rps

Usei Java 21 e Spring Boot 4. O prompt acima gerou o esqueleto. Depois fixei a stack (Spring Boot em vez de Vert.x ou Micronaut), coloquei a configuração em variáveis de ambiente (REDIS_CLUSTER, PG_CONNECT) e ajustei o README com os passos pra rodar local e fazer o benchmark. A arquitetura é a mesma do Node: Redis de cache, Postgres como fonte da verdade, e o request só vai no banco quando não acha no cache.

Onde deu trabalho

Paridade com o Node. O projeto original tem seed, migração do Postgres pro Redis e suporte a Redis cluster. Em Java, cada script e cada variável de ambiente precisava de um equivalente. A IA montou a estrutura, mas a conexão (pool do Postgres e modo cluster do Redis) eu acertei na mão, olhando a documentação e o que o Node fazia.

Performance desde o começo. A meta é passar de 1M req/s, e um Spring MVC tradicional, com I/O bloqueante, dificilmente chega perto disso. No segundo prompt deixei claro que queria stack reativa (WebFlux ou parecido) e cliente Redis não bloqueante. A IA trocou pra WebFlux com Lettuce e o projeto foi pro caminho certo.

Configuração. Entre REDIS_CLUSTER, PG_CONNECT, portas e seeds, era coisa demais. O primeiro esqueleto veio com tudo fixo no código. Pedi “tudo por variável de ambiente, nada hardcoded” e a IA refatorou pra application.yml lendo do ambiente.

Onde a IA acertou e onde errou

Acertou na estrutura (Maven, pacotes, dependências), no fluxo básico (controller → service → Redis/Postgres) e no primeiro README. Errou mais em detalhe de configuração, como versão de dependência e as propriedades do Spring Data Redis pra cluster. Também errou nos scripts de seed e migração: essa lógica está no código do Node, ela não tinha esse código no contexto e inventou um seed genérico. Quando passei o link do repo e, depois, colei trechos do express.js e do utils.js no chat, o comportamento ficou muito mais parecido. Ela é boa pra esqueleto e padrão, e fraca pra reproduzir script e config que não estão no contexto.

Os três prompts

1. Primeiro: objetivo, link do Node e requisitos em tópicos (API, Redis, Postgres, env, README, mesmo fluxo). Não falei de Spring e deixei a IA sugerir.
2. Segundo: “Usar Spring Boot 4 e Java 21. Stack reativa (WebFlux) e cliente Redis não bloqueante. Toda configuração via variáveis de ambiente.” Isso corrigiu stack e config de uma vez.
3. Terceiro: colei trechos do Node (rotas, uso do Redis, formato do seed) e pedi pra alinhar o comportamento com aquele código. Ela ajustou endpoints e o fluxo do cache.

No fim eu tinha o projeto rodando, configurado por ambiente e com um README que dava pra seguir. Os ajustes finos (pool do Postgres, timeout do Redis, números do benchmark) fiz na mão. Dar o contexto em camadas, primeiro o objetivo, depois stack e config, por último o código de referência, funcionou bem melhor que um prompt enorme ou um monte de pergunta solta.

flowchart LR
  P1[Prompt 1: objetivo + link Node] --> P2[Prompt 2: stack + config]
  P2 --> P3[Prompt 3: trechos do Node]
  P3 --> Projeto[java-1m-rps]