El 9 de desembre de 2025, més de 400.000 persones van intentar comprar una de les 142.000 entrades disponibles per al LUX Tour de Rosalía a Espanya. El que va passar en aquelles 2 hores és un cas d'estudi fascinant sobre arquitectura de sistemes d'alta demanda, cues virtuals, i el trade-off fonamental entre experiència d'usuari i consistència transaccional.
📋 Índex de l'Article
PART 1: El Cas i l'Arquitectura General
PART 2: El Cor Tècnic
PART 3: Resiliència i Conclusions
PART 1: El Cas i l'Arquitectura General
1. El Cas Real: LUX Tour de Rosalía
El context
El 5 de desembre de 2025, Rosalía va anunciar la seva gira mundial LUX Tour 2026 per promocionar el seu quart àlbum d'estudi "LUX", estrenat al novembre de 2025. La gira inclouria 42 concerts en 17 països, amb 8 dates a Espanya:
🏟️ Madrid - Movistar Arena (capacitat ~17.500)
- • 30 Març 2026
- • 1 Abril 2026
- • 3 Abril 2026
- • 4 Abril 2026
🏟️ Barcelona - Palau Sant Jordi (capacitat ~18.000)
- • 13 Abril 2026
- • 15 Abril 2026
- • 17 Abril 2026
- • 18 Abril 2026
🎫 Total d'entrades disponibles a Espanya: ~142.000
📅 La cronologia 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 │ │ │ └─────────────────────────────────────────────────────────────────────┘
💬 Testimonis reals d'usuaris (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. Els 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 │ │ │ │ INVENTARI │ │ ─────────────────────────────────────────────────────────────── │ │ • Entradas Madrid (4 fechas x ~17.500): ~70.000 │ │ • Entradas Barcelona (4 x ~18.000): ~72.000 │ │ • TOTAL ENTRADAS ESPAÑA: ~142.000 │ │ │ │ PREUS OFICIALS │ │ ─────────────────────────────────────────────────────────────── │ │ • Entrada estándar mínima: 45€ │ │ • Entrada estándar máxima: 115€ │ │ • Paquetes VIP: hasta 500€ │ │ • Gastos de gestión reportados: 36,50€ │ │ │ │ REVENDA (post-venda) │ │ ─────────────────────────────────────────────────────────────── │ │ • Precios en Viagogo: +1.000€ │ │ • Incremento sobre precio original: +400% a +900% │ │ │ │ INFRAESTRUCTURA (estimacions) │ │ ─────────────────────────────────────────────────────────────── │ │ • 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 metres
🔽 L'analogia de l'embut
El problema fonamental és: Com processes 400.000 peticions quan només pots gestionar 1.000 transaccions segures per minut?
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 d'Arquitectura Complet
📱💻📱💻📱💻📱💻📱💻📱💻
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
PART 2: El Cor Tècnic
4. La Cua Virtual: Molt més que un número baixant
❓ Què és realment una Virtual Waiting Room?
La cua virtual NO és una cua FIFO tradicional. És un sistema de control d'admissió que actua com a buffer de pressió entre la demanda massiva i la capacitat real del sistema.
🎉 L'analogia 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 porter és la Virtual Waiting Room. La discoteca és el sistema de ticketing.
📈 Per què la teva posició a vegades PUJA?
RAÓ 1: Verificació anti-bot
Els bots detectats s'eliminen o es mouen al final. Tu puges posicions relatives.
RAÓ 2: Usuaris re-encolats per inactivitat
Usuaris que tanquen la pestanya i tornen es re-encolen al final.
RAÓ 3: Admissió per lots
Entre lots, nous usuaris poden entrar a la cua. Si n'entren més dels que surten, la teva posició puja.
RAÓ 4: Cues prioritàries activades
Clients Santander entraven a cua prioritària. Usuaris normals baixaven posicions relatives.
🌊 L'Analogia 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.
🐍 Algoritme de Cua - Codi 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 Dades 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 Dades d'Inventari
La base de dades d'inventari és on passa la garantia de NO-OVERSELLING. Cada reserva d'assistent ha de ser atòmica - o es completa totalment o no es fa res.
MÀQUINA D'ESTATS DE L'ASSISTENT:
┌───────────────┐
│ 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 Dades 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 amb Altres Esdeveniments
┌─────────────────────────────────────────────────────────────────────────────┐ │ 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 i Control de Flux
El rate limiting actua com una vàlvula que controla quantes peticions arriben realment al backend. Sense ell, el sistema col·lapsaria instantàniament.
🚿 La Metàfora de l'Aixeta i la Banyera
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 └──────────────┘
🧮 Els 3 Algoritmes de Rate Limiting Més Usats
🪣 1. TOKEN BUCKET (el más usado para APIs)
Imagina un cubell amb tokens. Cada petició consumeix 1 token. El cubell es reomple a velocitat constant (ex: 10 tokens/segon). Si el cubell està buit, la petició es rebutja (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 petició. Compta quantes peticions hi ha en els últims N segons.
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)
A diferència de Token Bucket: processa a tasa CONSTANT, no variable. Ideal per checkout/pagaments on volem flux predictible.
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
🪣
Cub amb tokens
Capacidad: 100 tokens
⏱️
Es reomple amb el temps
10 tokens/segundo
📨
Cada request = 1 token
Si vacío → Error 429
7. WebSockets: Milions de Connexions
Com mantens 400.000+ usuaris informats de la seva posició a la cua en temps real? El polling HTTP tradicional significaria 133.000 peticions/segon només per mostrar posicions. La solució: 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)
PART 3: Resiliència i Conclusions
🔌 Arquitectura WebSocket per 400.000+ Connexions
┌─────────────────────────────────────────────────────────────────────┐ │ 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 i Resiliència
Què passa quan un servei falla? Sense protecció, la fallada es propaga en cascada i tomba tot el sistema. Els Circuit Breakers prevenen això.
💥 Fallades 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 Fonamental
En sistemes de ticketing d'alta demanda, hi ha dos objectius en conflicte:
👤 Experiència d'Usuari
- Respuestas rápidas (<500ms)
- Sin colas de espera
- UI fluida y responsive
- Sin errores
💰 Integritat Transaccional
- Cero overselling
- Todas las transacciones completan
- Consistencia de inventario 100%
- Pagos seguros
La indústria va escollir:
INTEGRITAT TRANSACCIONAL
A costa de cues de 2+ hores i usuaris frustrats
10. Tecnologies Utilitzades
☁️
AWS
EC2, EKS, RDS, ElastiCache
⚡
Fastly
CDN, Edge, DDoS
🔴
Redis
Cache, Sessions, Queues
📨
Kafka
Event streaming
🐘
PostgreSQL
Inventory, Transactions
☸️
Kubernetes
Container orchestration
11. Conclusió
El sistema de ticketing del LUX Tour de Rosalía va fer exactament el que havia de fer: vendre 142.000 entrades a 142.000 persones diferents, sense vendre'n cap dues vegades, processant correctament cada pagament.
┌─────────────────────────────────────────────────────────────────────┐ │ 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ó final
La cua virtual de 2 hores que vas veure al LUX Tour de Rosalía NO va ser una fallada. Va ser una FEATURE.
És el sistema dient-te: "Hi ha 400.000 persones. Només hi ha 142.000 entrades. Processarem això de forma ordenada perquè cada venda sigui vàlida."
La cua virtual no és el problema. És la solució.
Necessites arquitectura d'alta disponibilitat?
Si el teu negoci necessita sistemes que gestionin pics de demanda extrema sense fallar, això és exactament el que fem.
Parlem del teu projecte
Microsoft 365
ES 
CAT 
EN