Waze com bug nos alertas: o que devs aprendem com a arquitetura

Acabei de ler no Sapo.pt que o Waze está com sérios problemas nos alertas de polícia, radares e até no botão Voltar do Android. Como desenvolvedor, isso me chamou atenção não pelo bug em si, mas pelo que ele revela sobre a arquitetura do app e os desafios de manter um sistema de navegação em tempo real funcionando para milhões de usuários simultaneamente. Deixa eu te explicar o que está acontecendo por baixo dos panos — e o que devs podem aprender com isso.

O que realmente está acontecendo com os alertas do Waze

Segundo o Sapo.pt, os usuários estão relatando três problemas distintos: alertas de polícia que somem instantaneamente após serem reportados, avisos de radar com latência de 3 a 4 segundos (o que anula completamente o propósito do alerta), e um bug no Android onde o botão Voltar apenas minimiza o app em vez de fechá-lo. Um usuário no Reddit chegou a dirigir 160 km sem receber nenhum alerta no mapa.

Na minha experiência construindo sistemas com dados geoespaciais, isso não é um bug isolado — é sintoma de degradação em uma das camadas críticas do app. Provavelmente estamos vendo um problema de propagação de eventos, cache inconsistente ou rate limiting mal calibrado no backend. Vou destrinchar cada um.

Por que alertas “somem” do mapa: a questão da propagação de eventos

O Waze funciona com um modelo crowd-sourced: quando você reporta um radar, esse evento precisa ser validado, georreferenciado e propagado para outros motoristas próximos em tempo real. Quando o ícone “nunca aparece no mapa” ou “desaparece instantaneamente”, há três causas prováveis:

• Race condition no broadcast: o evento é processado pelo seu cliente antes de ser confirmado pelo servidor, e a reconciliação subsequente o remove.
• Filtro de duplicatas agressivo: o sistema está descartando seu alerta porque interpretou como duplicata de outro recente, possivelmente por causa de timestamps dessincronizados.
• TTL (time-to-live) muito curto: o alerta é criado com expiração de poucos segundos e morre antes de chegar no seu mapa renderizado.

A latência de 3-4 segundos: problema de WebSocket ou polling?

Um alerta que chega “no momento exato em que você passa pelo radar” não é alerta — é registro histórico. Isso indica que o canal de comunicação em tempo real entre servidor e cliente está com gargalo. A solução do suporte técnico (“limpar cache” ou digitar ##@resetapp) é classicamente o que equipes de suporte recomendam quando o problema real está no servidor, e elas não querem admitir.

Na Prática: como eu arquitetaria um sistema de alertas geoespaciais em tempo real

Deixa eu mostrar como eu faria isso se tivesse que construir um sistema de alertas de trânsito em tempo real com baixo custo e alta confiabilidade. A stack que usaria: Node.js + Redis + WebSocket + PostGIS.

// Servidor: broadcasting de alertas por geofencing
const WebSocket = require('ws');
const Redis = require('ioredis');
const redis = new Redis();

const wss = new WebSocket.Server({ port: 8080 });

// Cada conexão registra o cliente com sua posição atual
const clients = new Map(); // ws -> { lat, lng, lastSeen }

wss.on('connection', (ws) => {
  ws.on('message', async (data) => {
    const msg = JSON.parse(data);
    
    if (msg.type === 'position') {
      // Atualiza posição do cliente
      clients.set(ws, { 
        lat: msg.lat, 
        lng: msg.lng, 
        lastSeen: Date.now() 
      });
      
      // Busca alertas próximos (raio de 5km)
      const alerts = await redis.georadius(
        'alerts:active',
        msg.lng, msg.lat,
        5, 'km'
      );
      
      ws.send(JSON.stringify({ type: 'alerts', data: alerts }));
    }
    
    if (msg.type === 'report') {
      // Valida e persiste o alerta com TTL de 15 minutos
      const alertId = `alert:${Date.now()}:${msg.userId}`;
      await redis.geoadd('alerts:active', msg.lng, msg.lat, alertId);
      await redis.setex(`alert:meta:${alertId}`, 900, JSON.stringify({
        type: msg.alertType, // 'police', 'radar', 'hazard'
        reportedBy: msg.userId,
        confirmed: 0
      }));
      
      // Faz broadcast para clientes na região
      broadcastToRegion(msg.lat, msg.lng, 10, {
        type: 'new_alert',
        alertId,
        alertType: msg.alertType
      });
    }
  });
});

function broadcastToRegion(lat, lng, radiusKm, payload) {
  for (const [ws, pos] of clients.entries()) {
    const distance = haversine(lat, lng, pos.lat, pos.lng);
    if (distance <= radiusKm && ws.readyState === WebSocket.OPEN) {
      ws.send(JSON.stringify(payload));
    }
  }
}

O ponto-chave aqui é separar dois canais: pull (o cliente pergunta pelos alertas próximos ao se mover) e push (o servidor avisa quando há um novo alerta na região). Quando uma dessas vias falha — como claramente está falhando no Waze — o usuário fica no escuro.

O bug do botão Voltar no Android: problema clássico de Activity lifecycle

O terceiro bug relatado é interessante do ponto de vista de desenvolvimento mobile. Após uma atualização, o botão Voltar do Android não fecha mais o Waze — ele apenas minimiza o app. Segundo o Sapo.pt, a Google reconheceu o problema mas não deu prazo para correção.

Na minha experiência com Android nativo, isso geralmente acontece quando devs substituem o comportamento padrão do OnBackPressedCallback sem chamar finish() ou moveTaskToBack(true) corretamente. Provavelmente algum refactor da equipe introduziu um override que está chamando super.onBackPressed() mas o AndroidManifest.xml tem alguma configuração de launchMode que está interferindo.

Um fix rápido que eu aplicaria:

// MainActivity.kt - comportamento correto do botão Voltar
class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        
        onBackPressedDispatcher.addCallback(this, object : OnBackPressedCallback(true) {
            override fun handleOnBackPressed() {
                if (isNavigationInProgress()) {
                    // Minimiza para segundo plano, mantendo a rota ativa
                    moveTaskToBack(true)
                } else {
                    // Comportamento padrão: fecha a activity
                    finish()
                }
            }
        })
    }
}

Comparação: Waze vs Google Maps vs alternativas open source

Quando um app como o Waze apresenta esses problemas, vale considerar alternativas. Mas antes, uma observação: a esmagadora maioria dos problemas reportados são exatamente os que um sistema de navegação proprietário e fechado pode ter — você não consegue inspecionar o código, debugar o problema ou fazer um fork corrigido. Esse é o argumento a favor de alternativas como o Organic Maps ou o OsmAnd.

Para um dev que valoriza controle e auditoria, OsmAnd é a opção mais interessante. Você pode até contribuir com correções diretamente no GitHub deles — algo impossível no Waze.

Erros Comuns que devs cometem em apps de geolocalização

Trabalhando com apps que dependem de geolocalização, vejo os mesmos erros se repetindo. Anota esses aqui porque eles custam caro em produção:

1. Não tratar o "GPS drift": o GPS em túneis e áreas urbanas densas oscila. Filtro de Kalman é seu amigo, não opcional.
2. Confiar em timestamps do cliente: o celular do usuário pode ter o relógio 5 minutos adiantado. Use sempre serverTimestamp.
3. Não implementar debounce em atualizações de posição: enviar a cada 100ms satura a rede e a bateria. Mínimo razoável é 1-2 segundos.
4. Cache de tiles do mapa sem TTL adequado: o usuário vê informações desatualizadas por horas.
5. Não testar com perda de conectividade intermitente: o carro entra e sai de áreas com sinal. O app precisa de fila offline robusta.
6. Tratar alertas como "dados quentes" sem fallback: se o push falhar, o usuário TEM que conseguir puxar os alertas manualmente.

No caso do Waze, eu apostaria que o erro #1 (TTL de alertas) e #6 (sem fallback) são os principais culpados pelos sintomas reportados.

FAQ — Perguntas que devs fazem sobre o Waze e sistemas de navegação

O problema do Waze é só no Android ou afeta iOS também?
Segundo o Sapo.pt, o bug do botão Voltar é específico do Android. Já os alertas que somem e a latência nos radares parecem ser generalizados, atingindo ambas as plataformas. Isso reforça a hipótese de que o problema está no backend, não no app cliente.

Por que limpar o cache às vezes resolve esse tipo de problema?
Porque força o app a re-baixar o estado do servidor, descartando versões locais corrompidas ou stale. É um "reset de pobre" que funciona em 20% dos casos — nos outros 80%, o problema volta em horas.

Como o Waze ganha dinheiro se o app é gratuito?
Publicidade local e dados de tráfego vendidos para prefeituras e empresas de logística. Quando o sistema de alertas falha, o valor do dado despenca — por isso a Google precisa resolver isso com urgência.

Existe API pública do Waze para integrar alertas em outros apps?
Não oficialmente. Existem projetos não-oficiais como o Waze API no GitHub que fazem scraping, mas quebram frequentemente quando o Waze muda algo no app. Para um projeto sério, use TomTom, HERE ou OpenStreetMap.

Vale a pena construir um clone do Waze como projeto pessoal?
Vale, e muito. É um projeto que combina WebSockets, geolocalização, geofencing, mobile development e visualização de dados em mapa. Eu recomendo usar Leaflet no frontend e PostGIS no backend. É um projeto razoavelmente complexo que vai te ensinar mais do que qualquer curso.

Implicações práticas para devs que usam o Waze no dia a dia

Se você, como eu, usa o Waze para ir a meetups, eventos tech ou visitas a clientes, o que fazer enquanto isso não é resolvido? Algumas dicas práticas baseadas no que o suporte sugere e no que eu testei:

• Mantenha o app atualizado — a Google está empurrando correções em releases silenciosos.
• Ative o som dos alertas (não só vibração) — você percebe o delay mais rápido.
• Use o Google Maps como backup, especialmente em rotas desconhecidas.
• Se o bug do botão Voltar te incomoda no Android, use gesto de navegação — não depende do botão.
• Reporte os bugs diretamente pelo app (menu → Ajuda → Reportar problema). Quanto mais reports, mais rápido a correção.

No fim das contas, o caso do Waze é um ótimo lembrete de que até apps de bilhões de dólares com equipes de engenharia gigantes têm problemas. A diferença é que empresas menores não têm o luxo de ter o Reddit inteiro monitorando seus bugs em tempo real. Se você está construindo um app com dependência de dados em tempo real, a lição é clara: invista pesado em observabilidade, fallback e comunicação transparente com o usuário quando algo quebra.

Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.