Si has trabajado alguna vez en pagos digitales fuera de eventos (e-commerce, SaaS, banca), tu intuición sobre latencia probablemente está calibrada en segundos. "Bajo 2 segundos" suele ser objetivo razonable. En pagos NFC en eventos en directo esa intuición está mal calibrada por un orden de magnitud: el objetivo serio está en torno a 500 milisegundos de tap a confirmación, y a partir de 1 segundo el negocio empieza a perder dinero medible.
Lo descubrí en festivales reales con Bracelit, la plataforma que cofundamos en 2016 y que terminó procesando más de 25M€ en eventos como Mutua Madrid Open, Solheim Cup 2023 o la Copa del Mundo de Cyclo-Cross. Esto es lo que de verdad aprendimos sobre por qué la latencia, en este sector, no es métrica técnica: es métrica de negocio.
01Cómo se traduce la latencia en euros perdidos
La cadena de eventos típica en una barra de festival con pulseras NFC es:
- El usuario llega a la barra.
- Pide consumición.
- El camarero toca la pulsera con el lector.
- El sistema valida saldo y registra la transacción.
- El lector pita confirmando, el camarero entrega.
Si el paso 4 tarda 500 ms, todo es invisible: el camarero ya está sirviendo la siguiente. Si tarda 2 segundos, el camarero espera. Si tarda 5 segundos (situación habitual con conectividad mala y arquitectura no optimizada), el usuario empieza a poner cara rara, el camarero golpea el lector, repite el tap. Si pasan 10 segundos sin respuesta, abandono.
Y aquí viene el problema: el abandono no es del usuario al sistema. Es del usuario al producto. La siguiente vez paga en otra barra. O en efectivo. O directamente decide no consumir más en la jornada. La pulsera que falla un par de veces deja de usarse, y con ella desaparece la ventaja competitiva del modelo cashless: que la gente consume más cuando no tiene que sacar la cartera.
02Por qué la latencia en eventos es radicalmente distinta a la de un e-commerce
1. Conectividad imperfecta y compartida
Un festival con 30.000 personas tiene la wifi saturada. El 4G/5G de los operadores está congestionado. Los recintos cerrados (estadios, palacios de deportes) tienen cobertura mala estructural. La latencia de red oscila entre 50 ms y 5 segundos en intervalos de minutos. Diseñar asumiendo conectividad estable es garantía de problema.
2. Hardware con sus propios tiempos
El protocolo NFC en sí añade unos 100-200 ms al tap, dependiendo del lector y del tipo de tag. Si encima el lector está mal alimentado o tiene el firmware desactualizado, suma. Si la pulsera está medio agotada (la batería de las pulseras activas baja a lo largo del evento), suma. La latencia "lógica" del sistema es solo una parte; hay un suelo físico que no se baja con software.
3. Picos de concurrencia muy comprimidos
Un festival concentra el 60-70% de las transacciones de la jornada en 4-5 horas. En un estadio, las medias parte y descansos generan picos de minutos donde miles de personas pagan simultáneamente. La arquitectura tiene que sostener picos extremos en ventanas cortas, sabiendo que el resto del tiempo está subutilizada.
4. Errores que no se pueden recuperar después
Si tu e-commerce cae 10 minutos un martes a las 3 de la tarde, recuperas las ventas perdidas. Si tu plataforma cae 10 minutos durante el concierto principal del sábado, esos 10 minutos no vuelven. El evento es uno y se acabó. Esto cambia la relación coste-beneficio de cada decisión técnica: mejor sobreingeniería en lo crítico que el riesgo de fallar en directo.
03Decisiones técnicas que reducen la latencia (de verdad)
1. Procesamiento offline-first donde corresponda
La validación de saldo y registro de transacción no tiene por qué viajar a un servidor central en cada tap. En arquitecturas que diseñé para Bracelit, parte de la lógica vive en el lector (o en un dispositivo intermedio del recinto): valida saldo localmente con caché reciente, registra la transacción, y sincroniza con el central cuando puede. La consistencia eventual es aceptable aquí; la latencia de tap, no.
2. Caché agresivo de datos críticos
Saldos de usuarios, listas de productos por barra, precios por evento. Todo eso vive en caché lo más cerca posible del lector. Sin caché bien pensado, cada tap genera una llamada a la base de datos, y la base de datos se convierte en el cuello de botella en el primer pico.
3. Idempotencia obsesiva
Los reintentos ocurren constantemente — por timeouts de red, por taps repetidos del camarero, por dispositivos que pierden conectividad y se la recuperan. Sin idempotencia, cada reintento es una transacción duplicada. Y los cobros duplicados en un festival generan un caos operativo que te ocupa la oficina durante días.
transaction_id = sha256(device_id + timestamp_bucket + amount)
if not redis.exists(transaction_id):
db.insert(transaction)
redis.setex(transaction_id, 300, "ok")
✓ tap duplicado ignorado · ✓ sin cobro doble
4. Observabilidad orientada a transacciones, no a infraestructura
Los dashboards genéricos de "uptime, CPU, memoria" no sirven el día del evento. Lo que sirve son dashboards específicos: transacciones por minuto, tiempo medio de tap por barra, tasa de timeout por dispositivo, saldos procesados, errores agrupados por tipo. El equipo de operaciones tiene que poder ver el evento en tiempo real desde la perspectiva del negocio, no desde la perspectiva del servidor.
5. Plan de degradación graceful
Cuando algo falla — y va a fallar — el sistema tiene que saber degradarse de forma controlada en lugar de caerse. Si la red central pierde conexión, los lectores siguen aceptando taps en modo offline durante una ventana, registran en local, y la sincronización ocurre cuando se restablece. Sin esto, una caída de 5 minutos en la red del recinto se traduce en barras paradas.
04El error que más gente comete cuando empieza en eventtech
Trasladar mentalmente arquitecturas SaaS estándar al sector de eventos. Tiene forma de "tenemos un backend que aguanta 1000 req/s, un Stripe-like para procesar pagos y una app móvil que se conecta a la API". En e-commerce esto funciona. En un festival con conectividad imperfecta, hardware NFC y 30.000 personas pagando simultáneamente, esto te garantiza problemas el primer sábado por la noche.
La diferencia mental clave: en SaaS el cliente espera. En eventos el cliente no espera, y el evento es el cliente. Diseñar a partir de esa premisa cambia decisiones desde el primer día — no se compensa con optimización tardía.
05Qué deben buscar las empresas que evalúan plataformas eventtech
Preguntas correctas a un proveedor
- ¿Cuál es la latencia objetivo de tap? Pide número concreto. Si la respuesta es "depende", desconfía. Lo serio está en torno a 500-700 ms en condiciones normales.
- ¿Qué pasa si la red central cae durante el evento? El sistema serio sigue aceptando pagos en modo offline durante una ventana, no se cae. Pide demostración del modo degradado.
- ¿Qué dashboards veré durante el evento? Si solo te enseñan dashboards de servidor (CPU, memoria), no entienden el sector. Tiene que haber dashboards de negocio en tiempo real.
- ¿Qué hardware soportan y por qué ese hardware? Diferentes lectores tienen distintas latencias y autonomías. La elección de hardware no es accesoria.
- ¿Cómo se gestiona la idempotencia y la conciliación post-evento? Pide ver un ejemplo real de informe de conciliación de un evento previo.
- ¿Qué eventos referencia tienen del tamaño del mío? Un proveedor que ha operado eventos de 5.000 personas no equivale a uno que ha operado eventos de 50.000.
06Caso real: Bracelit y los aprendizajes en directo
Cofundamos Bracelit en 2016 y la plataforma terminó procesando más de 25M€ en transacciones en más de 450 eventos. Algunas referencias: Mutua Madrid Open, Solheim Cup 2023, Copa del Mundo de Cyclo-Cross en Benidorm. Ganamos el Programa Minerva (Vodafone + Junta de Andalucía) y aparecimos en El País, Europa Press y Alhambra Venture.
Lo que más nos enseñó no fueron los eventos grandes — fueron los pequeños fallos en eventos medianos donde aprendíamos la diferencia entre lo que parecía aguantar en pruebas y lo que realmente aguantaba en una barra a las 22:00 con tres camareros y cola. Cada incidente operativo se convertía en una decisión arquitectónica para el siguiente evento. Esa iteración compactada en el tiempo es lo que diferencia una plataforma eventtech madura de una que parece bien sobre el papel.
07Conclusión
En pagos NFC en eventos, la latencia no es una métrica técnica más. Es la variable que decide cuánto factura el evento, qué experiencia tiene el asistente y si la plataforma se contrata otra vez al año siguiente. Diseñar para 500 ms reales en condiciones adversas es radicalmente distinto a diseñar para 500 ms en pruebas controladas.
Si estás construyendo o evaluando producto eventtech, en Nirmana aplicamos esta experiencia a empresas que construyen tecnología para eventos en directo. Hablemos.
