O plano original exigia que a aplicação na nuvem se conectasse diretamente ao MikroTik local. Na prática, o equipamento estava isolado atrás de um CGNAT, bloqueando qualquer acesso externo. A solução não foi uma gambiarra na rede, mas uma pivotagem arquitetural.

O MikroTik foi atualizado e passou a iniciar um túnel seguro (WireGuard) de dentro para fora. A aplicação passou a controlar o roteador por esse canal, sem expor portas na internet.

Lição aprendida: A restrição física da rede deixou de ser um obstáculo a ser "contornado" e virou o novo requisito. A arquitetura deve respeitar a realidade do ambiente, não o contrário.

O primeiro mecanismo de proteção contabilizava endereços MAC para impedir que um voucher fosse compartilhado entre vários dispositivos. Na prática, essa regra tratava todos os dispositivos da mesma maneira e não representava corretamente o comportamento esperado.

A solução passou a classificar o dispositivo a partir do user-agent, utilizando ua-parser, e aplicar limites por categoria. Assim, computadores e dispositivos móveis passaram a consumir slots diferentes dentro da regra de proteção.

Um bug crítico permitia que usuários comprassem apenas 1 minuto de acesso e navegassem indefinidamente. O motivo: a rotina de limpeza atualizava o banco em lote (QuerySet.update()) focando em velocidade, o que ignorava completamente as validações do modelo (que barravam saldo negativo).

A correção sacrificou a performance de banco em favor da integridade: o processamento passou a ser iterativo, garantindo que o cálculo (min(solicitado, restante)) passasse pelas regras de negócio antes do salvamento.

Lição aprendida: Eficiência de banco de dados é inútil se ela armazena uma transação financeiramente inválida. A integridade das regras de domínio sempre tem precedência sobre a performance da query.

A liberação do acesso dependia dos webhooks do Mercado Pago. Como redes falham, esses avisos frequentemente são reenviados (retries). Se o sistema confiasse cegamente no evento, um reenvio acidental duplicaria o saldo do cliente.

O fluxo foi redesenhado: a aplicação agora verifica de forma atômica o estado access_granted_at. Se a liberação já ocorreu no banco, o novo aviso é respondido com sucesso (HTTP 200), mas ignorado no domínio.

Lição aprendida: Nunca confie no "exactly-once delivery" da rede. Eventos externos são, por definição, mentirosos ou duplicados. A idempotência precisa morar no coração da transação.

Ao encerrar o tempo de um cliente, a aplicação pedia ao MikroTik para remover a permissão de acesso. O roteador respondia "HTTP 200 OK", mas demorava milissegundos para aplicar a regra fisicamente, permitindo que o cliente continuasse navegando.

A solução foi mudar a fonte da verdade: a integração parou de confiar na resposta HTTP e passou a sondar ativamente o roteador (até 8 tentativas em 200ms) até confirmar que o MAC Address realmente havia desaparecido das regras ativas.

Lição aprendida: Status 200 significa "eu ouvi seu pedido", não "a tarefa está concluída". Ao integrar hardware ou sistemas externos lentos, o estado real observado é a única prova de sucesso.

Quando o provedor inicial do Redis apresentou instabilidade, tentamos usar a memória local (LocMemCache) e o banco de dados (DatabaseCache) como saídas de emergência para manter o Rate Limiting ativo. Ambas as trocas falharam silenciosamente.

O algoritmo exigia incrementos atômicos e estado distribuído — propriedades que a memória local fragmentava entre os workers e o banco relacional não garantia sem onerar as transações. O Redis teve que voltar como backend definitivo.

Lição aprendida: Substituir uma peça de infraestrutura exige muito mais do que assinar a mesma interface genérica de "Cache". É mandatório garantir que as propriedades físicas (atomicidade, concorrência) das quais o algoritmo depende sejam preservadas.

A primeira versão da integração apresentava erros 404 ocasionais, principalmente no fluxo do Card Payment Brick, e registrava um score de qualidade de integração de aproximadamente 57/100 no Mercado Pago.

O diagnóstico mostrou divergências entre os payloads formatados pela aplicação e os schemas estritos esperados pelo provedor.

A integração foi refatorada para normalizar os dados, separar explicitamente DDD e telefone, adequar os metadados e tipar corretamente o array de itens. Como resultado, os erros 404 foram eliminados e o score subiu para aproximadamente 85/100.

Lição aprendida: Integrações de terceiros exigem validação rigorosa dos contratos da API e capacidade de investigar além do código da própria aplicação.