O que são Cold Starts em Serverless?

Cold start é a penalidade de latência paga quando a plataforma serverless precisa criar e inicializar um novo ambiente antes de executar o seu código. Não é um bug, é uma fatura: scale-to-zero significa que ambientes ociosos são recolhidos para que ficar parado não custe nada — e a primeira request depois da recolha paga o setup. Entender as fases, os números reais e a escada de mitigação transforma cold starts de um medo vago em uma decisão de engenharia com preço.

Principais pontos

As cinco fases, com o relógio correndo

COLD START                                              custo típico
1  Alocar um sandbox (micro-VM / contêiner)             ~50–100 ms
2  Baixar o pacote de deploy                             50–500 ms  ← escala com o tamanho do bundle
3  Subir o runtime da linguagem                          50–1.000 ms ← interpretador rápido, VM lenta
4  Rodar o SEU init (imports, clients de SDK, conexões)  0 ms–segundos ← a maior alavanca que você controla
5  Invocar o handler                                     o trabalho de verdade

WARM START = só o passo 5 (+ ~1–10 ms de descongelamento). O ambiente foi
congelado, não destruído — conexões e caches fora do handler sobrevivem,
e é por isso que disciplina no init paga aluguel em cada request seguinte.

O contraste que vale a pena medir você mesmo — uma função em um backend sempre em execução, onde a corrida nunca começa:

// JavaScript / Node.js — Back4app JS SDK
// Cloud Code runs on an always-on backend — no scale-from-zero cold start
const t0 = Date.now();
const avg = await Parse.Cloud.run('averageStars', { movie: 'Arrival' });
console.log(`Round trip: ${Date.now() - t0} ms`); // consistent p50 ≈ p99
// The FaaS mitigations (warmers, provisioned capacity, bundle diets)
// don't apply here: the process serving this call was already running.

// Flutter / Dart — Back4app Flutter SDK
// Cloud Code runs on an always-on backend — no scale-from-zero cold start
final t0 = DateTime.now();
final response = await ParseCloudFunction('averageStars')
    .execute(parameters: {'movie': 'Arrival'});
print('Round trip: ${DateTime.now().difference(t0).inMilliseconds} ms');
// Consistent p50 ≈ p99: the process serving this call was already running.

// iOS / Swift — Back4app Swift SDK
// Cloud Code runs on an always-on backend — no scale-from-zero cold start
let t0 = Date()
let avg: Double = try await Cloud.run(name: "averageStars",
                                      parameters: ["movie": "Arrival"])
print("Round trip: \(Int(Date().timeIntervalSince(t0) * 1000)) ms")
// Consistent p50 ≈ p99: the process serving this call was already running.

// Android / Kotlin — Back4app Android SDK
// Cloud Code runs on an always-on backend — no scale-from-zero cold start
val t0 = System.currentTimeMillis()
val avg = ParseCloud.callFunction<Double>(
    "averageStars", mapOf("movie" to "Arrival"))
println("Round trip: ${System.currentTimeMillis() - t0} ms")
// Consistent p50 ≈ p99: the process serving this call was already running.

Cold starts vs. warm starts

Quanto duram, e com que frequência — honestamente

A duração depende sobretudo do runtime e do bundle: runtimes interpretados (JavaScript, Python) tipicamente 200–400 ms; compilados (Go, Rust) abaixo de ~100–300 ms; baseados em VM (JVM, .NET) de 500 ms a vários segundos, com snapshot-restore cortando dramaticamente o número da JVM; os p99 rodam 2–3× a mediana, e árvores de dependências inchadas já foram medidas multiplicando o startup várias vezes, independentemente da linguagem. A frequência é onde a maioria dos explicadores conta só metade da história. Tráfego de produção constante vê cold starts em menos de um por cento das invocações — tranquilizador, e real. Mas a conta se inverte no tráfego esparso: a aritmética de Fowler — uma função invocada uma vez por hora dá cold start praticamente toda vez, e ambientes de dev veem taxas frias de 30–90%. E o gatilho que todo mundo esquece: o scale-out de concorrência — quando dez requests chegam e três ambientes estão warm, sete dão cold start ao mesmo tempo, no meio do seu pico de tráfego, que é exatamente quando dói.

A escada de mitigação, com preços

Em ordem de custo, do mais barato primeiro. Gratuito, no código: encolha o bundle de deploy e pode as dependências — a maior alavanca que a maioria dos times ainda não puxou; importe só os submódulos do SDK que você usa; carregue sob demanda módulos pesados de caminhos raros; abra conexões de banco no escopo de init para que warm starts as reutilizem. Barato, na configuração: aumente a memória (a CPU escala junto, de forma material para runtimes de VM); habilite snapshot-restore onde a plataforma oferecer. Frágil, remédio caseiro: pings de keep-warm — uma request agendada a cada poucos minutos mantém um ambiente warm e não faz nada pelo scale-out; status honesto: gambiarra legada. Pago, definitivo: capacidade pré-provisionada (“concorrência provisionada”, “instâncias mínimas”) — N ambientes sempre inicializados, cold starts eliminados até N, a um preço sempre ativo que cancela em parte o pagar-pelo-uso. A ironia merece a própria frase: a correção para o problema-assinatura do serverless é comprar de volta o servidor que prometeram que você não tinha.

Isolates: como os runtimes de edge contornam o problema

Plataformas de edge reportam cold starts próximos de zero mudando a arquitetura em vez de aquecê-la: no lugar de subir um contêiner ou micro-VM por tenant, elas rodam milhares de isolates V8 — sandboxes no estilo aba de navegador — dentro de um único processo de longa duração. Criar um contexto de isolate custa milissegundos de um dígito e megabytes, não centenas de milissegundos e um boot de runtime. A troca é o ambiente: um subconjunto de APIs padrão da web, limites apertados de CPU, sem sistema de arquivos — uma ferramenta diferente, não um upgrade gratuito, coberta com honestidade no verbete de edge.

Casos de uso comuns onde cold starts importam

• APIs interativas — um humano está olhando o spinner; o p99 inclui a cauda fria.
• Pagamentos e checkout — sensíveis a latência e precificados em conversão.
• Login e emissão de sessão — o caminho da primeira impressão, muitas vezes depois de períodos ociosos.
• Endpoints de tráfego esparso — ferramentas de admin e APIs internas onde quase toda chamada é fria.
• Onde não importam: jobs enfileirados, webhooks, trabalho agendado — o assíncrono absorve a cauda de forma invisível.

Você deveria otimizar cold starts? Matriz de decisão

Limitações e trade-offs

• Mitigações trocam dinheiro por latência. Capacidade pré-aquecida é uma conta permanente; decida por endpoint, não para a plataforma inteira.
• Warmers mentem para os dashboards. Uma função pingada parece saudável enquanto cada pico real de tráfego ainda dá cold start no scale-out.
• Economia no init tem limites. Lazy-loading agressivo move a latência dos cold starts para os caminhos de primeiro uso — meça para onde você a moveu.
• Benchmarks envelhecem rápido. Rankings de runtime e números de plataforma mudam a cada ano; números velhos (e penalidades de rede corrigidas há muito tempo) ainda circulam — date seus dados.
• A métrica que importa é a sua. Estatísticas de percentual frio descrevem o tráfego de outra pessoa; só o seu p99 sob carga parecida com produção justifica gastar.

Cold starts no Back4app

O Back4app é uma plataforma open-source de Backend as a Service (BaaS) que combina banco de dados gerenciado, APIs REST e GraphQL geradas automaticamente, autenticação, armazenamento de arquivos e funções serverless com Cloud Code. A história de cold start aqui é ausência arquitetural: o Cloud Code roda dentro de um backend sempre em execução, então não existe o momento de scale-from-zero — sem corrida de init, sem pool warm para gerenciar, sem linha de capacidade provisionada na fatura — e a medição dos code tabs mostra o que isso compra: p50 e p99 a uma distância de grito um do outro, na primeira request do dia e na milionésima. A troca é a nomeada em BaaS vs. serverless: você abre mão da granularidade de cobrança por invocação em troca de latência consistente e um banco de dados anexado — o que, para backends de apps voltados ao usuário, costuma ser o lado da troca que os usuários conseguem sentir.