El finde largo en que el hotel atendió a la mitad

Una cadena de tres hoteles. Un fin de semana largo. 9.700 reservas intentadas y 4.100 cerradas.

Las 5.600 que faltan no fallaron por su propia causa. Casi todas tenían la habitación libre y el pago válido.

Lo que pasó fue esto, y son tres cosas encadenadas.

Una. El conector de portales de venta, el que sincroniza disponibilidad con las agencias, devolvió errores intermitentes durante 14 horas. No una caída limpia: errores salteados. El servicio de reservas lo llamaba dentro del mismo pedido, así que cada reserva que tocaba un error moría con él. También las reservas directas de la web del hotel, que no tenían nada que ver con ningún portal.

Dos. Nadie pensó en sacar esa llamada del camino, porque sacarla sin más significa dejar de sincronizar, y dejar de sincronizar significa sobrevender. La sincronización tolera diez minutos de demora sin problema. Lo que no tolera es perderse: una sobreventa en fin de semana largo es un huésped en la puerta a las once de la noche.

Tres. Durante esas 14 horas tampoco se pudo consultar ninguna reserva existente. Ni desde la web ni desde la recepción del hotel. El único camino hasta el dato pasaba por el mismo servicio que se estaba muriendo, así que hubo gente con reserva confirmada discutiendo en el mostrador con alguien que tampoco la podía ver.

El equipo tiene 8 unidades operativas y hoy usa 3.

Rearmá el sistema entero. Este ejercicio junta el nivel: el error de una integración externa no puede propagarse a la operación propia; aislar ese fallo no puede significar apagar la función que fallaba; y consultar una reserva no puede depender de la misma pieza que las crea, sin borrar esa pieza, que es la que escribe.