Pular para o conteúdo
thiagoetipadrões

Contatos

apps/architecture/serverless-faas

037 · Arquiteturas de Alto Nível (Macro-Architecture) · ≈ 6 min de estudo

Serverless / FaaS

O código vira funções pequenas acionadas por eventos (HTTP, fila, agenda); a plataforma cria e descarta os ambientes de execução conforme a demanda e cobra por invocação. O projeto reproduz o modelo de execução do AWS Lambda — cold start, reuso quente, concorrência reservada e reciclagem — sobre um PostgreSQL real. Use para carga esporádica ou em picos, sem servidor ocioso para manter.

passos
6
arquivos
5
testes
0
tecnologias
5
Infraestrutura realTypeScriptBunElysiaPostgreSQLDocker
CenárioRelaçõesComparar
Baixar cartão

Cenário

Banco digital recebe PIX por função serverless: cada evento credita a conta e registra o endToEndId. O evento pode chegar duas vezes (entrega pelo menos uma vez) e o crédito não pode dobrar. Num pico, a concorrência reservada protege o banco de dados; uma função agendada fecha o relatório diário de PIX.

Planta

Sequência
8/8
alt[nenhum ambiente livre e abaixo da concorrencia reservada][concorrencia reservada esgotada]POST /pix1invoke pix-receive2init() cria o pool (cold start)3throttled4429 Retry-After5handler(event) reusa o pool6INSERT pix_received ON CONFLICT + UPDATE saldo7credited ou duplicate8ambiente ocioso alem do TTL e descartado, conexao fechadaClienteAPI GatewayRuntime FaaSAmbiente de execucaoPostgreSQL
8

8 passos — reproduza para seguir o fluxo

Como funciona

6 passos

Função sob demanda, escala até zero.

Esconde cada passo: lembre antes de tocar para revelar.

Vocabulário compartilhado

Retry-After+3
endToEndId+2
  1. 01

    Cada função tem init (fora do handler), handler e dispose; init roda uma vez por ambiente de execução e cria o pool — invocações quentes reusam a conexão

  2. 02

    Um ambiente atende uma invocação por vez: chamadas simultâneas abrem ambientes novos, cada um com o seu cold start

  3. 03

    Acima da concorrência reservada a invocação é recusada (ErrorThrottled → 429 com Retry-After), sem tocar o banco

  4. 04

    Cada ambiente segura uma conexãoN ambientes = N conexões no PostgreSQL — é o problema que o RDS Proxy resolve na AWS

  5. 05

    O endToEndId como chave primária torna o evento reentregue um no-op: duplicate em vez de segundo crédito

  6. 06

    Ambiente ocioso além do TTL é descartado e a conexão fecha; a próxima invocação volta a pagar o cold start

Trade-offs

O que se ganha, o que se paga

4 vantagenscada ganho tem um preço4 custos

Vantagens

  • Escala de zero a N ambientes sem servidor ocioso

  • Paga por invocação

  • Concorrência reservada limita o impacto no banco

  • Função pequena, deploy independente

Custos

  • Cold start na primeira invocação e depois de cada reciclagem

  • Caro em carga alta e constante

  • Cada ambiente abre conexão própria — exige proxy de conexões

  • Entrega pelo menos uma vez: idempotência obrigatória em toda função

apps/architecture/serverless-faas

5 arquivos

src/

  • runtime_faas.tsModelo de execução: ambientes, cold/warm start, concorrência reservada, reciclagem
  • function_pix.tsFunção de crédito de PIX, idempotente por endToEndId
  • function_fraud.tsFunção de checagem de fraude
  • function_report.tsFunção agendada do relatório diário
  • gateway_faas.tsAPI Gateway: HTTP para invocação, throttle para 429

Executar · com Docker

  1. ./docker.sh up# sobe PostgreSQL
  2. cp .env.example .env# variáveis de ambiente
  3. bun install# dependências
  4. bun run demo# roda o cenário
  5. bun run test# integração contra o serviço real
Requisitos
BunDocker
Sobe junto
PostgreSQL

Relações

Onde ele se encaixa

Mapa
  1. Serverless / FaaS
  • Combina com3
  • Alternativa a1

Por que se relacionam

Combina com

Alternativa a

Teste rápido

Qual destes combina com Serverless / FaaS?

Próximo projeto · Arquiteturas de Alto Nível (Macro-Architecture)Peer-to-Peer
Esc

↑ ↓ navegarEnter abrir191 resultados