Antes de otimizar qualquer coisa, vale mapear o terreno em que sua aplicação roda. São três perguntas, e a maioria dos times nunca parou pra responder todas elas com segurança.
1. Sua linguagem é single-thread ou multi-thread?
Primeiro ponto: entender a linguagem que você está utilizando. Ela é single-thread? O time sabe o que são threads?
Isso importa porque define sua estratégia de otimização desde a base: numa linguagem single-thread, um processo CPU-bound pode travar o atendimento de outras requisições; numa multi-thread, o comportamento é outro. (Aprofundamos isso no post sobre concorrência e paralelismo.)
2. Onde isso roda, e com que especificação?
Segundo ponto: entender a infraestrutura disponível. Onde isso vai rodar — serverless, Kubernetes, EC2? Quantos núcleos? Single core ou vários núcleos? Que especificação têm esses núcleos?
Cada ambiente traz variáveis diferentes: serverless tem cold start e limites de concorrência por invocação; Kubernetes depende de como você configurou requests e limits de CPU nos pods; EC2 te dá controle total, mas a responsabilidade de dimensionar certo é toda sua.
3. Quais são as dependências, e quais as restrições delas?
Terceiro ponto: quais são as dependências? Banco de dados, serviços externos? Quais as restrições de cada um?
Uma aplicação pode estar rápida no seu código e lenta na prática porque o banco tem um pool de conexões limitado, ou porque um serviço externo impõe rate limit. Isso não aparece no profiling da sua própria aplicação — só aparece quando você olha a dependência isoladamente.
Como a Henceforth ajuda
Esse mapeamento é sempre o nosso ponto de partida: entender a linguagem e o modelo de concorrência, a infraestrutura disponível e as restrições reais de cada dependência, antes de sugerir qualquer mudança. É o que evita otimizar a coisa errada.
Se você não sabe responder com segurança essas três perguntas sobre a sua aplicação, fale com a nossa equipe e vamos mapear isso juntos.