Voltar ao laboratório
Referência Pagamentos 6 min

Referência: Cálculo de TPS para Sistemas de Pagamento

20 de maio de 2026

O que é TPS

TPS (Transactions Per Second) é a métrica primária para dimensionar gateways de pagamento, adquirentes e switches financeiros.

Diferente de RPS (requests por segundo) — que conta qualquer requisição HTTP — TPS conta apenas transações financeiras completas (autorização, captura, estorno, consulta de saldo).

Fórmulas Essenciais

TPS Médio

TPS_médio = Total de transações por dia / (Horas de operação × 3600)

Exemplo: 500.000 tx/dia em 16h de operação

TPS_médio = 500.000 / (16 × 3600) = 8,68 TPS

TPS de Pico

O pico geralmente ocorre em horários específicos (almoço, fim do expediente, datas especiais).

TPS_pico = TPS_médio × Fator de pico

Fatores de pico por contexto:

| Contexto | Fator de pico típico | |----------|---------------------| | E-commerce B2C | 3x – 5x | | Gateway genérico | 5x – 8x | | Black Friday / Promoção | 10x – 15x | | Varejo físico (hora do almoço) | 4x – 6x |

Capacidade recomendada

Nunca dimensione exatamente para o pico — use margem de segurança:

Capacidade_alvo = TPS_pico × 1.3   (margem de 30%)

Benchmarks de Referência

Por tipo de transação (latência p95 esperada)

| Operação | Latência p95 aceitável | Latência crítica (alerta) | |----------|----------------------|--------------------------| | Autorização online | < 500ms | > 1.000ms | | Consulta de saldo | < 200ms | > 500ms | | Estorno | < 800ms | > 2.000ms | | Captura | < 400ms | > 800ms |

TPS por processador (hardware moderno, Java 21 + Spring Boot)

| Setup | TPS sustentável | |-------|----------------| | 1 instância, 8 vCPU, PostgreSQL local | 200 – 500 TPS | | 3 instâncias + PgBouncer + Redis cache | 1.000 – 3.000 TPS | | Cluster Kubernetes 10 pods + RDS Multi-AZ | 5.000 – 15.000 TPS |

Dimensionamento de Banco de Dados

Conexões necessárias

Conexões_DB = Instâncias × Threads_por_instância × (1 + buffer)

Com HikariCP (padrão Spring Boot):

pool-size recomendado = (vCPU × 2) + disco_efetivo_spindles

Regra prática:

  • Para PostgreSQL em SSD: máximo de 100 conexões por instância RDS.small
  • Use PgBouncer em modo transaction para reutilização agressiva

Estimativa de storage (1 ano)

Storage_GB = TPS_médio × 3600 × 8760 × Tamanho_registro_KB / 1.048.576

Exemplo: 10 TPS × registro de 2KB = ~5.5 GB/ano (apenas dados brutos, sem índices)

Pontos de Estrangulamento Comuns

1. Connection pool do banco

Sintoma: latência sobe mesmo com CPU baixa. Fix: Aumentar pool ou adicionar PgBouncer.

2. Lock de tabela em reconciliação

Sintoma: TPS cai drasticamente em horários programados. Fix: Processar reconciliação em tabela shadow, não na transacional.

3. Timeout de HSM

Sintoma: % de erros sobe em pico sem CPU alta. Fix: Pool dedicado para HSM, retry com backoff, circuit breaker.

4. Gargalo no switch ISO8583

Sintoma: filas crescem no horário de pico. Fix: Múltiplos canais TCP (sessions) por adquirente.

Checklist de Dimensionamento

  • [ ] Qual é o TPS médio esperado no lançamento?
  • [ ] Qual é o cenário de pico (data, horário, evento)?
  • [ ] Qual a latência máxima aceitável por tipo de transação?
  • [ ] O banco de dados tem pool sizing correto?
  • [ ] Há circuit breaker para o adquirente?
  • [ ] O sistema foi testado com 130% do TPS pico estimado?
  • [ ] Existe plano de escala horizontal (Kubernetes HPA ou similar)?

Ferramentas para Load Test

# k6 — moderno, suporta protocolos TCP/HTTP
k6 run --vus 100 --duration 60s script.js

# Locust — Python, bom para fluxos complexos
locust -f locustfile.py --host http://localhost:8080

# JMeter — padrão corporativo, bom relatório
jmeter -n -t plan.jmx -l results.jtl
Referência: Cálculo de TPS para Sistemas de Pagamento — APCosta Lab — APCosta