SLA, latência (p99) e uptime: o que exigir de uma API de dados em 2026

Quando o seu fluxo de antifraude tem um orçamento de 300 milissegundos para aprovar ou recusar uma transação Pix, uma API de dados que responde "rápido na média" e cai "só de vez em quando" é um passivo operacional, não um fornecedor. O SLA (Service Level Agreement, ou Acordo de Nível de Serviço) é o instrumento contratual que transforma promessa de marketing em obrigação verificável. Este artigo mostra o que um comprador de dados em fintech — risco, fraude, compliance, crédito e engenharia — deve exigir e escrever num SLA de API de dados em 2026: latência medida no percentil 99 (p99), uptime aferido sobre requisições reais, degraus de volume, idempotência, fallback e janelas de retry. A tese central é simples e contraintuitiva: o número que decide a sua perda por fraude e a sua conversão de onboarding não é a média anunciada no site do fornecedor, é a cauda que ninguém coloca no contrato.

O que é um SLA de dados — definição operacional

Um SLA de dados é o contrato que define, de forma mensurável e com consequência, o nível de serviço que um provedor de dados (DaaS, Data as a Service) entrega a quem consome a API. Ele não é o mesmo que o material comercial. O material comercial diz "99,9% de disponibilidade e baixa latência"; o SLA define quem mede, sobre qual janela, com qual percentil, qual o crédito quando se descumpre, e o que conta como exceção.

Na prática, três objetos coexistem e costumam ser confundidos. O SLI (Service Level Indicator) é o que se mede — latência da requisição, taxa de erro, disponibilidade. O SLO (Service Level Objective) é a meta interna — por exemplo, p99 abaixo de 250 ms. O SLA é a parte do SLO que vira obrigação contratual com penalidade. Um SLA sem SLI definido é decorativo.

"Em 2026, a maior parte dos provedores de ponta anuncia alta disponibilidade, mas o uptime anunciado nem sempre reflete o desempenho no mundo real — a arquitetura por trás do feed importa tanto quanto o número: redundância, modelos de failover e o próprio SLA" (fonte: Financial Modeling Prep, 2026, currencyfreaks.com).

Latência: por que a média mente e o p99 decide

Conduktor; Webalert, 2026

Latência é o tempo entre a sua requisição e a resposta utilizável. O erro mais caro de um comprador de dados é negociar latência pela média. A média esconde a cauda, e é na cauda que o cliente real é prejudicado. Considere um sistema que processa 1 milhão de chamadas por hora com meta de p99 abaixo de 100 ms: isso significa que 990 mil chamadas terminam dentro de 100 ms, mas até 10 mil podem demorar mais (fonte: Conduktor, 2026, conduktor.io). Dez mil eventos lentos por hora, num fluxo antifraude, são dez mil decisões tomadas no escuro ou perdidas no timeout.

Por isso o número que vai para o contrato é o percentil, não a média. O p99 é o valor abaixo do qual ficam 99% das requisições; o p95, 95%. Provedores sérios publicam ambos. Benchmarks de 2026 mostram provedores de infraestrutura mantendo p95 consistente abaixo de 150 ms para chamadas de leitura, com SLAs de 99,99% e certificação SOC 2 Tipo II (fonte: Chainstack, 2026, chainstack.com). A pergunta que o comprador faz na mesa de POC não é "qual a latência média?", é "qual o p99 sob a minha carga de pico, na minha região, com o meu payload?".

O orçamento de latência do seu fluxo

Antes de exigir um número do fornecedor, decomponha o seu próprio orçamento. Num onboarding digital, o usuário tolera segundos; num bloqueio de transação em pagamento instantâneo, o controle precisa operar em milissegundos para não comprometer a experiência do Pix em tempo real (fonte: idCerberus, 2026, idcerberus.com). Sistemas modernos de antifraude analisam fatores comportamentais e de geolocalização em milissegundos para bloquear tentativas em tempo real — e a chamada de dados externos é apenas um dos elos dessa cadeia. Se o seu orçamento total é 300 ms e o motor de decisão consome 120 ms, a sua API de enriquecimento não pode ter p99 de 250 ms.

Uptime: o que "99,9%" custa em minutos e como aferir

Uptime é a fração do tempo em que o serviço está disponível. Aqui a aritmética importa e raramente é lida com atenção. Um SLA de 99,9% permite cerca de 8 horas e 46 minutos de indisponibilidade por ano, ou aproximadamente 43,8 minutos por mês. Subir para 99,99% reduz isso em 10 vezes: cerca de 52,6 minutos por ano, ou cerca de 4 minutos por mês (fonte: Webalert, 2026, web-alert.io). Cada nove adicional é exponencialmente mais difícil e costuma custar dez vezes mais em infraestrutura e engenharia.

O ponto que decide a qualidade do contrato é como o uptime é medido. Há três armadilhas recorrentes:

1. Janela de medição. 99,9% ao ano permite uma queda longa única; 99,9% ao mês é muito mais rígido. Exija medição mensal e crédito mensal.
2. O que conta como "indisponível". Um serviço que responde HTTP 200 com payload vazio ou com erro de negócio pode ser contado como "no ar" se o SLA mede só ping. Exija que a disponibilidade seja aferida sobre requisições reais bem-sucedidas (taxa de erro abaixo de um limiar), não sobre health check.
3. Exclusões. Janelas de manutenção programada, ataques, falhas de terceiros e force majeure frequentemente saem da conta. Leia as exclusões antes de acreditar no número.

A consequência prática é gerencial: atingir 99,99% exige detectar e resolver incidentes em menos de uma hora somada no mês, o que implica monitoramento automatizado, plantão e redundância entre regiões ou provedores (fonte: Webalert, 2026, web-alert.io). Se o fornecedor promete 99,99% mas não descreve failover, o número é aspiracional.

Orçamento de erro: a forma adulta de negociar

A disciplina de SRE inverte a pergunta. Em vez de "quanto uptime eu preciso?", pergunte "quanto de indisponibilidade eu posso gastar?". Um SLO mensal de 99,9% dá um orçamento de erro de cerca de 43 minutos por mês, e cada incidente consome esse saldo (fonte: SRE School, 2026, sreschool.com). Esse enquadramento é útil na negociação porque alinha incentivos: o fornecedor que gasta orçamento em manutenção mal planejada paga crédito, e você decide racionalmente se quer comprar o nono adicional ou investir em fallback do seu lado.

Degraus de volume: rate limit, burst e o SLA que some no pico

Um SLA de latência e uptime que não fala de volume é incompleto. Toda API impõe limites — rate limit (requisições por segundo ou por minuto) e burst (pico instantâneo tolerado). O risco do comprador é descobrir o teto na Black Friday, quando o tráfego de onboarding e antifraude triplica e a API começa a devolver HTTP 429 (Too Many Requests). Pior: muitos SLAs suspendem a garantia de latência justamente quando o rate limit é ultrapassado.

O que exigir por escrito:

• Degraus contratados com a vazão sustentada (RPS médio) e o burst máximo, com a latência p99 garantida dentro de cada degrau.
• Comportamento no estouro: a resposta deve ser 429 com cabeçalho Retry-After, e não timeout silencioso. Adote backoff exponencial nas retentativas para não inundar a API e agravar o rate limit (fonte: Zuplo, 2026, zuplo.com).
• Capacidade pré-provisionada para janelas de pico (datas de campanha, lançamentos), comunicada com antecedência e refletida no preço.
• Preço por consulta efetiva, separando consultas que retornam dado útil de consultas vazias ou de erro — o CFO mede custo por proposta aprovada, não por chamada bruta.

Idempotência: a rede de segurança contra cobrança e decisão dupla

Quando uma chamada dá timeout, o cliente não sabe se a operação aconteceu. Retentar sem proteção pode duplicar o efeito — duas consultas faturadas, duas decisões registradas, dois eventos de monitoramento. A idempotência resolve isso: o cliente gera uma chave única (tipicamente um UUID v4) e a envia no cabeçalho; o servidor guarda a chave e a resposta, e em retentativas devolve a resposta armazenada sem reprocessar (fonte: Stripe, 2026, docs.stripe.com). A operação ocorre uma vez; o cliente retenta com segurança até obter resposta definitiva.

Para o comprador de dados, idempotência tem efeito direto em custo e em compliance. Em custo, evita pagar pela mesma consulta efetiva duas vezes. Em compliance, evita trilhas de auditoria com decisões duplicadas que poluem o monitoramento de PLD/FT (Prevenção à Lavagem de Dinheiro e Financiamento do Terrorismo), regido pela Circular BCB 3.978/2020. Boas práticas de 2026 a exigir no SLA:

1. Suporte a chave de idempotência em todos os endpoints de escrita e consulta faturável, com a chave gerada pelo cliente.
2. Janela de cache documentada — 24 a 48 horas é o padrão aceito para operações financeiras, com sistemas de pagamento chegando a 48–72 horas para cobrir fins de semana (fonte: Zuplo, 2026, zuplo.com).
3. Armazenamento também das respostas de erro, para que a retentativa receba o mesmo erro de validação e não "passe" por mudança de dado.
4. Nunca usar dado pessoal como chave (e-mail, CPF) — a chave é técnica, não identificador de negócio.

Fallback e degradação graciosa: o que a API faz quando a fonte falha

Uma API de dados é, no fundo, uma orquestradora de fontes — bureaus, bases públicas, Open Finance. Quando uma fonte cai ou estoura latência, o comportamento da API define se o seu fluxo trava ou degrada com elegância. Exija no contrato a descrição explícita da estratégia de fallback:

• Timeout interno menor que o seu. A API deve desistir de uma fonte lenta antes de estourar o seu orçamento, devolvendo resposta parcial sinalizada em vez de pendurar a conexão.
• Resposta parcial com metadados. O retorno deve indicar quais fontes responderam e quais falharam, para que o seu motor decida com a informação disponível (por exemplo, aprovar com fricção adicional em vez de recusar).
• Cache de último valor conhecido para dados cadastrais estáveis, com carimbo de frescor — útil quando a alternativa é não decidir.
• Circuit breaker por fonte, para isolar uma dependência defeituosa sem derrubar a API inteira.

O princípio é tratar o uptime anunciado com ceticismo e desenhar a sua própria resiliência. Como nota a literatura de infraestrutura, o número anunciado nem sempre reflete o desempenho real, e a redundância e o modelo de failover importam tanto quanto o percentual (fonte: Financial Modeling Prep, 2026, currencyfreaks.com). Em fluxos críticos, o comprador maduro mantém um segundo provedor ou uma regra de degradação do seu lado — não delega 100% da resiliência ao SLA do fornecedor.

Como escrever o SLA: a cláusula que você leva para a mesa

Reúna o que foi visto numa estrutura que o procurement e a engenharia assinam juntos. Um SLA de API de dados defensável em 2026 contém, no mínimo:

1. SLIs nomeados: latência (p95 e p99, por endpoint e por região), disponibilidade (sobre requisições bem-sucedidas), taxa de erro, frescor do dado.
2. Metas numéricas por degrau de volume, com p99 garantido dentro de cada degrau e comportamento documentado no estouro.
3. Janela de medição mensal e fonte da medição (dashboard do fornecedor auditável e/ou medição própria do cliente).
4. Penalidades em crédito escalonadas por faixa de descumprimento, com gatilho de rescisão sem multa após N meses consecutivos abaixo da meta.
5. Exclusões explícitas e limitadas, com manutenção programada notificada com antecedência e contabilizada fora do horário de pico.
6. Idempotência, fallback e webhooks descritos como obrigação técnica, não como cortesia.
7. Sandbox e suporte com SLA próprio de resposta para incidentes P1 (severidade máxima), normalmente em minutos para tempo real.

O teste final de um SLA é o bake-off. Não assine pela latência do datasheet; rode uma POC comparativa sob a sua carga de pico, na sua região, medindo p99 e taxa de erro com o seu próprio instrumento. Provedores que resistem a serem medidos sob carga real estão dizendo, sem dizer, qual é a cauda deles.

Perguntas frequentes

Por que exigir p99 e não a latência média?

Porque a média esconde a cauda. Num volume de 1 milhão de chamadas por hora, uma meta de p99 abaixo de 100 ms ainda deixa até 10 mil chamadas mais lentas — e são essas que estouram o orçamento de tempo do antifraude ou geram timeout no onboarding. A média pode ser ótima enquanto a experiência de 1% dos usuários é péssima.

Qual a diferença prática entre 99,9% e 99,99% de uptime?

99,9% permite cerca de 43,8 minutos de indisponibilidade por mês; 99,99% reduz isso para cerca de 4 minutos. É uma redução de 10 vezes, que custa tipicamente 10 vezes mais em engenharia e infraestrutura. Vale negociar o nono adicional apenas para os fluxos onde minutos de queda viram perda direta — antifraude em tempo real, por exemplo.

O que precisa ser garantido nos degraus de volume?

A vazão sustentada (RPS) e o burst máximo, com o p99 garantido dentro de cada degrau, e o comportamento no estouro (HTTP 429 com Retry-After, nunca timeout silencioso). Sem isso, o SLA de latência evapora justamente no pico, que é quando você mais precisa dele.

Por que idempotência aparece num SLA de dados?

Porque sem chave de idempotência uma retentativa após timeout pode duplicar consultas faturadas e decisões registradas. Com a chave (um UUID gerado pelo cliente) e uma janela de cache de 24–48 horas, o servidor devolve a resposta original sem reprocessar — protegendo custo por consulta efetiva e a trilha de auditoria de PLD/FT.

Como o uptime deve ser medido para não enganar?

Sobre requisições reais bem-sucedidas, em janela mensal, com taxa de erro abaixo de um limiar — não sobre health check que aceita HTTP 200 com payload vazio. E leia as exclusões: manutenção programada, falhas de terceiros e force majeure costumam sair da conta e inflar o número anunciado.

Devo depender só do SLA do fornecedor para resiliência?

Não em fluxos críticos. O número anunciado nem sempre reflete o desempenho real, e a arquitetura de failover importa tanto quanto o percentual. O comprador maduro exige fallback e degradação graciosa do fornecedor e mantém, do seu lado, um segundo provedor ou uma regra de degradação para os casos em que não decidir é a pior opção.

Leia também no DataHub

• Cobertura e qualidade da base: o critério que decide o fornecedor de dados em 2026 — Decisão técnica
• Preço por consulta e economia de dados: o custo que cresce com o funil em 2026 — Decisão técnica
• API de dados de PJ: como integrar risco e compliance no fluxo em 2026 — Produtos DataHub
• Guia do CTO e Head de Dados: como avaliar uma API de dados de risco em 2026 — Para decisores
• Dados judiciais, dívidas e protestos: a camada de risco PJ que o score não vê em 2026 — Tipos de dado

Fontes

1. Conduktor — SLAs for Streaming: Defining and Measuring Real-Time Guarantees (2026)
2. Webalert — Uptime SLA Explained: 99.9% vs 99.99% Availability (2026)
3. Zuplo — Implementing Idempotency Keys in REST APIs: A Complete Guide (2026)
4. Stripe API Reference — Idempotent requests (2026)
5. SRE School — What is P99 latency? (2026 Guide) (2026)
6. Financial Modeling Prep / CurrencyFreaks — Best Financial API Picks for Real-Time Data in 2026 (2026)
7. Chainstack — Top RPC Providers for DeFi and Production in 2026 (benchmarks p95/SLA/SOC 2) (2026)
8. idCerberus — KYC e Antifraude: onboarding digital seguro e rápido (LGPD Brasil) (2026)