Diseño de Sistema de Reserva de Entradas

Arquitectura de un Sistema de Reserva de Entradas: Desde la API hasta la Escalabilidad

Un sistema de reserva de entradas debe permitir la navegación por eventos, búsquedas basadas en parámetros y reservas fiables sin ventas dobles. Se centra en la disponibilidad de datos para lecturas y consistencia estricta para escrituras. Carga esperada: hasta 10 millones de usuarios para un evento popular, latencia de búsqueda inferior a 500 ms, proporción lectura/escritura de 100:1.

Entidades clave: Evento (con fecha, descripción, tipo), Usuario, Artista, Lugar (con mapa de asientos), Entrada (con asiento, precio, estado), Reserva (con lista de entradas y estado).

Diseño de Endpoints de la API

La API se construye en torno a tres funciones prioritarias. Comienza con endpoints simples, refinando a medida que avanza el diseño.

Ver evento:

GET /events/:id -> Evento & Lugar & Artista & Entrada[]

Devuelve detalles del evento, lugar, artista y lista de entradas para renderizar el mapa de asientos en el cliente.

Búsqueda:

GET /events/search?keyword={palabra_clave}&start={fecha_inicio}&end={fecha_fin}&pageSize={tamaño_página}&page={número_página} -> Evento[]

Filtra por palabras clave, fechas, paginación para alto rendimiento.

Reserva (versión inicial):

POST /bookings/:eventId -> bookingId
{
  "ticketIds": string[],
  "paymentDetails": ...
}

Posteriormente se divide en reserva y confirmación para fiabilidad transaccional.

Arquitectura de Alto Nivel

Componentes del Sistema

• API Gateway: enrutamiento, autenticación, limitación de tasa, registro.
• Servicio de Eventos: lectura de datos de eventos, lugares, artistas desde la BD.
• Servicio de Búsqueda: manejo de consultas de búsqueda con filtrado.
• Servicio de Reservas: gestión de reservas con transacciones.
• Bases de datos: PostgreSQL para transacciones ACID (Reservas, Entradas), NoSQL o caché para lecturas (Eventos, Lugares).

Flujo de visualización: cliente → Gateway → Servicio de Eventos → BD → respuesta con mapa de asientos.

Escalabilidad bajo Carga

Para 10 millones de usuarios activos diarios por evento, usar:

• Caché: Redis para lecturas frecuentes (eventos, búsqueda).
• Fragmentación: por eventId en Entradas/Reservas.
• CQRS: separación de lecturas (réplicas de lectura) y escrituras (maestra).
• Balanceador de Carga: distribución del tráfico entre servicios.

La proporción 100:1 lectura/escritura dicta prioridad en réplicas de lectura y CDN para datos estáticos (mapas de asientos).

Detalles de Reserva y Consistencia

Área crítica: evitar reservas dobles. PostgreSQL con transacciones y aislamiento Serializable o Control de Concurrencia Optimista (OCC) en versiones de entradas.

Proceso:

• Cliente selecciona ticketIds.
• Servicio de Reservas inicia transacción: SELECT FOR UPDATE en Entradas.
• Verifica estado (disponible), actualiza a reservado.
• Crea registro de Reserva.
• Confirmación de pago → estado confirmado.

Ejemplo de tabla Entradas:

| id | event_id | sección | fila | asiento | precio | estado | versión |

|----|----------|---------|-----|------|-------|--------|---------|

| 1 | 123 | A | 1 | 5 | 100 | disponible | 1 |

OCC: en UPDATE, verifica versión, rechaza en conflicto.

Para alta concurrencia: retenciones temporales (TTL 10 min) en Redis.

Optimización de Búsqueda

El filtrado SQL básico no escala a 10 millones. Transición a:

• Elasticsearch para búsqueda de texto completo por palabra clave, artista, lugar.
• Indexación de Eventos con campos: nombre, rango_fechas, ubicación.
• Búsqueda facetada para filtros (fecha, tipo).

Flujo: Servicio de Búsqueda → consulta ES → agregación → caché en Redis.

Latencia <500 ms lograda precargando eventos populares.

Análisis Profundo de Escalabilidad

Bases de Datos

• PostgreSQL Maestro (Reservas, Entradas): fragmentado por eventId.
• Réplicas de Lectura: 10+ para visualización de eventos.
• Redis: sesiones, retenciones temporales, eventos principales.
• Elasticsearch: búsqueda, análisis.

Migración de datos: Servicio de Eventos escribe en Kafka → CDC → réplicas/ES.

Monitoreo y Tolerancia a Fallos

• Circuit Breakers en servicios.
• Comprobaciones de salud, escalado automático.
• Copias de seguridad: archivado WAL en S3.

Conclusiones Clave

• Consistencia estricta solo en transacciones de Reserva, consistencia eventual para búsqueda.
• OCC + bloqueos temporales en Redis previenen el 99% de conflictos sin bloqueos.
• CQRS/ES aseguran <500 ms de búsqueda bajo carga 100:1.
• Fragmentación por eventId escala a 10M+ usuarios activos diarios.
• API Gateway centraliza seguridad y limitación.

— Editorial Team