System design: Uber — geolocalização e matching em tempo real

Motoristas ativos simultaneamente (pico): 2.000.000
Update de localização: a cada 4 segundos
Location writes/segundo: 2M / 4 = 500.000/s

Cada update: ~200 bytes (lat, lng, heading, speed, timestamp, driver_id)
Bandwidth de ingestão: 500K × 200 bytes = ~100 MB/s

Corridas/dia: 20.000.000
Corridas/segundo: 20M / 86.400 ≈ 230/s (média)
Pico (sexta à noite, chuva): 230 × 10 = ~2.300/s

Cada matching precisa:
  1. Query geoespacial: "motoristas disponíveis num raio de 3km"
  2. Ranking: quem é o melhor match
  3. Notify driver: enviar request
  4. Timeout: esperar aceite (10-15s)
  5. Fallback: se recusar, próximo da lista

Corridas/dia: 20M × ~2 KB metadata = 40 GB/dia
Location history: 500K updates/s × 200 bytes × 86.400s = ~8.6 TB/dia (raw)
  → Geralmente só último ponto é guardado em real-time
  → Histórico é amostrado (1 ponto/30s vs 1/4s) = ~1.4 TB/dia

┌─────────────────────────────────────────────────────────────────────┐
│                   LOCATION INGESTION (contínuo)                       │
├─────────────────────────────────────────────────────────────────────┤
│                                                                       │
│  Driver App ──(cada 4s)──→ Location Service ──→ Geospatial Index     │
│                                    │                                  │
│                                    ▼                                  │
│                            Location History DB                        │
│                                                                       │
└─────────────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────────────┐
│                       RIDE MATCHING                                    │
├─────────────────────────────────────────────────────────────────────┤
│                                                                       │
│  Rider App ──→ Ride Service ──→ Matching Service                     │
│                     │                │                                 │
│                     │                ├──→ Geospatial Index (query)    │
│                     │                ├──→ ETA Service                  │
│                     │                └──→ Pricing Service              │
│                     │                         │                        │
│                     │                         ▼                        │
│                     │              Notify Driver (WebSocket/Push)      │
│                     │                         │                        │
│                     │                    Accept/Reject                 │
│                     ▼                         │                        │
│                  Ride DB ◄────────────────────┘                       │
│                                                                       │
└─────────────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────────────┐
│                     REAL-TIME TRACKING                                 │
├─────────────────────────────────────────────────────────────────────┤
│                                                                       │
│  Rider App ◄──WebSocket──── Tracking Service ◄──── Location Service  │
│                                                                       │
└─────────────────────────────────────────────────────────────────────┘

SELECT * FROM drivers
WHERE status = 'available'
  AND ST_Distance(location, POINT(-23.55, -46.63)) < 3000  -- 3km
ORDER BY ST_Distance(location, POINT(-23.55, -46.63))
LIMIT 10;

(-23.5505, -46.6333) → "6gycfq" (célula de ~1.2km × 0.6km com 6 chars)
(-23.5510, -46.6340) → "6gycfq" (mesma célula! estão próximos)
(-23.5505, -46.5900) → "6gycg5" (célula diferente, mais longe)

1. Calcular geohash do passageiro: "6gycfq"
2. Identificar 8 células vizinhas: "6gycfr", "6gycfp", "6gycfn", ...
3. Buscar motoristas nessas 9 células
4. Filtrar por distância real (distância euclidiana/haversine)
5. Rankear

        [Mundo inteiro]
       /    |    |    \
    [NW]  [NE]  [SW]  [SE]
                  |
          /   |   |   \
        ...  ...  ...  [São Paulo Centro]
                            |
                    /    |    |    \
                 [Pinheiros][Consolação][Bela Vista][Liberdade]

Resoluções H3:
  Res 7: ~5.16 km² (bom pra matching)
  Res 9: ~0.1 km² (bom pra ETA granular)
  Res 12: ~0.003 km² (tracking preciso)

1. Driver reporta (lat, lng)
2. Sistema calcula H3 index na resolução 9: "892a1008003ffff"
3. Armazena: driver_id → h3_cell mapping
4. Rider pede corrida em (lat, lng)
5. Sistema calcula H3 cell do rider + k-ring (vizinhos num raio k)
6. Busca todos drivers nos cells do k-ring
7. Ranking por distância real + ETA

Estrutura: HashMap<H3Cell, Set<DriverID>>

Update (driver moveu):
  1. Remove driver do cell antigo: cells["892a1008003"].remove("drv_123")
  2. Adiciona no cell novo: cells["892a1008007"].add("drv_123")
  
Query (rider quer corrida):
  1. Calcula k-ring de cells: h3.kRing("892a100800f", k=2)
  2. Pra cada cell no ring: retorna drivers disponíveis
  3. Merge + sort por distância

1. Rider solicita corrida
   │
   ▼
2. Query geospatial: candidatos num raio de 3-5km
   (retorna ~20-50 drivers)
   │
   ▼
3. Pra cada candidato, calcula ETA de pickup (ETA Service)
   (filtra: ETA > 15min? descarta)
   │
   ▼
4. Score = weighted_sum(eta_score, rating_score, direction_score, ...)
   │
   ▼
5. Envia request pro driver com maior score
   │
   ├──→ Driver aceita (10-15s pra responder)
   │       → Corrida atribuída ✓
   │
   └──→ Driver recusa ou timeout
           → Próximo da lista (step 5 com #2 do ranking)
           → Repete até 3-5 tentativas
           → Se ninguém aceita: "nenhum motorista disponível"

Riders pedindo: [R1, R2, R3, R4, R5]
Drivers disponíveis: [D1, D2, D3, D4, D5, D6, D7]

Otimização: minimizar ETA total de pickup do batch
  → R1↔D3, R2↔D1, R3↔D7, R4↔D5, R5↔D2

ML Model:
  Input: hora, dia da semana, clima, eventos, dados históricos
  Output: previsão de demanda por cell H3 nos próximos 15 min

Se cell "Aeroporto GRU" vai ter alta demanda em 20min:
  → Notifica motoristas na região: "alta demanda prevista em GRU"

┌──────────────────────────────────────────────────┐
│                  ETA Service                       │
├──────────────────────────────────────────────────┤
│                                                    │
│  1. Route calculation (graph algorithm)           │
│     - Road network como grafo (nós = interseções) │
│     - Dijkstra/A* pra shortest path               │
│                                                    │
│  2. Segment speed estimation                       │
│     - Dados históricos por trecho por hora        │
│     - Dados real-time de motoristas ativos        │
│     - Machine learning pra predição              │
│                                                    │
│  3. Aggregation                                    │
│     - Soma tempo de cada segmento da rota         │
│     - Adiciona overhead (semáforos, conversões)    │
│     - Retorna ETA + confidence interval           │
│                                                    │
└──────────────────────────────────────────────────┘

Nós (nodes): interseções, curvas, mudanças de velocidade
Arestas (edges): segmentos de rua entre dois nós

Cada edge tem:
  - distance_meters: 342
  - speed_limit_kmh: 60
  - current_speed_kmh: 25 (real-time, inferido de GPS dos drivers)
  - road_type: "arterial" | "local" | "highway"
  - weight (tempo): distance / current_speed = 342/25 × 3.6 = ~49s

Driver D1 percorreu segmento S47 em 85 segundos (distância: 500m)
  → Velocidade observada: 500/85 × 3.6 = 21 km/h

Driver D2 percorreu S47 em 90 segundos
  → Velocidade: 20 km/h

Média ponderada recente (últimos 5 min): 20.5 km/h
Velocidade esperada (sem tráfego): 50 km/h
Congestion factor: 50/20.5 = 2.4x mais lento

Cache key: eta:{origin_h3}:{destination_h3}:{time_bucket}
Cache value: {eta_seconds: 480, confidence: 0.85, route_polyline: "..."}
TTL: 2-5 minutos (tráfego muda)

Driver App (cada 4s)
       │
       ▼ (UDP ou HTTP/2 com batching)
  Load Balancer
       │
       ▼
  Location Gateway (stateless, alto throughput)
       │
       ├──→ Geospatial Index (in-memory, real-time)
       │      update: move driver de cell A pra cell B
       │
       ├──→ Kafka topic: "driver-locations"
       │      │
       │      ├──→ Consumer: Location History DB (write-optimized)
       │      ├──→ Consumer: ETA Speed Aggregator
       │      └──→ Consumer: Tracking fanout (riders observando)
       │
       └──→ Redis: last_known_location:{driver_id}
              (pra queries pontuais)

1. Rider abre tela de tracking → conecta WebSocket ao Tracking Service
2. Tracking Service subscribe no Kafka topic filtrado por driver_id
3. A cada location update do driver no Kafka:
   → Tracking Service pusha pro rider via WebSocket
4. Rider vê o ícone do carro se movendo no mapa

Update T=0:  driver em (-23.550, -46.633), speed=30km/h, heading=90°
Update T=4:  driver em (-23.550, -46.630)

Entre T=0 e T=4, client anima o carro se movendo suavemente
usando speed + heading pra estimar posição intermediária

fare = base_fare 
     + (distance_km × per_km_rate)
     + (duration_min × per_min_rate)
     + booking_fee
     - promotions

Exemplo São Paulo (UberX):
  fare = R$3.00 + (8.5 × R$1.20) + (22 × R$0.15) + R$1.50
       = R$3.00 + R$10.20 + R$3.30 + R$1.50
       = R$18.00

Para cada cell H3 (resolução 7), a cada 2 minutos:

  demand = requests_nos_ultimos_5min
  supply = drivers_disponiveis_no_cell
  
  ratio = demand / supply
  
  if ratio > 1.5:
    surge_multiplier = f(ratio)  -- curva configurável
    -- ex: ratio 2.0 → surge 1.5x
    -- ex: ratio 4.0 → surge 2.5x
  else:
    surge_multiplier = 1.0

  fare_final = fare_base × surge_multiplier

CREATE TABLE rides (
    id UUID PRIMARY KEY,
    rider_id UUID NOT NULL,
    driver_id UUID,
    status TEXT NOT NULL,
    -- 'requested','matched','driver_en_route','arrived',
    -- 'in_progress','completed','cancelled'
    
    pickup_lat DECIMAL(9,6),
    pickup_lng DECIMAL(9,6),
    dropoff_lat DECIMAL(9,6),
    dropoff_lng DECIMAL(9,6),
    
    pickup_eta_seconds INT,
    estimated_fare_cents BIGINT,
    actual_fare_cents BIGINT,
    surge_multiplier DECIMAL(3,2),
    
    requested_at TIMESTAMP,
    matched_at TIMESTAMP,
    pickup_at TIMESTAMP,
    dropoff_at TIMESTAMP,
    
    INDEX idx_rider (rider_id, requested_at DESC),
    INDEX idx_driver (driver_id, requested_at DESC),
    INDEX idx_status (status)
);

CREATE TABLE drivers (
    id UUID PRIMARY KEY,
    user_id UUID REFERENCES users(id),
    vehicle_type TEXT,        -- 'economy', 'comfort', 'black'
    license_plate VARCHAR(20),
    status TEXT,              -- 'available', 'busy', 'offline'
    current_ride_id UUID,
    rating DECIMAL(2,1),
    acceptance_rate DECIMAL(3,2),
    
    INDEX idx_status (status)
);

CREATE TABLE location_updates (
    driver_id UUID,
    timestamp TIMESTAMPTZ,
    lat DECIMAL(9,6),
    lng DECIMAL(9,6),
    speed_kmh DECIMAL(5,1),
    heading DECIMAL(5,2),
    accuracy_meters DECIMAL(4,1),
    
    -- TimescaleDB: particiona automaticamente por tempo
    PRIMARY KEY (driver_id, timestamp)
);

-- Retenção: 7 dias raw, depois downsample pra 1 update/30s
SELECT set_chunk_time_interval('location_updates', INTERVAL '1 day');

-- Redis: HashMap por H3 cell
SADD "cell:892a1008003:available" "drv_123" "drv_456" "drv_789"
SADD "cell:892a1008007:available" "drv_012" "drv_345"

-- Quando driver move pra outro cell:
SREM "cell:892a1008003:available" "drv_123"
SADD "cell:892a100800f:available" "drv_123"

-- Query: drivers disponíveis num raio (k-ring):
SUNION "cell:892a1008003:available" "cell:892a1008007:available" "cell:892a100800f:available" ...

1. Matching Service seleciona driver D1 pra rider R1
2. Tenta: UPDATE drivers SET status='busy', current_ride_id='ride_R1' 
         WHERE id='D1' AND status='available'
3. Se affected_rows = 1 → sucesso, driver locked
4. Se affected_rows = 0 → outro matching pegou primeiro → próximo candidato

Demand/min no cell do estádio: 5.000
Supply disponível: 200
Ratio: 25x → surge de 8x? Insustentável.