Evita las reservas duplicadas: por qué fallan los sistemas, y el modelo que no puede fallar
La doble reserva casi nunca ocurre porque un calendario «se equivocó». Ocurre porque el software comprobó si una franja estaba libre, y la reservó, como dos pasos separados con un hueco entre medias — y un segundo cliente se coló por ese hueco. Cierra ese hueco y el resto del calendario puede ser tan simple o tan elaborado como quieras. Déjalo abierto, y ningún pulido en el widget de reservas evita que dos personas acaben ocasionalmente en la misma silla.
Dónde se abre de verdad la brecha
La secuencia habitual detrás de casi cualquier reserva: comprobar «¿sigue libre esta franja?», recibir un «sí», y luego escribir la reserva. Una lectura, y luego una escritura — y entre medias, por breve que sea, una ventana. Una segunda solicitud que comprueba la misma franja durante esa ventana también ve «sí, sigue libre». Ambas creen ahora que están reservando una franja libre, porque en el momento en que cada una miró, lo estaba.
No puedes saber, haciendo clic por una demo un tranquilo martes por la tarde, si la comprobación y la escritura de debajo están unidas de forma segura o peligrosamente separadas — el calendario tiene el mismo aspecto en ambos casos.
Por qué "basta con un calendario más bonito" no lo arregla
Mucho software de reservas es, por debajo del widget, un constructor de formularios genérico que nunca se diseñó para que dos personas reclamaran a la vez algo tan limitado. La selección de fecha puede ser fluida, la disponibilidad puede parecer en vivo, la pantalla de confirmación puede ser impecable — y el back end sigue comprobando con una lectura y escribiendo con una escritura aparte y posterior. El tráfico real y simultáneo encuentra la costura.
El modelo que de verdad cierra la brecha
Deja de tratar «comprobar» y «reservar» como dos operaciones: repite la comprobación de disponibilidad y escribe la reserva dentro de una única transacción de base de datos que bloquee las filas de esa franja. La solicitud que llegue primero termina su comprobación-y-escritura sin interrupción; la segunda espera su turno, y luego vuelve a comprobar contra la nueva realidad. No queda ninguna ventana en la que se pueda actuar sobre información obsoleta de «sigue disponible» — es la base de datos la que impone el orden, en vez de que el código de la aplicación confíe en que no habrá carreras.
Qué pasa en realidad cuando dos personas pulsan «reservar» a la vez
1
Las dos solicitudes llegan casi a la vez
2
Una solicitud toma el bloqueo primero
3
La primera petición vuelve a comprobar y escribe, todo a la vez
4
La segunda solicitud vuelve a comprobar la nueva situación
5
Al segundo cliente se le avisa al instante
Cómo lo resuelve Olmira
El motor de reservas de Olmira ejecuta la reverificación de disponibilidad y la escritura de la reserva como un solo paso, dentro de una única transacción de base de datos bloqueada — así que cuando dos clientes van a por el mismo hueco a la vez, una reserva se confirma y a la otra se le avisa, antes de que se mueva ningún dinero, de que la hora acaba de ocuparse. El mismo bloqueo cubre el recurso subyacente, no solo el servicio que se vende, de modo que dos servicios distintos que comparten una sala o una persona del equipo tampoco pueden reservarla dos veces a la vez sin que nadie se entere. Una protección aparte, más pequeña, atrapa el accidente más habitual — el mismo cliente haciendo doble clic en «reservar» — y le pide que confirme en lugar de crear dos citas en silencio. Mira cómo encaja todo en la página de reservas.
Guías relacionadas
Ausencias: qué mueve de verdad la cifra
No: el tráfico alto solo hace que aparezca antes. El fallo de fondo existe en el momento en que más de una petición puede estar en curso para la misma plaza, algo que es cierto incluso en una página tranquila; un negocio con poco tráfico simplemente puede pasar meses entre esos raros momentos en que dos personas hacen clic a la vez. Es una propiedad del diseño, no una función de lo ocupado que estés.
No. El calendario es lo que ve el cliente; la parte que impide la doble reserva ocurre por completo en el servidor, de forma invisible, en el instante exacto en que se escribe una reserva. Una interfaz de calendario cuidada no te dice nada sobre lo que pasa por debajo cuando dos personas pulsan la misma franja en el mismo segundo.
Deberían enterarse de inmediato —antes de que se cobre ningún pago— de que el hueco acaba de ocuparse, y ver la siguiente opción real. El fallo que de verdad preocupa es el contrario: un sistema que deja pasar las dos reservas y solo saca a la luz el conflicto más tarde, normalmente cuando alguien se presenta.
El mismo mecanismo se aplica en cualquier sitio donde se reserve algo compartido y limitado: una mesa, una sala, un equipo, una franja de entrega. La solución tiene siempre la misma forma: bloquea y vuelve a comprobar el recurso realmente limitado en el momento de confirmar, no un momento antes.
Sí, en sectores concretos: las aerolíneas llevan mucho tiempo vendiendo más plazas de las que tienen contra una tasa prevista de no presentación, como decisión empresarial deliberada y modelada, con una política de compensación asociada. Eso es algo distinto del caso accidental del que trata esta guía, en el que nadie lo pretendía y a nadie le alegra descubrirlo.