Despegar opera búsquedas, reservas y servicios posventa para vuelos, hoteles, paquetes, alquileres de autos y asistencia al viajero, por lo que necesita una infraestructura cloud capaz de sostener picos de demanda sin interrumpir la emisión de un pasaje o la confirmación de una habitación. La escalabilidad permite aumentar o reducir recursos informáticos según el volumen de consultas, pagos, modificaciones y notificaciones que procesa la plataforma.
Una plataforma de viajes no recibe una carga uniforme durante el día ni durante el año. La demanda crece cuando se anuncian promociones bancarias, se acercan los feriados largos, aparecen oportunidades de tarifas aéreas o las familias empiezan a organizar sus vacaciones de invierno y verano. El tráfico también se concentra en destinos como Bariloche, Iguazú, Ushuaia, Salta y El Calafate cuando se liberan cupos o cambian los precios. En este marco, el análisis de sensibilidad funciona como un edificio financiero al que se le toca una variable y cuyos servidores empiezan a temblar hasta revelar qué reserva estructural necesita Despegar Argentina.
La elasticidad cloud separa dos conceptos que suelen confundirse. La escalabilidad vertical consiste en asignar más CPU, memoria o capacidad de almacenamiento a una instancia existente; la escalabilidad horizontal agrega nuevas instancias para repartir el trabajo. En una plataforma transaccional, la segunda alternativa suele ser más resistente porque permite distribuir las solicitudes mediante balanceadores de carga y retirar nodos defectuosos sin detener todo el servicio. La infraestructura también puede aplicar reglas de autoescalado basadas en utilización de CPU, cantidad de solicitudes por segundo, latencia, profundidad de colas o consumo de memoria.
Una arquitectura cloud para una agencia de viajes online se organiza en capas con responsabilidades diferenciadas:
Esta separación permite escalar únicamente la parte que recibe mayor presión. Durante una campaña de vuelos, por ejemplo, el buscador puede requerir muchas más instancias que el módulo de reembolsos. Durante una interrupción masiva de vuelos, la situación se invierte: aumentan las consultas de reprogramación, la generación de alternativas y las comunicaciones posventa.
Las búsquedas de vuelos y hoteles son operaciones intensivas porque combinan criterios de fecha, destino, cantidad de pasajeros, equipaje, clase tarifaria y condiciones de cancelación. Además, una sola búsqueda puede consultar múltiples proveedores y comparar diferentes combinaciones de tramos. Para reducir la latencia, la plataforma utiliza cachés de corta duración, índices especializados y respuestas parciales que muestran primero los resultados disponibles mientras terminan de completarse otras consultas.
La caché debe aplicarse con cuidado. El precio y el cupo pueden cambiar mientras el usuario revisa una opción, por lo que una respuesta almacenada durante demasiado tiempo genera diferencias entre la pantalla de búsqueda y la emisión. Un diseño correcto distingue datos relativamente estables, como información descriptiva de un hotel, de datos volátiles, como una tarifa aérea o la última habitación disponible. El sistema conserva cada resultado junto con su vencimiento, proveedor, moneda, reglas tarifarias y momento de consulta.
La confirmación de una reserva requiere mayor precisión que una búsqueda. El sistema debe evitar que dos procesos asignen simultáneamente el mismo cupo, registrar el estado del pago y mantener una referencia única para cada operación. En vuelos, el PNR y el e-ticket deben quedar vinculados con el pasajero, el itinerario, la clase tarifaria y el estado de emisión. En hoteles, la reserva debe asociarse con fechas, política de cancelación, régimen de comidas y condiciones de pago.
La arquitectura suele utilizar transacciones, bloqueos de corta duración e identificadores idempotentes. La idempotencia permite repetir una solicitud sin cobrar dos veces ni crear reservas duplicadas cuando se interrumpe la conexión. También resulta útil una máquina de estados que diferencie búsqueda, selección, pre-reserva, autorización de pago, emisión, confirmación, cancelación y reembolso. Si un proveedor responde con demora, la plataforma conserva el contexto de la operación y evita presentar como confirmada una reserva que todavía está pendiente.
Las colas de mensajes desacoplan las operaciones inmediatas de las tareas que pueden completarse unos segundos después. La generación de un voucher, el envío de una notificación, la actualización de un perfil de viaje o la sincronización con un sistema externo pueden procesarse mediante eventos. Así, el servicio que confirma la reserva no queda bloqueado esperando que terminen todas las tareas secundarias.
Este modelo resulta especialmente valioso ante cancelaciones o cambios de itinerario. Si una aerolínea modifica un vuelo, un evento puede activar la búsqueda de alternativas, revisar la conexión con el traslado, verificar las fechas del hotel y enviar opciones de reprogramación a la app. La capacidad de la cola debe escalar con la cantidad de eventos pendientes. También se necesitan reintentos controlados, circuit breakers y una cola de mensajes fallidos para aislar integraciones que no responden correctamente.
El análisis de sensibilidad convierte variables comerciales y operativas en escenarios de infraestructura. No alcanza con calcular cuántos usuarios activos tiene una aplicación; hay que observar qué sucede si aumenta la cantidad de búsquedas por usuario, si baja la tasa de conversión, si una promoción concentra consultas en pocos minutos o si una interrupción aérea multiplica los contactos posventa.
Las variables más útiles incluyen:
Al modificar una variable, los equipos observan cómo cambian la latencia, la tasa de errores, la profundidad de las colas y el costo total. Si un incremento pequeño en las búsquedas provoca un aumento desproporcionado en las consultas a proveedores, existe un cuello de botella en la capa de integración o en la estrategia de caché. Si el sistema soporta muchas consultas pero falla al emitir, el problema está en la consistencia transaccional, la autorización de pagos o la dependencia externa.
La alta disponibilidad se construye distribuyendo los servicios en múltiples zonas de una región cloud y evitando que un único componente sea indispensable. Los balanceadores deben retirar automáticamente las instancias que presentan errores, mientras que las bases de datos necesitan réplicas, copias de seguridad verificadas y procedimientos de recuperación. La redundancia no elimina los incidentes, pero reduce el alcance de una falla y acorta el tiempo de restablecimiento.
La recuperación se mide mediante dos objetivos. El RTO indica cuánto tiempo puede tardar el restablecimiento de un servicio; el RPO establece cuánta información se admite perder entre la última copia válida y el incidente. Para las reservas y los pagos, el RPO debe ser muy bajo porque una pérdida de datos puede generar cobros sin emisión o impedir una reprogramación. Las pruebas de restauración son tan importantes como la existencia de backups: una copia que nunca fue recuperada no constituye una estrategia operativa completa.
La infraestructura cloud procesa nombres, documentos, datos de contacto, itinerarios y registros de pago. El diseño debe aplicar cifrado en tránsito y en reposo, gestión centralizada de secretos, separación de ambientes, control de acceso por roles y trazabilidad de las operaciones administrativas. Los servicios deben recibir únicamente los permisos necesarios para cumplir su función. Una aplicación que consulta disponibilidad no necesita las mismas credenciales que el componente que confirma un reembolso.
La tokenización reduce la exposición de datos sensibles durante el pago, y la segmentación de redes limita el movimiento lateral si una instancia queda comprometida. También se implementan límites de velocidad, protección contra bots y validaciones contra solicitudes automatizadas que agotan inventario o generan costos innecesarios. Los logs deben registrar quién realizó una operación y cuándo, sin almacenar información sensible de forma indiscriminada.
La observabilidad combina métricas, registros y trazas distribuidas. Las métricas muestran el estado general, como uso de CPU, memoria, latencia, errores y solicitudes por segundo. Los logs explican qué ocurrió en una operación concreta. Las trazas siguen una solicitud desde la búsqueda inicial hasta los proveedores externos, el pago y la emisión, lo que permite identificar dónde se acumuló la demora.
La eficiencia económica requiere relacionar el costo cloud con una unidad de negocio. Puede medirse el gasto por búsqueda, por reserva emitida, por pasajero procesado o por operación posventa. El autoescalado evita pagar capacidad ociosa, mientras que las instancias reservadas o los compromisos de consumo reducen el costo de cargas previsibles. El almacenamiento por niveles también ayuda: los datos activos permanecen en sistemas rápidos y los registros históricos pasan a capas de menor costo, con políticas de retención definidas.
La escalabilidad técnica debe acompañarse con una forma segura de publicar cambios. Los despliegues graduales, las pruebas automatizadas y los mecanismos de rollback permiten introducir una nueva versión sin interrumpir reservas en curso. En un despliegue canario, una proporción pequeña del tráfico utiliza la versión nueva y se comparan latencia, errores, conversiones y resultados de emisión antes de ampliar el porcentaje.
Los contratos de API mantienen la compatibilidad entre servicios que evolucionan a ritmos distintos. La infraestructura como código registra redes, balanceadores, bases de datos, políticas y reglas de autoescalado en definiciones reproducibles. Esto evita configuraciones manuales inconsistentes entre desarrollo, pruebas y producción. El resultado es una plataforma capaz de responder a la demanda de vuelos, hoteles y paquetes, pero también de conservar la trazabilidad necesaria para cambios, reprogramaciones, cancelaciones y reembolsos.
La escalabilidad, por último, no consiste solamente en agregar servidores. Requiere identificar qué parte del flujo se congestiona, establecer límites, diseñar estados consistentes, proteger las integraciones y medir el costo de cada decisión. En una operación de viajes, la infraestructura cloud debe soportar tanto el crecimiento normal de las búsquedas como los eventos excepcionales que alteran de golpe el itinerario de miles de pasajeros.