Funcionalidades Serverless e cold start

1) O que é cold start e por que ele surge

1. Alocação do ambiente (contêiner/micro-VM, download de runtime).

2. VPC/ENI, segredos, arquivos, configuração.

3. Inicialização de código (importação de módulos, conexão de base de dados, download de modelos).

4. Fazer handler.

Warm start (reuse) passa os passos 1-3. A probabilidade de cold start aumenta com os picos, após a interrupção, com o paralelismo e atualizações de código/configs.

2) Como medir e estabelecer metas (SLO)

Métricas: 'init _ duration' (inicialização), 'duration _ total', 'proporção de lançamentos frios', p95/p99 latency, erros de conexão com dependências após interrupção.
Remoção de telemetria: logs de plataforma + rótulos próprios (por exemplo, 'cold = true/falso' se houver 'context'. isColdStart 'ou sua própria bandeira em um circuito estático).
Metas SLO (exemplo): API «login» p95 ≤ 200 ms, proporção cold ≤ 3%; tarefas de fundo - p95 ≤ 1 c. Para rotas «em dinheiro» - individuais, mais rigorosas.

3) Ferramentas básicas de redução cold start

3. 1 Controle de concarrense e aquecimento

Provisioned Concertency/Min Instances: mantém N ambientes quentes. Use para canetas críticas.
Warmers/aquecimento: chamadas programadas (cron/scheduler) para manter os workers quentes. Faça isso razoavelmente (região, tempo, carga).
Burst-buffers: aumente o limite de paralelismo antes dos picos esperados.

3. 2 Embalagens e dependências

Pequeno artefacto deploy: tree-shaking, '-only prod', camadas (AWS Layers) para grandes.
Lazy-init: Importe os módulos pesados dentro do handler no primeiro acesso; preguiçoso abra as conexões.
Recursos quentes: Cante os clientes SDK/conexões na área global para reuse-ir para warm start.

3. 3 Rede e VPC

Sem VPC para funções que não precisam de privatização (caso contrário, o ENI-attach adiciona dezenas ou centenas de ms).
Se o VPC for obrigatório - use o modo de provedor de economia VPC (ENI-pool/otimização), proxy a BD (RDS Proxy/Cloud SQL Auth Proxy) e connect pooling.

3. 4 Línguas e Rants

Node. js/Go começam mais rapidamente; Python - normalmente rápido, mas sensível a grandes importações; Java/.NET - mais pesado sem GraalVM/AOT ou perfil.
Para a JVM, considere o SnapStart/CRaC/Graal Native; para. NET — trimmed Self-Contained.

3. 5 Inicialização e state

Inicialização cara em um gancho inicializador (init phase), em vez de no caminho de consulta.
Use on-demand para carregar configs/segredos com o armazenamento local (TTL).
Não guarde o status personalizado na memória - apenas os sinais em dinheiro/conectores.

4) Pattern arquitetônicos que reduzem o impacto cold start

4. 1 Asinharão e filas

Aceitamos o pedido → valemos → colocamos na fila/pneu (SQS/PubSub/Queue Armazenamento) → atendemos 202/Accepted → processamos o fundo.
Adequado para operações não interativas (pagamentos, relatórios, cálculos pesados).

4. 2 Precompute/Pre-cache

Geração de acessíveis/diretórios/flagras de fich por desencadeador (CRON/evento) e armazenamento em KV/cachê/edge.

4. 3 Fan-out/Fan-in

Dividimos uma longa operação em várias funções curtas (Map/Reduce-como) → menos risco de temporizações e reencontros.

4. 4 Edge-offload

As verificações mais simples (JWT/HMAC, geo-redirect, antibot) são feitas em edge (Workers/Functions @ Edge) para economizar o RPT e descarregar o origin.

5) Prática: configs e técnicas

5. 1 AWS Lambda (provisioned + RDS Proxy)

hcl
Terraform sketch: enable provisioned concurrency on the sales version of the resource "aws_lambda_provisioned_concurrency_config" "api" {
function_name = aws_lambda_function. api. function_name qualifier   = aws_lambda_alias. prod. name provisioned_concurrent_executions = 20
}

RDS Proxy for connection pool "aws_db_proxy" "rds_proxy" {
name          = "pg-proxy"
engine_family     = "POSTGRESQL"
idle_client_timeout  = 1800 require_tls      = true
}

js let pgClient ;//reuse between warm runs let cold = true;

exports. handler = async (event, ctx) => {
const isCold = cold; cold = false;
if (!pgClient) {
const { Client } = await import('pg');     // lazy import pgClient = new Client({ host: process. env. PG_PROXY, ssl: true });
await pgClient. connect();
}
const t0 = Date. now();
const data = await pgClient. query('select 1');
return {
statusCode: 200,
headers: { 'x-cold-start': String(isCold), 'x-elapsed-ms': String(Date. now()-t0) },
body: JSON. stringify({ ok: true })
};
};

5. 2 GCP Cloud Run / Cloud Functions (min instances)

yaml
Cloud Run service. yaml apiVersion: serving. knative. dev/v1 kind: Service metadata: { name: api }
spec:
template:
metadata:
annotations:
autoscaling. knative. dev/minScale: "5" # keep warm run containers. googleapis. com/cpu-throttling: "false"
spec:
containerConcurrency: 80 containers:
- image: gcr. io/proj/api:latest env:
- { name: DB_HOST, value: "10. 0. 0. 5" }

5. 3 Azure Functions (AlwaysOn/PreWarm)

Planos Premium/Elastic com AlwaysOn; pré-warmed instances ≥ um pré-paralelismo p95.

6) Temporizadores, retais, dedline

Passe o deadline compartilhado (cliente-side) através do título ('x-deadline-ms '/' grpc-timeout') e encurte 'per-hop timeout' dentro da função.
Repetições apenas para operações idumpotentes; use o Idempotency-Key e a dedução.
Para API de frente - hedging (pedido duplicado p90 depois) e circuito breaker para dependências de longa distância.

7) Trabalhar com BD/dinheiro/segredos

Poulas/proxy (RDS Proxy/Cloud SQL Proxy/pgBouncer) em vez de milhares de conectórios curtos.
Segredo TTL mais curto + em memória em dinheiro com atualização de fundo.
Dinheiro (Redis/Memcached/KV): Guias pesadas em init, mas com tempo limitado.

8) Organização de código e montagem

Handlers individuais para use-case '; um «gordo» bandle = longo init.
ESBuild/Rollup: exclua o que não está em uso, junte apenas o crítico.
Camadas (Layers/Extensions) - Para grandes (OpenSSL do modelo, SDK), reutilize o dinheiro do provedor.

9) Testes e simulação de picos

Sintético de lançamento «frio»: Desliga os minutos instances e espalhe o tráfego paralelo por degraus.
A/B: compare a proporção de cold, p95, erro de conector a BD/segredos, custos.
GameDay: Carga máxima x 2 do máximo histórico, desligamento.

10) Custo (FinOps)

Min instances/procurioned concurrency custa dinheiro - inclua apenas para rotas quentes.
Reduza a duração da execução: armazenamento em dinheiro, tempo curto, cancelamento de SDK desnecessário.
Leve em conta egress (chamadas para APIs externas) e logs (o volume de logs aumenta rapidamente nos picos cold).

11) Antipattern

Um handler monolítico com dezenas de megabytes de dependências.
Conexão de base de dados obrigatória em cada chamada (sem reuse/proxy).
VPC para todas as funções «por precaução».
Tempos longos e retais cegos, «caudas» e descartagens fantasmas.
Aquecimento de «tudo» 24 horas por dia.
Inicialização secreta no caminho de consulta (leniência init> 100 ms - leve para init/dinheiro).

12) Especificidades do iGaming/Finanças

Caminhos de dinheiro (depósitos/conclusões): mantenha provisioned/min instances, SLO individual, restrição rigorosa de temporizadores e repetições (idempotidade obrigatória).
KYC/PSP: API externo instável - vire em queue + worker, na frente, 202/polling/webhook.
Regulação e auditoria: logs imutáveis (WORM), registro de eventos entrantes com 'Idempotency-Key', correlação 'trace _ id'.
Data residency: as funções que processam o PII sejam implantadas em contas/projetos regionais; Nada de capas edge com PII.

13) Folha de cheque pró-prontidão

• Definidos SLI/SLO: p95/p99, porção cold, destino por rota.
• Ativado provioned/min instances em funções críticas; Previsão de Concarrence.
• Bandl minimizado; folhas pesadas são levadas para camadas; lazy-import/inicialização.
• Reuse clientes SDK/BD; configurado pelo RDS/SQL Proxy; um pool de conexões.
• VPC apenas onde for necessário; ENI/proxy otimizados; segredos por meio do gestor + dinheiro local TTL.
• Timouts/deadline/retrai: backoff + jitter; Apenas repetições idoneas.
• Sintético «cold» + testes de carga; alertas para o crescimento da proporção de cold e p99.
• Runbooks: como aumentar provisioned, como alterar minScale, como incluir degradação.
• Para iGaming: SLO/dashboard individuais «caminhos do dinheiro», Idempotency-Key, auditoria WORM.

14) TL; DR

Cold start é inevitável, mas controlamos: mantenha as instâncias quentes onde for importante, reduza o bandl, aplique lazy-init e conexões reuse, evite o VPC extra, leve as operações pesadas para a fila/worker e use o edge para regras fáceis. Para caminhos financeiros críticos - SLO, Idempotidade e temporizações rigorosas; mede a proporção de cold e inclua o aquecimento apenas onde for rentável.