DEV Community: Marcos Soares

Memory Leaks em JavaScript: Diagnóstico, Causas Reais e Correção

Marcos Soares — Fri, 11 Sep 2026 12:02:55 +0000

Um processo Node.js que reinicia sozinho a cada 40 minutos raramente está com bug de lógica. Está com vazamento de memória.

O sintoma clássico: o container roda liso por meia hora, o heap_size_used sobe em degraus, o garbage collector começa a rodar com mais frequência (major GC a cada poucos segundos em vez de a cada poucos minutos), a latência p99 dobra e o orquestrador mata o pod com OOMKilled. Reiniciar resolve. Por 40 minutos.

Este post é sobre encontrar a causa, não sobre aumentar --max-old-space-size.

Como o V8 decide o que é lixo

Existe um mito persistente de que o garbage collector do JavaScript usa contagem de referências. Não usa, e essa confusão faz gente escrever código defensivo inútil.

O V8 usa mark-and-sweep com alcançabilidade a partir de um conjunto de raízes (GC roots): o objeto global, a pilha de execução atual, closures ativas, e no browser, a árvore do DOM viva. Tudo que não é alcançável a partir dessas raízes vira lixo, independentemente de quantas referências circulares exista entre os objetos.

// Isto NÃO vaza. Ciclo é irrelevante para mark-and-sweep.
function criarCicloIsolado() {
  const pedido = { id: 1 };
  const cliente = { nome: 'Ana' };

  pedido.cliente = cliente;
  cliente.ultimoPedido = pedido; // referência circular

  return null; // ninguém mais alcança pedido nem cliente
}

criarCicloIsolado();
// Ambos são coletados no próximo major GC.

O heap do V8 é dividido em gerações. Objetos novos nascem na new space (Scavenger, coleta rápida e frequente, tipicamente 1-16 MB). Objetos que sobrevivem a duas coletas são promovidos para a old space, varrida pelo Mark-Compact, que é caro. Um vazamento é, quase sempre, objetos sendo promovidos para old space e nunca liberados de lá.

Isso importa na prática: se seu vazamento envolve objetos grandes e de vida curta, você não tem vazamento, tem pressão de alocação (aumenta o custo de GC mas o heap estabiliza). Se o heapUsed após um major GC forçado continua subindo, aí sim é vazamento.

// medir-heap.js — rode com: node --expose-gc medir-heap.js
// --expose-gc é a única forma confiável de medir heap "limpo" sem
// confundir lixo pendente com vazamento real.

function heapDepoisDoGC() {
  global.gc(); // força major GC síncrono
  const { heapUsed, external, arrayBuffers } = process.memoryUsage();
  return {
    heapMB: (heapUsed / 1024 / 1024).toFixed(2),
    externalMB: (external / 1024 / 1024).toFixed(2),
    arrayBuffersMB: (arrayBuffers / 1024 / 1024).toFixed(2),
  };
}

setInterval(() => {
  console.log(new Date().toISOString(), heapDepoisDoGC());
}, 10_000);

Se heapMB sobe monotonicamente ao longo de 20 amostras sob carga constante, você tem vazamento no heap JavaScript. Se heapMB fica estável mas o RSS do processo sobe, o vazamento está fora do heap do V8: Buffers, addons nativos, ou fragmentação do alocador.

Essa distinção entre linguagem e runtime é a mesma que aparece quando se discute o modelo de execução do JavaScript: a especificação da linguagem não diz nada sobre GC gerational nem sobre libuv. Tudo isso é V8 e Node.js.

As cinco causas que respondem por quase todo vazamento real

1. Listeners que nunca são removidos

O caso mais comum em Node.js e o mais comum em SPAs. Cada addEventListener ou .on() cria uma referência forte do emissor para o handler, e do handler para tudo que ele captura no escopo.

Este é um trecho. O tutorial completo, com todos os exemplos, os testes e as limitações, está em https://www.vivodecodigo.com.br/backend/memory-leaks-javascript-diagnostico-heap-snapshot-producao. Se você já passou por esse problema de outro jeito, conta nos comentários: a discussão aqui ajuda a melhorar o artigo.

Engenharia Backend com Node.js e TypeScript: o Guia Definitivo para 2026

Marcos Soares — Thu, 26 Mar 2026 02:56:53 +0000

Engenharia Backend com Node.js e TypeScript: O Guia Definitivo para 2026

Depois de duas décadas construindo sistemas web, posso afirmar: Node.js não é apenas hype. É a escolha que te permite dormir tranquilo sabendo que seu sistema processa milhões de requisições sem te acordar às 3h da manhã.

O ecossistema Node.js amadureceu de forma impressionante em 2026. Temos Prisma 6 revolucionando acesso a dados, TypeScript trazendo sanidade para projetos grandes, e performance que compete com linguagens "tradicionalmente mais rápidas". Mas construir um backend que funciona é fácil. Construir um que escala, é seguro e mantível... isso é engenharia de verdade.

Por Que Node.js Domina o Backend em 2026

A maioria escolhe Node.js pelos motivos errados: "é JavaScript", "é rápido para prototipar". O verdadeiro poder está na arquitetura event-driven e I/O não-bloqueante. Para aplicações modernas onde o gargalo é I/O (banco, APIs, filesystem), Node.js brilha único.

Números reais do Vivo de Código:

324 sinais de tendência processados em tempo real
866 entidades no Knowledge Graph com 54K edges
Pipeline ML com 8 modelos simultâneos
Response time médio de 89ms

O Ecossistema Amadureceu

TypeScript: Padrão da indústria. Type safety sem sacrificar flexibilidade.

Prisma: Type-safe, migrations automáticas, query optimization inteligente.

Fastify: Performance superior ao Express com melhor DX.

Node.js 22+: WebStreams nativas, melhor GC, startup 40% mais rápido.

Arquitetura Profissional: Separando Amadores de Engenheiros

Não é sobre 15 camadas de abstração. É estrutura que permite evolução, testing e debugging eficientes.

// src/core/application/use-cases/user/create-user.use-case.ts
export class CreateUserUseCase {
  constructor(
    private readonly userRepository: UserRepository,
    private readonly passwordHasher: PasswordHasher,
    private readonly eventBus: EventBus,
    private readonly logger: Logger
  ) {}

  async execute(command: CreateUserCommand): Promise<CreateUserResult> {
    this.logger.info('Creating user', { email: command.email });

    // Validação de domínio
    const existingUser = await this.userRepository.findByEmail(command.email);
    if (existingUser) {
      throw new UserAlreadyExistsError(command.email);
    }

    // Criação da entidade
    const hashedPassword = await this.passwordHasher.hash(command.password);
    const user = User.create({
      email: command.email,
      password: hashedPassword,
      name: command.name
    });

    // Persistência
    await this.userRepository.save(user);

    // Eventos de domínio
    await this.eventBus.publishAll(user.getDomainEvents());

    return CreateUserResult.success(user);
  }
}

Camadas da Arquitetura

Domain Layer: Entidades, Value Objects, Domain Services. Lógica de negócio pura.

Application Layer: Use Cases, Command/Query handlers. Orquestra operações.

Infrastructure Layer: Repositories, External APIs, Database. Detalhes técnicos.

Presentation Layer: Controllers, Middlewares, DTOs. Interface com mundo externo.

Autenticação e Autorização: Segurança Sem Paranoia

JWT continua sendo padrão, mas implementação importa. Refresh tokens obrigatórios, rotação automática, blacklist para revogação.

// src/infrastructure/auth/jwt-auth.service.ts
export class JwtAuthService implements AuthService {
  async generateTokenPair(userId: string): Promise<TokenPair> {
    const payload = { sub: userId, type: 'access' };

    const accessToken = this.jwtService.sign(payload, {
      expiresIn: '15m',
      issuer: this.config.jwt.issuer,
      audience: this.config.jwt.audience
    });

    const refreshToken = this.jwtService.sign(
      { ...payload, type: 'refresh' },
      {
        expiresIn: '7d',
        secret: this.config.jwt.refreshSecret
      }
    );

    // Armazena refresh token com TTL automático
    await this.redis.setex(
      `refresh_token:${userId}`,
      604800, // 7 dias
      refreshToken
    );

    return { accessToken, refreshToken };
  }
}

Implementação de RBAC

Role-Based Access Control com hierarquia de permissões. Middleware que verifica não apenas autenticação, mas autorização granular por recurso.

Performance e Caching: A Diferença Entre Funcionar e Escalar

Caching em múltiplas camadas: Redis para sessões, CDN para assets, query caching no Prisma, HTTP caching com ETags.

Redis Strategies:

Cache-aside para dados frequentes
Write-through para dados críticos
Pub/sub para invalidação distribuída

Database Optimization:

Connection pooling inteligente
Query optimization automática
Read replicas para consultas pesadas

Observabilidade: Enxergando o Invisível

Logs estruturados com Pino, métricas com Prometheus, tracing distribuído com OpenTelemetry. Não é sobre coletar dados, é sobre ter insights acionáveis.

Health Checks Inteligentes:

Liveness: processo está rodando?
Readiness: pode receber tráfego?
Startup: inicialização completa?

Testes: Confiança Para Deploy Sexta-feira

Pirâmide de testes equilibrada: muitos unit tests, alguns integration tests, poucos e2e tests. TDD não é religião, é ferramenta para design melhor.

Test Containers para integration tests com dependências reais. Supertest para testes de API. Jest configurado para performance máxima.

Deploy e DevOps: Da Máquina Local Para Produção

Docker multi-stage builds, Kubernetes com auto-scaling, CI/CD com zero-downtime deployments. Blue-green deployments para releases críticas.

Monitoring de Produção:

APM para performance
Error tracking para bugs
Business metrics para impacto

Leia o artigo completo com todos os exemplos de código e diagramas em https://vivodecodigo.com.br/backend/engenharia-backend-nodejs-typescript-guia-definitivo

Anatomia do Vivo de Codigo: Como Construi um Blog com Stack de Startup

Marcos Soares — Thu, 26 Mar 2026 02:48:31 +0000

Como Construí um Blog com Arquitetura de Startup Unicórnio por $0/mês

Depois de 21 anos construindo sistemas, criei um blog que publica posts sozinho usando ML, knowledge graph e pipeline automatizado. Por que alguém faria isso ao invés de usar WordPress?

Este é o decision log completo da arquitetura do Vivo de Código: Next.js 16, PostgreSQL com pgvector, 10 containers Docker na Oracle Cloud e um sistema que parece saído de uma startup de $1B rodando com custo zero.

A Arquitetura Geral

graph TB
    subgraph "Frontend (Vercel)"
        A[Next.js 16 + React 19]
        A --> D[6 Cron Jobs Proxy]
    end

    subgraph "Database (Supabase)"
        E[PostgreSQL + pgvector]
        E --> F[Embeddings 384-dim]
        E --> G[Knowledge Graph]
    end

    subgraph "VPS Oracle Cloud"
        I[10 Docker Containers]
        I --> J[ACI - FastAPI]
        I --> K[MinIO Storage]
        I --> L[12 Python Crons]
    end

    A --> E
    A --> I
    J --> E

Esta arquitetura serve 27 posts, ~2.000 palavras cada, com pipeline de ML que roda embeddings, extrai entidades e constrói grafos de conhecimento automaticamente.

Por Que Next.js 16 e Não Astro/Hugo

Alternativas consideradas:

Astro (melhor performance)
Hugo (velocidade insana)
WordPress (ecossistema gigante)

Por que Next.js venceu:

Server Components: Posso rodar ML direto no servidor. O Revenue Router do AdSense segmenta anúncios por perfil sem API calls.
ISR + On-Demand Revalidation: Pipeline publica post → webhook revalida páginas específicas. Zero rebuild manual.
Flexibilidade: Páginas estáticas (posts), dinâmicas (busca) e híbridas (comentários) na mesma stack.

Números reais:

Build: ~2min para 27 posts
FCP: ~0.8s
TTI: ~1.2s

PostgreSQL + pgvector: O Cérebro do Sistema

Por que não MongoDB/Redis/Elasticsearch:

PostgreSQL resolve tudo: dados relacionais, embeddings vetoriais, full-text search e JSON. Um banco, múltiplas funções.

-- Busca semântica com pgvector
SELECT 
  title,
  content,
  1 - (embedding <=> query_embedding) as similarity
FROM posts 
WHERE 1 - (embedding <=> query_embedding) > 0.7
ORDER BY embedding <=> query_embedding
LIMIT 10;

O pipeline de embeddings:

Post publicado → webhook dispara
Texto chunked em 512 tokens
all-MiniLM-L6-v2 gera embeddings 384-dim
pgvector indexa para busca semântica
Knowledge graph extrai entidades relacionadas

Custo: $0 (Supabase free tier: 500MB, 2 conexões simultâneas)

VPS Oracle Cloud: 10 Containers por $0

Por que Oracle Cloud e não AWS/GCP:

Oracle Always Free: 4 OCPUs ARM, 24GB RAM, 200GB storage. Para sempre. Sem cartão de crédito após trial.

Os 10 containers rodando:

# docker-compose.yml (resumido)
services:
  aci-api:
    image: vivodecodigo/aci:latest
    ports: ["8000:8000"]

  minio:
    image: minio/minio
    volumes: ["./data:/data"]

  ml-pipeline:
    image: vivodecodigo/ml-pipeline:latest
    environment:
      - SUPABASE_URL=${SUPABASE_URL}
      - HUGGINGFACE_TOKEN=${HF_TOKEN}

12 Python crons rodando:

Scraping de fontes RSS (4x/dia)
Processamento de embeddings (1x/dia)
Backup automático (1x/semana)
Health checks (1x/hora)
Analytics sync (1x/dia)

Pipeline de ML sem GPU

O desafio: Rodar modelos Transformer em CPU ARM sem explodir o orçamento.

A solução:

Sentence-transformers otimizado para CPU
Batch processing noturno
Cache agressivo de embeddings
Quantização INT8 nos modelos

Tempo de processamento:

1 post (~2000 palavras): ~45s
Batch 10 posts: ~6min
Embedding similarity search: ~50ms

Knowledge Graph Caseiro

Cada post vira um nó conectado por:

Similaridade semântica (embeddings)
Tags compartilhadas
Entidades nomeadas (spaCy)
Referências cruzadas

Resultado: sistema de recomendação que sugere posts relacionados com 78% de precisão vs 23% de tags manuais.

Monitoramento e Analytics

Stack de observabilidade:

Umami (analytics privacy-first)
Sentry (error tracking)
Uptime Robot (monitoring)
Custom dashboards (Grafana + Prometheus)

Métricas que importam:

Tempo de leitura médio: 4min 32s
Taxa de rejeição: 23%
Posts mais lidos: tutoriais práticos
Horário de pico: 14h-16h (Brasil)

Custos Reais Mensais

Vercel: $0 (hobby plan)
Supabase: $0 (free tier)
Oracle Cloud: $0 (always free)
Cloudflare: $0 (free tier)
Domínio: R$ 40/ano
Total mensal: ~R$ 3,33

Lições Aprendidas

Over-engineering vale a pena quando cada decisão vira conhecimento aplicável em projetos pagos.
Free tiers são poderosos se você conhece os limites e otimiza dentro deles.
Automação é investimento - 40h construindo pipeline vs 2h/semana publicando manualmente.
PostgreSQL é subestimado - um banco que faz trabalho de 4 ferramentas.

O Vivo de Código não é só um blog. É um laboratório de produção onde testo tecnologias que uso com clientes, sem o risco de quebrar sistemas críticos.

Leia o artigo completo com todos os exemplos de código e diagramas em https://vivodecodigo.com.br/backend/anatomia-vivo-de-codigo-arquitetura-blog-tech