Escalabilidade em Produção com Bun: Uma Abordagem de Alta Performance

1. Introdução

A ascensão do Bun foi quase um "efeito domino" no ecossistema JavaScript. Por mais que o Node.js tenha sido um titã que moldou uma década de backends modernos, ele é fruto de uma época em que "escalar significa colocar um Nginx na frente e torcer". O Bun nasce em outra era, com expectativas muito mais altas e usuários que já entenderam o custo da lentidão.

E, olha, muita gente acha que Bun “é só mais rápido”.
Mas vamos ser honestos: ninguém muda uma arquitetura inteira só por velocidade.

Você muda quando percebe que a performance abre caminhos arquiteturais diferentes.

Um exemplo simples:

No Node.js, rodar um cold start num microserviço serverless podia levar 120 a 300 ms.
No Bun, você vê coisas iniciando em 10 a 40 m2s.

Isso não é só "mais rápido".
Isso muda o que você pode construir.

---

2. Arquitetura e o Event Loop no Bun

O Bun usa JavaScriptCore, e isso importa por vários motivos. Um deles é a forma como ele lida com I/O.

Para perceber o impacto na prática, experimente isso:

Exemplo: servidor HTTP ultra básico

Node.js

import http from "http";

http.createServer((req, res) => {
  res.end("Olá mundo!");
}).listen(3000);

Bun

Bun.serve({
  port: 3000,
  fetch(req) {
    return new Response("Olá mundo!");
  }
});

Ok, visualmente parecem iguais. Mas o detalhe é o custo interno:

• No Node.js, cada requisição passa por camadas do V8, libuv e bindings nativos.
• No Bun, o servidor HTTP é nativo e direto no JavaScriptCore.

Resultado?
Um servidor simples como esse consegue lidar com 150k+ req/s em Bun e 30k–50k req/s em Node.

Exemplo real de impacto

No Node.js, para lidar com WebSockets em larga escala, você quase sempre precisa:

• Redis Pub/Sub
• process managers
• clustering
• heartbeat tuning
• sharding manual

No Bun, você muitas vezes consegue o mesmo com:

• Bun.serve
• Um servidor WebSocket direto, sem overhead

É a diferença entre construir uma ponte e apenas atravessar o rio.

---

3. Paralelismo e Clustering

Vamos falar de um erro que vejo semanalmente:

Muita gente roda o Bun em produção usando 1 processo só.

Sim, ele é rápido.
Sim, ele usa menos memória.
Mas você continua tendo vários cores disponíveis, e ignorar isso é deixar performance ociosa.

Exemplo prático usando reusePort

Um arquivo server.js:

Bun.serve({
  port: 3000,
  reusePort: true,
  fetch(req) {
    return new Response(`PID: ${process.pid}`);
  }
});

E rodando 4 processos:

bun server.js &
bun server.js &
bun server.js &
bun server.js &

Agora faça:

curl localhost:3000

Você verá:

PID: 14523
PID: 14525
PID: 14526
PID: 14528

Sem cluster do Node.
Sem PM2.
Sem balanceador interno.

Quem distribuiu as requisições?
O kernel do Linux.

Por que isso importa?

No Node.js, você escreveria:

• cluster manual
• worker management
• IPC
• scripts de respawn
• lógica de fallback

No Bun, você escreve:

reusePort: true

E segue a vida.

---

4. Balanceamento de Carga e Proxy Reverso

Esse é um ponto onde muitos devs cometem o erro clássico do “agora o Bun faz tudo, vou tirar o Nginx”.
Spoiler: não faça isso (na maioria das arquiteturas).

Exemplo prático de setup Bun + Nginx

Nginx:

server {
    listen 80;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
    }
}

Bun:

Bun.serve({
  port: 3000,
  fetch(req) {
    return new Response("OK");
  }
});

Por que manter o Nginx?

• Terminação SSL profissional
• Rate limiting real
• Cache baseado em regras
• Proteção contra ataques triviais
• Logs estruturados
• Melhor controle de headers

Cenário ilustrativo

Sem Nginx:

• 1 milhão de requisições HTTPS → seu Bun precisa descriptografar tudo.

Com Nginx:

• Nginx faz a terminação
• Bun recebe tráfego “limpo”
• A CPU agradece

---

5. Estratégias de Cache e I/O

Aqui é onde vemos o Bun realmente mudando hábitos.

⚡ Exemplo: cache na memória super simples

const cache = new Map();

Bun.serve({
  fetch() {
    if (cache.has("msg")) return new Response(cache.get("msg"));

    cache.set("msg", "valor muito rápido");
    return new Response("valor muito rápido");
  }
});

Parece trivial, mas no Bun isso roda tão rápido que, para muitos microserviços, você literalmente remove a necessidade de Redis.

Exemplo com bun:sqlite

import { Database } from "bun:sqlite";

const db = new Database("local.db");

db.run("CREATE TABLE IF NOT EXISTS logs (msg TEXT)");

db.run("INSERT INTO logs (msg) VALUES (?)", "Server iniciado");

No Node, usar SQLite em produção costuma ser quase tabu.
No Bun… é totalmente viável.

---

6. Observabilidade e Métricas

Aqui vão exemplos reais de coisas que você PRECISA monitorar.

Exemplo: medir latência das rotas

Bun.serve({
  fetch(req) {
    const start = performance.now();

    const resp = handleRequest(req);

    const dur = performance.now() - start;
    console.log("latência:", dur, "ms");

    return resp;
  }
});

Simples? Sim.
Mas essencial para descobrir o vilão invisível:

• A query lenta
• O JSON gigante
• O serviço externo que pinga às vezes
• A rota que ninguém usa mas consome CPU

Exemplo com OpenTelemetry (pseudo-config)

import { trace } from "@opentelemetry/api";

const tracer = trace.getTracer("bun-app");

Bun.serve({
  fetch(req) {
    return tracer.startActiveSpan("request", span => {
      const result = handle(req);
      span.end();
      return result;
    });
  }
});

---

7. Conclusão (com exemplo final)

Imagine uma startup usando Node.js que recebe:

• 20k req/s num burst
• cold starts lentos
• necessidade de clustering
• Redis para quase tudo
• Nginx para aliviar o HTTPS
• várias gambiarras para WebSockets

Agora imagine a mesma startup migrando para Bun:

• 150k req/s
• cold start quase instantâneo
• clustering via kernel
• cache em memória eficiente
• WebSockets nativos
• SQLite local para partes do sistema
• stack mais simples

Não é que o Bun “faz milagres”.
É que ele te dá ferramentas melhores, que simplificam decisões que antes eram difíceis, caras ou impossíveis.

E quando arquitetura fica mais simples, a escala vem como consequência natural.