Un operador aéreo de la región nos llamó con un problema que suena chico y no lo es: la factura mensual de su capa de datos en tiempo real no bajaba, y cada intento de optimizarla terminaba en la misma disyuntiva incómoda — o se pagaba de más, o la información llegaba tarde a la pista.
Rediseñamos el sistema que mantiene sincronizada la información operativa de cada vuelo y la distribuye en vivo a las tablets del personal en tierra y a bordo. La carga diaria de sincronización bajó entre 95% y 98.75% en los bloques de mayor volumen, y la lectura sobre Firebase Realtime Database se redujo en un factor de ~420x — sin perder un solo segundo de frescura en pantalla.
01
El problema no era el volumen. Era la cadencia plana.
El sistema anterior trataba a todos los vuelos igual, todo el tiempo. Un vuelo que sale a las 22:00 se consultaba con la misma insistencia a las 06:00 de la mañana que a las 21:40, cuando efectivamente está pasando algo. Multiplicado por cada vuelo elegible, por cada endpoint del sistema de reservas y por cada hora del día, eso produce cientos de miles de refreshes diarios de los cuales una fracción mínima descubre un cambio real.
Es el patrón más caro que existe en integraciones aeronáuticas: pagar frecuencia constante para capturar eventos que se concentran en ventanas muy angostas.
Y no se resuelve simplemente bajando el polling. Bajar la frecuencia de forma pareja abarata la operación y rompe el producto: el momento en el que el dato tiene que ser exacto —el cierre de puerta, el último cambio de asiento, el pasajero que no se presentó— es exactamente el momento en el que ese polling relajado llega tarde.
02
Primera decisión: cadencia adaptativa por proximidad operativa
Rediseñamos la sincronización como una escalera de etapas anclada a la hora estimada de salida de cada vuelo. Cada vuelo avanza por esa escalera solo, según cuánto falta para su operación, y cada etapa tiene su propio ritmo. El principio es simple de enunciar y sorprendentemente rico de calibrar: la frecuencia de actualización de un vuelo debe ser función de su distancia al evento, no del reloj de pared.
El efecto compuesto es contundente: el manifiesto pasó de 396,000 refreshes diarios a 4,950, y los datos de aeronave de 108,000 a 4,950. No porque el sistema mire menos, sino porque dejó de mirar donde no pasaba nada.
La consecuencia menos obvia, y la más valiosa operativamente: la calidad del dato en la hora caliente subió.
Al liberar el presupuesto de requests que se gastaba en vuelos dormidos, pudimos apretar la cadencia en la ventana crítica sin que el costo total se moviera hacia arriba.
El detalle que cambia todo: configuración al milímetro
Una escalera de etapas cableada en código es un problema nuevo disfrazado de solución. La operación aérea no es estable: cambia por temporada, por estación, por tipo de vuelo, por cómo se comporta el sistema de reservas en un mercado específico. Por eso cada etapa es configuración, no código. Para cada una se define de forma independiente:
Eso permite algo que en la práctica vale tanto como el ahorro: ajustar la política de sincronización sin desplegar. Si una estación necesita más resolución en los últimos 30 minutos, se mueve un parámetro. Si un endpoint empieza a responder lento en un horario específico, se relaja esa rama sola sin tocar el resto. Si una ruta internacional exige un dato adicional, se agrega solo donde corresponde.
03
Segunda decisión: usar Firebase para lo que Firebase hace mejor
Aquí estaba el otro gran drenaje, y era menos visible. Firebase Realtime Database es excelente en una cosa muy específica y difícil: distribuir un cambio de estado a muchos dispositivos suscritos, al instante, de forma segura y con reconexión resuelta. Cuando cambia el estado de un vuelo, todas las tablets suscritas lo reciben por push, sin que nadie pregunte. Eso es exactamente lo que una operación en pista necesita.
Lo que RTDB no es —y donde el costo se dispara— es una base de consulta para el backend. Su facturación es proporcional a los bytes descargados. Un proceso de servidor que relee el nodo raíz de vuelos en loop para saber qué vuelos tiene que procesar ahora está pagando, una y otra vez, por bajar 600 KB de datos que él mismo escribió hace treinta segundos. En números: 20,160 lecturas diarias del nodo principal, unos 362.88 GB mensuales de tráfico de bajada, casi enteramente redundante.
El espejo en memoria
Invertimos la relación. El servicio mantiene un espejo en memoria del estado de vuelos, que se hidrata con un snapshot completo y se refresca cada 30 minutos, mientras que los cambios que el propio servicio produce se aplican al espejo en el mismo momento en que se escriben.
20,160 / día → 48 / día. El snapshot raíz se refresca cada 30 minutos; el resto vive en memoria.
362.88 GB → 0.864 GB. Un factor de ~420x, con el mismo comportamiento en pantalla.
Cada componente terminó haciendo solo aquello en lo que es mejor que la alternativa.
La memoria del proceso resuelve estado caliente de alta frecuencia. Firebase resuelve distribución en tiempo real a N dispositivos con garantías de entrega y seguridad. Ninguno de los dos paga el precio de hacer el trabajo del otro.
04
El ahorro, endpoint por endpoint
Base comparable: 50 vuelos visibles por día sobre una estación, hora promedio de salida 12:00, 2 horas promedio de seguimiento en vivo. La tabla muestra el piso verificable, no el mejor escenario.
| Sistema / dato | Antes / día | Ahora / día | Ahorro |
|---|---|---|---|
| Manifiesto de vuelo | 396,000 | 4,950 | −391,050 · −98.75% |
| Detalle de pasajeros | 396,000 | 4,950 | −391,050 · −98.75% |
| Servicios especiales (SSR) | 396,000 | 4,950 | −391,050 · −98.75% |
| Inventario de tramo | 396,000 | 4,950 | −391,050 · −98.75% |
| Información de seguridad gubernamental (solo internacionales) | 396,000 | 4,950 | −391,050 · −98.75% |
| Datos de aeronave (inbound) | 108,000 | 4,950 | −103,050 · −95.42% |
| Estado de vuelo (PSS) | 14,400 | hasta 7,290 | −7,110 · −49.4% |
La cifra de estado de vuelo merece una aclaración honesta, porque es la que solemos ver mal contada en este tipo de informes: 7,290 es una cota alta, no un valor esperado. Asume que las 50 operaciones diarias son todas salidas seguidas y que cada una permanece 2 horas en vivo. Si parte de esos vuelos son llegadas, o si el tiempo real en vivo es menor, el número baja sensiblemente — en escenarios intermedios cae a 3,665 y en los más acotados a 2,915.
05
Qué significa en la factura
Con un histórico de referencia de $800 a $1,000 mensuales, la proyección del nuevo modelo se ubica en una banda muy inferior. Comunicamos $80 – $200 como estimación de trabajo, no el escenario optimista: preferimos que el número que se lleva un comité sea el que se sostiene bajo supuestos conservadores.
El ahorro directo, de todas formas, es la parte menos interesante del resultado. Lo que se ganó en paralelo:
06
Lo que nos llevamos como principio
Tres ideas que aplicamos desde entonces en cualquier sistema de tiempo real con costo por operación.
La cadencia es un recurso, y hay que presupuestarla.
No se trata de refrescar más o menos: se trata de decidir explícitamente dónde se gasta la frecuencia. Casi siempre está mal distribuida, y casi siempre el rediseño mejora costo y calidad al mismo tiempo, no uno a costa del otro.
Si una política va a cambiar, tiene que ser configuración.
Todo parámetro de sincronización que hoy está cableado es una futura ventana de mantenimiento. Externalizarlos convierte cada ajuste de semanas en minutos, y permite calibrar por estación, por ruta y por temporada sin tocar el sistema.
Cada pieza de infraestructura es insustituible en una cosa y cara en muchas.
Firebase es extraordinario distribuyendo cambios a miles de dispositivos suscritos. Es un mal lugar para que un backend vaya a leer su propio estado. Separar esos roles no requirió tecnología nueva: requirió ver dónde se pagaba dos veces por el mismo dato.
07 — Trabajemos juntos
Si estás pagando frecuencia constante para capturar eventos que ocurren en ventanas angostas, hay un caso parecido esperando en tu factura.
Flyware diseña y construye sistemas de datos operativos para aviación: sincronización en tiempo real, integraciones con PSS y plataformas de tierra y a bordo. Empezamos por medir dónde se va la cadencia — y esa medición, por sí sola, suele pagar el proyecto.
Caso de éxito · Sincronización de operaciones de vuelo. Cifras sobre base comparable de 50 vuelos/día.