Ride-sharing en tiempo real

Cómo aclarar requisitos en la entrevista

Casos de uso típicos. Pico aeroportuario (alta demanda + drivers waiting), evento masivo (concierto, estadio) con surge, madrugada con baja densidad de oferta, ride compartido (Pool/UberX/Black), viaje programado a futuro, ride para alguien más (regalo / corporativo), ride con paradas múltiples, ride en zona con mala señal.

Preguntas que debes hacer:

• ¿Tier único (UberX) o múltiples (Pool, Black, XL, paquetes)? Cambia el matching.
• ¿Soportas viajes programados a futuro? Implica scheduler queue separado.
• ¿Multi-stop en un mismo ride?
• ¿Pagos in-app, efectivo, o ambos? Ojo con flujos cash y reconciliación.
• ¿Surge pricing dinámico o estático?
• ¿Hay cancellation fee, en qué condiciones?
• ¿Drivers full-time o gig? Cambia incentivos y SLA.
• ¿Ride compartido con detour máximo permitido?
• ¿Cobertura geográfica: una ciudad, país, global multi-region?

Frase clave: "Voy a asumir UberX único, pago in-app, una ciudad. Si me pides multi-tier o multi-stop, lo agrego como extensión al final."

Cómo defiendo estas APIs en la entrevista

REST + WebSocket es la combinación correcta. Para acciones discretas con state transitions (crear ride, accept, cancel) uso HTTP REST porque me da idempotencia, retry semantics y status codes claros. Para flujos continuos (location updates del driver, ride offers, tracking en vivo) uso WebSocket porque mantiene una conexión persistente y evita la sobrecarga de re-handshake.

Idempotencia donde duele. POST /rides exige Idempotency-Key — sin esto, un timeout en el cliente puede cobrarte dos rides. POST /rides/{id}/accept es naturalmente idempotente (si ya aceptaste, devuelvo 200 con el estado actual; si otro driver ya aceptó, devuelvo 409 Conflict).

Status codes que importan. 201 al crear ride, 202 si el match es async, 409 en doble accept, 410 Gone si el ride expiró, 429 con Retry-After si rate limit.

Frase clave: "Las APIs siguen state machine del ride: pending → matched → in_progress → completed. Cada transición es una operación HTTP idempotente; las posiciones y notificaciones van por el canal WS persistente."

Cómo lo explico en la entrevista

Driver online. El driver abre la app y se conecta por WebSocket al Gateway con sticky session. Cada 3–5 s envía su posición; el Location Service hace GEOADD geo:drivers:{city} con TTL 30 s. Si deja de reportar, "desaparece" del índice, así nunca matcheo a un driver fantasma.

Rider pide viaje. El rider hace POST /api/rides con Idempotency-Key. El Ride Service crea la fila en Postgres en estado pending y emite un evento al stream. El Matcher consume el evento, llama GEORADIUS en Redis para los N drivers más cercanos, los rankea por ETA y reputación, y publica un RIDE_OFFER a cada candidato por Pub/Sub que cae al WebSocket del driver.

Accept atómico. Cuando el primer driver toca aceptar, hace POST /rides/{id}/accept. Aquí está la parte crítica: SETNX lock:ride:{id} driver_id con TTL 30 s. El primero gana, los demás reciben 409. Confirmo a ambos por WebSocket. Esto evita doble assignment sin necesidad de transacciones distribuidas.

Frase clave: trato la posición como estado en memoria con TTL en Redis GEO, la transición de estados del ride como SQL transaccional, y el matching como un servicio de eventos. Cada componente hace lo que mejor sabe hacer.

Cómo defiendo este diseño de base de datos

Tres datos, tres herramientas. Postgres para entidades estables (rides, drivers, vehicles) con foreign keys y ACID — el state machine del ride no admite errores. Redis GEO para posiciones (alta frecuencia, TTL natural, primitivas geoespaciales nativas) — un Postgres con PostGIS no aguanta 250K updates/s. Kafka para eventos del ride (downstream consumers: payment, rating, analytics).

Particionado por ciudad. Drivers, rides, geo set — todo particionado por city. El matching siempre ocurre dentro de una ciudad; cross-city no existe. Esto da scale lineal: agrega una ciudad, agrega capacidad, sin coordinar globalmente.

Índices y types específicos. En rides: (rider_id, created_at DESC) para "mis rides recientes", (driver_id, status) para "rides activos del driver". Tipo GEOGRAPHY para pickup/dropoff aprovecha PostGIS para queries de área. Redis sorted set geo:drivers:{city} hace GEOADD y GEORADIUS en O(log N).

Frase clave: "El ciclo de vida del ride vive en Postgres porque ACID; las posiciones en Redis porque latencia y TTL; los eventos en Kafka porque desacople. Cada decisión está justificada por el patrón de acceso."

Cómo defiendo estas decisiones técnicas

Cada decisión está atada a un constraint. Match < 5 s p95 → broadcast paralelo + push (no espero a que el primero responda). Strong consistency en accept → SETNX atómico, no 2PC distribuido. 250K location updates/s → WebSocket con pseudo-binary protocol, no HTTP. 1M conexiones concurrentes → sticky LB con scaling horizontal.

Tradeoffs explícitos. Geohash da partition natural pero zonas calientes saturan un bucket — tradeoff aceptado a cambio de simplicidad operativa. WebSocket sticky requiere migration cuando un pod falla, pero la complejidad de stateless con state externo es peor. Push providers externos agregan dependencia, pero son la única forma de despertar app cerrada.

Métricas que validan cada decisión. Tiempo desde request → match (target p95 < 5 s). Tasa de doble-accept (debe ser 0; alerta a > 0.01%). Stale location rate (drivers que parecen disponibles pero no responden — alerta a > 5%). Push delivery rate (target > 95%). WebSocket reconnection storm tras deploy.

Cuándo cambio de opinión. Si el SLA es match < 1 s → pre-asigno pool de drivers a zonas calientes. Si voy multi-region active-active → S2 cells en lugar de geohash, con consensus para cross-region drivers. Si caigo en alta contención de accept → uso lease + handoff explícito en lugar de SETNX puro.

Frase clave: "Cada decisión balanced contra un trade. Sticky LB cuesta complejidad de failover pero gana en latencia. Geohash cuesta hot regions pero gana en simplicidad. Un sistema sin tradeoffs explícitos es un sistema sin defensa en la entrevista."

Cómo defenderlo en la entrevista

El truco con GPS traces. Cada ride genera ~100 KB de location updates (lat/lng cada 3–5 s × 15 min). A 5M rides/día son ~500 GB/día. Mantenerlas en SSD es muy caro. Las muevo a S3 IA tras 30 días y a Glacier tras 1 año.

Lifecycle automático. S3 lifecycle rule por prefijo: rides/2024/ → IA tras 90 días → Glacier tras 365 días. Postgres parte solo orders < 90 días; archive tablespace con foreign data wrappers a S3.

Frase clave: "Las posiciones live cuestan caro en RAM pero son sub-ms; rides recientes en SSD por ACID; historiales en S3 IA por compliance; archive en Glacier porque solo el regulador o un investigador los toca."

API Gateway vs Load Balancer: cómo defender cada uno

El WebSocket cambia las reglas. Necesito sticky sessions porque el state del ride/driver vive en memoria del pod. Tanto API Gateway como L7 LB pueden hacer sticky, pero L4 NLB tiene menor latencia y mayor throughput. Para 250K location updates/s, los ~10 ms extra del Gateway compounded son costosos.

Frase clave: "Para ride-sharing me inclino por NLB: el WebSocket de los drivers tiene 1M conexiones concurrentes y location updates a 250K/s; un API Gateway agrega latencia y costo por evento que no necesito. Auth lo hago con JWT verificado en el pod (verificación local con public key, no llamada externa)."