Hemos duplicado una reserva en nuestro sistema de Málaga. ¿Cómo se evita?

En la base de datos, no en la aplicación. Comprobar la disponibilidad y después escribir la reserva como dos sentencias separadas deja una ventana en la que ambas peticiones ven la habitación libre, y con carga esa ventana se acierta con regularidad. Las vías fiables son una restricción de exclusión sobre el rango de fechas en PostgreSQL, o una transacción que bloquee la fila de la unidad antes de escribir en MySQL. Las comprobaciones en código reducen la frecuencia y no eliminan la posibilidad, que es la peor categoría de fallo que se puede publicar.

¿Por qué a algunos huéspedes se les desplaza la reserva un día?

Porque la entrada se guardó como timestamp y luego se convirtió a una zona horaria. Una entrada es una fecha de calendario - el 14 es el 14 tanto si reserva desde Dublín como desde Dubái - y guardarla como tipo fecha en vez de fecha-hora elimina toda esa familia de fallos. Las tarifas por noche, las estancias mínimas y los plazos de cancelación se cuentan en días, así que una fecha que se mueve por horas corrompe la aritmética y no solo la visualización.

¿Cómo se deben modelar las tarifas de temporada?

Como periodos con un orden de prelación, no como una columna de la unidad. Una tarifa base, una temporada, una oferta y un ajuste de última hora pueden aplicarse a la misma noche, así que el modelo necesita rangos de fechas, un orden definido cuando se solapan, y el precio por noche resuelto guardado en la reserva. Recalcular una reserva antigua con la tabla de tarifas de hoy es como un huésped acaba con una confirmación y una factura que no coinciden.

Nuestro channel manager envía la misma reserva dos veces.

Es comportamiento esperado, y el sistema tiene que absorberlo. El identificador de reserva del canal se convierte en una restricción única, así que la segunda entrega la rechaza la base de datos en vez de crear una reserva fantasma. Lo mismo vale para cancelaciones que llegan antes de la reserva que cancelan, que ocurre más de lo que debería y es sobrevivible si cada mensaje se procesa contra un identificador y no por orden de llegada.

Laravel en Málaga

Desarrollo Laravel en Málaga para reservas y alquiler

Una agencia Laravel en Málaga para hoteles y operadores de alquiler. Dos huéspedes reservando la última habitación, rangos de fechas que no deben solaparse, y una entrada que no es un timestamp.

Actualizado el 4 de noviembre de 2026

Un sistema de reservas de Málaga maneja una cantidad modesta de datos y un problema de verdad difícil: dos personas intentando llevarse la misma habitación en el mismo momento.

Eso es poco habitual. La mayoría de las aplicaciones se complican al crecer los datos; un sistema de reservas es difícil a cualquier tamaño, porque la corrección depende de lo que pasa entre dos sentencias y no de cuántas filas hay. Todo lo demás de estos sistemas - tarifas, canales, calendarios de limpieza - es trabajo corriente apoyado sobre esa única cuestión.

La disponibilidad en Málaga es una carrera, y la tiene que ganar la base de datos

La forma natural de escribir una reserva es también la rota. Comprobar si la unidad está libre para esas fechas, y luego insertar la reserva.

Entre esas dos sentencias, una segunda petición puede hacer la misma comprobación y obtener la misma respuesta. Con tráfico normal pasa lo bastante poco como para parecer un misterio; durante una promoción pasa a diario. El resultado que ve el huésped es una reserva confirmada que no se puede cumplir, y ninguna cantidad de código cuidadoso cierra ese hueco.

La solución es que la base de datos se niegue. PostgreSQL admite una restricción de exclusión que rechaza cualquier reserva cuyo rango de fechas se solape con otro de la misma unidad, con lo que la garantía vive donde realmente se arbitra la concurrencia. En MySQL el equivalente es una transacción que bloquea la fila de la unidad antes de comprobar, así que la segunda petición espera en vez de seguir con información obsoleta. En ambos casos el trabajo de la aplicación pasa a ser gestionar el rechazo con elegancia, que es bastante más fácil de acertar.

Una entrada es una fecha de Laravel, no un momento

Es el segundo defecto recurrente en los sistemas de alquiler de Málaga, y es más sutil de lo que parece.

Guardada como timestamp, una entrada adquiere una zona horaria, y una zona horaria convierte el 14 en el 13 a las 23:00 para alguien. Las tarifas por noche cuentan días. Las estancias mínimas cuentan días. Las ventanas de cancelación gratuita cuentan días. Una vez que la fecha se mueve por horas, cada uno de esos cálculos falla por uno en algunos casos y acierta en otros, que es el tipo de fallo más difícil de reproducir.

Una columna de fecha guarda una fecha. Dinero y fechas son las decisiones que no se deshacen cubre las dos mitades, y en un sistema de reservas llegan juntas a la misma tabla.

Las tarifas de temporada de Málaga pertenecen a periodos

Un precio por noche rara vez es un número. Hay una tarifa base, una temporada, quizá una oferta, quizá un ajuste de última hora, y una estancia mínima que solo se aplica en agosto.

Modelado como columnas de la unidad, esto se vuelve inmantenible en una temporada. Modelado como periodos con fechas y una prelación definida, sigue siendo explicable - y, sobre todo, el precio resuelto por noche se guarda en la reserva en vez de recalcularse después. Un huésped con una confirmación por un importe y una factura por otro es un problema de confianza, no de contabilidad, y lo causa enteramente recalcular el pasado con las reglas de hoy.

Una política de cancelación de Málaga es una regla con fechas dentro

Cancelación gratuita hasta siete días antes de la llegada, la mitad de la estancia dentro de esos siete días, nada devuelto dentro de cuarenta y ocho horas. Eso no es un campo en una reserva. Es una política con umbrales, y los umbrales se miden desde una fecha en la zona horaria del propio alojamiento.

La política que se aplica es la que estaba en vigor cuando se hizo la reserva, fijada a la reserva en ese momento. Cambiar las condiciones de cancelación de la temporada que viene no debe cambiar en silencio lo que un huésped aceptó en marzo, y el único montaje que lo garantiza es guardar la política resuelta con la reserva y no una referencia a una política que se puede editar.

Que es además lo que hace calculable la devolución sin una conversación. Una cancelación en un momento dado cae en un tramo, el tramo da un importe, y el importe se deriva en lugar de decidirse. Cuando una persona lo anula - una devolución de cortesía fuera de política - eso se registra como una excepción con su motivo, de modo que el patrón de excepciones sea visible para quien fija la política.

Las tarifas no reembolsables van al lado y requieren cuidado, porque son un producto distinto y no un indicador. Un huésped que reservó una tarifa no reembolsable con descuento ha comprado otra cosa, y mezclar las dos en una estructura de tarifas con un booleano es la forma de emitir una devolución que no tocaba.

Las actualizaciones de canales en Málaga llegan tarde y se pisan entre sí

Un alojamiento se vende por su propia web y por tres o cuatro intermediarios, y cada uno de ellos guarda una copia de la disponibilidad. Las copias no coinciden, de forma continua, y la única pregunta es hasta qué punto.

La dirección que causa problemas es la entrante. Dos reservas de la última unidad llegan de dos canales en el mismo minuto, y ninguno de los dos sabía del otro. Eso es un sobrecupo y no se evita empujando inventario más rápido - el alojamiento o guarda un colchón, o acepta la exposición a propósito, o reparte inventario por canal de modo que cada canal solo pueda vender lo que se le dio. Las tres son decisiones comerciales legítimas y el sistema tiene que poder expresar la que elija el operador.

Hacia fuera, el problema es el orden. Las actualizaciones enviadas a un canal pueden procesarse en otra secuencia o descartarse sin avisar, así que la aplicación no puede dar por hecho que lo último que envió es lo que el canal cree. Lo que funciona es enviar el estado absoluto para un rango de fechas en lugar de una diferencia, de modo que un mensaje perdido lo corrija el siguiente en lugar de dejar un desvío permanente, y reconciliar periódicamente leyendo lo que el canal cree tener.

Cada intercambio con cada canal conviene registrarlo, con el contenido, porque la conversación que sigue a un sobrecupo es sobre qué se envió y cuándo. Un registro que pueda responder eso en un minuto vale varias veces el almacenamiento que cuesta - y es la única manera de decirle a un canal que publicó una disponibilidad que nunca se le dio.

En lo comercial

El alcance se fija por escrito antes de empezar y se presupuesta por proyecto. El marco de España - facturación certificada, reglas fiscales territoriales, requisitos del sector público - está en la página de mercado de España.

Factura la Codefacture Yazılım A.Ş. en Türkiye, en euros, por transferencia, sin IVA turco bajo la exención de servicios exportados.