Recebimento de eventos de captura por push com ACK correto e corte de payload

Ingestão de captura em campo falha por três motivos, quase sempre nessa ordem: o link cai no meio do envio, o cliente reenvia, o servidor processa duas vezes. Resolver isso na camada de aplicação, depois do fato, é caro e incompleto. A decisão pertence ao protocolo.

ACK explícito, não implícito

Um HTTP 200 devolvido antes do evento estar durável é uma mentira útil que cobra juros depois. O servidor só confirma depois de gravar o evento em armazenamento durável, com o identificador que o cliente enviou. Enquanto não recebe esse ACK, o cliente mantém o evento na fila local com backoff exponencial e teto.

Idempotência por identificador de evento

O identificador é gerado no dispositivo, no momento da captura, e viaja com o evento por toda a cadeia. No servidor, ele é chave única. Reenvio depois de ACK perdido acerta a mesma linha e devolve o mesmo ACK. Deduplicar por conteúdo — hash de imagem, janela de tempo — parece equivalente e não é: dois eventos legítimos podem ter conteúdo idêntico.

insert into eventos (id_evento, dispositivo, payload)
values ($1, $2, $3)
on conflict (id_evento) do nothing
returning id_evento;

Corte de payload no cliente

Enviar o quadro inteiro é confortável para quem escreve o servidor e caro para quem paga a franquia de dados. O recorte relevante — a região da detecção, mais margem — costuma ser ordens de grandeza menor que o quadro completo, e o efeito aparece duas vezes: no tráfego por evento e na latência até o ACK, porque há menos byte para subir em link ruim.

O quadro completo continua existindo, guardado no dispositivo por uma janela definida, e é buscado sob demanda quando alguém contesta a decisão. Isso mantém a auditoria possível sem pagar tráfego por evento que ninguém vai olhar.

O que medir

• Latência da captura até o ACK durável, em mediana e p95 — média esconde o problema.
• Taxa de reenvio por dispositivo: dispositivo que reenvia muito indica link ruim ou bug de fila, e são coisas diferentes.
• Tamanho de payload por evento, para saber quando o corte parou de funcionar.
• Eventos descartados por teto de retentativa — esse número precisa ser visível, não silencioso.