El 9 de diciembre de 2025, más de 400.000 personas intentaron comprar una de las 142.000 entradas disponibles para el LUX Tour de Rosalía en España. Lo que ocurrió en esas 2 horas es un caso de estudio fascinante sobre arquitectura de sistemas de alta demanda, colas virtuales, y el trade-off fundamental entre experiencia de usuario y consistencia transaccional.
📋 Índice del Artículo
PARTE 1: El Caso y la Arquitectura General
PARTE 2: El Corazón Técnico
PARTE 3: Resiliencia y Conclusiones
PARTE 1: El Caso y la Arquitectura General
1. El Caso Real: LUX Tour de Rosalía
El contexto
El 5 de diciembre de 2025, Rosalía anunció su gira mundial LUX Tour 2026 para promocionar su cuarto álbum de estudio "LUX", estrenado en noviembre de 2025. La gira incluiría 42 conciertos en 17 países, con 8 fechas en España:
🏟️ Madrid - Movistar Arena (capacidad ~17.500)
- • 30 Marzo 2026
- • 1 Abril 2026
- • 3 Abril 2026
- • 4 Abril 2026
🏟️ Barcelona - Palau Sant Jordi (capacidad ~18.000)
- • 13 Abril 2026
- • 15 Abril 2026
- • 17 Abril 2026
- • 18 Abril 2026
🎫 Total de entradas disponibles en España: ~142.000
📅 La cronología del caos
┌─────────────────────────────────────────────────────────────────────┐ │ CRONOLOGÍA DE LA VENTA - LUX TOUR 2025 │ ├─────────────────────────────────────────────────────────────────────┤ │ │ │ 📅 5 DICIEMBRE 2025 │ │ └─ 12:00h - Rosalía anuncia LUX Tour en redes sociales │ │ └─ En minutos, #LuxTour es trending topic mundial │ │ │ │ 📅 9 DICIEMBRE 2025 - PREVENTA │ │ └─ 10:00h - Inicio preventa (Artist Presale + Santander) │ │ └─ 10:05h - Colas virtuales superan 100.000 personas │ │ └─ 10:15h - Primeros reportes de errores 503 y 500 │ │ └─ 10:30h - Posiciones reportadas: 33.000, 65.000 en cola │ │ └─ 12:00h - Mayoría de preventa AGOTADA │ │ └─ 12:45h - Colas de +400.000 personas │ │ │ │ 📅 11 DICIEMBRE 2025 - VENTA GENERAL │ │ └─ 10:00h - Inicio venta general │ │ └─ 10:01h - Colas instantáneas de +50.000 personas │ │ └─ 10:30h - Colapso total de canales de venta │ │ └─ 12:00h - SOLD OUT TOTAL - 8 conciertos agotados │ │ └─ Total tiempo venta general: ~2 HORAS │ │ │ │ 📅 POST-VENTA │ │ └─ Entradas en reventa a +1.000€ │ │ └─ OCU denuncia ante Ministerio de Consumo │ │ │ └─────────────────────────────────────────────────────────────────────┘
💬 Testimonios reales de usuarios (X/Twitter)
"Después de conseguir la cantidad de cero entradas y estar ahora por el número 33.000 y 65.000 en las colas virtuales del LUX Tour de Rosalía, procederé a dejar de ser fan de toda música y artista mainstream"
— @iris_angsan
"Por favor artistas del mundo buscad otro método para vender entradas que no sea la estafa de ticketmaster"
— @Franqk1997
"Que cuando me haya metido solo quedasen entradas platinum… esto es un robo"
— @laxista01
2. Los Números del Caos
┌─────────────────────────────────────────────────────────────────────┐ │ CIFRAS REALES - LUX TOUR ESPAÑA │ ├─────────────────────────────────────────────────────────────────────┤ │ │ │ DEMANDA │ │ ─────────────────────────────────────────────────────────────── │ │ • Usuarios en cola virtual (pico): +400.000 │ │ • Usuarios simultáneos estimados: +1.000.000 │ │ • Posiciones reportadas en cola: 33.000 - 65.000 por fecha │ │ • Tiempo medio de espera: 1-3 horas │ │ │ │ INVENTARIO │ │ ─────────────────────────────────────────────────────────────── │ │ • Entradas Madrid (4 fechas x ~17.500): ~70.000 │ │ • Entradas Barcelona (4 x ~18.000): ~72.000 │ │ • TOTAL ENTRADAS ESPAÑA: ~142.000 │ │ │ │ PRECIOS OFICIALES │ │ ─────────────────────────────────────────────────────────────── │ │ • Entrada estándar mínima: 45€ │ │ • Entrada estándar máxima: 115€ │ │ • Paquetes VIP: hasta 500€ │ │ • Gastos de gestión reportados: 36,50€ │ │ │ │ REVENTA (post-venta) │ │ ─────────────────────────────────────────────────────────────── │ │ • Precios en Viagogo: +1.000€ │ │ • Incremento sobre precio original: +400% a +900% │ │ │ │ INFRAESTRUCTURA (estimaciones) │ │ ─────────────────────────────────────────────────────────────── │ │ • Peticiones por segundo (pico): 30.000 - 50.000 req/s │ │ • Conexiones WebSocket simultáneas: 500.000 - 2.000.000 │ │ • Errores HTTP reportados: 503, 500 │ │ │ └─────────────────────────────────────────────────────────────────────┘
3. Arquitectura General: Vista de 10.000 metros
🔽 La analogía del embudo
El problema fundamental es: ¿Cómo procesas 400.000 peticiones cuando solo puedes manejar 1.000 transacciones seguras por minuto?
DEMANDA
│
│ 400.000+ usuarios
│ queriendo comprar
│ AL MISMO TIEMPO
▼
┌───────────────┐
│ ████████ │ ← Todos intentan entrar
│ ████████ │
│ ████████ │
└───────┬───────┘
│
│ EMBUDO (el sistema)
│
┌───────▼───────┐
│ │ │ ← El sistema solo puede procesar
│ │ │ un número limitado a la vez
│ ▼ │
└───────────────┘
│
│ ~500-1000 transacciones/minuto
│ de forma segura
▼
┌───────────────┐
│ ENTRADAS │
│ VENDIDAS │
│ 142.000 │
└───────────────┘
🏗️ Diagrama de Arquitectura Completo
📱💻📱💻📱💻📱💻📱💻📱💻
USUARIOS (400.000+)
↓
CAPA 1: CDN / EDGE (Fastly)
- Protección DDoS
- Detección de bots
- Cacheo de contenido estático
- Rate limiting por IP
↓
⭐ CAPA 2: SALA DE ESPERA VIRTUAL
LA CAPA CRÍTICA que determina quién entra y quién espera
- Queue Manager Cluster (6-12 nodos)
- Redis Cluster (128-256 GB RAM)
- WebSocket para actualizaciones en tiempo real
↓ Solo pasan usuarios ADMITIDOS (~500/min)
CAPA 3: APLICACIÓN (Kubernetes)
Catalog Service
Session Service
Cart Service
Inventory Service
Payment Service
↓
CAPA 4: DATOS
Redis
Sessions, Cache
Kafka
Events, Queues
PostgreSQL
Inventory, Transactions
PARTE 2: El Corazón Técnico
4. La Cola Virtual: Mucho más que un número bajando
❓ ¿Qué es realmente una Virtual Waiting Room?
La cola virtual NO es una cola FIFO tradicional. Es un sistema de control de admisión que actúa como buffer de presión entre la demanda masiva y la capacidad real del sistema.
🎉 La analogía de la discoteca
❌ SIN portero
- Todos empujan a la vez
- La puerta colapsa
- Nadie entra
- Caos total
✅ CON portero
- Forma una cola ordenada
- Deja entrar de 10 en 10
- Cuando alguien sale, entra otro
- ¡La discoteca funciona!
El portero es la Virtual Waiting Room. La discoteca es el sistema de ticketing.
📈 ¿Por qué tu posición a veces SUBE?
RAZÓN 1: Verificación anti-bot
Los bots detectados se eliminan o mueven al final. Tú subes posiciones relativas.
RAZÓN 2: Usuarios re-encolados por inactividad
Usuarios que cierran pestaña y vuelven se re-encolan al final.
RAZÓN 3: Admisión por lotes
Entre batch y batch, nuevos usuarios pueden entrar. Si entran más de los que salen, tu posición sube.
RAZÓN 4: Colas prioritarias activadas
Clientes Santander entraban en cola prioritaria. Usuarios normales bajaban posiciones relativas.
🌊 La Analogía de la Presa Hidroeléctrica
DEMANDA (río caudaloso)
│
│ 400.000 usuarios/segundo
▼
┌──────────────────────────────────┐
│ │
│ VIRTUAL WAITING ROOM │
│ (la presa) │
│ │
│ ████████████████████████████ │
│ ████████████████████████████ │ ← Usuarios esperando
│ ████████████████████████████ │ (agua represada)
│ ████████████████████████████ │
│ │
└──────────────┬───────────────────┘
│
┌────┴────┐
│ VÁLVULA │ ← Rate limiter
│ │ (500 usuarios/minuto)
└────┬────┘
│
▼
┌──────────────────────────────────┐
│ │
│ SISTEMA DE VENTA │
│ (turbina/generador) │
│ │
│ Capacidad: 500 usuarios │
│ concurrentes comprando │
│ │
│ Si entra más agua de la que │
│ puede procesar: COLAPSO │
│ │
└──────────────────────────────────┘
La presa NO es el problema. La presa es LA SOLUCIÓN.
Sin ella, el sistema colapsaría inmediatamente.
🐍 Algoritmo de Cola - Código Real
""" Pseudocódigo del algoritmo de cola virtual Basado en patrones comunes (Queue-it, Cloudflare Waiting Room, etc.) """ import redis import time import uuid class VirtualQueueManager: """Gestor de cola virtual para eventos de alta demanda.""" def __init__(self, redis_cluster, event_id: str): self.redis = redis_cluster self.event_id = event_id self.admission_rate = 500 # usuarios/minuto self.max_in_store = 5000 # máx simultáneos en tienda def enqueue_user(self, user_fingerprint: str, ip_hash: str) -> dict: """Añade un usuario a la cola.""" # Generar token único queue_token = f"qt_{uuid.uuid4().hex[:16]}" entry_time = time.time() # Añadir a Sorted Set (score = timestamp) # ZADD queue:rosalia_lux_2025 1733738400.123 "qt_abc123" self.redis.zadd( f"queue:{self.event_id}", {queue_token: entry_time} ) # Guardar metadatos self.redis.hset(f"user:{queue_token}", mapping={ "entry_time": entry_time, "fingerprint": user_fingerprint, "status": "WAITING", "verified": "false" }) # Calcular posición position = self.redis.zrank(f"queue:{self.event_id}", queue_token) + 1 return { "token": queue_token, "position": position, "estimated_wait": self._calculate_wait(position) } def get_position(self, queue_token: str) -> dict: """Obtiene posición actual (llamado vía WebSocket cada 1-5s).""" rank = self.redis.zrank(f"queue:{self.event_id}", queue_token) if rank is None: return {"status": "ADMITTED"} # Ya pasó a tienda return { "position": rank + 1, "total": self.redis.zcard(f"queue:{self.event_id}"), "estimated_wait": self._calculate_wait(rank + 1) }
🔴 Estructura de Datos Redis
# ═══════════════════════════════════════════════════════════════════════ # ESTRUCTURA DE DATOS REDIS PARA COLA VIRTUAL # ═══════════════════════════════════════════════════════════════════════ # SORTED SET: Cola principal ordenada por timestamp ZADD queue:rosalia_lux_2025 1733738400.123456 "qt_a1b2c3d4e5f6g7h8" ZADD queue:rosalia_lux_2025 1733738400.123457 "qt_i9j0k1l2m3n4o5p6" # ... x 400.000 usuarios # Consultas típicas: ZRANK queue:rosalia_lux_2025 "qt_a1b2c3d4e5f6g7h8" # → Posición ZCARD queue:rosalia_lux_2025 # → Total en cola ZRANGE queue:rosalia_lux_2025 0 49 # → Primeros 50 # HASH: Metadatos de cada usuario HSET user:qt_a1b2c3d4e5f6g7h8 entry_time "1733738400.123456" device_fingerprint "fp_chrome_win10_1920x1080" status "WAITING" # WAITING, ADMITTED, PURCHASED verified "true" priority "0" # 0=normal, 1=presale, 2=VIP EXPIRE user:qt_a1b2c3d4e5f6g7h8 14400 # TTL 4 horas # STRINGS: Contadores en tiempo real SET stats:rosalia_lux_2025:total_admitted "45000" SET stats:rosalia_lux_2025:current_in_store "487" SET stats:rosalia_lux_2025:admission_rate "500" # PUB/SUB: Notificaciones para WebSockets PUBLISH queue:rosalia_lux_2025:updates '{ "type": "POSITION_UPDATE", "batch": [ {"token": "qt_abc...", "position": 45001, "wait_min": 85}, {"token": "qt_def...", "position": 45002, "wait_min": 85} ] }'
5. La Base de Datos de Inventario
La base de datos de inventario es donde ocurre la garantía de NO-OVERSELLING. Cada reserva de asiento debe ser atómica - o se completa totalmente o no se hace nada.
MÁQUINA DE ESTADOS DEL ASIENTO:
┌───────────────┐
│ AVAILABLE │
│ (disponible) │
└───────┬───────┘
│ add to cart
▼
┌───────────────┐
│ SOFT_LOCKED │ ← TTL: 10 min
│ (en carrito) │ Si expira → vuelve a AVAILABLE └───────┬───────┘
│ checkout
▼
┌───────────────┐
│ HARD_LOCKED │ ← TTL: 15 min
│ (pagando) │ Si falla pago → AVAILABLE └───────┬───────┘
│ payment OK
▼
┌───────────────┐
│ SOLD │ ← FINAL - Nunca vuelve atrás │ (vendido) │
└───────────────┘
🐘 Esquema de Base de Datos PostgreSQL
-- Tabla principal de asientos CREATE TABLE seats ( seat_id VARCHAR(50) PRIMARY KEY, event_id VARCHAR(36) NOT NULL, section VARCHAR(50) NOT NULL, row_name VARCHAR(10) NOT NULL, seat_number INT NOT NULL, base_price DECIMAL(10,2) NOT NULL, -- Estado de disponibilidad status VARCHAR(20) NOT NULL DEFAULT 'AVAILABLE', -- AVAILABLE, SOFT_LOCKED, HARD_LOCKED, SOLD -- Información de bloqueo locked_by VARCHAR(100), locked_until TIMESTAMP WITH TIME ZONE, -- Información de venta sold_to VARCHAR(100), sold_at TIMESTAMP WITH TIME ZONE, order_id VARCHAR(36), updated_at TIMESTAMP WITH TIME ZONE DEFAULT NOW(), version INT DEFAULT 0 ); -- Índices optimizados para queries de alta frecuencia CREATE INDEX idx_seats_event_status ON seats(event_id, status); CREATE INDEX idx_seats_locked_until ON seats(locked_until) WHERE status IN ('SOFT_LOCKED', 'HARD_LOCKED'); -- Tabla de transacciones CREATE TABLE transactions ( transaction_id VARCHAR(36) PRIMARY KEY, order_id VARCHAR(36) NOT NULL, session_id VARCHAR(100) NOT NULL, total DECIMAL(10,2) NOT NULL, payment_status VARCHAR(30) NOT NULL, -- PENDING, AUTHORIZED, CAPTURED, FAILED, REFUNDED payment_intent_id VARCHAR(100), created_at TIMESTAMP WITH TIME ZONE DEFAULT NOW() );
📊 Comparativa con Otros Eventos
┌─────────────────────────────────────────────────────────────────────────────┐ │ COMPARATIVA EVENTOS TICKETING ESPAÑA 2024-2025 │ ├─────────────────────────────────────────────────────────────────────────────┤ │ │ │ EVENTO │ FECHAS │ ENTRADAS │ SOLD OUT │ COLA MAX │ │ ───────────────────────────────────────────────────────────────────────── │ │ Bad Bunny (Mayo 2025) │ 12 │ ~200.000 │ Días │ +500.000 │ │ ───────────────────────────────────────────────────────────────────────── │ │ Rosalía LUX Tour │ 8 │ ~142.000 │ ~2 horas │ +400.000 │ │ ───────────────────────────────────────────────────────────────────────── │ │ Taylor Swift Eras │ 2 │ ~100.000 │ Minutos │ +800.000 │ │ (Madrid 2024) │ │ │ (preventa) │ │ │ │ │ CONTEXTO GLOBAL TICKETMASTER: │ │ • Tickets vendidos anualmente: +500 millones │ │ • Visitantes únicos anuales: +1.000 millones │ │ • Usuarios en base de datos: +560 millones (dato hackeo 2024) │ │ • Países de operación: 19 │ │ │ └─────────────────────────────────────────────────────────────────────────────┘
6. Rate Limiting y Control de Flujo
El rate limiting actúa como una válvula que controla cuántas peticiones llegan realmente al backend. Sin él, el sistema colapsaría instantáneamente.
🚿 La Metáfora del Grifo y la Bañera
SIN RATE LIMITING: ████████████████████████████████████████ ████████████████████████████████████████ ← 50.000 req/segundo ████████████████████████████████████████ │ ▼ ┌──────────────┐ │ BAÑERA │ ← Capacidad: 5.000 req/segundo │ (backend) │ │ ████████████ │ │ ████████████ │ ← OVERFLOW! COLAPSO! │ ████████████ │ ═════╧══════════════╧═════ CON RATE LIMITING: ████████████████████████████████████████ ████████████████████████████████████████ ← 50.000 req/segundo ████████████████████████████████████████ │ ▼ ┌──────────────┐ │ VÁLVULA │ ← Rate Limiter: máximo 5.000 req/s │ (control) │ El resto: 429 Too Many Requests └──────┬───────┘ │ ▼ (flujo controlado) ┌──────────────┐ │ BAÑERA │ ← Recibe exactamente lo que puede │ (backend) │ │ ░░░░░░░░ │ ← Nivel óptimo, sin overflow └──────────────┘
🧮 Los 3 Algoritmos de Rate Limiting Más Usados
🪣 1. TOKEN BUCKET (el más usado para APIs)
Imagina un cubo con tokens. Cada request consume 1 token. El cubo se rellena a velocidad constante (ej: 10 tokens/segundo). Si el cubo está vacío, la request se rechaza (429).
Capacidad: 100 tokens ████████░░░░░ Tokens actuales: 40 ▲ Refill: 10 tokens/seg │ Refill constante Si bucket vacío → 429
✅ Permite ráfagas cortas, O(1) por operación
📊 2. SLIDING WINDOW LOG (para detección de abuso)
Guarda un log de timestamps de cada request. Cuenta cuántas requests hay en los últimos N segundos.
Ventana: últimos 60s | Límite: 100 requests t=0 t=20 t=40 t=60 t=80 t=100 ├──────┼──────┼──────┼──────┼──────┤ │ │██████│██████│██████│ │ = 100 req ◄───── ventana activa ────►
✅ Muy preciso, ideal para detectar abuso
💧 3. LEAKY BUCKET (para procesar a tasa constante)
Diferencia con Token Bucket: procesa a tasa CONSTANTE, no variable. Ideal para checkout/pagos donde queremos flujo predecible.
Entrada variable ──► ┌─────────┐ ──► Salida CONSTANTE(picos demanda) │ ░░░░░░░ │ (500 pagos/min)
│ ░░░░░░░ │ siempre igual └────┬────┘
▼
═════════ (goteo constante)
✅ El PSP (Stripe) tiene límites estrictos. Leaky bucket asegura cumplimiento.
🔴 Token Bucket - Redis Lua Script
-- TOKEN BUCKET - Redis Lua Script (atómico) local key = KEYS[1] local capacity = tonumber(ARGV[1]) -- ej: 100 local refill_rate = tonumber(ARGV[2]) -- tokens/segundo local now = tonumber(ARGV[3]) local data = redis.call("HMGET", key, "tokens", "last_refill") local tokens = tonumber(data[1]) or capacity local elapsed = (now - (tonumber(data[2]) or now)) / 1000 local new_tokens = math.min(capacity, tokens + elapsed * refill_rate) if new_tokens >= 1 then redis.call("HMSET", key, "tokens", new_tokens - 1, "last_refill", now) return {1, new_tokens - 1, 0} -- [permitido, restantes, wait=0] else return {0, new_tokens, ((1 - new_tokens) / refill_rate) * 1000} -- [rechazado] end
🪣 Token Bucket Algorithm
🪣
Cubo con tokens
Capacidad: 100 tokens
⏱️
Se rellena con el tiempo
10 tokens/segundo
📨
Cada request = 1 token
Si vacío → Error 429
7. WebSockets: Millones de Conexiones
¿Cómo mantienes a 400.000+ usuarios informados de su posición en cola en tiempo real? El polling HTTP tradicional significaría 133.000 peticiones/segundo solo para mostrar posiciones. La solución: WebSockets.
❌ HTTP Polling
- 400K users × 1 req/3s = 133K req/s
- Overhead masivo
- Alta latencia
- Insostenible
✅ WebSockets
- 1 conexión persistente por usuario
- Servidor envía actualizaciones
- Overhead mínimo
- Baja latencia (~100ms)
PARTE 3: Resiliencia y Conclusiones
🔌 Arquitectura WebSocket para 400.000+ Conexiones
┌─────────────────────────────────────────────────────────────────────┐ │ USUARIOS │ │ 📱💻📱💻📱💻📱💻📱💻📱💻📱💻📱💻📱💻📱💻📱💻📱💻📱💻📱💻 │ │ (400.000+ conexiones WebSocket simultáneas) │ └─────────────────────────────────────────────────────────────────────┘ │ │ wss:// (WebSocket Secure) ▼ ┌─────────────────────────────────────────────────────────────────────┐ │ LOAD BALANCER (L4 - TCP) │ │ • Sticky sessions por IP hash │ │ • Health checks TCP cada 5s │ │ • Connection draining en deploys │ └─────────────────────────────────────────────────────────────────────┘ │ │ │ │ │ ▼ ▼ ▼ ▼ ▼ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │WS Node │ │WS Node │ │WS Node │ │WS Node │ │WS Node │ ...x40 │ 1 │ │ 2 │ │ 3 │ │ 4 │ │ N │ │10K conn│ │10K conn│ │10K conn│ │10K conn│ │10K conn│ │32GB RAM│ │32GB RAM│ │32GB RAM│ │32GB RAM│ │32GB RAM│ └────┬───┘ └────┬───┘ └────┬───┘ └────┬───┘ └────┬───┘ │ │ │ │ │ └──────────┴──────────┴──────────┴──────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────┐ │ REDIS PUB/SUB │ │ │ │ Canales: │ │ ├─ queue:rosalia_lux:positions → Broadcast posiciones │ │ ├─ queue:rosalia_lux:admitted → Usuarios admitidos │ │ └─ queue:rosalia_lux:alerts → Mensajes de sistema │ │ │ │ Throughput: ~50.000 mensajes/segundo durante pico │ │ Latencia end-to-end: < 100ms │ └─────────────────────────────────────────────────────────────┘
8. Circuit Breakers y Resiliencia
¿Qué pasa cuando un servicio falla? Sin protección, el fallo se propaga en cascada y tumba todo el sistema. Los Circuit Breakers previenen esto.
💥 Fallos en Cascada
❌ SIN Circuit Breaker
[Cart] ──► [Inventory] ──► [DB] 💀 SLOW │ │ │ timeout 30s (threads bloqueados) ▼ [Cart] 💀 SATURADO │ ▼ [API Gateway] 💀 [Queue Service] 💀 [Payment] 💀 RESULTADO: TODO EL SISTEMA CAE
✅ CON Circuit Breaker
[Cart] ──► [CIRCUIT BREAKER] ──✗──► [Inventory] │ │ OPEN: fail-fast ▼ Return: {"error": "SERVICE_UNAVAILABLE"} [Queue Service] ✅ [Payment Service] ✅ [Catalog Service] ✅ EL RESTO DEL SISTEMA FUNCIONA
CIRCUIT BREAKER STATES: ┌──────────────┐ 5 fallos ┌──────────────┐ │ CLOSED │ ─────────────────►│ OPEN │ │ (normal) │ │ (cortado) │ └──────────────┘◄───────────────── └──────────────┘ ▲ test OK │ │ │ after 30s │ ┌──────────────┐ │ └────────────│ HALF-OPEN │◄──────┘ if OK │ (probando) │───────┐ └──────────────┘ │ │ if fails ▼ vuelve a OPEN
9. El Trade-off Fundamental
En sistemas de ticketing de alta demanda, hay dos objetivos en conflicto:
👤 Experiencia de Usuario
- Respuestas rápidas (<500ms)
- Sin colas de espera
- UI fluida y responsive
- Sin errores
💰 Integridad Transaccional
- Cero overselling
- Todas las transacciones completan
- Consistencia de inventario 100%
- Pagos seguros
La industria eligió:
INTEGRIDAD TRANSACCIONAL
A costa de colas de 2+ horas y usuarios frustrados
10. Tecnologías Utilizadas
☁️
AWS
EC2, EKS, RDS, ElastiCache
⚡
Fastly
CDN, Edge, DDoS
🔴
Redis
Cache, Sessions, Queues
📨
Kafka
Event streaming
🐘
PostgreSQL
Inventory, Transactions
☸️
Kubernetes
Container orchestration
11. Conclusión
El sistema de ticketing del LUX Tour de Rosalía hizo exactamente lo que tenía que hacer: vender 142.000 entradas a 142.000 personas diferentes, sin vender ninguna dos veces, procesando correctamente cada pago.
┌─────────────────────────────────────────────────────────────────────┐ │ RESUMEN: LUX TOUR ROSALÍA 2025 │ ├─────────────────────────────────────────────────────────────────────┤ │ │ │ LO QUE EL SISTEMA LOGRÓ │ │ ─────────────────────────────────────────────────────────────── │ │ ✅ 142.000 entradas vendidas sin overselling │ │ ✅ Todas las transacciones completadas correctamente │ │ ✅ Consistencia de inventario al 100% │ │ ✅ Sistema operativo durante todo el evento │ │ │ │ LO QUE EL SISTEMA SACRIFICÓ │ │ ─────────────────────────────────────────────────────────────── │ │ ⚠️ Experiencia de usuario (colas de horas) │ │ ⚠️ Velocidad de respuesta (errores 503 en picos) │ │ ⚠️ Percepción pública (frustración masiva) │ │ │ └─────────────────────────────────────────────────────────────────────┘
💭 La reflexión final
La cola virtual de 2 horas que viste en el LUX Tour de Rosalía NO fue un fallo. Fue una FEATURE.
Es el sistema diciéndote: "Hay 400.000 personas. Solo hay 142.000 entradas. Vamos a procesar esto de forma ordenada para que cada venta sea válida."
La cola virtual no es el problema. Es la solución.
¿Necesitas arquitectura de alta disponibilidad?
Si tu negocio necesita sistemas que manejen picos de demanda extrema sin fallar, esto es exactamente lo que hacemos.
Hablemos de tu proyecto
Microsoft 365
ES 
CAT 
EN