Pular para o conteúdo
thiagoetipadrões

Contatos

apps/data-patterns/batch-processing

101 · Dados & Persistência · ≈ 6 min de estudo

Batch Processing (Fechamento de Posição EOD)

Processamento programado em lote, distinto de um fluxo orientado a evento: roda em janelas de corte, grava checkpoint a cada bloco processado, e é seguro de reprocessar sem duplicar efeito.

passos
6
arquivos
9
teste
1
tecnologias
5
Infraestrutura realTypeScriptBunElysiaPostgreSQLDocker
CenárioRelaçõesComparar
Baixar cartão

Cenário

Fechamento de posição (EOD — end of day) de uma corretora/banco digital: toda transação lançada no dia precisa virar um lançamento consolidado no extrato (account_statements) e atualizar o saldo final da conta. Esse lote roda uma vez por dia sobre potencialmente milhões de transações — se o processo cair no meio (deploy, falta de memória, crash), reprocessar tudo do zero é caro e arriscado. O motor grava um checkpoint a cada bloco processado e, ao reiniciar, retoma exatamente de onde parou.

Planta

Sequência
9/9
SELECT transactions WHERE booked_at = hoje AND id > last_processed_id LIMIT 101bloco de transações2UPDATE account_statements (aplica bloco)3UPDATE batch_runs SET last_processed_id = ... (checkpoint)4processo cai (SIGKILL) no meio do lotereinicia o serviço5POST /batch/eod/run6SELECT batch_runs (recupera last_processed_id)7retoma exatamente do checkpoint, não do zero8UPDATE accounts SET balance = closing_balance (finaliza)9EOD Batch EnginePostgreSQLOperador
9

9 passos — reproduza para seguir o fluxo

Como funciona

6 passos

Fechamento de posição em lote no fim do dia.

Esconde cada passo: lembre antes de tocar para revelar.

  1. 01

    POST /batch/eod/:data/run cria (ou reencontra) a execução em batch_runs pela chave job + data, guardando os saldos de abertura uma única vez

  2. 02

    Execução completed → responde sem processar: rodar o dia de novo nunca duplica o extrato

  3. 03

    Cada bloco é uma transaçãoTrava a linha da execução, relê o last_processed_id, busca id > checkpoint ORDER BY id LIMIT chunkSize, aplica no extrato e grava o novo checkpoint — efeito e checkpoint commitam juntos ou nenhum

  4. 04

    Dois executores do mesmo job ao mesmo tempo não aplicam o mesmo bloco: o segundo espera a trava e segue depois do checkpoint do primeiro

  5. 05

    Bloco vazio → o saldo de fechamento vai para as contas e a execução vira completed, na mesma transação, com total_processed e horário de fim

  6. 06

    Se o processo morre no meio, a próxima chamada retoma do último bloco commitado — nada reprocessado, nada pulado

apps/data-patterns/batch-processing

9 arquivos

sql/

  • 01_schema.sqlschemaContas, transações do dia, extrato e batch_runs, valores em centavos

src/

  • engine_eod.tsMotor do fechamento: bloco + checkpoint na mesma transação, retomada e no-op
  • api_batch.tsAPI interna Elysia que dispara e consulta a execução
  • pool_batch.tsPool do PostgreSQL e transactionExecute
  • seed_transaction.tsMovimento do dia determinístico
  • config_batch.tsVariáveis de ambiente validadas no boot
  • engine_eod.test.tstesteIntegração com PostgreSQL real: SIGKILL no meio e retomada exata, no-op do dia fechado, dois executores concorrentes e saldo nas contas
  • demo.tsdemoExecução morta no meio, retomada e rodada repetida

./

  • docker.shinfraSobe o PostgreSQL 16 na porta 5432

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. Batch Processing
  • Combina com6
  • Alternativa a1

Por que se relacionam

Combina com

Alternativa a

Teste rápido

Qual destes combina com Batch Processing?

Próximo projeto · Dados & PersistênciaSearch Index
Esc

↑ ↓ navegarEnter abrir191 resultados