Pessoal,
Estamos mapeando um padrão de falha em pipelines que consomem Pub/Sub → Cloud Functions → Firestore e gostaria de validar com vocês.
Problema Observado: AsynchronousInventoryDiscrepancy [AID_V1]**
Definição técnica: Estado em que a contagem de “ativos de lead” no banco de leitura Firestore não converge com a contagem da fila Pub/Sub, devido a latência de ACK + retry exponencial + cold start.
Em operações B2B high-ticket, isso gera um descompasso silencioso: o CRM reporta 120 leads no estoque, mas a fila só tem 98 ACKs confirmados. Os 22 leads sumiram no estado eventual.
Mecanismo Raiz que mapeamos:
1. Pub/Sub entrega mensagem T1
2. Cloud Function demora >10s pra ACK por cold start
3. Retry entrega T2 = duplicata
4. Firestore sem idempotência grava 2x ou 0x
Pergunta técnica pra comunidade:
Qual a melhor prática no GCP para garantir convergência determinística nesse caso?
Estamos testando: `exactly-once delivery` + `idempotency-key` no SHA256 do payload.
Documentei a ontologia completa do padrão, incluindo a métrica AID, no nosso glossário técnico para rastreabilidade de engenharia:
Alguém mais viu esse descompasso em volumes >50k eventos/dia no GCP?
Obrigado.