A decisão de cobrar por consumo costuma nascer numa reunião comercial e chegar ao time técnico como um requisito de faturamento. É a ordem errada. Sem instrumentação confiável antes da mudança de preço, o que se entrega é uma fatura que o cliente contesta, um suporte que não consegue explicar o número e uma receita que o financeiro se recusa a reconhecer.
O trabalho técnico de cobrança por uso não é integrar um gateway. É construir uma cadeia de medição auditável entre o evento que acontece no produto e a linha que aparece no boleto. Cada elo dessa cadeia tem um modo de falha conhecido, e todos eles se manifestam como divergência de valor no fim do mês.
Instrumentar antes de precificar, sempre nessa ordem
Antes de escolher o valor da unidade, é preciso ter pelo menos um ciclo completo de faturamento medindo em modo sombra: a métrica é coletada, agregada e exibida internamente, mas ninguém é cobrado por ela. Esse período existe para responder três perguntas que nenhuma planilha responde.
A primeira é qual a distribuição real de consumo entre os tenants. Em quase toda base madura, a curva é fortemente assimétrica: uma minoria de contas responde pela maior parte do volume, e a mediana fica muito abaixo da média. Precificar pela média produz um plano que é caro demais para o corpo da base e barato demais para quem realmente consome.
A segunda é qual a variação intra-mês. Se um tenant oscila entre 200 e 2.000 chamadas por dia, o modelo precisa de teto, franquia ou média móvel — cobrar o pico gera contestação garantida.
A terceira é qual a taxa de perda de eventos do pipeline atual. Se a coleta perde 2% dos registros em picos de carga, esse número precisa ser conhecido e reduzido antes de virar dinheiro. Divergência de medição vira crédito em conta, e crédito em conta vira desconfiança permanente no número.
A unidade de medida é uma decisão de arquitetura, não de marketing
Existe uma tentação de cobrar pela unidade que é fácil de explicar comercialmente — usuário ativo, documento processado, requisição. O critério correto é diferente: a unidade deve ser aquela que se correlaciona com o custo marginal de servir o cliente e que o cliente consegue controlar.
Quando a unidade não se correlaciona com custo, a margem some no cliente que consome muito por unidade cobrada. Quando o cliente não consegue controlá-la, ele sente a cobrança como arbitrária e passa a contestar toda variação.
| Unidade | Correlação com custo | Controle pelo cliente | Risco principal |
|---|---|---|---|
| Usuário ativo no mês | Fraca em produtos de processamento | Alto | Compartilhamento de login para reduzir a conta |
| Requisição de API | Boa em produtos de leitura | Médio | Retry automático inflar a contagem |
| Registro armazenado | Boa quando o custo é de storage | Baixo — dado antigo não se apaga sozinho | Cliente descobre a conta só quando ela já cresceu |
| Job concluído | Forte em processamento assíncrono | Alto | Definir o que conta como concluído em caso de falha parcial |
Entre as quatro, a mais defensável em produto de processamento é o job concluído, porque alinha o que o cliente pagou ao que ele recebeu. O preço a pagar por essa escolha é ter de definir por contrato o comportamento em falha: job que estourou timeout no meio, job que processou 80% dos itens e abortou, job reprocessado por erro da plataforma. Cada um desses casos precisa de uma regra escrita antes do lançamento, não depois da primeira contestação.
A cadeia de medição e onde ela quebra
O caminho do evento até a fatura tem quatro estágios, e cada estágio precisa de uma garantia explícita.
Emissão. O evento é gerado no ponto do código onde o trabalho de fato aconteceu, não onde a requisição chegou. Emitir na borda conta tentativa; emitir na conclusão conta entrega. A emissão deve carregar identificador do tenant, tipo de unidade, quantidade, timestamp do evento e um identificador único de deduplicação.
Transporte. Filas com garantia de entrega ao menos uma vez são a escolha padrão, o que transfere para o consumidor a responsabilidade de deduplicar. Descartar evento em caso de fila cheia é uma decisão que precisa ser consciente e monitorada — perder medição significa faturar a menos, e faturar a menos silenciosamente é pior do que uma falha ruidosa.
Agregação. Os eventos brutos são somados por tenant, por unidade e por janela. O erro comum aqui é agregar destrutivamente: somar e descartar o detalhe. Sem o evento bruto retido por um período que cubra pelo menos dois ciclos de faturamento mais o prazo de contestação contratual, não existe forma de auditar uma conta questionada.
Fechamento. A janela do ciclo precisa de um período de carência antes do fechamento definitivo, para absorver eventos atrasados por reprocessamento de fila. Um evento que chega depois do fechamento cai no ciclo seguinte com o timestamp original preservado — nunca é descartado nem recontado no ciclo já emitido.
Idempotência: o único requisito não negociável
Em pipeline com entrega ao menos uma vez, o mesmo evento chega mais de uma vez com frequência previsível. Se a agregação for um incremento cego, a conta do cliente cresce sozinha depois de qualquer redeploy do consumidor.
A defesa é uma chave de idempotência gerada na emissão e verificada na ingestão, com a inserção do registro e a atualização do agregado dentro da mesma transação:
-- ingestao de evento de uso, idempotente por event_id
BEGIN;
INSERT INTO uso_evento (event_id, tenant_id, unidade, quantidade, ocorrido_em)
VALUES ($1, $2, $3, $4, $5)
ON CONFLICT (event_id) DO NOTHING;
-- so agrega se a linha acima foi de fato inserida
UPDATE uso_agregado a
SET quantidade = a.quantidade + $4
FROM (SELECT 1 FROM uso_evento WHERE event_id = $1 AND inserido_em > now() - interval '1 second') novo
WHERE a.tenant_id = $2 AND a.unidade = $3 AND a.ciclo = $6;
COMMIT;A variação mais robusta em volume alto é abrir mão do agregado incremental e recalcular a soma sob demanda a partir da tabela de eventos, com índice composto por tenant, unidade e janela. Custa mais leitura, mas elimina a classe inteira de bugs em que o agregado e o detalhe divergem e ninguém sabe qual dos dois está certo.
A chave de idempotência deve ser derivada do trabalho executado — identificador do job, por exemplo — e não gerada aleatoriamente no momento da emissão. Chave aleatória não protege contra reemissão pelo produtor, apenas contra reentrega pelo transporte.
O que precisa estar de pé antes de virar a chave
Cobrança por uso muda a relação do cliente com o produto: ele passa a olhar o consumo. Se o produto não oferece essa visibilidade, o suporte vira o painel de consumo, atendendo uma por uma.
Três coisas precisam existir no dia do lançamento. Uma tela de consumo no próprio produto, atualizada com defasagem de no máximo algumas horas e com detalhamento suficiente para o cliente identificar qual integração ou usuário puxou o volume. Um alerta configurável quando o consumo do ciclo atinge um percentual definido pelo cliente. E um endpoint de exportação do detalhe do período, porque cliente corporativo vai querer bater o número contra o próprio log antes de aprovar a fatura.
Do lado interno, o requisito equivalente é reconciliação automática entre a soma dos eventos brutos, o agregado e o valor emitido na fatura, rodando todo dia com alerta em qualquer divergência acima de uma tolerância mínima. Divergência descoberta pelo cliente é incidente comercial; descoberta pela reconciliação é bug.
O passo seguinte, com a medição estável e um ciclo sombra completo em mãos, é modelar o preço sobre a distribuição observada — definir a franquia no percentil que cobre o corpo da base e o preço marginal sobre o excedente, e simular a fatura de cada tenant existente antes de comunicar qualquer mudança.
Deixe um comentário