O Que Aumenta E Nunca Diminui

A matemática da vida prática

A coisa mais honesta que existe no universo de dados é uma variável monotonicamente crescente. No dia a dia das pessoas que trabalham com métricas, sistema de recompensa ou qualquer mecanismo de progressão, isso aparece o tempo todo. E a pergunta que todo mundo faz, direta ou não, é exatamente sobre o que aumenta e nunca diminui — porque isso define se o seu sistema é confiável ou se vai gerar frustração. Eu já perdi horas debugando um sistema de XP que supostamente não recuava, até perceber que havia um bug de concorrência onde dois eventos de drop calcularam o mesmo incremento ao mesmo tempo e um deles sobrescreveu o outro. O resultado era menos XP que o jogador tinha antes. Não parecia regressão para quem olhava a tela, mas os logs mostravam que em certos servidores, sob alta carga, o total podia sim diminuir. A correção foi simples: lock no counter ou usar operações atômicas. Dezenove meses depois, ainda vejo gente fazendo isso do jeito errado em engines que não oferecem atomicidade nativa por padrão.

O que aumenta e nunca diminui na prática

O conceito em si é simples demais para ser profundo por si só. É tudo que tem acúmulo irreversível: experiência, conhecimento, cicatrizes, custo de oportunidade já pago. O que torna útil saber identificar isso é que, quando você conhece os itens dessa lista, pode construir sistemas onde o jogador ou usuário se sinta seguro — cada passo realmente importa. Se algo pode voltar atrás, a confiança no progresso desaparece em três minutos de teste. Existem dois casos bem diferentes que as pessoas costumam confundir. O primeiro é o incremento puro, sem nenhuma condição de rollback. O segundo é o incremental com probabilidade, onde o valor técnico continua subindo, mas a percepção do usuário pode sentir oscilação. Um exemplo real: jogos live-service que adicionam moeda cosmética com taxa fixa por sessão, mas tiram pontos por punição. A moeda nunca volta ao estado inicial, mas a curva percptiva não é linear. Isso gera reclamações de "me tiraram algo" mesmo que o saldo final esteja no positivo. Uma coisa que pouca gente explica com clareza é a diferença entre monotonia estrita e monotonia fraca. Em programação, monotonia estrita exige que cada novo estado seja sempre maior que o anterior. Monotonia fraca permite iguais. A maioria dos sistemas de progresso que eu já vi usa monotonia fraca, porque eventos repetidos precisam ser silenciosos, não punidos. Confundir os dois gera bugs chatos, tipo checkpoints que só avançam se o jogador morrer antes, o que parece correto no papel e quebra no primeiro playtest.

Como implementar um contador que só sobe

Vou mostrar o jeito que eu uso, que não é o mais bonito, mas é o que menos dá dor de cabeça em produção. O código abaixo funciona tanto em JavaScript como em Python com pequenas adaptações de sintaxe. O padrão básico é proteger a variável com uma função de incremento que valida se o novo valor é realmente maior. Se não for, descarta. Isso elimina incrementos zerados e reversões acidentais causadas por race conditions ou chamadas duplicadas de rede.

```javascript let points = 0; function safeIncrement(amount) { if (amount <= 0) return; const next = points + amount; if (next > points) { points = next; save(points); } } ```

O problema real começa quando você precisa de múltiplos incrementadores concorrentes. Nesse cenário, a simples verificação acima não basta. Você precisa de lock, ou de operações atômicas, ou de um modelo orientado a eventos que serialize as atualizações. Em JavaScript, isso significa usar filas de promises encadeadas ou um microtask queue que processe um incremento por vez. Em Python, o module `threading` com um `RLock` resolve, mas custa performance visível se o loop de incremento for muito frequente. Eu costumo adotar um padrão híbrido: um estado imutável local que acumula deltas, e um flush periódico que aplica os deltas de forma atômica ao backend. O flush acontece a cada 200 milissegundos ou quando o buffer ultrapassa 50 deltas, o que vier primeiro. Esse tradeoff reduz a carga de rede em cerca de oitenta por cento em sessões intensas e mantém a consistência percebida como monotônica. A desvantagem é que, em caso de crash, o buffer em memória vai junto. Por isso o flush atômico é essencial: ele já deve ter escrito no servidor antes do próximo evento ser aceito.

Pegadinhas comuns que quebram a monotonia

Eu já vi três tipos de erro se repetirem com frequência irritante. O primeiro é a soma de valores negativos disfarçada de positivo. Se a fonte de dados vem de uma API de terceiros e retorna um `delta` que pode ser negativo, um acumulador ingênuo vai cair. A solução mais barata é tratar qualquer delta negativo como zero antes de aplicar, o que preserva a monotonia e evita surpresas. O segundo erro é o arredondamento em ponto flutuante. Somar `0.1` cem vezes não dá exatamente `10.0`. Isso pode gerar um valor ligeiramente menor que o esperado, e em testes de precisão, o bug aparece apenas em certos arredondamentos de exibição, o que atrasa a descoberta. Eu trabalho com inteiros desde o início: valores em centavos ou unidades base, e só formato para decimal na camada de apresentação. Isso elimina o problema completamente na prática. O terceiro erro, que eu chamo de "falsa monotonia", acontece quando você protege apenas o número, mas esquece do contexto. O saldo sobe, mas o histórico de eventos pode registrar uma queda porque o evento de crédito veio antes do evento de débito no log. Para auditoria, a sequência cronológica errada parece regressão. A correção exige timestamps coerentes e, idealmente, um log append-only com checkpoint assinado. Eu fiz uma integração assim com HMAC por lote, e isso reduziu disputas de suporte em cerca de setenta por cento no meu último projeto, porque o cliente podia verificar a assinatura e ver que nada havia voltado.

Quando esse modelo falha

Não adianta romantizar: incrementadores puramente monótonos têm desvantagens reais. Eles criam lock-in comportamental. Se o jogador percebe que seu progresso é irreversible, ele joga de forma mais conservadora, porque medo de perder se foi substituído por medo de desperdiçar. Em sistemas de economia, isso significa inflação sem válvula de escape. A única saída honesta é ter alguma forma de compensação externa, como eventos temporários que concedem bônus sem modificar o histórico existente, ou mecanismos de prestige que resetam apenas o estado temporário, não o acumulador permanente. Outro problema é a falta de sensibilidade a padrões de uso. Um contador que só sobe ignora quem joga de forma diferente. Jogadores casuais e hardcore chegam ao mesmo valor final por caminhos distintos, mas a monotonia pura não captura essa diferença. Para equilibrar, adicione métricas auxiliares que registram velocidade, variação, eficiência, coisas que podem subir e descer livremente. Assim você mantém a proteção do principal e ganha nuance nos derivados. Existe ainda o risco de saturação cognitiva. Quando tudo é permanente e visível, o usuário sente peso excessivo. A literatura de UX chama isso de carga de decisão aumentada. Na prática, eu limpo o histórico após certa idade dos registros e mantenho apenas os ultimos sessenta dias. O total permanece monotônico; a tela, não. Isso costuma melhorar métricas de retenção em duas a quatro semanas sem alterar a lógica de negócio.

Um exemplo concreto

Vou descrever um sistema real que construí. Era um jogo mobile com moeda premium que nunca poderia diminuir, mas precisava suportar reembolsos e correções de bugs. A solução foi separar totalmente o saldo permanente do saldo corretivo. O saldo permanente só recebia incrementos positivos via função `safeIncrement`. O saldo corretivo era uma camada separada, com sua própria lógica de auditoria, onde devoluções podiam ocorrer como eventos negativos, mas esses eventos nunca tocavam o saldo permanente. O saldo total exibido era a soma das duas camadas, e a monotonia aplicada era apenas à camada permanente. Isso resolveu o conflito entre "nunca diminuir" e "precisamos corrigir erros". A complexidade extra apareceu na camada de relato: o painel de auditoria tinha duas tabelas distintas, uma para transações permanentes e outra para corretivas, cada uma com sua assinatura de hash. A manutenção ficou mais trabalhosa, mas a confiança do time e dos auditores cresceu. Em dois anos, só tivemos uma ocorrência de inconsistência, e foi causada por um deploy errado de configuração, não por falha na lógica de monotonia. Se você está começando um projeto e quer adotar esse padrão, o conselho mais direto é simples: defina claramente qual componente deve ser monotônico, proteja-o com incrementadores validados, use inteiros para evitar erros de ponto flutuante, e mantenha logs append-only com checkpoints assinados. Qualquer atalho nessa etapa vai cobrar juros caros depois. Não é sobre perfeição; é sobre ter uma base que não minta para quem vai confiar nela.