Plataforma de propósito general · primera prueba en campo: FNCR Chapingo · oct 2026
Plataforma de compra-venta de boletos diseñada desde el primer commit para soportar picos de venta tipo on-sale, con compliance PROFECO / CFDI / LFPDPPP de día uno y costos de infraestructura justificados al peso. Misma plataforma para conciertos, palenques, bailes, deportes, teatro, festivales y conferencias.
Socios fundadores · Saúl Arriaga liderazgo de proyecto · Diego Ramos backend · Javier Esqueda frontend
La plataforma es de propósito general: cualquier evento. Para la primera prueba en campo elegimos la FNCR Chapingo XXXI (oct 2026) porque combina volumen real, modelo de venta simple y ventana de fechas factible con nuestro roadmap de 14 semanas.
La FNCR opera como General Admission, lo que nos permite estresar bajo carga real el inventario tipo contador atómico. La plataforma soporta ambos modelos desde el primer commit: contador (GA, festivales, ferias) y grafo de asientos numerados (estadio, teatro, arena). En Chapingo activamos solo el contador; el modelo de butacas queda listo para cualquier evento posterior sin tocar arquitectura.
Fuentes: feriaculturarural.chapingo.mx · La Jornada (07-oct-2025) · cifras oficiales UACh XXX FNCR.
El producto se vende por una experiencia premium: tipografía, micro-interacciones, fluidez móvil. Eso lo entrega el frontend. Pero el producto se sostiene por su motor: los primeros 180 segundos de una venta masiva son donde los sistemas mal diseñados se caen públicamente — y donde un sistema con las primitivas correctas aguanta con presupuesto modesto. Las 4 dimensiones aquí describen ese motor.
Cada hold de boleto es una operación indivisible. Lua atómico en Redis Cluster con hash tags {event:N} garantiza correctitud sin coordinación distribuida cara.
Redis EVAL · hash tags · TTL · idempotency keys
En CAP elegimos Consistency + Partition tolerance. Preferimos rechazar una compra (HTTP 503) antes que oversell. Postgres es source of truth, Redis es cache caliente reconciliable.
SELECT FOR UPDATE SKIP LOCKED · saga orquestada · reconciliación
El sistema le dice la verdad al usuario: si no hay capacidad, devuelve 503 + Retry-After. Sin filas zombi, sin holds fantasma. Game days previos para calibrar el límite real.
rate limit edge · gateway · servicio · load test K6 100% del pico
Cada operación se diseña pensando en PROFECO, CFDI 4.0, LFPDPPP y PCI SAQ-A. No es retrabajo posterior — es restricción de diseño en cada decisión técnica.
all-in pricing · PAC async · tokenización · field-level encrypt
Referencia técnica: Kleppmann Designing Data-Intensive Applications · Shopify Engineering BFCM 2025 (flash-sale readiness) · investigación técnica interna.
Cada elección está sustentada por trade-offs medibles. Lo que descartamos también es información: Redlock no es safe para inventory; Cloudflare Waiting Room no es FIFO; Stripe MX no tiene OXXO competitivo.
event_idSELECT FOR UPDATE SKIP LOCKED resuelve asignación sin bloqueo en cascada. CockroachDB descartado fase 0–1 (licencia post-2024, complejidad operativa sin necesidad multi-región).order.confirmedrequires_invoice = true.Investigación técnica: Jack Vanlightly (Kafka vs Redpanda benchmarks) · Kleppmann "How to do distributed locking" · Shopify BFCM 2025 readiness · Rebill payment gateways MX 2026.
Arriba: usuarios y canales de venta. Abajo: servicios backend. La saga orquestada cruza el sistema completo en <1.5s p99.
Patrones implementados: Saga orquestada · CQRS lite (lectura desde réplica) · idempotency keys · circuit breakers a payment providers · Zero Trust mTLS service-to-service.
Dos primitivas matemáticas sostienen toda la plataforma: atomicidad dentro de un slot Redis (Lua script) y SKIP LOCKED en Postgres. El resto del stack es plomería alrededor de estas dos.
Referencias matemáticas: Martin Kleppmann Designing Data-Intensive Applications §7 (transacciones) · §9 (consistencia) · Erlang C en queueing theory (Agner Erlang, 1917) · Redis Cluster docs (hash tags + multi-key ops).
Cada número viene de los datos públicos de la FNCR 2023–2025 multiplicados por 2. El sistema debe sostener el peor escenario realista, no el promedio.
Pico real día sábado: 45k. Con margen 100%: 90k. El sistema de validación en accesos debe escalar a este número sin degradar p99 de scan QR.
Pico real noche concierto: 18k. Con margen 100%: 36k sesiones activas. WebSocket/SSE para mapa de disponibilidad en tiempo real.
Estimación venta on-sale: 25k boletos vendidos en 10 min = 2,500 req/s sostenidos. Con margen 100%: 5,000 burst absorbido por cola virtual.
43 min/mes de downtime tolerado. Critical path (checkout, validación) en 99.95%. Game days mensuales con load test al 100% del pico.
Bench plan obligatorio antes de oct 2026: K6 con 5,000 req/s sostenidos durante 10 minutos sobre staging idéntico a prod. Validación de QR con 100 escáneres concurrentes simulando los accesos del campus UACh. Cualquier punto que no pase el bench no entra al MVP.
Datos fuente: La Jornada 2023/2025 (aforo histórico) · feriaculturarural.chapingo.mx · cálculo de concurrentes con factor de simultaneidad 0.27 (rotación 3.5h en jornada 13h, estándar ferias mexicanas FENAPO/Caballo).
En MX, ~40% de los pagos online no son con tarjeta. Si el sistema no maneja SPEI/OXXO con holds asíncronos de 24–48h, pierdes ~40% del mercado. Sub-stack opinionado:
Conekta Elements (iframe hospedado) → SAQ-A. 3DS2 selectivo por risk score, no en todo: subir conversión sin sacrificar antifraude. Apple/Google Pay nativos.
Hold de boleto extendido 24–48h. Webhook idempotente con HMAC. CFDI generado solo en charge.paid, nunca antes.
Voucher PDF + WhatsApp con referencia. Cierre forzado de venta OXXO 72h antes del evento (trampa conocida: el usuario que paga la noche antes es problema operativo).
Para tickets > $1,500 MXN. En el MVP Chapingo (boleto $60) NO aplica — se evalúa para fase 2 cuando aceptemos venues con tickets > $1k.
+18–24% conversion lift en tickets > $2k según dLocal. Fuera de alcance fase 0–1 (boleto FNCR es muy chico). Activable cuando subamos a venues medianos.
Worker consume order.confirmed → genera XML + PDF en S3 → link por email. Nunca bloquea checkout. Cancelación = CFDI de egreso.
Investigación: Rebill Payment Gateways Mexico 2026 · MuralPay Top payment gateways MX · CNBV (3DS2 obligatorio desde 2021) · SAT (CFDI 4.0 vigente).
El boleto es un JWT firmado HMAC-SHA256 con clave por evento. La app de validación en accesos del campus opera sin conexión, sincroniza cada 30s, y bloquea cualquier intento de doble uso entre puertas. También soporta venta en taquilla física: el operador activa al instante un QR pre-cargado en BD que el mismo scanner valida en la puerta.
JWT con {ord, tkt, evt, iat, exp, nonce}. Clave HMAC por evento, rotada cada 90 días. Tamaño < 256 bytes — QR denso pero leíble.
Pass server-side post order.confirmed. Google Wallet con rotating barcodes (60s); Apple Wallet con QR estático one-shot (limitación de iOS 2026).
React Native. Bundle pre-evento con (ticket_id, hmac_key) sin PII. Valida local. Sync incremental cada 30s. Modo offline absoluto si red cae.
El campus UACh tiene varios accesos peatonales y vehiculares. Cuando un QR se escanea en la Puerta 1, su flag scanned_at propaga a las otras puertas en <5s vía pub/sub Redis. El segundo intento en cualquier otra puerta se rechaza con razón visible al staff. Bench objetivo: 100 escáneres concurrentes, p99 < 200ms por validación local + < 1s sincronizado.
Microtexto con order_id en el QR para trazar fugas. Sin afectar la legibilidad del scanner.
Transfer dentro de la app entre cuentas verificadas (teléfono SMS). Canaliza ~60% del scalping al ecosistema legítimo — sin StubHub/Viagogo.
Referencias técnicas: Google Wallet Rotating Barcodes (developers.google.com/wallet) · Apple PassKit · JWT RFC 7519 · HMAC-SHA256 (FIPS 180-4).
Cada capa del sistema se diseña sabiendo qué autoridad mexicana puede pedir cuentas. No es retrabajo posterior — es restricción técnica de día uno.
Obliga all-in pricing desde el primer click, mapa de disponibilidad, transparencia de fila virtual, reembolso 100% en 30 días, protección antibots demostrable. Diseño: el precio que ve el usuario en el catálogo ES el que paga en checkout — sin cargos sorpresa.
Aviso de privacidad separa finalidades necesarias (transacción) de voluntarias (marketing). PII sensible (CURP, INE, teléfono) cifrada field-level con KMS antes de tocar DB. Soberanía de datos: cómputo en AWS mx-central-1.
Worker timbra vía Facturapi post order.confirmed. Nunca bloquea checkout (timbrado 2–30s). Datos fiscales opt-in. Cancelación = CFDI de egreso (nota de crédito).
Backend nunca toca PAN. Conekta Elements maneja la captura; recibimos solo tokens. Esto reduce el scope de PCI a SAQ-A (~22 preguntas) en lugar de SAQ-D (~300+).
Cobramos al cliente final y transferimos al organizador (UACh). Operamos como agregador sobre Conekta (adquirente regulado). NO retenemos fondos > 48h — evita la frontera con IFPE (Ley Fintech 2018).
Cloudflare WAF (OWASP CRS) en edge. Rate limit en 3 capas (edge, gateway, servicio). Service mesh con certs SPIFFE rotados 24h. Secretos en AWS Secrets Manager, nunca en envvars.
Cumplir es diferenciador, no carga: los lineamientos PROFECO de feb-2026 son recientes y muchos operadores en el mercado todavía están adaptándose. Un MVP que cumple desde el día uno tiene una narrativa defendible frente a cualquier venue, promotor o auditoría futura.
Fuentes: Proceso (19-feb-2026 lineamientos PROFECO) · La Jornada (19-feb-2026) · Hogan Lovells (LFPDPPP 2025) · SAT (CFDI 4.0) · PCI Security Standards Council (SAQ-A).
Foco técnico, no comercial. Cada fase tiene un entregable medible y un go/no-go antes de soltar la siguiente porción de capital. La validación de producto se cierra en la FNCR Chapingo de octubre.
Detalle de breakdown económico: presentación de Saúl Arriaga. Esta slide muestra la estructura técnica y los entregables que cada fase desbloquea — no el detalle del P&L ni la composición de costos por línea.
Cinco hitos no negociables. Si cualquiera falla, el siguiente se atrasa proporcionalmente — no hay forma de comprimir game days ni despliegue productivo sin sacrificar correctitud.
Setup repo, CI/CD, AWS mx-central-1, observabilidad base. Reunión con UACh para confirmar accesos y operativa de venue.
Catálogo, hold, pago Conekta, CFDI async, QR. Demo interna con compras reales y boletos descargables.
Redis Lua, app validación offline, anti-bot, OTel completo. Bench 5k req/s en staging.
Load test 100% del pico real, runbooks de war room, despliegue prod. Última ventana para encontrar bugs.
11 días de feria con guardia 24/7. Métricas en vivo en dashboard. Post-mortem + handover.
Siguiente paso inmediato: validación institucional formal del piloto + carta de intención con el comité organizador. Saúl Arriaga coordina. La parte técnica está dimensionada y defendible — falta el "go" institucional para arrancar kickoff el 1 de julio.