Latência de verificação: o que é síncrono, o que é assíncrono e por quê

A primeira surpresa de quem integra verificação de identidade é o tempo. O resto da API da empresa responde em dezenas de milissegundos, e de repente existe uma operação que leva segundos, às vezes minutos, e ocasionalmente horas, quando cai em revisão humana. A segunda surpresa é descobrir que isso não é defeito do fornecedor: é a natureza da operação, e o desenho da integração inteira muda quando se aceita isso cedo.

Este artigo explica de onde vem o tempo de uma verificação, por que a espera síncrona é o anti-padrão clássico, como os três canais assíncronos se dividem e o que medir para saber se a integração está saudável.

De onde vem o tempo

Uma verificação composta executa módulos com perfis de latência completamente diferentes. A análise de imagem, leitura do documento, comparação facial, prova de vida, custa processamento real de modelo, com o orçamento de milissegundos dissecado no artigo sobre o custo de rodar prova de vida. As consultas cadastrais dependem de fontes externas, cada uma com seu tempo de resposta e suas janelas de indisponibilidade, e o comportamento correto quando a fonte não responde, degradar com honestidade em vez de travar, é o tema do artigo sobre quando a fonte externa cai. E existe o módulo cuja latência não se mede em milissegundos: a revisão humana, que entra quando os sinais não sustentam decisão automática.

Somando: o percentil rápido de uma verificação completa mora em segundos, e a cauda longa existe por construção. Nenhum contrato de API muda isso; o que muda é como a integração convive com o fato.

O anti-padrão: segurar o request aberto

A tentação natural é chamar a API e esperar a resposta na mesma conexão. Funciona na demo e desmorona em produção, por uma cadeia conhecida: o cliente configura um timeout, a cauda longa o estoura, o cliente repete a chamada, o servidor processa duas vezes, e a interface do usuário fica presa num spinner que não informa nada. Pior: cada segundo de espera síncrona segura recursos dos dois lados da conexão para nada.

O protocolo HTTP tem semântica pronta para isso desde sempre: o código 202 Accepted, definido na RFC 9110, significa exatamente "aceitei o trabalho, o processamento não terminou". A operação de longa duração devolve 202 com um identificador, e o resultado viaja por outro canal. Quem repete a chamada por engano precisa encontrar um consumidor idempotente do outro lado, tema do artigo sobre idempotência em APIs.

Os três canais assíncronos, cada um no seu papel

• Webhook, o canal canônico servidor a servidor. Quando a decisão sai, o fornecedor chama um endpoint do integrador, com assinatura verificável e reentrega automática em caso de falha do receptor. É o canal do registro definitivo: o que o webhook entregou é o que o sistema do integrador grava e processa. O desenho seguro do receptor está no artigo sobre webhooks seguros em KYC.
• Consulta de estado (polling), a rede de segurança. Um endpoint de leitura do estado atual da verificação, consultado em intervalo modesto, cobre os buracos do mundo real: o webhook que a rede engoliu, o receptor que estava fora do ar no momento errado. Polling como canal único é desperdício; polling como reconciliação é resiliência.
• Eventos para interface (SSE ou WebSocket), o canal da experiência. Painéis e widgets precisam refletir o progresso sem recarregar página. Server-sent events, padronizado na especificação HTML do WHATWG, resolve o sentido servidor-para-navegador com simplicidade; WebSocket cobre o caso bidirecional. Na UNIFOKAL, por exemplo, a separação é essa: a decisão chega ao sistema do cliente por webhook, o painel acompanha ao vivo por SSE, e o widget do usuário final se atualiza por WebSocket com consulta de estado como reserva.

A regra que amarra os três: canal de interface informa, canal canônico decide. Interface que grava decisão no banco a partir do evento de tela, em vez do webhook, cria duas fontes de verdade e a divergência aparece na pior hora.

A espera do usuário também é desenho

Enquanto os servidores conversam, existe um humano olhando para a tela. A referência clássica de Jakob Nielsen sobre tempos de resposta, publicada em Usability Engineering (1993), dá as três fronteiras: até um segundo preserva o fluxo de pensamento; a partir de dez, a atenção se perde e o usuário precisa de indicação de progresso. Verificação de identidade vive na terceira faixa, então a interface precisa dizer o que está acontecendo, etapa a etapa, e nunca prometer prazo que o sistema não controla. O usuário tolera espera explicada; o que ele não tolera é espera muda.

O que medir

Saúde de integração assíncrona se mede com quatro números, todos por percentil e não por média: o tempo até a decisão (fim a fim, o que o usuário sente), o tempo por módulo (onde o gargalo mora), o atraso de entrega do webhook (a distância entre a decisão existir e o integrador saber) e a taxa de reconciliação por polling, que mede quantos resultados o canal canônico não entregou de primeira. Uma integração pode estar rápida na média e doente no p95, e é no p95 que moram os clientes que reclamam.

Aceitar a natureza assíncrona da verificação não é rebaixar expectativa, é colocar a engenharia onde ela rende: canal certo para cada informação, medição por percentil e uma interface que trata o tempo como parte do produto, não como constrangimento.

Fontes citadas

• RFC 9110, HTTP Semantics, IETF, seção sobre o código de estado 202 Accepted: rfc-editor.org/rfc/rfc9110
• WHATWG, HTML Living Standard, seção Server-sent events: html.spec.whatwg.org
• Jakob Nielsen, Usability Engineering (1993), os três limites de tempo de resposta, resumo publicado pelo Nielsen Norman Group: nngroup.com