Scaling Strategies for Solo AI Services

Quando implantei a plataforma de IA clínica em um Mac Mini, esperava que o tráfego fosse meu problema de escalonamento. Não era.

Na primeira vez que alguns usuários concorrentes acessaram o sistema ao mesmo tempo, a latência saltou de aproximadamente 2 segundos para mais de 6. O próprio servidor mal se moveu — a CPU estava ociosa. O problema estava acima: cada requisição do usuário disparava uma chamada separada à API Claude, e o limite de requisições da API já estava saturado.

Uma fila é uma sala de espera educada — melhor do que todos correndo para a porta ao mesmo tempo. Esse único insight mudou completamente como pensei sobre escalonamento de um serviço de IA solo.

A mudança fundamental: Engenheiros solo de IA não precisam de mais servidores. Precisam de uso mais inteligente da única API que estão chamando.

As três alavancas que importam:

1. Cache — pule completamente a chamada à API quando você já tem a resposta.
2. Fila — controle quantas chamadas saem de uma vez para que você nunca bata na parede do limite de requisições.
3. Back-off — quando você for limitado, espere inteligentemente antes de tentar novamente.

Este módulo percorre cada alavanca com padrões TypeScript funcionais que você pode inserir em uma rota de API Next.js ou um serviço em background.

A Anthropic aplica limites de requisições em duas dimensões simultaneamente:

• Requisições por minuto (RPM) — o número de chamadas de API que você pode fazer por minuto.
• Tokens por minuto (TPM) — o total de tokens de entrada + saída em todas as chamadas nessa janela.

Quando qualquer limite é excedido, a API retorna HTTP 429 Too Many Requests junto com um cabeçalho Retry-After que informa quanto tempo esperar.

O Que Acontece na Prática

Imagine um serviço de automação de suporte onde cada ticket de entrada aciona uma chamada à API Claude. Em baixo volume (um ticket por minuto) tudo parece bem. Mas quando cinco tickets chegam em trinta segundos:

• Chamada 1 passa imediatamente.
• Chamadas 2–4 se acumulam em milissegundos.
• Chamada 5 chega enquanto as quatro primeiras ainda estão em voo.
• A API retorna 429 para as chamadas 3 e 5.
• Sem filas, ambas falham e o usuário vê um erro.

O serviço não está sobrecarregado — o Mac Mini está ocioso. Mas da perspectiva da API, o contrato de concorrência foi violado.

Prompt de reflexão: Pense no seu próprio serviço de IA (atual ou planejado). Qual é o pior caso de burst de usuários concorrentes que você esperaria em uma janela de cinco minutos? Como isso se compara ao limite RPM do seu nível?

A chamada de API mais barata é aquela que você nunca faz. Para serviços de IA, o cache tem um valor incomumente alto porque:

• Chamadas ao LLM são lentas (centenas de milissegundos a segundos).
• Chamadas ao LLM são cobradas por tokens — cada chamada tem um custo real.
• Muitas requisições do mundo real são semanticamente idênticas: o mesmo usuário fazendo a mesma pergunta com palavras ligeiramente diferentes, ou diferentes usuários fazendo perguntas comuns.

Um simples cache LRU (Least Recently Used) em memória lida com o caso mais comum — prompts repetidos exatos ou quase exatos.

Notas de design que vale a pena internalizar:

• Evicção LRU — quando o cache está cheio, a entrada mais antiga é evictada. Map preserva a ordem de inserção, então keys().next().value é sempre a chave mais antiga.
• TTL — uma hora é um padrão razoável para buscas de referência estáveis. Reduza para contexto conversacional que pode mudar frequentemente.
• Normalização de chave — colapsar espaços em branco extras significa que "o que é RAG?" e "o que é RAG?" compartilham a mesma entrada de cache. Adicione mais normalização (letras minúsculas, remoção de pontuação) se seus prompts são digitados pelo usuário.

O cache ajuda com requisições repetidas. Mas e em relação a um burst de requisições novas — que todas precisam de uma chamada ao vivo da API?

Sem controle de concorrência, todas essas chamadas disparam simultaneamente e a API limita suas requisições. A solução é um semáforo: um contador simples que limita quantas chamadas podem estar em voo ao mesmo tempo.

Pense em um semáforo como um restaurante com um número fixo de mesas. Novos clientes esperam na porta se todas as mesas estiverem ocupadas — eles não tentam se espremer todos de uma vez e derrubar as mesas.

O valor maxConcurrent depende do seu limite de RPM de nível e do seu tempo de resposta alvo. Um padrão conservador para um serviço de produção solo é 3–5 chamadas concorrentes. Se sua chamada média leva 2 segundos e você permite 3 concorrentes, você está limitado a aproximadamente 90 RPM — confortavelmente abaixo da maioria dos limites de nível.

Mesmo com um semáforo, você pode ocasionalmente receber um 429 — talvez seu serviço e outro app compartilhem a mesma chave de API, ou haja um burst na inicialização. A resposta correta é back-off exponencial com jitter.

• Exponencial — cada tentativa espera o dobro da anterior (1s → 2s → 4s → 8s).
• Jitter — aleatorize levemente a espera para que múltiplos chamadores paralelos não tentem novamente no exato mesmo momento (o problema do "thundering herd").

Envolva a chamada real à API dentro de withBackoff para obter comportamento automático de tentativas:

Às vezes a resposta certa é falhar rapidamente em vez de tentar novamente. Se um usuário está esperando por uma resposta interativa e a API está saturada, enfileirá-lo por 30 segundos é pior do que retornar uma mensagem amigável imediatamente.

Quando falhar rapidamente:

• O usuário está esperando de forma síncrona (chat, sugestão em tempo real, feedback de envio de formulário).
• O prazo da requisição já passou.
• Você esgotou o número máximo de tentativas.

Quando enfileirar e esperar:

• A requisição é em background ou assíncrona (digest agendado, handler de webhook, job em lote).
• O usuário optou por um fluxo de "notifique-me quando estiver pronto".
• A tarefa é idempotente — pode ser executada com segurança alguns minutos depois com o mesmo resultado.

Fluxo da Requisição: Todas as Três Camadas Juntas

Aqui está como cache, semáforo e back-off se encaixam em uma rota de API de produção:

flowchart TD
    A[Incoming Request] --> B{Cache hit?}
    B -- Yes --> C[Return cached response]
    B -- No --> D{Semaphore slot open?}
    D -- No --> E[Wait in queue]
    E --> F[Slot acquired]
    D -- Yes --> F
    F --> G[Call Claude API]
    G -- Success --> H[Store in cache]
    H --> I[Return response]
    G -- 429 --> J{Retries left?}
    J -- Yes --> K[Exponential back-off]
    K --> G
    J -- No --> L[Return fallback or error]

Resumo: Três Alavancas, Um Serviço

Escalar um serviço de IA solo não é sobre adicionar hardware. É sobre respeitar as restrições da API externa da qual você depende:

• Cache primeiro. Se a resposta já existe na memória, retorne-a — sem chamada à API necessária.
• Fila segundo. Um semáforo com um valor pequeno de maxConcurrent previne que tráfego em burst dispare muitas chamadas paralelas.
• Back-off graciosamente. Quando um 429 chegar, back-off exponencial com jitter dá à API tempo para se recuperar antes de você tentar novamente.
• Falhe rapidamente quando apropriado. Para fluxos interativos, um erro amigável retornado imediatamente é melhor do que 30 segundos de espera em fila.

Esses padrões não custam nada para implementar e muitas vezes são a diferença entre um serviço estável e um que fica inesperadamente indisponível em uma noite movimentada.