Porque não levar rankings de benchmarks a sério: os Top 3 da #rinhabackend usaram a técnica de batch insert em background async. E o ranking é baseado no total de inserts. Vejam: Isso não é trapaça porque os requerimentos não proibem isso, mas por isso o ranking não serve pra comparar "linguagens", porque nem todo mundo implementou batch inserts assíncronos. Em API Restful, quando um registro é criado, se devolve o HTTP Status 201 que é "created". Quando colocamos numa fila pra processar depois, o certo é devolver 202 que é "aceito (mas não processado)" com uma URL no header "Location" onde, ao abrir na sequência, ele pode devolver um 404 não encontrado, e você deveria voltar depois na mesma URL até confirmar. Ou até mais corretamente, a Location deveria devolver uma URL temporária como /fila/:fila_id que ficaríamos monitorando até ela retornar um status 301 que é movido permanentemente com uma nova Location com a URL final, agora garantidamente gravado no banco. O requerimento do desafio manda devolver 201 (daí o truque torna isso semanticamente "errado") e o stress test pega a URL e já manda consultar, e deveria voltar o registro com status 200. Pra isso funcionar, como o insert ainda não aconteceu, usa-se o recurso de cache. Então acontece assim: No POST /pessoas, não se grava no banco, coloca-se numa fila (como Redis) e grava o registro num cache em memória (o próprio Redis também). Depois de acumular alguns inserts, aí faz tudo de uma vez em background com batch insert. Devolve 201 created, que não é semanticamente correto, mas o desafio não pede que fosse, por isso, pra este cenário, não está errado. No GET /pessoas/:id não faz select no banco, pesquisa direto do cache em memória, e aí devolve 200. Mas porque batch insert é melhor do que insert um a um? porque 10 inserts não são só 10 inserts: são 10 begin transaction, 10 commit transaction, 10 abre e fecha de conexão, etc. Num batch isso cai pra somente 1 transaction. Em milhares de operações isso rapidamente faz diferença. Mas se todo mundo fizesse assim não ficaria tudo igual então? Não, nesse caso linguagens compiladas levam vantagem, porque pra manter uma fila e um cache precisa dividir CPU e Memória escasso. Linguagens interpretadas trocam recursos por facilidade/produtividade. Eu pensei na mesma estratégia na minha versão de Rails, mas Rails consome mais RAM e CPU do que Rust ou Go, então em somente 1.5 vCPU, minha versão fica mais lenta. De novo: isso não é trapaça, é uma estratégia válida de ser "eventualmente consistente" e tirar a garantia do insert e mudar o significado de 201. Como o stress test só se interessa na quantidade total e não se alguma coisa foi perdida, isso funciona. E por isso que não se deve generalizar nada a partir somente de benchmarks. Mas de qualquer forma, pra quem nunca viu essa técnica, é uma boa oportunidade de ver sendo feito de diversas maneiras diferentes em linguagens diferentes.