Destino Certo Viagens e Entregas: passageiro, motorista e painel admin, no padrão 99/Uber.

Ingestão contínua da localização dos motoristas

Com o motorista online, o app envia a posição GPS a cada 3–5 s (ou a cada 20 m percorridos) via MQTT/WebSocket. O serviço Location descarta pontos impossíveis (salto de velocidade, precisão ruim, GPS falso) e grava:

• GEOADD drivers:{cidade}:{categoria} no Redis: posição atual
• Índice H3 res 8 → set de driver_ids para buscar por células hexagonais vizinhas
• driver:{id}:state com disponibilidade, categoria, se aceita dinheiro, horário do último ping (expira em 30 s; sem ping = offline)
• Evento em Kafka para guardar o trajeto e alimentar o preço dinâmico

Passageiro define origem, destino e paradas

Autocomplete (Places com session token) e geocodificação reversa da posição atual. A origem é ajustada para o ponto de embarque mais próximo (uma via, não o meio de um quarteirão). As paradas entram como waypoints.

Cotação (Pricing Service)

• Chama Routes API computeRoutes com trânsito e waypoints → distância (km) e duração (min). Cache por par origem/destino arredondado a cerca de 100 m, por alguns minutos.
• Para cada categoria: tarifa = max(mínima, (base + km·R$km + min·R$min + paradas) × dinâmico) − cupom
• O multiplicador dinâmico vem da célula H3 da origem: razão entre pedidos e motoristas livres nos últimos 5 min, suavizada e limitada ao teto do admin.
• Tempo até o embarque por categoria: estimado pelos motoristas livres mais próximos no índice H3.
• Devolve um quote_token assinado (HMAC) com preço, rota, categoria e validade de 3–5 min. O backend nunca confia em preço enviado pelo app.

Confirmação do pedido

• O app envia POST /trips com o quote_token e uma chave de idempotência (toque duplo não cria duas corridas).
• Verificações: token válido, passageiro sem bloqueio, sem corrida ativa, selfie em dia se exigida.
• Pagamento: cartão → pré-autorização do valor + margem de segurança; Pix pré-pago → gera a cobrança e só despacha após o webhook de pago; carteira → reserva o saldo; dinheiro → só marca a corrida.
• A corrida é criada como REQUESTED → SEARCHING e o evento trip.requested é publicado.

Busca de candidatos (Dispatch Service)

• Busca em anéis H3 ao redor da origem, do mais próximo ao mais distante (k = 1, 2, 3…), até achar pelo menos N candidatos (ex.: 15) ou atingir o raio máximo da categoria (ex.: 3 km para carro, 2 km para moto).
• Filtros: online e livre, categoria compatível, documentos válidos, selfie do dia aprovada, aceita a forma de pagamento, não recusou esta corrida, não bloqueado pelo passageiro, filtro de destino respeitado.
• Pré-ranking barato: distância em linha reta (Haversine) para ficar com os 10 melhores.
• Tempo real de chegada: uma única chamada computeRouteMatrix (10 origens × 1 destino), ou o OSRM próprio para economizar.

Pontuação e escolha

O tempo até o passageiro pesa mais, mas não decide sozinho. A nota equilibra eficiência, qualidade e justiça entre motoristas:

score = 0.60·norm(ETA)              // menor tempo de chegada = melhor
      + 0.15·(1 − taxa_aceitação)  // favorece quem costuma aceitar
      + 0.10·norm(5 − avaliação)
      − 0.10·norm(tempo_ocioso)     // justiça: quem espera há mais tempo
      − 0.15·favorito              // bônus "Motorista Favorito"
// menor score vence · pesos configuráveis no admin e testados via A/B

Em pico, o modo batch matching junta os pedidos de uma janela de 2 s e resolve todos ao mesmo tempo (algoritmo Húngaro, que minimiza o tempo total de chegada da cidade). Isso evita que um pedido "roube" o único motorista próximo de outro.

Oferta com trava exclusiva

• SET offer_lock:{driver_id} {trip_id} NX EX 17: o motorista recebe uma oferta por vez, e a trava expira sozinha.
• A oferta segue pelo WebSocket. Push de alta prioridade (FCM/APNs) como reserva caso o app esteja em segundo plano.
• Contagem regressiva de 15 s. Recusa ou tempo esgotado → próximo candidato da lista. A recusa conta na taxa de aceitação.
• Sem candidatos → amplia o raio. Depois de cerca de 3 min ou N tentativas → NO_DRIVERS: libera a pré-autorização e avisa o passageiro.

Aceite atômico

Transição feita no banco com controle de concorrência. Garante que só um motorista fique com a corrida, mesmo com aceites simultâneos ou o passageiro cancelando no mesmo segundo:

UPDATE trips SET status='ACCEPTED', driver_id=$1, accepted_at=now(), version=version+1
WHERE id=$2 AND status IN ('SEARCHING','OFFERED') AND version=$3
RETURNING *;   -- 0 linhas = já foi aceita/cancelada → responde 409 ao app

Depois: marca o motorista como ocupado, libera a trava, avisa o passageiro (dados do motorista, placa, PIN, tempo de chegada) e abre o canal de chat e de acompanhamento.

Execução, finalização e liquidação

• A posição do motorista é retransmitida ao passageiro e ao link de compartilhamento (com limite de frequência). O tempo de chegada é recalculado a cada ~30 s.
• Com "Cheguei", começa o tempo de espera grátis. O PIN do passageiro inicia a corrida (IN_PROGRESS).
• O Safety monitora desvio de rota (distância até a polyline acima de X m) e paradas acima de N min, e pergunta ao passageiro se está tudo bem.
• Na finalização, o trajeto real é ajustado às vias (map matching). O preço cotado é mantido, salvo mudança de destino ou paradas, ou desvio acima de 20%: aí recalcula pela distância e tempo reais.
• Pagamento: cartão captura o valor, carteira debita, Pix confirma, dinheiro gera débito da comissão na conta do motorista.
• Ledger de partidas dobradas: débito do passageiro → crédito do motorista (líquido) + crédito da receita da plataforma, todos no mesmo trip_id e de forma imutável.
• Avaliações, progresso de metas, recibo por e-mail e eventos para o BI.