La Tecnología Detrás de Uber: Datos y Viajes

Cada vez que solicitas un viaje a través de la aplicación de Uber, se desencadena una serie de procesos tecnológicos complejos y fascinantes. Desde el momento en que confirmas tu destino hasta que te subes al vehículo, la aplicación te proporciona información crucial sobre tu conductor y el coche asignado. Pero, ¿cómo gestiona Uber toda esta información a una escala masiva? ¿Qué hay detrás de la fluidez con la que accedes a los detalles de tu viaje? Y más allá de eso, ¿cómo puedes tú, como usuario, acceder a la información que Uber tiene sobre ti?

Este artículo se sumerge en tres aspectos clave: cómo visualizas los detalles de tu viaje en la aplicación, la ingeniería de bases de datos de vanguardia que permite a Uber operar a su escala global, y el proceso para que los usuarios soliciten y descarguen una copia de sus datos personales.

Visualiza los Detalles de tu Viaje al Instante

Una vez que la aplicación de Uber te ha asignado un conductor para tu solicitud de viaje, la información sobre el vehículo y el conductor se comparte de inmediato en tu pantalla. Esta funcionalidad es fundamental para tu seguridad y tranquilidad, permitiéndote identificar correctamente el coche que viene a recogerte.

Para ver estos detalles, simplemente debes tocar la barra que muestra el nombre y la foto del conductor en la parte inferior de la pantalla de tu viaje. Esto desplegará una vista con la siguiente información vital:

• Una fotografía del conductor asignado.
• La marca y el modelo del vehículo.
• El número de la matrícula del vehículo.

Es crucial que, al ver llegar el vehículo a tu ubicación de recogida, confirmes que el número de matrícula que aparece en la aplicación coincide exactamente con el del coche físico. Esta verificación simple es una capa de seguridad importante. Además, los conductores a menudo confirmarán tu nombre antes de iniciar el viaje, añadiendo otra capa de seguridad.

La Potencia de las Bases de Datos de Uber: Docstore y CacheFront

Operar una plataforma como Uber, que maneja millones de viajes y pedidos de comida cada día en todo el mundo, requiere una infraestructura de datos extraordinariamente robusta y escalable. No es sorprendente que Uber no dependa de una única base de datos comercial tradicional, sino que haya desarrollado soluciones internas para satisfacer sus demandas únicas.

La espina dorsal de la infraestructura de datos de Uber es Docstore. Esta es una base de datos distribuida interna construida sobre MySQL. Docstore está diseñada para almacenar petabytes (PBs) de datos y servir decenas de millones de solicitudes por segundo. Es uno de los motores de base de datos más grandes dentro de Uber y es utilizado por microservicios de todas las verticales de negocio, desde los viajes hasta Uber Eats y más allá.

A pesar de estar construida sobre MySQL, una base de datos relacional muy probada, Uber enfrentó desafíos significativos a medida que crecían sus servicios y la complejidad de sus aplicaciones. La mayoría de los microservicios de Uber utilizan bases de datos respaldadas por almacenamiento basado en disco (como las SSDs NVMe que usa Docstore), lo cual es excelente para persistir datos, pero presenta limitaciones para aplicaciones que requieren latencia extremadamente baja y escalabilidad masiva, especialmente en operaciones de lectura.

Los Desafíos de la Escala

Los principales desafíos incluyeron:

• Velocidad de Recuperación del Disco: Existe un límite inherente a la rapidez con la que se pueden recuperar datos del disco. Aunque las SSDs NVMe son rápidas, la demanda de Uber a menudo supera esta capacidad directa.
• Escalado Vertical y Horizontal: Aumentar recursos (escalado vertical) o dividir datos en más particiones (escalado horizontal) son soluciones comunes, pero tienen limitaciones. El motor de base de datos en sí mismo puede convertirse en un cuello de botella, y el escalado horizontal es una operación compleja y lenta.
• Desbalance de Solicitudes: A menudo, la tasa de solicitudes de lectura es mucho mayor que la de escritura. Las bases de datos basadas en disco luchan por mantenerse al día con cargas de lectura muy altas.
• Costo: El escalado constante para mejorar la latencia es costoso, especialmente manteniendo la redundancia necesaria para la alta disponibilidad.

Para mitigar estos problemas, los equipos de microservicios tradicionalmente recurrían al uso de soluciones de caché distribuidas, como Redis. El patrón común era escribir tanto en la base de datos como en la caché, y servir las lecturas desde la caché para obtener respuestas más rápidas. Sin embargo, este enfoque descentralizado creó nuevos desafíos:

• Cada equipo tenía que configurar y mantener su propia caché de Redis.
• La lógica de invalidación de caché se implementaba de forma descentralizada en cada microservicio.
• La recuperación ante fallos regionales era compleja, requiriendo replicación de caché o sufriendo altas latencias mientras la caché se "calentaba" en la región de respaldo.

Esta complejidad descentralizada llevó a Uber a buscar una solución más integrada y eficiente.

CacheFront: La Solución de Caching Integrado

Para abordar los desafíos de rendimiento y escalabilidad, Uber desarrolló CacheFront, una solución de caching integrada directamente en Docstore. El objetivo principal de CacheFront es minimizar la necesidad de escalar la capa de almacenamiento de Docstore para soportar cargas de lectura intensas y de baja latencia.

CacheFront está construida sobre Redis, pero gestionada de forma centralizada dentro de la arquitectura de Docstore. Se integra en la capa del motor de consultas de Docstore, lo que permite desacoplar la caché del almacenamiento basado en disco y escalar ambas capas de forma independiente.

Arquitectura y Estrategias de CacheFront

La arquitectura de Docstore con CacheFront se divide principalmente en:

• Capa de Motor de Consultas (Stateless): Responsable de la planificación de consultas, enrutamiento, gestión de sharding, validación de solicitudes, etc. Aquí es donde se integra CacheFront.
• Capa de Motor de Almacenamiento (Stateful): Compuesta por nodos MySQL con SSDs NVMe, gestiona la persistencia de datos, la replicación (usando Raft) y las transacciones.
• Plano de Control: Gestiona la orquestación general.

CacheFront utiliza una estrategia de "cache-aside". Cuando llega una solicitud de lectura:

1. La capa del motor de consultas intenta obtener los datos de Redis.
2. Si los datos están en la caché ("cache hit"), se devuelven rápidamente al usuario.
3. Si los datos no están en la caché ("cache miss"), la capa de consultas los recupera del motor de almacenamiento (MySQL).
4. Los datos recuperados se devuelven al usuario y, de forma asíncrona, se escriben en la caché de Redis para futuras solicitudes (calentamiento de caché).

Invalidación de Caché y Consistencia

Uno de los mayores desafíos en el caching es la invalidación: asegurarse de que los datos en la caché estén actualizados con la base de datos. CacheFront aborda esto utilizando el servicio de captura de datos cambiados (CDC) de Docstore, llamado Flux. Flux monitorea los eventos del binlog de MySQL y publica estos cambios a consumidores. Un consumidor específico de Flux se encarga de invalidar o actualizar las entradas correspondientes en Redis cuando se producen cambios en la base de datos.

Esto permite que la caché sea consistente con la base de datos en cuestión de segundos, en lugar de depender únicamente del tiempo de vida (TTL) de la caché. Aunque esto proporciona consistencia eventual rápida, para casos de uso que requieren consistencia más fuerte (como "leer tus propias escrituras"), CacheFront ofrece una API explícita para invalidar la caché inmediatamente después de una escritura.

Características Avanzadas para Resiliencia y Escala

Para operar a la escala de Uber, CacheFront incorpora varias características avanzadas:

• Compare Cache: Un modo especial para verificar la consistencia entre la caché y la base de datos, logrando una consistencia superior al 99.99%.
• Cache Warming (Calentamiento de Caché): Para la alta disponibilidad entre regiones geográficas, CacheFront replica las claves de caché (no los valores completos) entre regiones. Cuando hay un fallo regional, la región de respaldo tiene las claves de caché relevantes y "calienta" su caché localmente al servir las primeras solicitudes perdidas, minimizando el impacto en el motor de almacenamiento.
• Negative Caching: Cacha el hecho de que una clave no existe en la base de datos, evitando consultar el motor de almacenamiento repetidamente para datos inexistentes.
• Sharding de Redis: Para manejar cargas extremas, una instancia de Docstore puede mapear a múltiples clústeres de Redis, shardeados por la clave de partición de Docstore. Esto distribuye la carga de caché y evita que la caída de un solo clúster de Redis sobrecargue una única partición de la base de datos.
• Circuit Breakers (Cortocircuitos): Para evitar latencias innecesarias al intentar acceder a nodos de Redis que fallan, se implementan cortocircuitos que redirigen o fallan rápidamente las solicitudes a esos nodos.
• Adaptive Timeouts (Tiempos de Espera Adaptativos): Ajusta dinámicamente los tiempos de espera para las operaciones de Redis basándose en el rendimiento histórico, asegurando que la mayoría de las solicitudes a la caché sean rápidas mientras se cancelan rápidamente las que tardan demasiado, redirigiéndolas a la base de datos.

El resultado de CacheFront ha sido impresionante. Ha mejorado significativamente las latencias de lectura (reduciendo la latencia P75 en un 75% y la P99.9 en más del 67%), ha reducido drásticamente la carga en el motor de almacenamiento de Docstore (permitiendo servir millones de solicitudes con muchos menos recursos de base de datos directos) y ha simplificado el desarrollo al proporcionar una solución de caching gestionada centralmente.

Accede y Descarga tus Datos Personales de Uber

Uber reconoce la importancia de la transparencia y el control del usuario sobre sus datos personales. Por ello, ofrece herramientas para que los usuarios accedan a la información que la plataforma ha recopilado sobre ellos durante el uso de los servicios.

Puedes acceder a estas opciones generalmente a través de la sección de privacidad o seguridad de tu cuenta en la aplicación o el sitio web de Uber.

Hay dos formas principales de interactuar con tus datos:

• Explorar tus Datos: Puedes ver un resumen de la información clave de tu cuenta. Esto puede incluir métricas como la cantidad total de viajes realizados o la cantidad de pedidos completados a través de Uber Eats. Para acceder a este resumen, a menudo se requiere iniciar sesión con verificación de 2 pasos para mayor seguridad.
• Descargar tus Datos: Si necesitas un registro más completo, puedes solicitar un archivo con una copia de tus datos. Una vez que solicitas esta descarga, Uber te notificará (generalmente por correo electrónico o SMS) cuando la solicitud sea recibida y, posteriormente, cuando el archivo con tus datos esté listo para ser descargado. Este archivo contendrá una variedad de información personal asociada a tu cuenta y uso de la plataforma.

Estas opciones te permiten tener visibilidad sobre cómo se utiliza tu información y, si lo deseas, mantener una copia local de tus registros de actividad en la plataforma.

Preguntas Frecuentes sobre los Datos y la Tecnología de Uber

¿Es seguro ver los detalles del conductor y vehículo en la aplicación?

Sí, es seguro. La información proporcionada (nombre, foto, marca/modelo del vehículo, matrícula) es esencial para tu seguridad y para que puedas identificar correctamente el coche asignado. La verificación de la matrícula es una práctica de seguridad recomendada.

¿Qué información del viaje puedo ver en la app?

Una vez asignado el viaje, puedes ver el nombre y foto del conductor, la marca, modelo y número de matrícula del vehículo. También puedes seguir la ubicación del vehículo en el mapa mientras se acerca.

¿Por qué Uber no usa una base de datos comercial estándar?

Dada la escala masiva de operaciones de Uber (millones de transacciones por segundo, petabytes de datos), las bases de datos comerciales estándar, si bien potentes, a menudo no pueden cumplir con los requisitos extremos de latencia, rendimiento y coste-eficiencia a esta escala sin personalizaciones o arquitecturas complejas. Desarrollar soluciones internas como Docstore permite un control total sobre la optimización para sus cargas de trabajo específicas.

¿Qué es exactamente Docstore?

Docstore es la base de datos distribuida interna de Uber. No es una base de datos completamente nueva desde cero, sino que está construida sobre MySQL, añadiendo capas de distribución, sharding, consenso (con Raft) y otras optimizaciones para operar a una escala masiva y con alta disponibilidad.

¿Qué papel juega Redis en la infraestructura de datos de Uber?

Redis es utilizado por Uber como la tecnología subyacente para su capa de caching integrada, CacheFront. Redis es ideal para caching debido a su velocidad (es una base de datos en memoria). CacheFront gestiona Redis de forma inteligente para mejorar las latencias de lectura y reducir la carga en Docstore.

¿Qué es Flux y por qué es importante para CacheFront?

Flux es el servicio de captura de datos cambiados (CDC) de Docstore. Es vital para CacheFront porque le permite invalidar o actualizar las entradas de caché casi en tiempo real (en segundos) cada vez que se produce un cambio en la base de datos MySQL subyacente, asegurando así la consistencia de la caché.

¿Qué tipo de datos puedo descargar de mi cuenta de Uber?

La descarga de datos generalmente incluye información relacionada con tu cuenta (perfil, configuración) y tu historial de uso de los servicios, como detalles de viajes pasados (origen, destino, fecha, hora, coste), historial de pedidos de Uber Eats, interacciones de soporte, etc. El contenido exacto puede variar.

¿Cuánto tiempo tarda en estar lista la descarga de datos?

El tiempo puede variar dependiendo de la cantidad de datos asociados a tu cuenta y la carga en los sistemas de Uber. Generalmente, no es instantáneo y puede tardar algún tiempo en procesarse y preparar el archivo para su descarga. Uber te notificará cuando esté listo.

Conclusión

Ver los detalles de tu próximo viaje en la aplicación de Uber es posible gracias a una infraestructura tecnológica sofisticada. En el corazón de esta infraestructura se encuentra Docstore, una base de datos distribuida construida sobre MySQL, y su innovadora capa de caching integrada, CacheFront, impulsada por Redis y Flux. Esta combinación de tecnologías permite a Uber gestionar eficientemente la inmensa cantidad de datos y solicitudes necesarias para operar a escala global, asegurando al mismo tiempo una experiencia de usuario fluida y rápida.

Además, Uber proporciona a los usuarios las herramientas necesarias para mantener la transparencia sobre sus datos, permitiéndoles explorar resúmenes o descargar una copia completa de su información personal. Entender cómo funciona esta tecnología no solo es interesante, sino que también subraya la complejidad de los sistemas que usamos a diario y el compromiso necesario para gestionarlos a escala.

Si quieres conocer otros artículos parecidos a La Tecnología Detrás de Uber: Datos y Viajes puedes visitar la categoría Tecnología.