Diseñar una plataforma de emparejamiento de viajes en tiempo real

PLATAFORMA DE CONEXIÓN DE VIAJES EN TIEMPO REAL - ARQUITECTURA DEL BACKEND COMPONENTES PRINCIPALES Y RESPONSABILIDADES 1. Puerta de enlace API y Balanceador de carga - Punto de entrada para todas las solicitudes del cliente (pasajeros y conductores) - Distribuye el tráfico entre múltiples regiones y centros de datos - Maneja la autenticación, limitación de velocidad y validación de solicitudes - Dirige las solicitudes a los servicios apropiados según la ciudad y el tipo de solicitud 2. Servicio de Solicitud de Viaje - Acepta solicitudes de viaje de pasajeros con ubicaciones de recogida y destino - Valida los datos de la solicitud y calcula la tarifa estimada utilizando el servicio de precios - Publica eventos de solicitud de viaje en la cola de mensajes - Devuelve la confirmación de la solicitud con el tiempo estimado de recogida y la tarifa al pasajero - Responsabilidades: validación de solicitudes, estimación de tarifas, persistencia de solicitudes 3. Servicio de Conexión de Conductores - Consume eventos de solicitud de viaje de la cola de mensajes - Consulta conductores disponibles cercanos del índice de ubicación - Implementa el algoritmo de conexión considerando la proximidad del conductor, la calificación y la disponibilidad - Difunde ofertas de conexión a los conductores seleccionados con mecanismo de tiempo de espera - Maneja la aceptación/rechazo del conductor y previene la doble reserva - Responsabilidades: búsqueda de proximidad, lógica de conexión, notificación al conductor 4. Servicio de Ubicación - Mantiene el índice de ubicación en tiempo real de todos los conductores activos - Recibe actualizaciones de ubicación de los conductores cada 3 segundos - Proporciona consultas espaciales rápidas para búsquedas de conductores cercanos - Particiona los datos por ciudad para manejar la distribución desigual del tráfico - Responsabilidades: indexación de ubicación, consultas espaciales, seguimiento de disponibilidad del conductor 5. Servicio de Gestión de Viajes - Gestiona el ciclo de vida del viaje desde la aceptación hasta la finalización - Coordina las transiciones de estado (solicitado → aceptado → llegado → en curso → completado) - Difunde actualizaciones de estado tanto al pasajero como al conductor - Maneja la cancelación de viajes y casos extremos - Responsabilidades: gestión del estado del viaje, difusión de estado, coordinación de viajes 6. Servicio de Notificaciones - Envía actualizaciones en tiempo real a pasajeros y conductores a través de WebSocket o Server-Sent Events - Maneja notificaciones push para ofertas de conexión y cambios de estado - Gestiona la entrega de notificaciones con lógica de reintento - Responsabilidades: mensajería en tiempo real, entrega de notificaciones, gestión de conexiones 7. Servicio de Historial de Viajes - Almacena registros de viajes completados con todos los detalles relevantes - Proporciona consultas de historial de viajes para pasajeros y conductores - Asegura la durabilidad de los datos para fines de facturación - Responsabilidades: persistencia de registros de viajes, consultas de historial, durabilidad de datos 8. Servicio de Precios - Calcula las tarifas estimadas en función de la distancia, el tiempo y los precios dinámicos - Proporciona estimaciones de tarifas antes de la confirmación del viaje - Maneja los precios dinámicos durante las horas pico - Responsabilidades: cálculo de tarifas, lógica de precios dinámicos, generación de estimaciones 9. Servicio de Disponibilidad del Conductor - Rastrea el estado en línea/fuera de línea y la disponibilidad del conductor - Gestiona las transiciones de estado del conductor - Previene la asignación de conductores no disponibles - Responsabilidades: gestión del estado del conductor, seguimiento de disponibilidad ARQUITECTURA DEL FLUJO DE DATOS Flujo de Solicitud de Viaje a Asignación: 1. El pasajero envía la solicitud a través de la Puerta de enlace API con recogida y destino 2. El Servicio de Solicitud de Viaje valida, calcula la estimación de tarifa, almacena la solicitud en la base de datos 3. El evento de solicitud se publica en el tema de Kafka particionado por ciudad 4. El Servicio de Conexión de Conductores consume el evento, consulta el Servicio de Ubicación para conductores cercanos 5. El Servicio de Conexión selecciona los 3-5 conductores principales según proximidad y calificación 6. Las ofertas de conexión se envían a los conductores seleccionados a través del Servicio de Notificaciones (WebSocket) 7. El primer conductor en aceptar activa el Servicio de Gestión de Viajes 8. El Servicio de Gestión de Viajes bloquea la disponibilidad del conductor y notifica al pasajero 9. Los conductores restantes reciben la notificación de cancelación 10. El viaje transita al estado "aceptado", ambas partes reciben confirmación Flujo de Progreso del Viaje: 1. El conductor se dirige a la ubicación de recogida, envía actualizaciones de ubicación cada 3 segundos 2. El Servicio de Ubicación actualiza la posición del conductor en el índice en tiempo real 3. El Servicio de Gestión de Viajes monitorea la proximidad del conductor a la recogida 4. Cuando el conductor llega, el estado se actualiza a "llegado" y se notifica al pasajero 5. El pasajero entra en el vehículo, el estado del viaje cambia a "en curso" 6. Se envían actualizaciones de ubicación periódicas al pasajero mostrando la posición del conductor 7. Al llegar al destino, el estado del viaje cambia a "completado" 8. El registro del viaje se persiste en el Servicio de Historial de Viajes para facturación y análisis ALMACENAMIENTO Y CONSULTA EFICIENTES DE LA UBICACIÓN DEL CONDUCTOR Arquitectura del Índice de Ubicación: - Utilizar base de datos geoespacial (por ejemplo, Redis con índices geoespaciales o base de datos geoespacial especializada) - Particionar el índice de ubicación por ciudad para manejar la distribución desigual - Cada ciudad mantiene un conjunto ordenado separado con las ubicaciones de los conductores como pares (latitud, longitud) - Almacenar el ID del conductor, el estado de disponibilidad actual y la calificación en el índice de ubicación Estrategia de Consulta: - Implementar búsqueda basada en radio: encontrar todos los conductores dentro de N kilómetros de la ubicación de recogida - Utilizar partición basada en geohash para búsquedas más rápidas dentro de los límites de la ciudad - Almacenar en caché zonas de acceso frecuente (puntos calientes) en memoria - Implementar indexación espacial jerárquica para consultas de varios niveles Mecanismo de Actualización: - Los conductores envían actualizaciones de ubicación cada 3 segundos al Servicio de Ubicación - Las actualizaciones se agrupan y se escriben en el índice de ubicación con latencia mínima - Utilizar caché de escritura directa para garantizar la consistencia - Implementar TTL en las entradas de ubicación (por ejemplo, 30 segundos) para eliminar datos de conductor obsoletos - Las actualizaciones de ubicación se publican en el flujo de eventos para el seguimiento en tiempo real Optimización para Carga Pico: - Precalcular zonas de puntos calientes durante las horas de menor actividad - Mantener índices separados para áreas de alta demanda con granularidad más fina - Utilizar búsqueda de vecinos más cercanos aproximada durante cargas pico extremas - Implementar agrupación de actualizaciones de ubicación para reducir la presión de escritura ESCALADO PARA TRÁFICO PICO Y CIUDADES CON PUNTOS CALIENTES Gestión de Carga Pico (25 veces el promedio durante las horas pico): - Escalado horizontal: desplegar instancias adicionales de los servicios de conexión y gestión de viajes - Políticas de autoescalado basadas en la profundidad de la cola de solicitudes y las métricas de latencia - El balanceador de carga distribuye las solicitudes entre las instancias del servicio - La cola de mensajes (Kafka) actúa como búfer durante los picos de tráfico - Implementar cola de solicitudes con prioridad para pasajeros premium Estrategia de Ciudad con Puntos Calientes: - Instancias de servicio dedicadas para las 5-10 ciudades principales por volumen de solicitudes - Índices de ubicación separados para ciudades de alto tráfico con resolución espacial más fina - Centros de datos regionales ubicados cerca de las principales ciudades para reducir la latencia - Implementar disyuntores para prevenir fallos en cascada en ciudades sobrecargadas - Asignación dinámica de recursos: transferir capacidad de ciudades de bajo tráfico a ciudades de alto tráfico Escalado de Bases de Datos: - Fragmentar las bases de datos de solicitudes de viaje y de historial de viajes por ciudad y fecha - Utilizar réplicas de lectura para consultas de historial de viajes - Implementar capa de caché (Redis) para datos de viaje de acceso frecuente - Almacenamiento optimizado para escritura para actualizaciones de viaje en tiempo real Escalado del Servicio de Conexión: - Particionar el servicio de conexión por ciudad para reducir la contención - Implementar caché local de disponibilidad del conductor dentro de cada partición de ciudad - Utilizar estructuras de datos probabilísticas (filtros de Bloom) para eliminar rápidamente conductores no disponibles - Agrupar solicitudes de conexión para mejorar el rendimiento durante los picos FIABILIDAD, TOLERANCIA A FALLOS Y CONSISTENCIA DE DATOS Arquitectura de Alta Disponibilidad: - Despliegue multirregional con configuración activa-activa - Replicar datos críticos entre regiones con consistencia eventual - Implementar disyuntores y mamparos para aislar fallos - Comprobaciones de estado y conmutación por error automática para instancias de servicio Resiliencia ante Interrupciones Regionales: - Replicación de datos entre múltiples centros de datos dentro de cada región - Implementar conmutación por error entre regiones para servicios críticos - Mantener réplicas de solo lectura en el centro de datos secundario - Durante una interrupción, dirigir el tráfico al centro de datos saludable con interrupción mínima - Implementar degradación elegante: reducir la precisión de la conexión si el servicio de ubicación no está disponible Estrategia de Consistencia de Datos: - Fuerte consistencia para la disponibilidad del conductor y la asignación de viajes (prevenir doble reserva) - Consistencia eventual para actualizaciones de ubicación e historial de viajes - Utilizar transacciones distribuidas con el patrón saga para operaciones de varios pasos - Implementar claves de idempotencia para manejar solicitudes duplicadas Mecanismos de Tolerancia a Fallos: - La cola de mensajes proporciona durabilidad para solicitudes de viaje y actualizaciones de estado - Implementar lógica de reintento con retroceso exponencial para operaciones fallidas - Colas de mensajes fallidos para mensajes no procesables - Implementar mecanismos de tiempo de espera para ofertas de conexión de conductores (por ejemplo, 30 segundos) - Degradación elegante: si el servicio de conexión es lento, usar una conexión más simple basada en proximidad Durabilidad de Datos: - Los registros de viajes se persisten inmediatamente en almacenamiento duradero (base de datos + copia de seguridad) - Implementar registro de escritura anticipada para cambios de estado críticos - Copias de seguridad regulares del historial de viajes para fines de facturación - Implementar recuperación a un punto en el tiempo para escenarios de pérdida de datos Monitorización y Observabilidad: - Trazado distribuido para el seguimiento del flujo de solicitudes - Métricas en tiempo real de latencia, rendimiento y tasas de error - Alertas de violaciones de SLA y anomalías - Implementar despliegues canarios para nuevas funciones COMPENSACIONES CLAVE Y DECISIONES DE DISEÑO 1. Consistencia Eventual para Actualizaciones de Ubicación vs. Fuerte Consistencia para Disponibilidad Compensación: Las actualizaciones de ubicación utilizan consistencia eventual (ventana de actualización de 3 segundos) para reducir la carga de escritura y la latencia. La disponibilidad del conductor utiliza fuerte consistencia para prevenir la doble reserva. Esto equilibra el rendimiento con la corrección. 2. Velocidad de Conexión vs. Selección Óptima del Conductor Compensación: Priorizar la velocidad de conexión (p95 inferior a 2 segundos) sobre la búsqueda del conductor óptimo a nivel global. Utilizar heurísticas basadas en proximidad en lugar de algoritmos de optimización complejos. Aceptar que algunas conexiones no serán perfectas, pero asegurar una respuesta rápida. 3. Conexión Centralizada vs. Conexión Distribuida Compensación: Implementar un servicio de conexión centralizado por ciudad para consistencia y simplicidad. Evitar la conexión distribuida, que aumentaría la complejidad y la latencia. El escalado horizontal maneja la carga pico. 4. Índice de Ubicación en Tiempo Real vs. Actualizaciones de Ubicación Agrupadas Compensación: Utilizar un índice de ubicación en tiempo real con una ventana de actualización de 3 segundos en lugar de procesamiento agrupado. Proporciona una mejor precisión de conexión, pero requiere más infraestructura. Justificado por el requisito del producto de seguimiento en vivo. 5. Conexión Síncrona vs. Conexión Asíncrona Compensación: Utilizar conexión asíncrona con cola de mensajes para desacoplar la solicitud de viaje de la conexión del conductor. Mejora la resiliencia y permite escalar de forma independiente. Aceptar un ligero retraso (típicamente <500 ms) para una mejor estabilidad del sistema. 6. Base de Datos Geoespacial vs. Base de Datos de Propósito General Compensación: Utilizar una base de datos geoespacial especializada (o Redis con índices geo) para consultas de ubicación en lugar de una base de datos SQL general. Proporciona un mejor rendimiento para consultas espaciales, pero añade complejidad operativa. 7. Estrategia de Caché Compensación: Implementar caché multinivel (en memoria para puntos calientes, Redis para datos regionales) para reducir la carga de la base de datos. Aceptar consistencia eventual para datos cacheados. Implementar estrategia de invalidación de caché para actualizaciones críticas. 8. Consistencia de Datos de Facturación Compensación: Asegurar una fuerte consistencia para los registros de viajes utilizados en la facturación. Aceptar una mayor latencia para la finalización del viaje para garantizar la durabilidad de los datos. Implementar registros de auditoría para disputas de facturación. ASUNCIONES DE SIMPLIFICACIÓN 1. El procesamiento de pagos es manejado por un servicio separado (fuera del alcance) 2. La autenticación y verificación del conductor ya se han completado 3. Las calificaciones de pasajeros y conductores se precalculan y actualizan asincrónicamente 4. El algoritmo de precios dinámicos es simple (basado en la relación solicitud/conductor) 5. Las penalizaciones por cancelación de viaje son manejadas por un servicio separado 6. El cumplimiento normativo (residencia de datos, privacidad) se maneja a nivel de infraestructura 7. La conexión de conductores considera solo proximidad y disponibilidad (no tipo de vehículo, preferencias del pasajero) 8. El tiempo estimado de recogida se calcula como distancia/velocidad_promedio + tiempo_llegada_conductor 9. No hay soporte para viajes compartidos o colectivos en el diseño inicial 10. Se asume que las actualizaciones de ubicación del conductor son razonablemente precisas (sin detección de suplantación de GPS) RECOMENDACIONES TECNOLÓGICAS - Cola de Mensajes: Apache Kafka (particionada por ciudad para escalabilidad) - Índice de Ubicación: Redis con índices geoespaciales o base de datos geoespacial especializada - Base de Datos de Viajes: PostgreSQL con fragmentación por ciudad/fecha - Historial de Viajes: Base de datos de series temporales o almacén de datos para análisis - Notificaciones en Tiempo Real: Servidor WebSocket o Server-Sent Events - Caché: Redis para caché distribuida - Comunicación de Servicios: gRPC para servicios internos, REST para APIs externas - Monitorización: Prometheus + Grafana para métricas, ELK para registro - Trazado Distribuido: Jaeger o similar para trazado de solicitudes Esta arquitectura prioriza la baja latencia para las operaciones dirigidas al pasajero, manteniendo al mismo tiempo la consistencia de los datos donde más importa (disponibilidad del conductor y facturación). El diseño escala horizontalmente para manejar cargas pico y mantiene la disponibilidad durante interrupciones regionales a través de mecanismos de replicación y conmutación por error.

## Diseño del Sistema: Plataforma de Coincidencia de Viajes en Tiempo Real Este documento describe la arquitectura backend para una plataforma de transporte compartido en tiempo real diseñada para emparejar pasajeros con conductores cercanos de manera eficiente y confiable. ### 1. Servicios y Componentes Principales * **API Gateway:** El punto de entrada para todas las solicitudes del cliente (aplicaciones de pasajeros, aplicaciones de conductores). Maneja la autenticación, limitación de velocidad y enruta las solicitudes a los microservicios apropiados. * **Servicio de Usuarios:** Gestiona los perfiles de usuario (pasajeros y conductores), autenticación y autorización. * **Servicio de Ubicación:** Ingiere y almacena actualizaciones de ubicación en tiempo real de los conductores. Proporciona consultas eficientes de conductores cercanos. * **Servicio de Coincidencia:** Componente central responsable de encontrar y asignar conductores a las solicitudes de viaje. Consulta el Servicio de Ubicación para conductores cercanos y gestiona la lógica de coincidencia. * **Servicio de Viajes:** Gestiona el ciclo de vida de un viaje, desde la solicitud hasta la finalización. Almacena detalles del viaje, estado, historial y estimaciones de tarifas. * **Servicio de Notificaciones:** Maneja notificaciones push en tiempo real a pasajeros y conductores para actualizaciones de estado (por ejemplo, conductor aceptado, conductor llegó). * **Servicio de Estimación de Tarifas:** Calcula las tarifas estimadas y los tiempos de recogida basados en la distancia, el tiempo, los precios específicos de la ciudad y la disponibilidad del conductor. * **Servicio de Geo-cercas:** (Opcional pero útil) Gestiona los límites de la ciudad y potencialmente las zonas dentro de las ciudades para el enrutamiento y la fijación de precios. * **Servicio de Análisis/Informes:** Procesa los datos de los viajes para inteligencia de negocios, informes y análisis históricos. ### 2. Flujo de Datos: Solicitud de Viaje a Finalización del Viaje 1. **Solicitud de Viaje:** Una aplicación de pasajero envía una solicitud de viaje (recogida, destino) al API Gateway, que la reenvía al **Servicio de Coincidencia**. El **Servicio de Usuarios** autentica al pasajero. 2. **Estimación de Tarifa y ETA:** El **Servicio de Coincidencia** (o un **Servicio de Estimación de Tarifas** dedicado) consulta al **Servicio de Viajes** (para datos históricos/reglas de precios) y potencialmente al **Servicio de Geo-cercas** para proporcionar una tarifa estimada y un tiempo de recogida a la aplicación del pasajero. 3. **Búsqueda de Conductores:** El **Servicio de Coincidencia** consulta al **Servicio de Ubicación** para conductores disponibles dentro de un radio predefinido del punto de recogida del pasajero. 4. **Notificación al Conductor:** El **Servicio de Coincidencia** envía ofertas de viaje a un subconjunto de conductores cercanos a través del **Servicio de Notificaciones**. Esto se hace de manera que no abrume a los conductores y garantice tiempos de respuesta rápidos. 5. **Aceptación del Conductor:** Un conductor acepta la solicitud a través de su aplicación. Esta solicitud pasa por el API Gateway al **Servicio de Coincidencia**. 6. **Asignación del Conductor y Prevención de Doble Reserva:** El **Servicio de Coincidencia** verifica que el conductor todavía esté disponible (por ejemplo, verificando un bloqueo de corta duración o un estado en una caché distribuida). Si está disponible, asigna el conductor al viaje. Esta asignación se registra en el **Servicio de Viajes**. El estado del conductor se actualiza a 'En Viaje' en el **Servicio de Ubicación**. 7. **Actualizaciones de Estado del Viaje:** El **Servicio de Viajes** se actualiza con los cambios de estado del viaje (por ejemplo, 'Aceptado', 'Conductor Llegó', 'En Progreso'). El **Servicio de Notificaciones** envía estas actualizaciones a las aplicaciones de pasajeros y conductores. 8. **Finalización del Viaje:** El conductor marca el viaje como completado. El **Servicio de Viajes** registra los detalles finales del viaje, calcula la tarifa final (potencialmente utilizando el **Servicio de Estimación de Tarifas** como referencia) y actualiza el estado del conductor de nuevo a 'Disponible' en el **Servicio de Ubicación**. 9. **Historial de Viajes:** Todos los detalles del viaje se almacenan de forma duradera en el **Servicio de Viajes** y son accesibles a través de APIs para pasajeros y conductores. ### 3. Almacenamiento y Consulta Eficiente de la Ubicación del Conductor * **Almacén de Datos:** Una base de datos geoespacial especializada o una combinación de una base de datos NoSQL (como Cassandra o DynamoDB para un alto rendimiento de escritura) con una capa de indexación geoespacial (por ejemplo, usando GeoHashes o R-trees). Alternativamente, una cuadrícula de datos en memoria dedicada con capacidades geoespaciales (como Redis con comandos Geo) para lecturas de latencia extremadamente baja. * **Indexación:** Las ubicaciones de los conductores se indexan por GeoHash o un esquema de partición espacial similar. Esto permite consultas eficientes de conductores dentro de un cuadro delimitador o radio. * **Modelo de Datos:** Cada registro de conductor almacenaría su ubicación actual (lat/lon), la marca de tiempo de la última actualización, el estado de disponibilidad y potencialmente el ID del viaje actual. * **Consultas:** Cuando llega una solicitud de viaje, el **Servicio de Coincidencia** consulta al **Servicio de Ubicación** para conductores dentro de un radio del punto de recogida. Esta consulta utiliza el índice espacial para reducir rápidamente los candidatos potenciales. * **Actualizaciones en Tiempo Real:** Los conductores envían actualizaciones de ubicación cada 3 segundos. Estas actualizaciones son de alto volumen y deben procesarse de forma asíncrona, quizás a través de una cola de mensajes (por ejemplo, Kafka) antes de escribirse en el almacén de ubicación. ### 4. Escalado para Tráfico Pico y Ciudades de Alta Demanda * **Arquitectura de Microservicios:** Desacoplar los servicios permite escalar de forma independiente. Servicios como el **Servicio de Coincidencia** y el **Servicio de Ubicación** necesitarán escalar horizontalmente la mayor parte del tiempo. * **Procesamiento Asíncrono:** El uso de colas de mensajes (Kafka, RabbitMQ) para operaciones no críticas como actualizaciones de ubicación, notificaciones y procesamiento de análisis desacopla los servicios y suaviza los picos de tráfico. * **Fragmentación/Particionamiento de Bases de Datos:** Fragmentar las bases de datos del **Servicio de Ubicación** y del **Servicio de Viajes**. Para la ubicación, la fragmentación por región geográfica (ciudad o prefijo GeoHash) puede ser efectiva. Para los viajes, la fragmentación por ID de usuario o ID de viaje. * **Caché:** Almacenar en caché agresivamente los datos accedidos con frecuencia, como la disponibilidad del conductor y los estados recientes de los viajes, en cachés distribuidas (por ejemplo, Redis, Memcached). * **Balanceo de Carga:** Utilizar balanceadores de carga inteligentes en múltiples niveles (API Gateway, comunicación inter-servicios) para distribuir el tráfico de manera uniforme. * **Manejo de Ciudades de Alta Demanda:** Implementar políticas de escalado dinámico. Las ciudades con mayor volumen de solicitudes pueden recibir más recursos. Las geo-cercas pueden ayudar a enrutar solicitudes y gestionar recursos por ciudad. El **Servicio de Coincidencia** puede priorizar solicitudes de áreas de alta demanda o ajustar dinámicamente los radios de búsqueda. * **Enrutamiento Geográficamente Consciente:** Enrutar las solicitudes a centros de datos o clústeres que estén geográficamente más cerca de la mayoría de los usuarios en una ciudad específica para reducir la latencia. ### 5. Fiabilidad, Tolerancia a Fallos y Consistencia de Datos * **Redundancia:** Desplegar servicios en múltiples zonas de disponibilidad y regiones. Utilizar configuraciones activas-activas o activas-pasivas multirregión para servicios críticos. * **Durabilidad de Datos:** Utilizar bases de datos con replicación y persistencia integradas. Para datos críticos de viajes, considerar el uso de una base de datos SQL distribuida o un almacén NoSQL de alta disponibilidad con fuertes garantías de durabilidad. * **Idempotencia:** Diseñar APIs para que sean idempotentes siempre que sea posible, especialmente para operaciones críticas como la aceptación de viajes, para manejar reintentos de manera elegante. * **Circuit Breakers y Reintentos:** Implementar circuit breakers y mecanismos de reintento inteligentes entre servicios para prevenir fallos en cascada. * **Comprobaciones de Estado y Monitoreo:** Comprobaciones de estado integrales para todos los servicios e infraestructura. Sistemas robustos de monitoreo y alertas. * **Consistencia de Datos:** * **Consistencia Fuerte:** Requerida para operaciones críticas como la asignación de conductores para prevenir doble reserva. Esto se puede lograr utilizando bloqueos distribuidos (por ejemplo, a través de ZooKeeper o Redis con Redlock) u operaciones atómicas dentro de una transacción distribuida si la base de datos lo admite. El estado de un conductor 'asignado' debe ser fuertemente consistente. * **Consistencia Eventual:** Aceptable para actualizaciones menos críticas como la sincronización del historial de viajes, la estimación de tarifas (que se puede recalcular) y las actualizaciones de perfiles de usuario. Esto permite una mayor disponibilidad y rendimiento. ### 6. Compromisos Clave * **Consistencia vs. Disponibilidad:** Para la asignación de conductores, se prioriza la consistencia fuerte para prevenir la doble reserva, incluso si implica un ligero aumento de la latencia o una posible indisponibilidad temporal si falla el servicio de bloqueo distribuido. Para las actualizaciones de estado del viaje o las transmisiones de ubicación del conductor, la consistencia eventual es aceptable para maximizar la disponibilidad y el rendimiento. * **Latencia vs. Costo/Complejidad:** El uso de bases de datos geoespaciales en memoria o esquemas de indexación complejos para el **Servicio de Ubicación** puede lograr tiempos de consulta inferiores a un segundo, pero aumenta la complejidad operativa y el costo. Un enfoque más simple podría implicar reindexaciones periódicas o búsquedas de radio menos precisas, intercambiando algo de latencia por simplicidad. * **Actualizaciones en Tiempo Real vs. Duración de la Batería/Uso de Datos:** El intervalo de actualización de 3 segundos para los conductores es un compromiso entre proporcionar datos de ubicación en tiempo real para la coincidencia y conservar la duración de la batería y los datos móviles del conductor. Este intervalo podría ajustarse dinámicamente. * **Granularidad del Servicio:** Dividir en muchos microservicios ofrece escalabilidad y despliegue independiente, pero aumenta la sobrecarga de comunicación inter-servicios y la complejidad. Un enfoque más monolítico sería más simple pero más difícil de escalar y mantener. **Suposiciones Simplificadoras:** * El procesamiento de pagos es manejado por un servicio separado, fuera del alcance. * La incorporación y verificación de conductores son manejadas por sistemas administrativos separados. * El enfoque está en la lógica central de coincidencia y gestión de viajes, no en casos extremos como el enrutamiento complejo o la fijación de precios dinámica basada en ratios de oferta-demanda en tiempo real (aunque la arquitectura admite la adición de estos).