O painel mostra cem créditos. O cliente inicia um trabalho que pode consumir setenta.
Enquanto ele roda, uma segunda execução pede mais quarenta.
Se as duas olharem apenas para o saldo de cem, ambas podem começar. O problema só aparece depois, quando os consumos precisam caber na mesma carteira.
Todos os números deste exemplo são didáticos. A questão é como representar um compromisso antes de saber seu custo final.
O saldo não responde sozinho quanto pode ser gasto
Num modelo com reservas, é útil distinguir três coisas: o total ainda não consumido, a parte comprometida com trabalhos em andamento e o que continua disponível para novas operações.
Uma reserva não é necessariamente um débito definitivo. Ela impede que o mesmo recurso seja prometido simultaneamente a mais de uma execução.
No exemplo, reservar setenta deixa trinta disponíveis. Um segundo trabalho que exige quarenta não cabe nesse momento.
| Momento | Saldo total | Reservado | Disponível |
|---|---|---|---|
| Antes do trabalho | 100 | 0 | 100 |
| Após reservar 70 | 100 | 70 | 30 |
| Trabalho termina consumindo 50; reserva é encerrada | 50 | 0 | 50 |
A diferença de vinte deixa de estar comprometida quando a primeira operação é concluída. Não são créditos novos; eram créditos que não chegaram a ser consumidos.
A verificação precisa valer no momento da reserva
Duas requisições podem ler o mesmo saldo ao mesmo tempo.
Por isso, “consultei e parecia suficiente” não resolve concorrência. A validação do disponível e o registro da reserva precisam formar uma operação consistente na arquitetura adotada.
Também é necessário reconhecer repetições. Se a mesma solicitação volta depois de um timeout, não deveria criar outra reserva para o mesmo trabalho.
O mecanismo concreto depende do banco e do sistema. O requisito de negócio é mais simples: uma unidade de saldo não pode ser comprometida duas vezes sem que a política permita isso explicitamente.
A reserva precisa de um fim
Quando o trabalho termina, o sistema determina o consumo efetivo e encerra a reserva conforme a regra.
Se ele falha, é preciso saber se algum consumo ainda é cobrável. Essa resposta depende do que o cliente comprou, não de um tratamento genérico de exceção.
Também existem trabalhos que desaparecem do radar: processo interrompido, confirmação perdida, resultado ainda desconhecido.
Uma rotina de recuperação pode encontrar reservas antigas, mas liberar tudo por tempo decorrido é perigoso se o trabalho continua executando. O desenho precisa coordenar prazo, cancelamento e consulta de estado.
Caso contrário, a recuperação devolve saldo que outra operação ainda pode consumir.
Confira também qual carteira está sendo lida
Existe outra explicação possível para “tenho crédito, mas a operação não passa”: o saldo pertence a outra unidade.
A documentação da Infi organiza carteiras por medidor. Um crédito no medidor de tokens não deve ser confundido com o pool legado chamado credits. A configuração do produto e a leitura da carteira precisam apontar para a mesma unidade. Guia de configuração.
Isso é independente do exemplo de reservas. A Infi expõe os saldos separados por medidor, mas o fluxo ilustrativo de reserva, confirmação e expiração não deve ser interpretado como um recurso público pronto da plataforma.
O que a tela precisa explicar
Se o produto trabalha com reservas, mostrar apenas um saldo total deixa o cliente sem contexto.
Exibir o que está disponível e o que está comprometido ajuda a explicar por que um trabalho pode precisar esperar. Associar a reserva à operação permite encontrar a causa.
Um ledger preserva a história dos movimentos. O modelo de reservas acrescenta a história dos compromissos em aberto.
Juntos, eles permitem responder duas perguntas diferentes: quanto o cliente ainda tem e quanto ele pode usar agora.