Diseñar un sistema de reservas de entradas para ventas relámpago de conciertos

Supuestos: Los compradores se autentican antes del pago, el proveedor de pagos admite claves de idempotencia y autorización seguida de captura, y la retención de ocho minutos es un plazo límite para completar una compra, no una garantía de que un pago iniciado en el último segundo tendrá éxito. La seguridad tiene prioridad sobre la disponibilidad durante un fallo regional ambiguo.

Arquitectura: Colocar una CDN y protección contra bots delante de una sala de espera virtual, una puerta de enlace de API y servicios sin estado de mapa de asientos, reserva, pedido y pago. Ejecutar servicios en múltiples zonas de disponibilidad en la región principal, con una reserva en espera en la región secundaria; escalar automáticamente los servicios orientados a la venta. Utilizar una base de datos transaccional como autoridad para el estado de los asientos, las retenciones, los pedidos y los límites por usuario. Replicar su estado confirmado de forma síncrona a la región secundaria. Publicar eventos de outbox de la base de datos en un bus de mensajes para notificaciones y actualizaciones de caché. Servir mapas de asientos desde una caché, con actualizaciones enviadas a los clientes; la disponibilidad mostrada es informativa, no una promesa. Mantener la ruta de escritura crítica independiente de la caché y el bus de mensajes.

Retenciones y compras: Asignar una fila de base de datos a cada par evento-asiento. Una solicitud de retención bloquea el registro del límite por evento del comprador y las filas de asientos solicitadas en un orden coherente, comprueba que el comprador retenga como máximo seis asientos y reclama de forma atómica los asientos que estén disponibles o cuyas retenciones hayan expirado. Almacenar el propietario de la retención, el token y la fecha de caducidad utilizando la hora de la base de datos. Devolver conflictos sin éxito parcial, a menos que el cliente acepte explícitamente menos asientos. Ni las entradas de caché ni un temporizador deciden la propiedad: cada retención y compra competidora comprueba la fila autoritativa en una transacción. Un trabajador expira las retenciones para actualizaciones rápidas del mapa, mientras que las lecturas y escrituras también tratan las retenciones expiradas como disponibles, por lo que un trabajador fallido no puede dejar asientos varados.

En el momento del pago, crear un intento de pedido duradero vinculado a la retención y una clave de idempotencia. Después de que la autorización del pago sea definitivamente exitosa, cambiar de forma atómica los asientos a VENDIDOS y el pedido a CONFIRMADO solo si cada asiento todavía pertenece a esa retención y no ha expirado. Confirmar la confirmación y su evento de outbox juntos. Capturar el pago después de la confirmación; reintentar las capturas fallidas y reconciliarlas operativamente. Si la confirmación pierde la carrera contra la expiración, anular o reembolsar la autorización. Un asiento vendido nunca vuelve a estar disponible a través de la expiración de la retención. Los reintentos del cliente utilizan la misma clave de intento y recuperan el resultado existente en lugar de crear otra compra.

Tráfico de apertura de venta y equidad: Admitir usuarios a través de la sala de espera a una velocidad limitada por la capacidad medida de la base de datos y el pago, no por el número de servidores web. Aleatorizar las posiciones entre los usuarios presentes antes de la apertura anunciada, y luego admitir a los que lleguen más tarde en orden de llegada. Emitir tokens de admisión firmados y de corta duración; aplicar límites de compra por cuenta, desafíos de bots y límites de velocidad sin permitir que los refrescos repetidos mejoren la posición. Mostrar estimaciones de la posición en la cola y descartar el tráfico no esencial. Almacenar en caché la geometría estática del mapa de asientos en la CDN y unificar las actualizaciones de disponibilidad; limitar las retenciones y los pagos concurrentes. La admisión se ralentiza cuando aumentan la contención de bloqueos, el retraso de pagos o las tasas de error. Un usuario admitido para navegar no obtiene prioridad de asiento hasta que se confirma una transacción de retención.

Incertidumbre del pago: Nunca mantener un bloqueo de base de datos durante una llamada al proveedor. Utilizar la clave de idempotencia del proveedor para reintentos y webhooks como evidencia para reconciliar autorizaciones de tiempo de espera o poco claras; un tiempo de espera HTTP no es una denegación. Consultar al proveedor antes de otro intento y mantener los intentos inciertos visiblemente pendientes. No confirmar un pedido sin una autorización definitiva y una transacción de asiento exitosa. Si el plazo de ocho minutos pasa primero, los asientos pueden ser recuperados; cualquier autorización posterior se anula o se reembolsa, no se convierte en un pedido confirmado. Alertar sobre intentos no resueltos y reconciliar contra los registros de liquidación del proveedor. Deshabilitar nuevos pagos si la reconciliación no es segura, en lugar de arriesgarse a cargos o ventas duplicadas.

Fiabilidad y objetivos: Instancias multizona, balanceadores de carga y conmutación por error de base de datos manejan fallos ordinarios de nodos o zonas. Los servicios sin estado pueden reiniciarse; una caché fallida recurre a lecturas autoritativas con límite de velocidad; un bus fallido retrasa los mapas y las notificaciones, pero no las compras. Las transacciones de base de datos, los registros duraderos, la replicación síncrona entre regiones antes de confirmar las confirmaciones, las copias de seguridad, las pruebas de restauración y la reproducción de outbox protegen los pedidos confirmados. Mantener la reserva en espera y probar la conmutación por error bajo carga de venta. La promoción requiere cercar al escritor antiguo y verificar el progreso replicado: dos regiones solas no pueden garantizar de forma segura tanto escrituras inmediatas durante una partición de red como confirmaciones sin pérdidas. Pausar las compras si la cercado o la replicación son inciertas. Medir una disponibilidad del flujo de compra del 99,95% durante una ventana mensual definida, sin excluir fallos del proveedor ni fallos de admisión, y presupuestar la capacidad y el tiempo de conmutación por error contra ella; una partición regional suficientemente larga puede incumplir el objetivo en lugar de permitir la sobreventa.

Compromisos: Utilizar una base de datos transaccional de asientos en lugar de bloqueos de Redis: un mayor costo de escritura compra propiedad y pedidos auditables y atómicos. Utilizar un escritor con conmutación por error cercada en lugar de escrituras de asientos activas-activas: menor disponibilidad de escritura geográfica, pero sin propietarios en conflicto. Utilizar mapas cacheados y ligeramente desactualizados en lugar de lecturas de base de datos para cada espectador: pueden ocurrir conflictos en la selección, pero una llegada de 500.000 usuarios no abruma a la autoridad. Utilizar admisión limitada en lugar de escalado automático ilimitado: algunos usuarios esperan, pero los pagos admitidos permanecen utilizables y la infraestructura no necesita ser aprovisionada para toda la oleada. Liberar retenciones expiradas a pesar de pagos inciertos en lugar de extenderlas indefinidamente: el inventario se devuelve a tiempo, a costa de anulaciones o reembolsos ocasionales.

Panel de ventas y alertas: Seguimiento de la profundidad de la cola, distribución del tiempo de espera y tasa de admisión; disponibilidad y latencia de la API; éxito de la retención, conflictos, retraso de expiración, fallos de límite por usuario y esperas de bloqueo de base de datos; conversión de pago y latencia de confirmación de pedido; tiempos de espera de pago, antigüedad de intentos pendientes, discrepancias de autorización a confirmación, reembolsos y fallos de captura. Alerta inmediata sobre cualquier violación de invariante de asiento duplicado o pedido confirmado perdido; página sobre retraso de replicación, cercado fallido, baja capacidad de base de datos, aumento de tasas 5xx, incertidumbre excesiva de pago y retraso de expiración. Seguimiento del retraso de la caché y del retraso del outbox por separado de la salud autoritativa de la compra.

1. Arquitectura de Alto Nivel y Almacenes de Datos: La arquitectura aprovecha una configuración multirregión activa-pasiva (la Región Primaria A maneja todas las escrituras transaccionales; la Región B sirve como standby en caliente para recuperación ante desastres y tráfico de lectura regional). Sala de Espera Virtual / Edge: Una capa de CDN (por ejemplo, Cloudflare) se antepone a todo el tráfico y se integra con una sala de espera virtual en el borde para absorber el pico inicial de 500.000 usuarios. API Gateway: Enruta el tráfico autenticado, realiza limitación de velocidad y valida tokens de admisión de cola firmados. Servicio de Disponibilidad de Asientos (Ruta de Lectura): Lee el estado de los asientos del lugar desde una caché en memoria (Redis) y sirve instantáneas del mapa de asientos cacheadas por CDN (actualizadas cada 1-2 segundos a través de SSE o sondeo corto). Motor de Retención y Reserva (Ruta de Escritura): Microservicios Go/Java que ejecutan comandos de reserva de asientos contra una capa de caché transaccional en memoria (Redis Cluster) respaldada por una base de datos relacional. Servicio de Pedidos y Pagos: Orquesta el ciclo de vida del pedido, crea intenciones de pago con el proveedor de pagos, escucha webhooks y maneja la reconciliación de estados. Almacenes de Datos: (a) Redis Cluster: Particionado por ID de Evento, contiene mapas de bits de estado de asientos y concesiones de retención (TTL: 8 minutos) para bloqueos de asientos de microsegundos. (b) Base de Datos Relacional (Amazon Aurora PostgreSQL Multi-AZ): El sistema de registro autoritativo para asientos, retenciones, pedidos, entradas y libros de contabilidad financieros, utilizando transacciones ACID para garantizar cero sobreventa. (c) Kafka / SQS: Bus de mensajes asíncrono para eventos de finalización de pedidos, notificaciones, generación de PDF de entradas y reconciliación de pagos. 2. Retenciones de Asientos, Concurrencia y Expiración: La cero sobreventa se garantiza mediante un modelo de reserva en dos fases. En la Fase 1 (Retención en Memoria), las solicitudes de selección de asientos (hasta 6 asientos) llegan al Motor de Retención. Un script Lua de Redis inspecciona atómicamente el estado del mapa de bits o hash de los asientos solicitados. Si todos los asientos están 'DISPONIBLES', los marca como 'RETENIDOS', escribe un Registro de Retención que contiene {user_id, hold_id, timestamp, seat_ids} y establece un TTL estricto de 480 segundos. Si algún asiento ya está 'RETENIDO' o 'VENDIDO', el script Lua se aborta limpiamente sin asignación parcial. En la Fase 2 (Retención en Base de Datos Autoritativa), se crea un registro de base de datos idempotente en Aurora dentro de una única transacción: INSERT INTO holds (id, user_id, event_id, seat_ids, expires_at) VALUES (...) y actualiza el estado del asiento a 'RETENIDO'. Manejo de Expiración: Si el usuario no finaliza la compra dentro de los 8 minutos, la retención de Redis expira a través de eventos de expiración de claves (Notificaciones de Keyspace de Redis respaldadas por un proceso de limpieza duradero en segundo plano que escanea Aurora en busca de 'expires_at < NOW() AND status = HELD'). El proceso de limpieza cambia atómicamente el estado del asiento de nuevo a 'DISPONIBLE' en Aurora y restaura el mapa de bits de Redis, liberando instantáneamente los asientos de nuevo a los compradores activos. Finalización de la Compra: Tras la confirmación del pago, una transacción ACID en Aurora actualiza los asientos a 'VENDIDO', marca el pedido como 'PAGADO', genera registros de entradas inmutables y actualiza el estado de los asientos en Redis a 'VENDIDO'. 3. Pico de Tráfico, Control de Admisión y Equidad: Manejar 500.000 usuarios concurrentes en 2 minutos requiere un control de admisión agresivo para que los servicios downstream operen estrictamente dentro de la capacidad. Sala de Espera en el Borde: Los usuarios que llegan antes y durante la apertura de la venta son dirigidos a una Sala de Espera en el Borde ligera. Los usuarios que llegan antes de T-0 se colocan en un grupo de preventa. En T-0, el orden de llegada se aleatoriza dentro del estallido inicial para eliminar ventajas de bots de milisegundos, después de lo cual se aplica una cola FIFO estricta. Admisión con Limitación de Velocidad: El sistema calcula el rendimiento de admisión en función del tamaño del lugar y la capacidad de procesamiento (por ejemplo, admitiendo 1.000 usuarios cada 10 segundos). Los usuarios admitidos reciben un token HMAC firmado criptográficamente que contiene {user_id, queue_slot, expires_at} válido para ingresar al mapa de asientos interactivo y al pipeline de pago. Optimización del Mapa de Asientos: Generar mapas de 60.000 asientos dinámicamente para 500.000 usuarios colapsaría las bases de datos. En su lugar, el estado del mapa de asientos se renderiza como un vector binario comprimido o un fragmento de JSON delta cacheados en el borde de la CDN con un TTL de 1 segundo. Los usuarios obtienen la geometría estática del lugar una vez, luego extraen deltas de estado de asientos con caché invalidada cada segundo, manteniendo la carga de lectura del backend por debajo de 500 RPS. 4. Integración de Pagos y Manejo de Fallos: Los pagos se orquestan a través de una máquina de estados asíncrona. Paso 1 (Inicio del Pago): El usuario ingresa al flujo de pago; el sistema crea un Pedido interno en estado 'PENDING_PAYMENT' vinculado al Hold ID. Se genera una clave de idempotencia (order_id + attempt_count). Paso 2 (Interacción con Proveedor Externo): El frontend recopila los detalles de pago utilizando SDKs del lado del cliente del proveedor (tarjetas tokenizadas) y envía la intención de cobro. Dado que la latencia p99 es de 3 segundos, las llamadas API se ejecutan de forma asíncrona con sondeo del lado del cliente sobre el estado del pedido en lugar de bloqueo síncrono de hilos HTTP. Tiempo de Espera y Resultados Poco Claros: Si la llamada expira o devuelve un error de red ambiguo, el Servicio de Pedidos no falla el pedido inmediatamente. En su lugar, coloca el pedido en 'PAYMENT_VERIFYING' e inicia un trabajador de respaldo que sondea el endpoint GET /charges/{idempotency_key} del proveedor con retroceso exponencial (por ejemplo, a los 2s, 5s, 10s). Búfer de Extensión de Retención: Si un pedido entra en 'PAYMENT_VERIFYING' dentro de los 60 segundos de la expiración de la retención de 8 minutos, el sistema otorga una extensión de seguridad automática de 2 minutos en la retención de Redis para evitar liberar asientos mientras se liquida un pago. Ingesta de Webhooks: Los webhooks del pasarela de pago se validan mediante firma HMAC y se escriben directamente en una cola duradera antes de su procesamiento, garantizando actualizaciones de estado idempotentes. Trabajador de Reconciliación: Un trabajo de reconciliación horario compara los informes de liquidación de la pasarela de pago con los registros de la base de datos para detectar cargos huérfanos o entradas no procesadas. 5. Fiabilidad, Failover y Durabilidad de Datos: Disponibilidad (99,95%) y Cero Pérdida de Datos: (a) Nivel de Base de Datos: Aurora PostgreSQL se ejecuta en 3 Zonas de Disponibilidad con replicación de almacenamiento síncrona automatizada y réplicas de lectura. Si falla el escritor principal, el failover automatizado promueve una réplica en menos de 30 segundos. (b) Nivel en Memoria: Redis opera en una topología maestro-réplica agrupada entre AZs. En el raro caso de un fallo irrecuperable de Redis, el estado de los asientos se reconstruye en menos de 15 segundos mediante un trabajo de calentamiento que ejecuta un escaneo rápido de índice sobre la tabla de asientos de Aurora. (c) Recuperación ante Desastres Regional: La replicación de almacenamiento entre regiones de Aurora mantiene un RPO de menos de 1 segundo. La Región B está configurada en standby frío/cálido. Si la Región A sufre una interrupción catastrófica del proveedor de nube, el failover de DNS redirige el tráfico a la Región B, donde los servicios se escalan automáticamente y reanudan las operaciones. (d) Idempotencia: Todas las API (hold, pay, release) aplican restricciones únicas a nivel de base de datos y tokens de idempotencia de Redis para prevenir efectos secundarios duplicados durante las reintentos. 6. Compromisos Clave de Arquitectura: (1) Bloqueo Lua en Memoria Redis vs. Bloqueo de Filas Puro en Base de Datos (SELECT FOR UPDATE). Rechazado: Los bloqueos de filas directos en PostgreSQL para 500.000 solicitudes concurrentes causan una contención masiva de bloqueos, puesta en cola de transacciones y agotamiento de conexiones. Elegido: Scripts atómicos Lua de Redis para la arbitraje inicial de retención, persistiendo en Postgres de forma asíncrona/secuencial. Compromiso: Sincronización de estado de doble capa ligeramente más compleja a cambio de latencia de microsegundos y cero saturación de la base de datos. (2) Cola Virtual en el Borde vs. Escalado Automático Masivo de Servicios Backend. Rechazado: Escalar dinámicamente pods de Kubernetes y bases de datos para manejar 500.000 RPS brutos para un evento con solo 60.000 asientos en total es prohibitivo en costos y limitado por el rendimiento de escritura de Aurora. Elegido: Cola en el borde con tasa de admisión controlada. Compromiso: Los usuarios esperan en una cola, pero la estabilidad del sistema, los costos operativos y la experiencia del usuario se mantienen predecibles y robustos. (3) Sondeo Delta en Caché CDN vs. WebSockets Full Duplex para Mapa de Asientos en Vivo. Rechazado: Mantener 500.000 conexiones WebSocket bidireccionales persistentes impone una sobrecarga severa de conexión con estado en los servidores de aplicaciones. Elegido: Sondeo delta de CDN con caché corta (1 segundo). Compromiso: Latencia de 1 segundo en la visualización del estado del asiento para los usuarios, lo cual es totalmente tolerable dada la verificación de retención Lua transaccional al hacer clic. 7. Métricas Clave de Operación y Alertas: Métricas: (a) Longitud de la Cola en el Borde y Tasa de Entrada. (b) Tasa de Creación de Retenciones y Tasa de Abandono. (c) Utilización de Memoria de Redis, CPU y latencia de ejecución de scripts Lua (p95, p99). (d) Conexiones Activas de Base de Datos, Latencia de Escritura y Retraso de Replicación. (e) Latencia de la Pasarela de Pago (p50, p99), Tasa de Error (5xx/tiempos de espera) y Retraso de Ingesta de Webhooks. (f) Contador de Violación de Invariantes: COUNT(DISTINCT order_id) WHERE seat_id = X AND status = 'SOLD' > 1 (estrictamente 0). Alertas Críticas: (1) Incumplimiento de Invariante: Cualquier detección de asiento sobrevendido (P0, página instantánea). (2) Pico de Tiempo de Espera de Pago: Tasa de tiempo de espera de pago > 5% durante 1 minuto (P1). (3) Memoria/CPU de Redis: CPU > 75% o recuento de evacuación > 0 (P1). (4) Retraso del Reaper de Retenciones Expiradas: Retraso de la cola del reaper > 30 segundos (P2).