Em crédito digital, cada segundo conta. Um consumidor que solicita um empréstimo pelo celular espera resposta em segundos, não minutos. Uma fintech que oferece crédito embedded no checkout precisa decidir antes que o cliente desista. Um marketplace que faz antecipação de recebíveis processa centenas de solicitações por minuto. A latência — o tempo entre o pedido e a decisão — é a métrica que separa operações competitivas de operações obsoletas.
Mas latência em decisões de crédito não é um problema simples de "otimizar o código". É um problema de arquitetura: como orquestrar múltiplas fontes de dados, executar políticas complexas, gerar explicações e registrar audit trail — tudo em menos de 2 segundos.
Anatomia da latência de decisão
Uma decisão de crédito típica passa por cinco estágios, cada um contribuindo para a latência total:
- Ingestão e validação — receber o request, validar campos obrigatórios (~10-50ms)
- Enriquecimento — consultar bureaus, Open Finance, APIs externas (~500-3000ms — o MAIOR gargalo)
- Execução de política — aplicar regras, calcular scores, processar tabelas de decisão (~20-100ms)
- Geração de explanation — produzir reason codes e explicação (~5-20ms)
- Persistência e response — salvar audit trail e retornar a decisão (~10-50ms)
Ingestão: 30ms | Enriquecimento: 1200ms | Política: 50ms | Explanation: 10ms | Persistência: 30ms
Total: ~1320ms (p50)
O enriquecimento (consultas externas) representa 60-80% da latência total. É onde está a maior oportunidade de otimização.
Otimização 1: Paralelização de consultas
A otimização mais impactante. Em vez de consultar Serasa, depois SPC, depois Receita Federal sequencialmente (1200ms + 800ms + 600ms = 2600ms), consulte todas em paralelo (max(1200, 800, 600) = 1200ms).
Para que paralelização funcione, a arquitetura de decisão precisa suportar execução assíncrona e DAGs (Directed Acyclic Graphs) — onde nós independentes executam simultaneamente.
Otimização 2: Cache inteligente
Nem toda consulta precisa ser feita em tempo real. Um score de bureau não muda a cada segundo. Estratégias de cache:
- TTL por fonte — score de bureau: cache de 24h. Consulta CNPJ Receita: cache de 7 dias. Lista PEP: cache de 1h
- Cache por solicitante — se o mesmo CPF solicitou crédito há 2 horas e foi negado, reusar os dados do enriquecimento anterior
- Cache condicional — para pré-aprovação, usar cache agressivo; para decisão final, forçar refresh
Otimização 3: Decision Cascade (Fast Path)
Nem toda decisão precisa percorrer o pipeline completo. Um Decision Cascade avalia regras de rejeição rápida antes de fazer consultas caras:
- Fast-reject — CPF inválido? Negar imediatamente, sem consultar bureaus (~10ms)
- Fast-approve — cliente com pré-aprovação ativa e histórico positivo? Aprovar com dados em cache (~100ms)
- Full pipeline — casos que precisam do fluxo completo (~1200ms)
Em operações com alto volume de rejeitados (ex: 40% de fast-reject), isso reduz dramaticamente a latência média e o custo por decisão.
Otimização 4: Persistência assíncrona
O audit trail é obrigatório, mas não precisa ser síncrono. A decisão pode ser retornada ao solicitante enquanto o registro é gravado em background. Isso remove ~30ms do caminho crítico. O requisito é garantir durabilidade (o registro não pode se perder) — event queues (Kafka, SQS) resolvem isso.
SLAs e percentis
Defina SLAs com percentis, não médias:
- p50 < 800ms — metade das decisões em menos de 800ms
- p95 < 2000ms — 95% das decisões em menos de 2 segundos
- p99 < 5000ms — 99% em menos de 5 segundos (permite outliers de fontes lentas)
Monitore por canal, produto e hora do dia. APIs de bureaus têm latência variável — performance pode degradar em horários de pico.
Timeouts e fallbacks
Fontes externas falham. Sem timeout e fallback, uma fonte lenta trava toda a decisão:
- Timeout por fonte — se Serasa não responder em 3s, usar cache ou prosseguir sem
- Fallback graceful — se bureau A falhar, consultar bureau B; se ambos falharem, enviar para análise manual
- Circuit breaker — se uma fonte falhar 10 vezes consecutivas, parar de chamá-la por 5 minutos
Latência no Decision Stack™
Integration Layer — Paralelização nativa de consultas, cache inteligente por TTL, circuit breakers automáticos.
Orchestration Layer — DAG com execução paralela de nós independentes; Decision Cascade para fast-path.
Observability Layer — Latência por componente, percentis em tempo real, alertas de degradação de SLA.
Como a Sinky otimiza latência
A Sinky executa decisões com latência p95 < 2 segundos. O Sinky Consulta paraleliza todas as consultas a fontes externas automaticamente, com cache configurável por fonte e circuit breakers nativos. O Sinky Studio suporta Decision Cascade para fast-reject/fast-approve. O Sinky Analytics monitora latência por componente em tempo real, alertando quando SLAs estão em risco.
Perguntas frequentes
Qual é uma boa latência para decisões de crédito?
Crédito digital: < 2 segundos (p95). Crédito PJ: 5-10 segundos. Para pré-aprovação batch, throughput importa mais que latência individual.
O que mais impacta a latência?
Consultas a fontes externas (bureaus, APIs) representam 60-80% do tempo total. Paralelização e cache são as otimizações mais impactantes.
Como medir latência?
Use percentis (p50, p95, p99), não média. Meça end-to-end e por componente. Monitore por canal, produto e hora do dia.
