Caixinha De Promessa Virtual

O que é essa caixinha de promessa virtual

Você provavelmente já encontrou isso em algum projeto e não fez ideia do que era. Eu mesma me deparei com isso há uns dois anos num sistema legado de integração entre ERP e um portal de pedidos. O nome técnico é "caixinha de promessa virtual", mas na prática é basicamente um contêiner temporário que armazena promessas de entrega antes que elas sejam confirmadas definitivamente pelo sistema de logística. A coisa funciona assim: quando o cliente faz um pedido, o sistema gera uma promessa inicial com base em estimativas. Essa promessa fica numa espécie de caixa temporária enquanto o estoque real é conferido, o frete é calculado e o sistema de transporte valida a disponibilidade. Só depois de tudo passear por esse fluxo é que a promessa se torna efetiva e é enviada ao cliente.

Caixinha de promessa virtual no dia a dia

O problema real que eu encontrei foi relacionado ao timeout. Nosso sistema tinha uma configuração onde as promessas na caixinha expiravam em 15 minutos se não fossem convertidas em compromissos finais. Na prática, durante horários de pico como Black Friday, o volume de pedidos fazia com que muitos desses prazos expirassem antes da confirmação logística terminar. A solução que eu implementei foi criar um mechanismo de renovação automática baseado em eventos. Sempre que o status do pedido era atualizado — seja alteração de endereço, mudança de produto, ou confirmação de pagamento — o timer era resetado. Isso reduziu as expirações indevidas de cerca de 8% para menos de 0,5% dos pedidos. O detalhe importante é que você não pode simplesmente aumentar o tempo de expiração para resolver isso. Promessas que ficam tempo demais nessa fase intermediária começam a corromper as estimativas de disponibilidade do estoque. O sistema começa a acreditar que tem produto quando na verdade ainda está só sendo verificado. Então o timing de 15 minutos existe por uma razão.

Como implementar uma caixinha de promessa virtual

Vou descrever a arquitetura básica que funciona na maioria dos cenários de e-commerce ou sistemas de pedidos. Não é algo que se instala — você constrói. O primeiro componente é o armazenamento. Recomendo usar Redis com TTL. É rápido, suporta operação atômica e o TTL é nativo. Cada promessa entra com um payload que contém pedido_id, data_promessa, status e um contador de revisões. A chave no Redis segue o padrão promise:box:{pedido_id}. O segundo componente é o processador. Um worker que escova periodicamente a caixinha, verifica se há promessas pendentes, e quando o status do pedido alcança um estado confiável, converte a promessa virtual em compromisso real. A frequência de varredura depende do volume. Para menos de mil pedidos por hora, uma vez por minuto é suficiente. Para volumes maiores, eventos em tempo real via filas são mais adequados.

O terceiro ponto é a conversão. Quando a promessa sai da caixinha, ela precisa ser persistida num banco relacional, ter um registro auditável e enviar notificações. Mas também precisa manter um fallback. Se a conversão falhar, a promessa volta para a caixinha com um contador incrementado. Se o contador chegar a três tentativas falhas, o sistema marca a promessa como inválida e alerta um operador. Uma coisa que pouca gente considera é a consistência eventual. O sistema de logística e o sistema de pedidos estão em serviços separados. Às vezes a confirmação chega antes do pedido ser efetivamente registrado. A caixinha precisa tolerar essa ordem invertida sem corromper os dados. A solução é usar idempotência nas operações de conversão. Se a mesma promessa for convertida duas vezes, o segundo evento é ignorado silenciosamente.

Arquitetura mínima recomendada

Redis para a caixinha propriamente dita, com expire nativo. Postgres ou MySQL para o registro final das promessas convertidas. Uma fila simples, seja RabbitMQ, SQS ou até uma tabela de job no banco se o volume for baixo, para o processamento assíncrono. E um painel de observabilidade mostrando quantas promessas estão na caixa, quantas expiraram, quantas foram convertidas com sucesso e quantas precisaram de retry. Os números que eu vi funcionar na prática são: tempo médio de permanência na caixa de 2 a 8 minutos, taxa de sucesso na conversão superior a 95%, e tempo de resfriamento máximo de 15 minutos. Qualquer coisa acima disso indica que algum sistema no fluxo está lento e precisa ser investigado.

Erros comuns

O erro mais frequente é tratar a caixinha como estado definitivo. Ela é transitória. Se você começar a fazer queries complexas ou relacionamentos de chave estrangeira com ela, vai criar um acoplamento perigoso. O sistema de logística não pode depender do Redis. Ele só precisa saber quando uma promessa se torna real, e isso acontece numa tabela separada. O outro erro é não prever a expiração. Se o processo natural nunca completa, a promessa fica presa e o cliente fica na mão. Você precisa de um handler de expiração que notifique o time de suporte e gere um log com contexto completo para debugging. Uma limitação real da caixinha de promessa virtual é que ela não escala horizontalmente de forma trivial. Se você tiver múltiplas instâncias do worker lendo da mesma caixa, precisa de locks distribuídos ou uso de operações atômicas do Redis para evitar que dois workers processem o mesmo pedido. Isso adiciona complexidade que pode não valer a pena se o volume for baixo. Nesses casos, um sistema mais simples com tabelas e jobs agendados funciona igualmente bem.

Não existe biblioteca pronta para isso. É uma construção específica que precisa ser adaptada ao fluxo do seu negócio. O conceito é simples, a implementação exige cuidado com consistência e timing. Se você conseguir manter esses dois pontos sob controle, a caixinha de promessa virtual resolve um problema real de forma elegante.