~/case-studies
Data Pipeline
Pipeline de sincronización multi-canal de ticketing
Sincronizar ventas, asientos e inventario entre varias plataformas de ticketing sin duplicados, sin discrepancias y con observabilidad real.
duración · MVP en 4 semanas · mantenimiento continuoequipo · 1 persona
El reto
- ▸Cuatro plataformas de ticketing vendiendo el mismo evento, cada una con su API, formato y reglas de cancelación.
- ▸Asientos sincronizados manualmente entre canales con riesgo de doble venta del mismo asiento.
- ▸Discrepancias contables entre lo que reportaban las ticketeras y lo que llegaba al banco.
- ▸Cero visibilidad de qué canal estaba vendiendo qué evento en tiempo real.
La solución
- ▸Pipeline TypeScript que normaliza cada API en un modelo común y guarda en PostgreSQL con dedupe por hash.
- ▸Reservas de asientos serializadas con Redis para garantizar que un mismo asiento no se vende dos veces.
- ▸Reconciliación contable automática diaria contra el extracto del banco.
- ▸Dashboard de observabilidad: estado de cada canal, latencia, errores, ventas por hora.
Stack
TypeScriptNode.jsPostgreSQLRedisPM2CronBullMQ
Impacto
- ▸Cero duplicados detectados en producción tras varios meses.
- ▸Reconciliación contable que cuadra sin intervención manual.
- ▸Visibilidad en vivo del rendimiento por canal y por evento.
- ▸Equipo financiero deja de pelearse con discrepancias entre informes de ticketeras.
Aprendizajes
- ▸Cada API de ticketing tiene su propio concepto de "venta confirmada". Hay que mapear caso por caso, no por documentación.
- ▸Dedupe por hash es más fiable que por ID externo. Los IDs cambian, el hash de los campos clave no.
- ▸Observabilidad desde el día 1. Un pipeline silencioso cuando falla cuesta más que el desarrollo.