Flujo conceptual de una reserva
Es un patrón de diseño general, no una afirmación sobre la arquitectura interna de Luminaria.
Disponibilidad consultada
El cliente recibe opciones calculadas desde una fuente autorizada.
Solicitud recibida
El servidor identifica recurso, horario, usuario y operación única.
Validación final
Se comprueba otra vez disponibilidad y reglas dentro de una operación consistente.
Confirmada o rechazada
El estado se registra una vez; reintentos no crean reservas duplicadas.
El calendario visible no es la fuente de verdad
La interfaz puede mostrar un horario libre y quedar desactualizada un instante después. La confirmación debe consultar y modificar la disponibilidad en una operación consistente. La regla central vive en el servidor, no en el color de una celda.
Modela estados explícitos
Una reserva puede estar solicitada, confirmada, cancelada o fallida. Algunos negocios necesitan estados adicionales, pero cada uno debe tener transiciones permitidas, responsable y efecto sobre capacidad. Sin ese modelo, pago, mensajes y agenda pueden contar historias distintas.
Concurrencia: dos solicitudes, un recurso
Cuando dos personas intentan reservar el mismo espacio, ambas pueden haber visto disponibilidad. El sistema debe serializar la decisión mediante restricciones y transacciones apropiadas. Una gana; la otra recibe una respuesta clara y opciones actualizadas.
Reintentos e idempotencia
Redes y proveedores pueden repetir solicitudes. Una clave de idempotencia permite reconocer la misma intención y devolver el resultado existente, en lugar de crear otra reserva o cobro.
Pagos y confirmación
El orden depende del negocio. Puede confirmarse antes, después o condicionado al pago. Lo indispensable es definir qué sucede si el pago tarda, falla o llega después de una cancelación. Compensaciones y reconciliación deben diseñarse como parte del flujo.
Holds y expiración son una decisión, no una obligación
Una retención temporal puede proteger capacidad durante el pago, pero añade expiración, liberación y recuperación ante fallas. Otros modelos validan al confirmar. La elección depende de escasez, duración del checkout y costo de conflicto.
Qué demuestra Luminaria y qué no afirmamos
La evidencia pública verificada de Luminaria muestra catálogo, detalle de producto o evento, reglas relacionadas con disponibilidad, carrito, checkout, continuidad de pagos y administración. Eso demuestra una experiencia conectada entre comercio y operación.
No afirmamos cuál es su arquitectura, proveedor de pagos ni si implementa holds con expiración: esos detalles no están verificados públicamente. El flujo de esta guía explica patrones generales que un sistema de reservas debe evaluar.
Pruebas que importan
Simula solicitudes simultáneas, reintentos, cancelaciones, fallas de pago y restauración de sesión. Verifica invariantes: una unidad de capacidad no puede confirmarse dos veces y cada cambio debe dejar rastro suficiente para operar y corregir.
Preguntas frecuentes
¿Bloquear el botón evita dobles reservas?
No. Dos personas o dos solicitudes pueden llegar desde dispositivos distintos. El control debe vivir en el servidor y en la base de datos.
¿Luminaria utiliza holds con expiración?
No publicamos ese detalle porque la evidencia disponible no permite verificar su implementación interna.