Forem: Vinicios "ViniDev" Coelho

Você sabe de fato como SSR funciona — e o que ele resolve?

Vinicios "ViniDev" Coelho — Tue, 27 Jan 2026 11:35:43 +0000

Server Side Rendering virou quase um “default” em muitas discussões sobre frontend moderno. Em algum momento, todo projeto grande passa pela mesma frase:

“A gente precisa de SSR por causa de SEO e performance.”

O problema é que, na prática, essa decisão costuma ser tomada sem que todos entendam o que realmente muda quando você adota SSR — e, principalmente, o que você passa a pagar por isso, em complexidade, custo e manutenção.

Este artigo não é uma defesa do SSR, nem um ataque. A proposta aqui é mais simples e mais difícil ao mesmo tempo: entender SSR como decisão arquitetural, não como feature de framework.

O que realmente acontece quando você usa SSR

Antes de falar de vantagens ou desvantagens, precisamos alinhar uma coisa importante:

SSR não elimina JavaScript, não elimina o browser e não elimina o client-side rendering. Ele apenas muda quando a renderização acontece.

Client Side Rendering (CSR), na prática

Em um SPA clássico:

O navegador solicita a página
Recebe um HTML mínimo (basicamente uma <div id="root">)
Baixa o bundle JavaScript
Executa o código
Faz chamadas de API
Renderiza a UI

Do ponto de vista do usuário (e do bot), o conteúdo não existe até o JavaScript rodar.

Esse modelo é simples, escalável e barato de servir, mas cria dois problemas bem conhecidos:

Conteúdo não aparece imediatamente
Bots e crawlers têm dificuldade para indexar corretamente

Server Side Rendering (SSR), sem abstrações

Quando você usa SSR, o fluxo muda:

O navegador faz a requisição
O servidor:
- executa o código do frontend
- resolve dependências
- busca dados
- monta o HTML final
Envia HTML já renderizado
O navegador exibe o conteúdo imediatamente
O JavaScript é carregado e ocorre a hydration

O ponto crítico aqui é este:

o servidor agora executa código que antes só rodava no browser.

Isso muda completamente o perfil do sistema.

O que o SSR resolve de verdade (em cenários reais)

Vamos falar apenas do que SSR de fato resolve, sem promessas exageradas.

SEO: o problema real, não o genérico

SSR resolve SEO quando o problema é a ausência de HTML indexável.

Isso acontece em cenários muito específicos, como:

Blogs e portais de conteúdo
Marketplaces
Landing pages de tráfego pago
Páginas públicas de produto ou serviço

Nesses casos, bots de busca:

Recebem HTML completo
Leem conteúdo sem executar JS
Conseguem indexar corretamente títulos, descrições e headings

Isso não é teoria. O próprio Google documenta que, embora consiga executar JavaScript, o processamento é atrasado e menos confiável, especialmente para SPAs complexas.

SSR não melhora SEO porque “é melhor”,

melhora porque remove a dependência de execução de JavaScript para indexação.

Performance percebida (e por que isso importa mais que benchmarks)

Um erro comum em discussões sobre SSR é focar apenas em métricas técnicas isoladas.

Na prática, o que SSR melhora é:

First Contentful Paint (FCP)
Largest Contentful Paint (LCP)

Ou seja: o momento em que o usuário vê algo útil na tela.

Em projetos reais isso aparece assim:

O cliente diz que “o site parece lento”
Mesmo quando o tempo total de carregamento não é alto
Porque a tela fica vazia por muito tempo

SSR antecipa o HTML e melhora a percepção.

Isso é especialmente relevante em:

Conexões móveis
Dispositivos mais fracos
Países com infraestrutura de rede instável

Mas é importante deixar claro:

SSR não elimina o custo de hidratação, nem reduz automaticamente o tempo total de execução do JavaScript.

Previews sociais e metadados dinâmicos

Outro problema extremamente comum em SPAs:

Preview errado no WhatsApp
LinkedIn puxando título genérico
Facebook sem imagem

Isso acontece porque crawlers de redes sociais não executam JavaScript.

SSR resolve esse problema de forma direta:

OG tags vêm prontas
Metadados corretos por rota
Preview consistente

Esse é um ganho real, simples e mensurável.

Onde o SSR começa a cobrar a conta

Até aqui, o SSR parece ótimo.

O problema é que ele muda a natureza do sistema — e isso tem consequências.

Custo de infraestrutura (o impacto invisível)

Antes do SSR:

HTML estático
CDN agressivo
Escala quase infinita a baixo custo

Depois do SSR:

Cada request executa código
Node (ou runtime equivalente) precisa estar sempre disponível
Escalar custa dinheiro

Em ambientes de alto tráfego, isso se traduz em:

Mais instâncias
Mais memória
Mais cold starts (em ambientes serverless)

SSR não é “mais rápido” por definição.

Ele é mais caro de servir.

Cache deixa de ser trivial

Cache em SSR raramente é simples.

Em projetos reais, páginas dependem de:

Usuário autenticado
Localização
Feature flags
A/B tests
Permissões

Cache por URL deixa de funcionar.

Cache por usuário explode a cardinalidade.

O resultado costuma ser:

Cache inconsistente
Bugs difíceis de reproduzir
Comportamentos diferentes entre usuários

Ambientes diferentes, bugs diferentes

Quando você executa frontend no servidor, surgem problemas clássicos:

window não existe
document não existe
localStorage não existe
APIs do browser simplesmente não estão lá

Isso gera:

Condicionais espalhadas pelo código
Lógicas duplicadas
Bugs que só aparecem em produção

Debug de SSR é, por natureza, mais complexo.

Hydration mismatch: o problema silencioso

Um dos problemas mais traiçoeiros do SSR.

Se o HTML gerado no servidor não for exatamente igual ao que o client espera:

Warnings aparecem
Componentes quebram
Estado fica inconsistente

Isso costuma acontecer por:

Datas e timezones
Valores aleatórios
Dependência de ambiente
Dados que mudam entre server e client

É um tipo de bug que não aparece em ambientes simples, mas surge com força em aplicações reais.

SSR não é tudo ou nada: maturidade arquitetural

Um erro comum em times experientes — e não apenas iniciantes — é tratar SSR como uma decisão binária:

ou a aplicação é SSR, ou não é.

Na prática, os sistemas mais bem-sucedidos usam SSR de forma seletiva.

SSR por tipo de página, não por projeto

Em cenários reais de mercado, o padrão mais comum é:

SSR
- Home pública
- Landing pages
- Páginas de produto
- Conteúdo indexável
CSR
- Dashboards
- Áreas autenticadas
- Fluxos internos
- Telas altamente interativas

Isso não é acaso.

São páginas com objetivos diferentes, usuários diferentes e restrições diferentes.

Static Generation, revalidação e estratégias híbridas

Grande parte dos problemas atribuídos ao “CSR puro” na verdade são resolvidos com geração estática bem feita, não necessariamente com SSR por request.

Na prática, muitos projetos poderiam:

Gerar HTML no build
Revalidar sob demanda
Atualizar conteúdo periodicamente

Isso reduz drasticamente:

Custo de infraestrutura
Complexidade de cache
Superfície de bugs

SSR por request deve ser reservado para quando:

O conteúdo realmente depende do request
O dado não pode ser pré-gerado
O ganho justifica o custo

Como decidir se SSR faz sentido no seu projeto

Antes de escolher SSR, perguntas como estas precisam ser respondidas com clareza:

Essa página precisa ser indexada por buscadores?
O conteúdo muda a cada request ou poderia ser gerado antes?
O ganho de FCP/LCP justifica o custo de execução no servidor?
O time está preparado para lidar com cache complexo?
O orçamento de infraestrutura comporta SSR em escala?
Esse código realmente precisa rodar no servidor?

Se a maioria dessas respostas for “não”, SSR provavelmente está sendo usado como solução genérica para um problema específico.

SSR como decisão de engenharia, não como tendência

SSR não é um avanço natural sobre CSR.

Ele é uma troca consciente.

Você troca:

Simplicidade → por controle
Custo baixo → por performance percebida
Arquitetura simples → por flexibilidade

Em times maduros, SSR não é adotado porque “o framework recomenda”, mas porque:

Existe um problema claro
O custo é conhecido
O time sabe o que está comprando

Conclusão

Entender SSR não é saber configurá-lo em um framework moderno.

É entender quando ele resolve um problema real — e quando apenas adiciona complexidade.

Os melhores sistemas não são aqueles que usam SSR em tudo, mas aqueles que:

Sabem onde usar
Sabem onde evitar
Sabem justificar a escolha

SSR não é uma melhoria automática.

É uma decisão arquitetural que cobra juros.

Referências e leituras recomendadas

Google Search Central — JavaScript SEO Basics
W3C — Rendering on the Web
Martin Fowler — Patterns of Enterprise Application Architecture
Vercel — Rendering Patterns
Web.dev — Rendering on the Web
Addy Osmani — The Cost of JavaScript

Concorrência, paralelismo e IA em produção: como reduzir a latência de endpoints de 40s para 8s

Vinicios "ViniDev" Coelho — Wed, 03 Dec 2025 23:05:33 +0000

TL;DR: Se você está integrando IA (LLMs, etc.) no backend e fazendo várias chamadas externas de forma sequencial, está jogando tempo fora. Ao aplicar noções básicas de concorrência e paralelismo (Promise.all, limitação de concorrência, separação entre ingestão externa e leitura paginada), é perfeitamente plausível reduzir um endpoint de ~40s para ~8s sem trocar de stack — só usando fundamentos de computação.

Concorrência, paralelismo e IA em produção: como reduzir a latência de endpoints de 40s para 8s

Nos últimos anos, ficou relativamente fácil “plugar” IA generativa em qualquer backend: basta chamar uma API, mandar o texto e receber a resposta. O problema é que, em produção, esse “basta chamar” rapidamente vira 40 segundos de espera num endpoint que deveria responder em poucos segundos.

O que separa um endpoint lento e frágil de um endpoint robusto e rápido, especialmente quando envolve IA externa, não é “misticismo de prompt engineering”. É fundamento de computação: processos, threads, concorrência, paralelismo, latência e throughput — conceitos que aparecem em livros clássicos de Sistemas Operacionais e Programação Concorrente, como Tanenbaum, Herlihy & Shavit, Goetz, Herb Sutter, etc.

Este artigo cria um cenário hipotético (não ligado a nenhum domínio específico) para mostrar, passo a passo, como aplicar esses conceitos em um backend Node.js/TypeScript que:

faz múltiplas chamadas a APIs externas de IA;
consulta serviços legados internos;
e reduz a latência de um endpoint de ~40s para ~8s, sem mudar de linguagem, apenas usando melhor concorrência, paralelismo e arquitetura.

A ideia é que você consiga reaproveitar os princípios em qualquer projeto com IA.

1. Cenário hipotético: agregador de relatórios inteligentes

Imagine um SaaS chamado ReportX.

Um cliente chama o endpoint:

GET /api/v1/reports/user/:userId?limit=5&page=1

Esse endpoint precisa:

Buscar os últimos N registros de atividade do usuário em sistemas internos (banco próprio, serviço legado, etc.).
Para cada registro, chamar uma API de IA externa (LLM) para gerar um resumo inteligente.
Agregar tudo num JSON de resposta paginado.

Versão ingênua:

buscar registros internos de forma sequencial;
para cada registro, chamar a IA sequencialmente;
só então responder.

Se cada chamada de IA leva ~2s, e você faz 5–10 chamadas em sequência, qualquer coisa que envolva IO adicional (DB, HTTP interno, etc.) empurra o tempo total facilmente para 30–40s.

Nosso objetivo: manter a mesma lógica de negócio, mas reduzir drasticamente a latência usando:

concorrência controlada (várias chamadas IO em paralelo);
paralelismo real quando necessário (trabalho CPU-bound, se houver);
e algumas estratégias arquiteturais simples.

2. Concorrência vs paralelismo (e por que isso importa para IA)

Uma forma clássica de separar os conceitos:

Concorrência: lidar com muitas coisas acontecendo ao mesmo tempo (estrutura e coordenação de tarefas).
Paralelismo: executar várias coisas literalmente em paralelo (ao mesmo tempo em múltiplos núcleos).

Em aplicações web típicas:

chamadas de banco, HTTP, IA externa → são tarefas I/O-bound ⇒ se beneficiam de concorrência (não bloquear enquanto esperam resposta);
operações intensivas de CPU (compressão, criptografia, parsing pesado, análise de grandes estruturas) → são CPU-bound ⇒ podem se beneficiar de paralelismo (worker threads, outros processos).

Herb Sutter cunhou o famoso “The free lunch is over” para explicar que simplesmente esperar por CPUs mais rápidas já não resolve; aproveitamento de múltiplos núcleos e modelos de concorrência tornam-se obrigatórios.

Em um endpoint que fala com IA:

o gargalo principal costuma ser IO externo (latência de rede até o provedor de IA);
portanto, concorrência bem usada (várias chamadas em paralelo, com limites) quase sempre gera ganhos gigantes de performance.

3. Versão ingênua: loop sequencial com IA externa

Comecemos com uma implementação simplificada (em TypeScript/Node) do endpoint do ReportX:

// services/aiClient.ts
export async function summarizeWithAI(text: string): Promise<string> {
  // Chamada genérica a um provedor de IA (LLM)
  const response = await fetch("https://api.ia-externa.com/v1/summarize", {
    method: "POST",
    headers: {
      "Authorization": `Bearer ${process.env.IA_API_KEY}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({
      model: "awesome-llm",
      text,
      max_tokens: 200,
    }),
  });

  if (!response.ok) {
    throw new Error(`IA API error: ${response.status}`);
  }

  const data = await response.json();
  return data.summary;
}

// services/activityService.ts
export async function findUserActivities(userId: string, limit: number, page: number) {
  const offset = (page - 1) * limit;
  // Imagine um SELECT simples no banco interno
  const rows = await db("activities")
    .where({ user_id: userId })
    .orderBy("created_at", "desc")
    .limit(limit)
    .offset(offset);

  const [{ count }] = await db("activities")
    .where({ user_id: userId })
    .count("* as count");

  return { rows, total: Number(count) };
}

E o endpoint (versão “ruim”):

// controllers/reportController.ts
import { summarizeWithAI } from "../services/aiClient";
import { findUserActivities } from "../services/activityService";

export async function getUserReportsHandler(req, reply) {
  const userId = req.params.userId;
  const page = Number(req.query.page ?? 1);
  const limit = Number(req.query.limit ?? 5);

  const { rows, total } = await findUserActivities(userId, limit, page);

  const reports = [];
  for (const activity of rows) {
    const summary = await summarizeWithAI(activity.raw_text); // <-- SEQUENCIAL
    reports.push({
      activityId: activity.id,
      createdAt: activity.created_at,
      summary,
    });
  }

  return reply.send({
    reports,
    total,
    totalPages: Math.ceil(total / limit),
  });
}

Se:

findUserActivities demora ~200–400ms;
cada summarizeWithAI leva ~2s;
e você traz 5 atividades por página…

Você tem: ~2s × 5 + overhead ≈ 10–12s.

Se subir para 10 atividades, facilmente chega perto de 20–25s. Com mais chamadas internas, outra API, ou IA mais lenta, esse “budget” de tempo explode.

4. Primeiro passo: concorrer chamadas de IA com Promise.all

A primeira melhoria óbvia é fazer as chamadas de IA em paralelo:

// controllers/reportController.ts
export async function getUserReportsHandler(req, reply) {
  const userId = req.params.userId;
  const page = Number(req.query.page ?? 1);
  const limit = Number(req.query.limit ?? 5);

  const { rows, total } = await findUserActivities(userId, limit, page);

  // Dispara todas as chamadas ao mesmo tempo
  const summaries = await Promise.all(
    rows.map((activity) => summarizeWithAI(activity.raw_text))
  );

  const reports = rows.map((activity, idx) => ({
    activityId: activity.id,
    createdAt: activity.created_at,
    summary: summaries[idx],
  }));

  return reply.send({
    reports,
    total,
    totalPages: Math.ceil(total / limit),
  });
}

Se cada chamada de IA ainda leva ~2s, mas você faz 5 em paralelo, o tempo total passa a ser ~2–3s para todas (mais o tempo de DB). Em projetos reais, é comum ver endpoints caindo de ~40s para ~8s apenas com esse tipo de abordagem — desde que a API externa tolere essa concorrência e seu backend esteja configurado para isso.

Mas não é só sair aumentando concorrência.

5. Controlando a concorrência: limitar “fan-out” para não derrubar nada

Se você simplesmente fizer Promise.all em 50 itens, pode:

estourar limite de conexões HTTP;
violar rate limits da API de IA;
ou saturar algum recurso interno.

Por isso, um padrão muito útil é um “limiter” de concorrência: em vez de disparar todas as promessas de uma vez, você impõe um máximo de tarefas rodando simultaneamente.

Um exemplo simples de “pool” genérico:

// utils/runWithConcurrency.ts
export async function runWithConcurrency<T>(
  items: T[],
  concurrency: number,
  worker: (item: T) => Promise<void>
): Promise<void> {
  const queue = [...items];
  const workers: Promise<void>[] = [];

  async function runWorker() {
    while (queue.length > 0) {
      const item = queue.shift();
      if (!item) return;
      await worker(item);
    }
  }

  const workerCount = Math.min(concurrency, items.length);
  for (let i = 0; i < workerCount; i++) {
    workers.push(runWorker());
  }

  await Promise.all(workers);
}

Aplicando no endpoint:

import { runWithConcurrency } from "../utils/runWithConcurrency";

export async function getUserReportsHandler(req, reply) {
  const userId = req.params.userId;
  const page = Number(req.query.page ?? 1);
  const limit = Number(req.query.limit ?? 5);
  const concurrency = 3; // por exemplo

  const { rows, total } = await findUserActivities(userId, limit, page);

  const reports: any[] = [];

  await runWithConcurrency(rows, concurrency, async (activity) => {
    const summary = await summarizeWithAI(activity.raw_text);
    reports.push({
      activityId: activity.id,
      createdAt: activity.created_at,
      summary,
    });
  });

  // Se a ordenação for importante, você pode ordenar depois por createdAt ou id
  reports.sort((a, b) => (a.createdAt > b.createdAt ? -1 : 1));

  return reply.send({
    reports,
    total,
    totalPages: Math.ceil(total / limit),
  });
}

Agora você:

ganha concorrência (várias chamadas acontecendo ao mesmo tempo);
mas mantém controle (no máximo concurrency chamadas de IA em paralelo).

Esse é o padrão que, na prática, costuma trazer ganhos do tipo “40 segundos → ~8 segundos” de forma relativamente simples.

6. Separando ingestão externa de leitura paginada

Outro ponto que ajuda muito (e que quase sempre aparece em sistemas com IA + integrações externas):

Ingestão/sincronização de dados externos,
Consulta/leitura desses dados via endpoints com paginação.

Em vez de chamar o sistema externo toda vez que você muda de página, é mais saudável:

Ter um serviço de importação que:

acessa o sistema externo,
normaliza e salva no seu banco,
aplica concorrência e paralelismo onde fizer sentido,
garante idempotência (reprocessar o mesmo input deixa o sistema no mesmo estado, por exemplo, sem duplicar dados).

Ter um endpoint paginado “limpo”, que:

só lê do seu banco local,
ordena e pagina normalmente,
não fala mais com o sistema externo.

Essa separação reduz a latência percebida pelo usuário e facilita muito o raciocínio sobre performance e cache.

Em código, ficaria algo como:

// services/externalIngestService.ts
export class ExternalIngestService {
  constructor(private readonly externalApiClient: ExternalApiClient) {}

  public async syncUserData(userId: string): Promise<void> {
    const batch = await this.externalApiClient.fetchFullHistory({ userId });

    // Concorrência controlada para normalizar e salvar:
    await runWithConcurrency(batch.items, 5, async (externalItem) => {
      const fingerprint = this.computeFingerprint(userId, externalItem);
      const alreadyExists = await this.existsByFingerprint(fingerprint);
      if (alreadyExists) return;

      const normalized = this.normalizeExternalItem(externalItem);
      await this.saveNormalized(userId, fingerprint, normalized);
    });
  }

  // ... computeFingerprint, existsByFingerprint, normalizeExternalItem, saveNormalized
}

E o endpoint paginado:

// controllers/reportController.ts
export async function getUserReportsHandler(req, reply) {
  const userId = req.params.userId;
  const page = Number(req.query.page ?? 1);
  const limit = Number(req.query.limit ?? 5);

  // 1) Tenta sincronizar com o sistema externo (mas não falha o endpoint se der erro)
  try {
    await externalIngestService.syncUserData(userId);
  } catch (err) {
    req.log.error({ err, userId }, "External sync failed");
  }

  // 2) Lê somente do seu banco (já sincronizado)
  const { rows, total } = await reportsRepository.findByUserPaginated(userId, page, limit);

  return reply.send({
    reports: rows,
    total,
    totalPages: Math.ceil(total / limit),
  });
}

O ganho aqui não é só de latência, mas de arquitetura:

você consegue melhorar paralelismo/concorrência na ingestão sem tocar nos endpoints de leitura;
pode mover a ingestão para jobs assíncronos, filas, cron, etc.;
e o endpoint em si fica muito mais previsível.

7. Onde entra paralelismo “de verdade”?

Até agora, tudo era concorrência I/O-bound em um processo único (Node usando event loop e non-blocking IO).

Mas em cenários de IA você pode ter situações CPU-bound:

pós-processamento pesado de respostas (análises estatísticas, embeddings locais, etc.);
parsing de arquivos grandes;
compressão, criptografia, etc.

Nesses casos, colocar tudo em Promise.all não ajuda, porque o gargalo é CPU. A solução é usar paralelismo real:

Worker Threads em Node;
múltiplos processos (cluster, containers);
ou até serviços separados.

A literatura de programação concorrente fala bastante sobre estruturas de dados lock-free, algoritmos para multiprocessadores e modelos de memória, especialmente em livros como The Art of Multiprocessor Programming (Herlihy & Shavit) e Java Concurrency in Practice (Goetz et al.).

Mesmo que você esteja em Node, entender esses conceitos ajuda a decidir quando vale a pena paralelizar CPU e quando só precisa de concorrência I/O.

8. Medindo: mais importante do que “achar” que ficou rápido

Antes e depois de qualquer refatoração de concorrência/paralelismo, meça:

latência média e p95/p99 do endpoint (por página, por tipo de usuário, etc.);

distribuição de tempo de:

consulta ao banco;
chamadas de IA;
outros serviços externos.

Ferramentas simples que já ajudam muito:

logs com startTime/endTime por etapa;
métricas em Prometheus / Grafana;
tracing distribuído (OpenTelemetry) quando seu sistema começa a crescer.

Só com métricas você consegue dizer:

“estava ~40 segundos em média, agora está ~8 segundos no p95 para páginas de 5 itens”.

Sem isso, é fácil cair em autoengano: paralelizar um trecho que não era gargalo ou, pior, aumentar a concorrência de forma que piore tudo (mais context switching, mais carga em APIs externas, mais erros intermitentes).

9. Checklist prático para endpoints com IA

Se você está construindo ou refatorando um endpoint que chama IA externa, aqui vai um checklist resumido:

Identifique o tipo de carga

A lógica é majoritariamente I/O-bound (HTTP, DB, IA)?

→ foque em concorrência (Promises, pools, limiters).
Possui trechos CPU-bound?

→ considere worker threads ou processos separados.

Evite loops sequenciais com IO lento

Troque loops for com await sequencial por Promise.all ou por um pool de concorrência.

Limite a concorrência

Use um parâmetro de concurrency configurável (por ambiente).
Respeite rate limits e capacidades do provedor de IA.

Separe ingestão externa de leitura

Tenha serviços de ingestão/sync que materializam dados no seu banco.
Deixe os endpoints de leitura o mais “puros” possível, apenas paginando e ordenando.

Use idempotência ao integrar sistemas externos

Idempotência aqui = chamar a mesma operação com o mesmo input N vezes e o sistema permanecer no mesmo estado depois da primeira execução.
Crie uma forma de fingerprint (hash) dos dados externos por entidade/usuário.
Antes de inserir, verifique se aquele fingerprint já existe.
- Assim, reprocessar o mesmo lote de dados não altera mais nada (efeito prático: você evita duplicidade de registros).

Meça sempre

Logue tempos por etapa e por página.
Monitore p95/p99, não só a média.

Estude fundamentos

Conceitos de processos, threads, sincronização, deadlocks, starvation (livros de SO).
Estruturas de dados e algoritmos concorrentes (Herlihy & Shavit).
Impacto da “revolução da concorrência” no software moderno (Herb Sutter).

10. Conclusão

A onda atual de IA deixou muita gente com a impressão de que o grande diferencial está apenas em “saber falar com modelos”. Na prática, quando você vai para produção, os velhos fundamentos de computação voltam com força total:

entender o modelo de concorrência da linguagem/plataforma (Node, JVM, etc.);
saber a diferença entre tarefas I/O-bound e CPU-bound;
estruturar pipelines com fan-out/fan-in, limites de concorrência, ingestão assíncrona e leitura paginada.

No nosso cenário hipotético, sair de um loop sequencial para um desenho concorrente e bem limitado reduziu latência na casa de 40s para ≈8s — sem trocar de stack, sem usar mágica, apenas aplicando princípios de Sistemas Operacionais e Programação Concorrente que já existem há décadas.

IA muda o que você pode fazer com os dados.

Concorrência, paralelismo e arquitetura ainda determinam se isso vai rodar bem em produção.

Referências recomendadas

Andrew S. Tanenbaum, Herbert Bos. Modern Operating Systems. 4ª ed.
Maurice Herlihy, Nir Shavit. The Art of Multiprocessor Programming.
Brian Goetz et al. Java Concurrency in Practice.
Herb Sutter. “The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software”. Dr. Dobb’s Journal, 2005.
Martin Kleppmann. Designing Data-Intensive Applications (capítulos sobre sistemas distribuídos, concorrência e tolerância a falhas).

Como teoria da computação escalou uma aplicação com uma infra custo beneficio.

Vinicios "ViniDev" Coelho — Wed, 26 Feb 2025 12:57:05 +0000

Introdução

Quando entrei neste projeto, o maior desafio era a alcançar um determinado nivel de escalabilidade para nos prepararmos para uma Proof of Concept que seriamos submetidos. A aplicação, construída em Ruby on Rails, processava consultas médicas transcrevendo-as em anamneses estruturadas via OpenAI. No entanto, ao rodarmos um teste de carga, percebemos que o sistema não aguentava mais de 20k requisições simultâneas.

Diante disso, precisei entender os gargalos e otimizar ao máximo a aplicação para fazer um uso mais eficiente de nossa infraestutura custo benefício, rodando Sidekiq, Puma e Redis.

Este artigo detalha como aumentamos a capacidade para suportar 500k requisições simultâneas, aproveitando 100% dos recursos disponíveis, sem precisar de usar de recursos para melhorar a infraestrutura.

O Diagnóstico: Identificando os Gargalos

Bom, antes de mais nada, pra quem ja vivenciou a experiencia de passar por uma POC sendo um desenvolvedor, sabe do que estou falando. É uma montanha russa! A todo momento alterações e novas features são solicitadas, mas nessa em específico, tínhamos uma grande barreira, a famigerada Escalabilidade.

Como ja foi citado, nossa aplicação que até o momento era apenas um MVP, estava enfrentando grandes problemas quanto a esse quesito, e seriamos massivamentes testados especificamente nesse nele, foi ai que por em prática conceitos básicos de Sistemas Operacionais fizeram com que nossa aplicação alcancasse 500k de requisições sem gargalar nossa infraestrutura.

Para entender os problemas da aplicação, criamos um teste de carga usando Locust, simulando o fluxo real do usuário no sistema. Nosso objetivo era medir a resistência da aplicação sob um grande volume de requisições simultâneas.

Pra quem ainda não conhece o Locust para testes de sobrecarga, vale conferir! É extremamente friendly e a curva de aprendizado para utilização é realmente muito rapida!

Segue link: https://locust.io/

Resultados do teste com Locust:

Inicialmente, com um número moderado de requisições, o sistema respondia bem.
À medida que a carga aumentava, os tempos de resposta começaram a crescer exponencialmente.
Ao atingir 20k requisições simultâneas, o servidor não conseguia mais lidar com a demanda, resultando em timeouts, erros de conexão resetada e, por fim, uma falha completa da aplicação.
A imagem anexada ilustra bem os principais erros encontrados durante o teste, como timeouts, erros de conexão fechada remotamente e falhas SSL, indicando que a aplicação não estava conseguindo manter conexões abertas ou responder dentro do tempo esperado.
O efeito cascata desses problemas gerava uma sobrecarga ainda maior no sistema, tornando a aplicação completamente indisponível.
Esse diagnóstico confirmou que nossa arquitetura não estava preparada para lidar com um volume massivo de acessos simultâneos, exigindo ajustes para melhorar o gerenciamento de conexões, fila de processamento e paralelismo.

Foi aí que entender um conceito básico de S.O salvou nossas vidas

Diante do cenário caótico que enfrentávamos, percebemos que a solução não estava apenas em otimizar código ou adicionar mais servidores indiscriminadamente. Precisávamos repensar como nossa aplicação lidava com múltiplas requisições simultâneas. Foi aí que os conceitos de concorrência, paralelismo, processos e threads se tornaram nossas armas principais para escalar sem comprometer a infraestrutura.

Concorrência: O Jogo de Equilibrar as Execuções

A concorrência é um dos conceitos fundamentais de Sistemas Operacionais. Ela permite que diferentes partes de um programa compartilhem recursos e se revezem na execução, gerenciando a carga de maneira mais eficiente.

Para ilustrar, imagine que você está em um restaurante pequeno e há um único garçom anotando pedidos, levando pratos e cobrando os clientes. O garçom não consegue fazer todas as tarefas ao mesmo tempo, então ele precisa se organizar:

Ele anota um pedido e pausa essa tarefa para levar um prato pronto até a mesa.
Depois de entregar o prato, ele volta para continuar anotando o pedido de outro cliente.

Isso é concorrência – as tarefas não acontecem simultaneamente, mas sim de forma intercalada, aproveitando os momentos em que o garçom pode realizar uma nova ação sem ficar parado esperando outra tarefa terminar.

Agora, imagine que o garçom começa a ficar sobrecarregado porque precisa lidar com muitos pedidos ao mesmo tempo. O que acontece?

O atendimento começa a ficar lento.
Os pedidos começam a acumular na cozinha.
Alguns clientes vão embora sem serem atendidos (timeouts na API ).

E foi exatamente isso que aconteceu com a nossa aplicação. Nossa API estava lidando com as requisições de forma sequencial, sem tirar proveito da concorrência real. O resultado? Um efeito cascata de travamentos e falhas de conexão.

Concorrência vs. Paralelismo: O Ponto de Virada

Agora, vamos imaginar que o restaurante cresce e decide contratar mais garçons.

Se os garçons continuarem compartilhando a mesma bandeja para levar pratos, eles ainda precisarão esperar uns pelos outros. Isso ainda é concorrência.
Mas se cada garçom tiver sua própria bandeja e puder atender clientes simultaneamente, agora estamos falando de paralelismo real!

Na nossa aplicação, o grande erro era tratar processos bloqueantes como concorrentes, quando, na verdade, eles poderiam ser paralelos.

O que isso significa na prática?

Algumas tarefas estavam competindo pelo mesmo recurso, quando poderiam ser distribuídas de forma independente.
Nossa API estava funcionando como um único garçom, lidando com várias requisições de maneira intercalada, mas sem processá-las ao mesmo tempo.

A solução? Transformar processos concorrentes em paralelos, eliminando bloqueios desnecessários!

Processos e Threads: Quem Faz o Trabalho?

Agora que entendemos que precisávamos de concorrência, como implementá-la na prática? Para isso, precisamos entender dois conceitos-chave: processos e threads.

O que são processos?

Um processo é uma instância independente de um programa em execução. Ele tem seu próprio espaço de memória e recursos exclusivos. No contexto de um servidor web, cada processo pode lidar com uma ou mais requisições, mas como cada processo consome uma quantidade significativa de memória, escalá-los diretamente pode ser caro e ineficiente.

O que são threads?

As threads são unidades menores de execução dentro de um processo. Diferente dos processos, threads compartilham o mesmo espaço de memória, tornando sua criação e gerenciamento mais leve. Isso permite que uma aplicação possa lidar com múltiplas tarefas ao mesmo tempo sem precisar iniciar novos processos do zero.

Podemos pensar nos processos como cozinhas separadas em um restaurante e nas threads como os chefs dentro de cada cozinha. Se cada cozinha trabalha de forma isolada, a comunicação pode ser lenta. Mas se dentro de cada cozinha há vários chefs compartilhando ingredientes e espaço, os pedidos são preparados de forma mais eficiente.

Ajustando a Concorrrência com Base na Quantidade de Núcleos do Servidor

Para garantir que o sistema aproveitasse 100% da capacidade disponível sem sobrecarregar os recursos, utilizamos um cálculo baseado na quantidade de núcleos da CPU.

Cada núcleo pode processar um número limitado de tarefas simultaneamente. Para definir quantos processos e threads usar, utilizamos a seguinte fórmula padrão:

Fórmula para Processos e Threads:
Número de processos = Número de núcleos físicos Número de threads por processo = 2 a 4 threads por núcleo

Isso significa que, se o servidor possui 8 núcleos físicos, podemos configurar:

8 processos Puma (1 por núcleo)
Entre 16 e 32 threads no total (2 a 4 por núcleo)

Por que esse cálculo funciona?

Se usarmos menos processos do que núcleos, não aproveitamos toda a CPU.
Se usarmos muito mais threads do que o recomendado, corremos o risco de aumentar a latência e criar contenção de recursos.

Como configurar isso no Puma?

No arquivo config/puma.rb, podemos definir a configuração dinamicamente:

workers ENV.fetch("WEB_CONCURRENCY") { 8 } # Número de processos baseado nos núcleos threads_count = ENV.fetch("RAILS_MAX_THREADS") { 16 } # Threads por processo threads threads_count, threads_count preload_app!

Ponto importante!

Teste diferentes configurações para encontrar o ponto ideal, pois a performance pode variar dependendo da carga de trabalho e do banco de dados.
Utilize ferramentas como htop ou top no Linux para monitorar o uso da CPU e ajustar conforme necessário.

Ajustando o NGINX para Lidar com Alto Volume de Requisições

Com o Puma e Sidekiq otimizados, ainda enfrentamos um problema: o NGINX não estava configurado para lidar com um alto número de conexões simultâneas. Como ele atua como um proxy reverso, precisávamos ajustá-lo para permitir mais conexões e evitar erros de 502 Bad Gateway e timeouts.

Principais ajustes que fizemos:

Aumentamos o limite de conexões simultâneas No arquivo /etc/nginx/nginx.conf, ajustamos os valores para permitir mais conexões concorrentes:

worker_processes auto; # Define automaticamente a quantidade de processos com base nos núcleos da CPU worker_connections 8192; # Define quantas conexões cada worker pode lidar simultaneamente multi_accept on; # Permite aceitar múltiplas conexões ao mesmo tempo
O que isso faz?

worker_processes auto → Define um número de processos igual ao número de núcleos da CPU.
worker_connections 8192 → Permite que cada processo gerencie até 8192 conexões simultâneas.
multi_accept on → Permite que o NGINX aceite várias conexões ao mesmo tempo, melhorando a latência.

Aumentamos o tempo limite das requisições
Com muitas requisições passando pelo NGINX, algumas podiam demorar mais tempo para serem processadas, especialmente as que envolviam a transcrição de consultas médicas via OpenAI. Ajustamos os timeouts para evitar encerramentos prematuros:

proxy_connect_timeout 60s; proxy_send_timeout 60s; proxy_read_timeout 60s; send_timeout 60s;

O que isso faz? Evita que conexões sejam fechadas prematuramente durante requisições mais demoradas.

Ajustamos o buffer de resposta
Como algumas respostas da API podiam ser grandes, aumentamos o buffer para evitar truncamento ou erros de payload.

proxy_buffer_size 128k; proxy_buffers 4 256k; proxy_busy_buffers_size 256k;

O que isso faz? Impede que respostas grandes sejam cortadas e melhora a eficiência da comunicação entre NGINX e Puma.

Como aplicamos isso para resolver nosso problema?

Nosso servidor original estava lidando com cada requisição de forma bloqueante, ou seja, cada requisição ocupava um recurso até ser completamente processada, sem permitir que outras requisições fossem tratadas enquanto isso. Esse comportamento causava um efeito cascata de timeouts e falhas, derrubando o sistema sob alta carga.

Para escalar corretamente e garantir 500k requisições simultâneas, aplicamos quatro estratégias principais:

Ajustamos a Concorrência com Base nos Núcleos do Servidor

Antes de qualquer mudança, entendemos que a chave para escalar nossa aplicação era aproveitar melhor os recursos do servidor, evitando desperdício de CPU e memória.

Como fizemos isso?

Calculamos o número ideal de processos e threads com base nos núcleos físicos do servidor
Definimos 1 processo Puma por núcleo e 2 a 4 threads por núcleo para garantir um melhor aproveitamento sem sobrecarregar o sistema
Monitoramos o desempenho com ferramentas como htop e top para ajustar os valores de acordo com o perfil da aplicação

Adotamos o servidor Puma com múltiplas threads

O Puma é um servidor web otimizado para concorrência baseada em threads. Diferente de servidores tradicionais que criam um novo processo para cada requisição, ele mantém um número fixo de processos e cria múltiplas threads dentro de cada um para atender às requisições simultaneamente. Isso permitiu que nossa aplicação Rails processasse muito mais requisições sem consumir memória excessivamente.

Implementamos filas de background com Sidekiq e Redis

Algumas operações, como a transcrição de consultas médicas via OpenAI, eram naturalmente demoradas e não precisavam ser processadas imediatamente na resposta da requisição. Utilizando o Sidekiq, conseguimos delegar essas tarefas para workers, que as executavam em segundo plano sem bloquear as requisições principais.

Ajustamos a concorrência da base de dados

O banco de dados também era um gargalo crítico. Otimizar conexões e garantir que as queries fossem eficientes foi essencial para evitar travamentos causados pelo excesso de conexões concorrentes.

O Resultado

Após essas mudanças, rodamos novamente os testes de carga com o Locust. O impacto foi impressionante:

Conseguimos aumentar a capacidade de 20k para 500k requisições simultâneas, aproveitando melhor a infraestrutura existente.
A latência média das requisições caiu significativamente, pois o servidor conseguia processar várias ao mesmo tempo sem sobrecarregar os recursos.
A estabilidade da aplicação foi garantida, mesmo sob cargas intensas.
Ao final, conseguimos alcançar a escalabilidade necessária sem precisar gastar com novos servidores, apenas utilizando conceitos básicos de concorrência, processos e threads a nosso favor.

E foi dessa forma que conseguimos sair de 20k de Requisiçõs a 500k+ com uma infra de custo benefício!!!

Deixo um agradecimento a toda equipe que esteve durante todo esse processo também!