O cliente pede um relatório. A primeira execução falha. A segunda também. A terceira termina e entrega o arquivo.
Seu sistema contou três execuções. O cliente recebeu um relatório.
Qual número entra na cobrança?
Depende do que você vendeu. O contador não tem informação suficiente para tomar essa decisão.
Trabalho realizado e unidade comercial podem divergir
Cobrar por recurso consumido pode fazer sentido. Cobrar por resultado concluído também. O problema começa quando a oferta descreve um e a implementação mede o outro.
Uma plataforma pode vender tempo de processamento, independentemente do resultado. Outra pode vender uma exportação válida. Duas operações tecnicamente parecidas sustentam contratos comerciais diferentes.
Se o produto promete cobrar por relatório entregue, incrementar a fatura a cada chamada interna transforma sua estratégia de recuperação num custo inesperado para o cliente.
Se promete cobrar por processamento, ignorar recursos consumidos em execuções sem resultado pode esconder uma parte relevante da operação.
Antes de medir, escreva uma definição que produto, engenharia e suporte consigam usar.
Um evento cobrável precisa sobreviver às repetições
Volte ao relatório concluído. O serviço registra o consumo, mas perde a confirmação e reenvia o evento.
Dessa vez, não houve outra execução. Houve outra entrega do mesmo registro.
A identidade do evento deve permanecer a mesma para que o consumidor reconheça a repetição. Gerar um novo identificador a cada envio dificulta distinguir uma nova unidade de uma tentativa de transporte.
Ao mesmo tempo, duas compras legítimas podem ter cliente, quantidade e horário muito parecidos. Deduplicar apenas pela aparência dos dados corre o risco de apagar consumo real.
Identidade comercial precisa ser explícita.
O que precisa acompanhar a quantidade
Uma quantidade sem contexto é um número, não uma cobrança.
Ela precisa estar associada ao cliente correto, ao produto e à unidade medida. O momento do consumo importa para o período. A regra comercial determina como aquele evento se transforma em valor.
Quando houver correção, preserve a relação com o registro original. Não envie silenciosamente outra quantidade usando uma identidade que já representava um fato diferente.
Também vale separar métricas operacionais de medidores faturáveis. Você pode observar todas as tentativas para acompanhar custo e confiabilidade, mas cobrar apenas as entregas que cumpriram a oferta.
Essa diferença ajuda a investigar margem e eficiência sem mudar o contrato do cliente.
Um exemplo real do SDK
Na Infi, o registro de uso pode ser enviado com o SDK nativo:
await infi.track({
customerId: enrollment.id,
productId,
meter: "tokens",
value: "1200",
eventId: usageEvent.id,
timestamp: usageEvent.timestamp
});O exemplo pressupõe cliente SDK configurado no servidor, produto com versão publicada, medidor chamado tokens e cliente inscrito nesse produto. Aqui, enrollment.id é o identificador da inscrição, não o ID de usuário da sua aplicação.
Para reenviar o mesmo consumo, preserve eventId e timestamp, que participam da deduplicação. Registrar uso não cria, por si só, uma assinatura ou um período de billing. Guia do SDK.
O código consegue registrar o fato. Seu produto precisa ter definido qual fato deveria ser registrado.
Faça o teste antes de fechar a fatura
Pegue três cenários: execução concluída, falha sem entrega e reenvio do mesmo evento.
Para cada um, anote quanto recurso foi gasto e quantas unidades foram vendidas. Os números podem ser diferentes. O importante é conseguir explicar por quê.
Se a equipe discorda nessa etapa, o desacordo já existe no produto. A fatura apenas vai torná-lo visível.
O primeiro requisito de metering não deveria ser “contar chamadas”.
Deveria ser “contar exatamente a unidade que decidimos vender”.