Entrevista de diseño de sistemas: Diseña Uber
«Diseña Uber» es una de las consignas de diseño de sistemas más comunes porque toca indexación geoespacial, transmisión de ubicación en tiempo real, emparejamiento y alto rendimiento de escritura, todo a la vez. El entrevistador no busca la arquitectura real de Uber: quiere verte acotar el problema, tomar decisiones defendibles y razonar sobre la escala en voz alta.
Trabájalo en un orden deliberado: aclara los requisitos, estima la escala, esboza las entidades y APIs principales, diseña los datos y la ruta de emparejamiento, y luego analiza los cuellos de botella y los compromisos. La guía a continuación sigue ese orden para que practiques la estructura, no solo la respuesta.
1. Aclarar los requisitos
Separa lo funcional de lo no funcional y fija el alcance antes de diseñar. Los pasajeros solicitan un viaje y ven al conductor acercarse en tiempo real; los conductores se conectan y reciben solicitudes cercanas; el sistema los empareja y sigue el viaje hasta completarlo.
- Funcional: solicitar un viaje, emparejar con un conductor cercano, seguir el viaje en vivo, calcular la tarifa, historial de viajes.
- No funcional: emparejamiento de baja latencia (segundos), alta disponibilidad, actualizaciones de ubicación en tiempo real, consistencia de que un conductor se asigne a exactamente un pasajero.
- Fuera de alcance (dilo explícitamente): el procesamiento interno de pagos, las calificaciones, el ML de tarifa dinámica — menciónalos y pospónlos.
2. Estimar la escala
Las cifras aproximadas justifican decisiones posteriores. Supón ~10 millones de conductores activos diarios que envían un ping de ubicación cada 4 segundos: eso son ~2,5 millones de escrituras por segundo de datos de ubicación, una carga dominada por escritura que descarta de inmediato una tabla relacional ingenua como ruta caliente.
3. Componentes principales y APIs
Esboza los servicios y el flujo de solicitudes. Mantén la ruta de emparejamiento independiente del almacén durable de viajes para que cada uno escale según sus propias características.
- Servicio de ubicación: ingiere los pings de los conductores y mantiene las posiciones actuales en un índice geoespacial en memoria.
- Servicio de emparejamiento: ante una solicitud de viaje, consulta a los conductores en línea cercanos y asigna uno.
- Servicio de viajes: registro durable del ciclo de vida del viaje (solicitado → emparejado → en curso → completado).
- Notificaciones/streaming: envía la posición en vivo del conductor al pasajero (WebSocket/long-poll).
4. Emparejamiento geoespacial: el corazón del problema
Esto es lo que más quiere escuchar el entrevistador. Almacenar lat/long en bruto y recorrerlos es O(n); necesitas un índice espacial. Explica quadtrees o geohashing: dividir el mapa en celdas para que «buscar conductores cerca de este punto» se convierta en una consulta de unas pocas celdas, no en un barrido completo.
El geohashing codifica una región en una cadena corta donde los prefijos compartidos indican proximidad espacial, lo que convierte «cercano» en una consulta por prefijo. Las celdas actuales de los conductores viven en un almacén en memoria (p. ej. Redis) para lecturas rápidas y actualizaciones frecuentes; el tamaño de celda es un compromiso ajustable entre precisión y dispersión de la consulta.
5. Escalabilidad y cuellos de botella
Nombra los puntos de presión y cómo los aliviarías. El flujo de 2,5 millones de escrituras por segundo de ubicación es el dominante.
- Particiona el índice de ubicación geográficamente: los conductores y pasajeros de una ciudad son atendidos por la misma partición, manteniendo el emparejamiento local.
- Absorbe el pico de escritura con un almacén en memoria y escrituras durables asíncronas; no necesitas cada ping en una base de datos durable.
- Garantiza un conductor por pasajero con una asignación atómica (un bloqueo o una actualización condicional) para evitar dobles reservas.
- Usa una cola de mensajes (Kafka) entre la ingesta de ubicación y los consumidores downstream para desacoplar los picos.
6. Compromisos que hay que verbalizar
Cierra nombrando las tensiones que un entrevistador valora: consistencia fuerte frente a eventual (la asignación del conductor debe ser fuerte; mostrar la ubicación puede ser eventual), velocidad en memoria frente a durabilidad, y precisión del tamaño de celda frente a dispersión de la consulta. Decirlo explícitamente es la diferencia entre una respuesta aprobatoria y una respuesta sólida.
Practica el diseño de sistemas de Uber con ayuda en tiempo real
El asistente de entrevistas de diseño de sistemas de Natively puede mantenerte estructurado durante una ronda en vivo, sugiriendo la siguiente dimensión a cubrir y mostrando los compromisos en tiempo real, todo en tu propio dispositivo.
