Projetar uma Plataforma de Pareamento de Corridas em Tempo Real

PLATAFORMA DE CORRESPONDÊNCIA DE VIAGENS EM TEMPO REAL - ARQUITETURA DE BACKEND COMPONENTES PRINCIPAIS E RESPONSABILIDADES 1. Gateway de API e Balanceador de Carga - Ponto de entrada para todas as solicitações do cliente (passageiros e motoristas) - Distribui o tráfego por várias regiões e data centers - Lida com autenticação, limitação de taxa e validação de solicitação - Roteia solicitações para os serviços apropriados com base na cidade e no tipo de solicitação 2. Serviço de Solicitação de Viagem - Aceita solicitações de viagem de passageiros com locais de embarque e destino - Valida os dados da solicitação e calcula a tarifa estimada usando o serviço de precificação - Publica eventos de solicitação de viagem na fila de mensagens - Retorna a confirmação da solicitação com o tempo estimado de embarque e a tarifa para o passageiro - Responsabilidades: validação de solicitação, estimativa de tarifa, persistência de solicitação 3. Serviço de Correspondência de Motoristas - Consome eventos de solicitação de viagem da fila de mensagens - Consulta motoristas disponíveis próximos do índice de localização - Implementa algoritmo de correspondência considerando proximidade do motorista, avaliação e disponibilidade - Transmite ofertas de correspondência para motoristas selecionados com mecanismo de tempo limite - Lida com aceitação/rejeição do motorista e evita reservas duplas - Responsabilidades: pesquisa de proximidade, lógica de correspondência, notificação do motorista 4. Serviço de Localização - Mantém o índice de localização em tempo real de todos os motoristas ativos - Recebe atualizações de localização dos motoristas a cada 3 segundos - Fornece consultas espaciais rápidas para pesquisas de motoristas próximos - Particiona dados por cidade para lidar com distribuição de tráfego desigual - Responsabilidades: indexação de localização, consultas espaciais, rastreamento de disponibilidade do motorista 5. Serviço de Gerenciamento de Viagens - Gerencia o ciclo de vida da viagem, desde a aceitação até a conclusão - Coordena transições de status (solicitada → aceita → chegou → em andamento → concluída) - Transmite atualizações de status para passageiro e motorista - Lida com cancelamento de viagem e casos extremos - Responsabilidades: gerenciamento de estado da viagem, transmissão de status, coordenação de viagem 6. Serviço de Notificação - Envia atualizações em tempo real para passageiros e motoristas via WebSocket ou Server-Sent Events - Lida com notificações push para ofertas de correspondência e mudanças de status - Gerencia a entrega de notificações com lógica de repetição - Responsabilidades: mensagens em tempo real, entrega de notificações, gerenciamento de conexão 7. Serviço de Histórico de Viagens - Armazena registros de viagens concluídas com todos os detalhes relevantes - Fornece consultas de histórico de viagens para passageiros e motoristas - Garante durabilidade dos dados para fins de faturamento - Responsabilidades: persistência de registros de viagem, consultas de histórico, durabilidade dos dados 8. Serviço de Precificação - Calcula tarifas estimadas com base na distância, tempo e precificação dinâmica (surge pricing) - Fornece estimativas de tarifa antes da confirmação da viagem - Lida com precificação dinâmica durante horários de pico - Responsabilidades: cálculo de tarifa, lógica de precificação dinâmica, geração de estimativas 9. Serviço de Disponibilidade do Motorista - Rastreia o status online/offline e a disponibilidade do motorista - Gerencia transições de estado do motorista - Evita a atribuição de motoristas indisponíveis - Responsabilidades: gerenciamento de status do motorista, rastreamento de disponibilidade ARQUITETURA DE FLUXO DE DADOS Fluxo de Solicitação de Viagem para Atribuição: 1. Passageiro envia solicitação via Gateway de API com embarque e destino 2. Serviço de Solicitação de Viagem valida, calcula estimativa de tarifa, armazena solicitação no banco de dados 3. Evento de solicitação publicado no tópico Kafka particionado por cidade 4. Serviço de Correspondência de Motoristas consome evento, consulta Serviço de Localização para motoristas próximos 5. Serviço de Correspondência seleciona os 3-5 melhores motoristas com base na proximidade e avaliação 6. Ofertas de correspondência enviadas aos motoristas selecionados via Serviço de Notificação (WebSocket) 7. Primeiro motorista a aceitar aciona o Serviço de Gerenciamento de Viagens 8. Serviço de Gerenciamento de Viagens bloqueia a disponibilidade do motorista e notifica o passageiro 9. Motoristas restantes recebem notificação de cancelamento 10. Viagem transita para o status "aceita", ambas as partes recebem confirmação Fluxo de Progresso da Viagem: 1. Motorista navega até o local de embarque, envia atualizações de localização a cada 3 segundos 2. Serviço de Localização atualiza a posição do motorista no índice em tempo real 3. Serviço de Gerenciamento de Viagens monitora a proximidade do motorista ao embarque 4. Quando o motorista chega, o status é atualizado para "chegou" e o passageiro é notificado 5. Passageiro entra no veículo, o status da viagem muda para "em andamento" 6. Atualizações de localização periódicas enviadas ao passageiro mostrando a posição do motorista 7. Após a chegada ao destino, o status da viagem muda para "concluída" 8. Registro da viagem persistido no Serviço de Histórico de Viagens para faturamento e análise ARMAZENAMENTO E CONSULTA EFICIENTES DE LOCALIZAÇÃO DE MOTORISTAS Arquitetura do Índice de Localização: - Usar banco de dados geoespacial (por exemplo, Redis com índices geoespaciais ou banco de dados geo especializado) - Particionar o índice de localização por cidade para lidar com distribuição desigual - Cada cidade mantém um conjunto ordenado separado com localizações de motoristas como pares (latitude, longitude) - Armazenar ID do motorista, status de disponibilidade atual e avaliação no índice de localização Estratégia de Consulta: - Implementar pesquisa baseada em raio: encontrar todos os motoristas dentro de N quilômetros do local de embarque - Usar particionamento baseado em geohash para consultas mais rápidas dentro dos limites da cidade - Armazenar em cache zonas acessadas com frequência (hotspots) na memória - Implementar indexação espacial hierárquica para consultas de vários níveis Mecanismo de Atualização: - Motoristas enviam atualizações de localização a cada 3 segundos para o Serviço de Localização - Atualizações em lote e gravadas no índice de localização com latência mínima - Usar cache write-through para garantir consistência - Implementar TTL em entradas de localização (por exemplo, 30 segundos) para remover dados de motorista desatualizados - Atualizações de localização publicadas no fluxo de eventos para rastreamento em tempo real Otimização para Carga de Pico: - Pré-calcular zonas de hotspots durante horários de menor movimento - Manter índices separados para áreas de alta demanda com granularidade mais fina - Usar pesquisa aproximada de vizinhos mais próximos durante cargas de pico extremas - Implementar lote de atualizações de localização para reduzir a pressão de gravação ESCALANDO PARA TRÁFEGO DE PICO E CIDADES HOTSPOT Tratamento de Carga de Pico (25x média durante o deslocamento): - Escala horizontal: implantar instâncias adicionais dos serviços de correspondência e gerenciamento de viagens - Políticas de auto-escala baseadas na profundidade da fila de solicitações e métricas de latência - Balanceador de carga distribui solicitações entre as instâncias de serviço - Fila de mensagens (Kafka) atua como buffer durante picos de tráfego - Implementar enfileiramento de solicitações com prioridade para passageiros premium Estratégia de Cidade Hotspot: - Instâncias de serviço dedicadas para as 5-10 principais cidades por volume de solicitações - Índices de localização separados para cidades de alto tráfego com resolução espacial mais fina - Data centers regionais posicionados perto de grandes cidades para reduzir a latência - Implementar disjuntores (circuit breakers) para evitar falhas em cascata em cidades sobrecarregadas - Alocação dinâmica de recursos: transferir capacidade de cidades de baixo tráfego para cidades de alto tráfego Escalabilidade do Banco de Dados: - Fragmentar bancos de dados de solicitação de viagem e histórico de viagens por cidade e data - Usar réplicas de leitura para consultas de histórico de viagens - Implementar camada de cache (Redis) para dados de viagem acessados com frequência - Armazenamento otimizado para gravação para atualizações de viagem em tempo real Escalabilidade do Serviço de Correspondência: - Particionar o serviço de correspondência por cidade para reduzir a contenção - Implementar cache local de disponibilidade do motorista dentro de cada partição de cidade - Usar estruturas de dados probabilísticas (filtros de Bloom) para eliminar rapidamente motoristas indisponíveis - Lote de solicitações de correspondência para melhorar a taxa de transferência durante os picos CONFIABILIDADE, TOLERÂNCIA A FALHAS E CONSISTÊNCIA DE DADOS Arquitetura de Alta Disponibilidade: - Implantação multirregional com configuração ativa-ativa - Replicar dados críticos entre regiões com consistência eventual - Implementar disjuntores e anteparos (bulkheads) para isolar falhas - Verificações de integridade e failover automático para instâncias de serviço Resiliência a Falhas Regionais: - Replicação de dados entre vários data centers dentro de cada região - Implementar failover entre regiões para serviços críticos - Manter réplicas somente leitura em data center secundário - Durante falha, rotear tráfego para data center íntegro com interrupção mínima - Implementar degradação graciosa: reduzir a precisão da correspondência se o serviço de localização estiver indisponível Estratégia de Consistência de Dados: - Forte consistência para disponibilidade do motorista e atribuição de viagem (evitar reservas duplas) - Consistência eventual para atualizações de localização e histórico de viagens - Usar transações distribuídas com o padrão saga para operações de várias etapas - Implementar chaves de idempotência para lidar com solicitações duplicadas Mecanismos de Tolerância a Falhas: - Fila de mensagens fornece durabilidade para solicitações de viagem e atualizações de status - Implementar lógica de repetição com backoff exponencial para operações com falha - Filas de mensagens mortas (dead letter queues) para mensagens não processáveis - Implementar mecanismos de tempo limite para ofertas de correspondência de motoristas (por exemplo, 30 segundos) - Degradação graciosa: se o serviço de correspondência estiver lento, usar correspondência mais simples baseada em proximidade Durabilidade dos Dados: - Registros de viagem persistidos imediatamente em armazenamento durável (banco de dados + backup) - Implementar write-ahead logging para mudanças de estado críticas - Backups regulares do histórico de viagens para fins de faturamento - Implementar recuperação point-in-time para cenários de perda de dados Monitoramento e Observabilidade: - Rastreamento distribuído para acompanhamento do fluxo de solicitações - Métricas em tempo real para latência, taxa de transferência e taxas de erro - Alertas para violações de SLA e anomalias - Implementar implantações canário para novos recursos PRINCIPAIS COMPROMISSOS E DECISÕES DE PROJETO 1. Consistência Eventual para Atualizações de Localização vs. Forte Consistência para Disponibilidade Compromisso: Atualizações de localização usam consistência eventual (janela de atualização de 3 segundos) para reduzir a carga de gravação e a latência. A disponibilidade do motorista usa forte consistência para evitar reservas duplas. Isso equilibra desempenho com correção. 2. Velocidade de Correspondência vs. Seleção Ótima do Motorista Compromisso: Priorizar a velocidade de correspondência (p95 inferior a 2 segundos) em vez de encontrar o motorista globalmente ótimo. Usar heurísticas baseadas em proximidade em vez de algoritmos de otimização complexos. Aceitar que algumas correspondências podem não ser perfeitas, mas garantir resposta rápida. 3. Correspondência Centralizada vs. Correspondência Distribuída Compromisso: Implementar serviço de correspondência centralizado por cidade para consistência e simplicidade. Evitar correspondência distribuída, que aumentaria a complexidade e a latência. A escala horizontal lida com a carga de pico. 4. Índice de Localização em Tempo Real vs. Lote de Atualizações de Localização Compromisso: Usar índice de localização em tempo real com janela de atualização de 3 segundos em vez de processamento em lote. Fornece melhor precisão de correspondência, mas requer mais infraestrutura. Justificado pelo requisito do produto para rastreamento ao vivo. 5. Correspondência Síncrona vs. Correspondência Assíncrona Compromisso: Usar correspondência assíncrona com fila de mensagens para desacoplar a solicitação de viagem da correspondência do motorista. Melhora a resiliência e permite a escalabilidade independente. Aceitar um pequeno atraso (geralmente <500ms) para melhor estabilidade do sistema. 6. Banco de Dados Geoespacial vs. Banco de Dados de Propósito Geral Compromisso: Usar banco de dados geoespacial especializado (ou Redis com índices geo) para consultas de localização em vez de banco de dados SQL geral. Fornece melhor desempenho para consultas espaciais, mas adiciona complexidade operacional. 7. Estratégia de Cache Compromisso: Implementar cache multinível (em memória para hotspots, Redis para dados regionais) para reduzir a carga do banco de dados. Aceitar consistência eventual para dados em cache. Implementar estratégia de invalidação de cache para atualizações críticas. 8. Consistência de Dados de Faturamento Compromisso: Garantir forte consistência para registros de viagem usados no faturamento. Aceitar maior latência para conclusão da viagem para garantir a durabilidade dos dados. Implementar logs de auditoria para disputas de faturamento. PREMISSAS DE SIMPLIFICAÇÃO 1. O processamento de pagamentos é tratado por um serviço separado (fora do escopo) 2. Autenticação e verificação de motoristas já concluídas 3. Avaliações de passageiros e motoristas são pré-calculadas e atualizadas assincronamente 4. O algoritmo de precificação dinâmica é simples (baseado na proporção solicitação/motorista) 5. Penalidades de cancelamento de viagem tratadas por serviço separado 6. Conformidade regulatória (residência de dados, privacidade) tratada no nível da infraestrutura 7. A correspondência de motoristas considera apenas proximidade e disponibilidade (não tipo de veículo, preferências do passageiro) 8. O tempo estimado de embarque é calculado como distância/velocidade_média + tempo_de_chegada_do_motorista 9. Sem suporte para pooling de viagens ou viagens compartilhadas no projeto inicial 10. Atualizações de localização do motorista assumidas como razoavelmente precisas (sem detecção de spoofing de GPS) RECOMENDAÇÕES DE TECNOLOGIA - Fila de Mensagens: Apache Kafka (particionado por cidade para escalabilidade) - Índice de Localização: Redis com índices geoespaciais ou banco de dados geo especializado - Banco de Dados de Viagens: PostgreSQL com sharding por cidade/data - Histórico de Viagens: Banco de dados de séries temporais ou data warehouse para análise - Notificações em Tempo Real: Servidor WebSocket ou Server-Sent Events - Cache: Redis para cache distribuído - Comunicação de Serviço: gRPC para serviços internos, REST para APIs externas - Monitoramento: Prometheus + Grafana para métricas, ELK para logs - Rastreamento Distribuído: Jaeger ou similar para rastreamento de solicitações Esta arquitetura prioriza baixa latência para operações voltadas ao passageiro, mantendo a consistência dos dados onde ela é mais importante (disponibilidade do motorista e faturamento). O projeto escala horizontalmente para lidar com cargas de pico e mantém a disponibilidade durante falhas regionais por meio de mecanismos de replicação e failover.

## Design de Sistema: Plataforma de Correspondência de Viagens em Tempo Real Este documento descreve a arquitetura de backend para uma plataforma de transporte por aplicativo em tempo real, projetada para corresponder passageiros a motoristas próximos de forma eficiente e confiável. ### 1. Principais Serviços e Componentes * **API Gateway:** O ponto de entrada para todas as solicitações do cliente (aplicativos de passageiro, aplicativos de motorista). Lida com autenticação, limitação de taxa e roteia solicitações para os microsserviços apropriados. * **Serviço de Usuário:** Gerencia perfis de usuário (passageiros e motoristas), autenticação e autorização. * **Serviço de Localização:** Ingesta e armazena atualizações de localização em tempo real de motoristas. Fornece consulta eficiente de motoristas próximos. * **Serviço de Correspondência:** Componente central responsável por encontrar e atribuir motoristas a solicitações de viagem. Consulta o Serviço de Localização para motoristas próximos e gerencia a lógica de correspondência. * **Serviço de Viagem:** Gerencia o ciclo de vida de uma viagem, desde a solicitação até a conclusão. Armazena detalhes da viagem, status, histórico e estimativas de tarifa. * **Serviço de Notificação:** Lida com notificações push em tempo real para passageiros e motoristas para atualizações de status (por exemplo, motorista aceitou, motorista chegou). * **Serviço de Estimativa de Tarifa:** Calcula tarifas estimadas e tempos de chegada com base na distância, tempo, preços específicos da cidade e disponibilidade do motorista. * **Serviço de Geo-fencing:** (Opcional, mas útil) Gerencia limites de cidades e potencialmente zonas dentro das cidades para roteamento e precificação. * **Serviço de Análise/Relatórios:** Processa dados de viagem para inteligência de negócios, relatórios e análise histórica. ### 2. Fluxo de Dados: Solicitação de Viagem até Conclusão da Viagem 1. **Solicitação de Viagem:** Um aplicativo de passageiro envia uma solicitação de viagem (local de partida, destino) para o API Gateway, que a encaminha para o **Serviço de Correspondência**. O **Serviço de Usuário** autentica o passageiro. 2. **Estimativa de Tarifa e ETA:** O **Serviço de Correspondência** (ou um **Serviço de Estimativa de Tarifa** dedicado) consulta o **Serviço de Viagem** (para dados históricos/regras de precificação) e potencialmente o **Serviço de Geo-fencing** para fornecer uma tarifa estimada e tempo de chegada de volta ao aplicativo do passageiro. 3. **Busca de Motorista:** O **Serviço de Correspondência** consulta o **Serviço de Localização** para motoristas disponíveis dentro de um raio predefinido do local de partida do passageiro. 4. **Notificação ao Motorista:** O **Serviço de Correspondência** envia ofertas de viagem para um subconjunto de motoristas próximos por meio do **Serviço de Notificação**. Isso é feito de forma a não sobrecarregar os motoristas e garantir tempos de resposta rápidos. 5. **Aceitação do Motorista:** Um motorista aceita a solicitação por meio de seu aplicativo. Essa solicitação passa pelo API Gateway para o **Serviço de Correspondência**. 6. **Atribuição do Motorista e Prevenção de Reserva Dupla:** O **Serviço de Correspondência** verifica se o motorista ainda está disponível (por exemplo, verificando um bloqueio de curta duração ou status em um cache distribuído). Se disponível, ele atribui o motorista à viagem. Essa atribuição é registrada no **Serviço de Viagem**. O status do motorista é atualizado para 'Em Viagem' no **Serviço de Localização**. 7. **Atualizações de Status da Viagem:** O **Serviço de Viagem** é atualizado com as mudanças de status da viagem (por exemplo, 'Aceita', 'Motorista Chegou', 'Em Andamento'). O **Serviço de Notificação** envia essas atualizações para os aplicativos de passageiro e motorista. 8. **Conclusão da Viagem:** O motorista marca a viagem como concluída. O **Serviço de Viagem** registra os detalhes finais da viagem, calcula a tarifa final (potencialmente usando o **Serviço de Estimativa de Tarifa** como base) e atualiza o status do motorista de volta para 'Disponível' no **Serviço de Localização**. 9. **Histórico de Viagens:** Todos os detalhes da viagem são armazenados de forma durável no **Serviço de Viagem** e são acessíveis por meio de APIs para passageiros e motoristas. ### 3. Armazenamento e Consulta Eficientes de Localização de Motoristas * **Armazenamento de Dados:** Um banco de dados geoespacial especializado ou uma combinação de um banco de dados NoSQL (como Cassandra ou DynamoDB para alta taxa de transferência de gravação) com uma camada de indexação geoespacial (por exemplo, usando GeoHashes ou R-trees). Alternativamente, um grid de dados em memória dedicado com capacidades geoespaciais (como Redis com comandos Geo) para leituras de latência extremamente baixa. * **Indexação:** As localizações dos motoristas são indexadas por GeoHash ou um esquema de particionamento espacial semelhante. Isso permite a consulta eficiente de motoristas dentro de uma caixa delimitadora ou raio. * **Modelo de Dados:** Cada registro de motorista conteria sua localização atual (lat/lon), timestamp da última atualização, status de disponibilidade e potencialmente o ID da viagem atual. * **Consulta:** Quando uma solicitação de viagem chega, o **Serviço de Correspondência** consulta o **Serviço de Localização** para motoristas dentro de um raio do ponto de partida. Essa consulta usa o índice espacial para reduzir rapidamente os candidatos potenciais. * **Atualizações em Tempo Real:** Motoristas enviam atualizações de localização a cada 3 segundos. Essas atualizações são de alto volume e devem ser processadas de forma assíncrona, talvez por meio de uma fila de mensagens (por exemplo, Kafka) antes de serem gravadas no armazenamento de localização. ### 4. Escalabilidade para Tráfego de Pico e Cidades com Alto Movimento * **Arquitetura de Microsserviços:** O desacoplamento de serviços permite a escalabilidade independente. Serviços como **Serviço de Correspondência** e **Serviço de Localização** precisarão escalar horizontalmente na maior parte. * **Processamento Assíncrono:** O uso de filas de mensagens (Kafka, RabbitMQ) para operações não críticas, como atualizações de localização, notificações e processamento de análises, desacopla serviços e suaviza picos de tráfego. * **Fragmentação/Particionamento de Banco de Dados:** Fragmentar os bancos de dados do **Serviço de Localização** e **Serviço de Viagem**. Para localização, a fragmentação por região geográfica (cidade ou prefixo GeoHash) pode ser eficaz. Para viagens, a fragmentação por ID de usuário ou ID de viagem. * **Cache:** Armazenar em cache agressivamente dados acessados com frequência, como disponibilidade de motoristas e status de viagens recentes, em caches distribuídos (por exemplo, Redis, Memcached). * **Balanceamento de Carga:** Usar balanceadores de carga inteligentes em vários níveis (API Gateway, comunicação inter-serviços) para distribuir o tráfego uniformemente. * **Tratamento de Cidades com Alto Movimento:** Implementar políticas de escalabilidade dinâmica. Cidades com maior volume de solicitações podem receber mais recursos. O Geo-fencing pode ajudar a rotear solicitações e gerenciar recursos por cidade. O **Serviço de Correspondência** pode priorizar solicitações de áreas de alta demanda ou ajustar dinamicamente os raios de busca. * **Roteamento Ciente de Geo:** Roteie solicitações para data centers ou clusters geograficamente mais próximos da maioria dos usuários em uma cidade específica para reduzir a latência. ### 5. Confiabilidade, Tolerância a Falhas e Consistência de Dados * **Redundância:** Implantar serviços em várias zonas de disponibilidade e regiões. Usar configurações ativas-ativas ou ativas-passivas multirregionais para serviços críticos. * **Durabilidade de Dados:** Usar bancos de dados com replicação e persistência integradas. Para dados críticos de viagem, considere usar um banco de dados SQL distribuído ou um armazenamento NoSQL altamente disponível com fortes garantias de durabilidade. * **Idempotência:** Projetar APIs para serem idempotentes sempre que possível, especialmente para operações críticas como aceitação de viagem, para lidar com retentativas de forma graciosa. * **Disjuntores e Retentativas:** Implementar disjuntores e mecanismos de retentativa inteligentes entre serviços para evitar falhas em cascata. * **Verificações de Integridade e Monitoramento:** Verificações de integridade abrangentes para todos os serviços e infraestrutura. Sistemas robustos de monitoramento e alerta. * **Consistência de Dados:** * **Consistência Forte:** Necessária para operações críticas como a atribuição de motoristas para evitar reservas duplas. Isso pode ser alcançado usando bloqueios distribuídos (por exemplo, via ZooKeeper ou Redis com Redlock) ou operações atômicas dentro de uma transação distribuída, se o banco de dados suportar. O status de um motorista sendo 'atribuído' deve ser fortemente consistente. * **Consistência Eventual:** Aceitável para atualizações menos críticas, como sincronização de histórico de viagens, estimativa de tarifas (que pode ser recalculada) e atualizações de perfil de usuário. Isso permite maior disponibilidade e desempenho. ### 6. Principais Compromissos * **Consistência vs. Disponibilidade:** Para a atribuição de motoristas, a consistência forte é priorizada para evitar reservas duplas, mesmo que isso signifique um leve aumento na latência ou uma potencial indisponibilidade temporária se o serviço de bloqueio distribuído falhar. Para atualizações de status de viagem ou transmissões de localização de motoristas, a consistência eventual é aceitável para maximizar a disponibilidade e a taxa de transferência. * **Latência vs. Custo/Complexidade:** O uso de bancos de dados geoespaciais em memória ou esquemas de indexação complexos para o **Serviço de Localização** pode alcançar tempos de consulta inferiores a um segundo, mas aumenta a complexidade operacional e o custo. Uma abordagem mais simples pode envolver reindexação periódica ou pesquisas de raio menos precisas, trocando alguma latência por simplicidade. * **Atualizações em Tempo Real vs. Vida Útil da Bateria/Uso de Dados:** O intervalo de atualização de 3 segundos para motoristas é um compromisso entre fornecer dados de localização em tempo real para correspondência e conservar a vida útil da bateria e os dados móveis do motorista. Esse intervalo pode ser ajustado dinamicamente. * **Granularidade do Serviço:** Dividir em muitos microsserviços oferece escalabilidade e implantação independente, mas aumenta a sobrecarga de comunicação inter-serviços e a complexidade. Uma abordagem mais monolítica seria mais simples, mas mais difícil de escalar e manter. **Suposições Simplificadoras:** * O processamento de pagamentos é tratado por um serviço separado, fora do escopo. * O embarque e a verificação de motoristas são tratados por sistemas administrativos separados. * O foco está na lógica central de correspondência e gerenciamento de viagens, não em casos extremos como roteamento complexo ou precificação dinâmica com base em proporções de demanda-oferta em tempo real (embora a arquitetura suporte a adição desses).