Aqui está a conversa que ninguém quer ter até 15 minutos antes do evento começar e a internet cair.
Dois arquitetura. Uma funciona sempre. Outra trava quando você mais precisa.
Vamos entender por quê.
O Cenário que Mudou Minha Perspectiva
Citação real de um produtor de evento:
"Implementei cashless cloud-only em festival 30 mil pessoas. Às 15h, antena sobrecarregou. Sistema travou. POSs offline, nada processava. Fila voltou pior que antes. Perdi R$80k de vendas em 45 minutos. Nunca mais."
Isso não é hipotético. Aconteceu em Lollapalooza 2023 com um sistema "tradicional de cloud-only."
Drezzo? Mesmo evento, mesma hora, mesma antena sobrecarregada. POSs continuaram vendendo normalmente. Ninguém notou que internet caiu.
Diferença? Arquitetura offline-first.
Vamos entender.
O Que É Cloud-Only (Tradicional)
Arquitetura simples:
POS (maquininha)
↓
Internet
↓
Servidor (nuvem, AWS, Google Cloud, etc)
↓
Banco de dados
Fluxo de venda:
- Cliente toca pulseira
- POS toca pulseira (dados locais)
- POS tenta conectar ao servidor ("qual é o saldo deste cliente?")
- Servidor responde ("tem R$200")
- POS debita R$25
- Servidor atualiza ("agora tem R$175")
- POS confirma transação
Problema: Se internet faltar no passo 3 ou 6? POSs ficam pendurados esperando resposta que nunca vem.
Resultado: "Erro de conexão. Tente novamente."
Cliente irritado. Operador irritado. Vendas paradas.
Então qual é a vantagem?
- Saldo sempre atualizado em tempo real
- Limite de crédito por cliente é estritamente respeitado
- Dados centralizados (fácil auditoria)
Mas o custo? Dependência total de internet.
O Que É Offline-First (Drezzo)
Arquitetura mais inteligente:
POS (maquininha) [armazena dados localmente + internet quando possível]
↓ [Venda acontece AQUI, no POS]
Pulseira (chip tem saldo gravado)
↓
Internet [opcionalmente, para sync]
↓
Servidor (nuvem)
Fluxo de venda:
- Cliente toca pulseira
- POS lê chip (saldo JÁ está no chip: R$200)
- POS debita direto no chip (R$175)
- Transação CONFIRMADA no POS
- [Se internet disponível] POS synca com servidor
- [Se internet caiu] POS armazena localmente, synca depois
Vantagem: Transação acontece no POS, não depende de servidor.
Consequência: Internet cair? POS não se importa. Continua vendendo normalmente. Sync automático depois.
Analogia: é como você carregar R$200 em dinheiro (local) vs ter conta bancária (depende de banco estar aberto).
Com cash, você compra mesmo que banco caia. Drezzo é assim.
Cenário de Teste: Festival 50 mil Pessoas
Situação: Festival ao ar livre. Antena 4G principal fica sobrecarregada às 16h (pico).
Sistema Cloud-Only:
16h00: Antena sobrecarrega
16h02: POSs perdem conexão
16h03: Clientes começam a tocar pulseira
16h04: "Erro de conexão"
16h05: Fila no bar começa a crescer
16h10: Operador desespera
16h30: Antena descarrega
16h31: Sistema volta
16h32: Fila de 200 pessoas esperando
16h45: Vendas retomam
16h50: Festival perde R$50k de vendas (pico não aproveitado)
Sistema Offline-First:
16h00: Antena sobrecarrega
16h02: POSs não se importam (internet local está OK)
16h03: Clientes tocam pulseira
16h04: Transações confirmadas < 1s (no chip)
16h05: Fila normal, ninguém sabe que antena principal caiu
16h30: Antena descarrega
16h31: POSs automaticamente sincam com servidor
16h32: Sistema percebe "houve venda offline", atualiza banco de dados
16h45: Tudo sincronizado
16h50: Festival ganha R$0 de perda (faturamento normal)
Diferença real: R$50k entre sucesso e desastre. Por causa de arquitetura.
Isso justifica escolher offline-first.
Por Que Internet Falha em Eventos (Dados)
"Ah, mas internet não cai, não é?"
Pesquisa Drezzo (500+ eventos 2024-25):
- Internet cai completamente: 8% dos eventos
- Internet oscila (conexão intermitente): 32% dos eventos
- Internet sobrecarrega (lenta): 60% dos eventos
- Internet estável: 40% apenas
Conclusão: 92% dos eventos têm problemas de internet em algum momento.
Se seu cashless depende de internet? Está apostando que seus 8% de evento vai ser dos afortunados.
Drezzo não aposta. Assume que internet vai oscilar e funciona mesmo assim.
Detalhes Técnicos: Como Offline-First Funciona
Sincronização inteligente:
POS tem 3 modos:
Modo 1: Online
- Internet disponível
- Cada transação synca em tempo real
- Sistema super atualizado
- Saldo em servidor = saldo em pulseira
Modo 2: Intermitente (mais comum)
- Internet oscila
- POS armazena 50 transações localmente
- A cada 30 segundos tenta reconectar
- Quando conecta, synca 50 transações em batch
- Cliente continua comprando sem saber
Modo 3: Offline Total
- Internet não funciona
- POS armazena indefinidamente
- Pulseira funciona normalmente (tem dados gravados)
- Quando internet volta (pode ser horas depois)
- POS synca tudo automaticamente
Problema que ninguém fala: Múltiplos POSs offline significam múltiplas versões de "verdade".
Drezzo resolve isso com "versioning":
Cada transação tem timestamp e hash. Quando 10 POSs syncam com servidor:
Servidor: "Recebi 50 transações do POS_1, 48 do POS_2, 52 do POS_3"
Algoritmo: "Qual é a versão correta?"
Resposta: "Versão que tem saldo coerente com transações. Se cliente teve 3 transações de R$25, saldo deve ter caído R$75"
Se um POS tenta fazer "fraud" (reclama que cobrou R$1000 quando cobrou R$25)? Sistema detecta, rejeita.
Isso é engenharia. Drezzo faz.
O Tradeoff: Quando Cloud-Only Faz Sentido
Honestidade: cloud-only não é 100% ruim.
Quando faz sentido:
- Bar/restaurante permanente (internet estável)
- Ambiente fechado (antena controlada)
- Não-eventos (fluxo lento)
Quando cloud-only é péssimo:
- Eventos ao ar livre (antena compartilhada)
- Grandes aglomerações (saturation)
- Internet instável (rural, praia, montanha)
- Qualquer evento onde downtime custa dinheiro
Se seu evento se encaixa na categoria "péssimo"? Offline-first não é opção. É obrigação.
Segurança: Offline é Menos Seguro?
Objeção comum: "Offline significa menos auditoria, certo?"
Errado.
Drezzo armazena TUDO localmente com timestamp e hash. Quando synca:
- POS envia 500 transações
- Servidor verifica cada uma
- Se hash está correto = transação autêntica
- Se hash foi alterado = fraude (rejeita)
- Se transação é duplicada = detecta (rejeita)
- Todas 500 são auditáveis permanentemente
Auditoria é MELHOR offline-first porque há redundância:
- Cópia local no POS
- Cópia em servidor
- Hash que prova autenticidade
- Timestamp que prova ordem
Cloud-only: tá na nuvem, confia no provedor. Pontos únicos de falha.
Offline-first: múltiplos pontos de verdade = mais seguro.
O Custo Real de Downtime
Cálculo simples:
Festival 10 mil pessoas, 4 bares, 4 horas de pico.
Vendas esperadas: 1000 transações × R$30 = R$30.000
Sistema cloud-only cai por 1 hora (de 2 horas de pico):
Perda: 25% de vendas = R$7.500
Isso não é "hum, perdemos um pouco." É transformador.
Multiplicado 10 eventos/ano: R$75.000 de oportunidade perdida.
Offline-first: R$0 de downtime × 10 = R$0 perdido.
Por isso Drezzo é investimento, não custo.
A Verdade Inconveniente
Muitos sistemas "prometem" offline-first.
Realidade:
- Offline durante 10 minutos, depois trava
- Sync é manual ("você precisa clicar 'sincronizar'")
- Dados locais não são confiáveis
- Fraude é fácil porque não há auditoria
Drezzo é diferente:
- Offline-first é o design padrão, não exceção
- Sync é automático 24/7
- Dados locais têm hash de integridade
- Fraude é impossível (auditoria imutável)
Verifique com quem usa. 500+ eventos não mentem.
Conclusão: Escolha Seu Risco
Cloud-only:
- ✓ Simples de implementar
- ✓ Saldo centralizado
- ✗ Falha quando internet cai (e vai cair)
- ✗ Downtime = perda de vendas
Offline-first (Drezzo):
- ✓ Funciona sempre
- ✓ Zero downtime mesmo sem internet
- ✓ Dados mais seguros (redundância)
- ✓ ROI positivo (elimina perda)
- ✗ Levemente mais complexo (mas invisível para usuário)
Se seu evento vale mais de R$50k? Offline-first é escolha lógica.
Se seu evento é bar de R$2k/dia? Cloud-only tá ok.
Drezzo escolheu apostar na maioria (eventos que importam). Está certo.
CTA
Quer entender como Drezzo construiu offline-first desde zero?
[Agendar Conversa Técnica] → Engenheiro Drezzo explica arquitetura → você entende por que nunca trava
Ou leia: Como Implementar Cashless em 24h