Evitar reservas simultáneas en una aplicación requiere decidir cuándo una plaza deja de estar disponible para otra persona. Un calendario actualizado ayuda a elegir, pero la confirmación necesita su propia regla. Dos visitantes pueden ver la misma plaza libre antes de que cualquiera de ellos termine el formulario o el pago.
Imaginemos una academia ficticia que ofrece un taller con aforo limitado. Queda una plaza y dos personas empiezan a reservar desde sus móviles. Una tarda más porque necesita consultar los datos de facturación. El sistema debe decidir qué conserva cada persona durante la espera y qué mensaje recibe cuando ya no es posible confirmar su solicitud.
Separar consulta, retención y confirmación
Escribe los estados de la plaza y las acciones que los modifican. Consultar disponibilidad, iniciar un formulario y aceptar una reserva son momentos diferentes. Si se utiliza una retención temporal, describe qué la crea y qué información muestra la aplicación sobre su vigencia. El usuario no debería tener que adivinar si su selección está protegida.
Define también el alcance de la retención. Puede afectar a una plaza, una combinación de recursos o varias fechas. El equipo responsable del servicio debe explicar qué sucede cuando solo parte de esa combinación sigue disponible. Una regla clara evita que la aplicación confirme una experiencia que la academia no puede prestar completa.
Resolver la competencia en el punto de aceptación
La última comprobación debe proteger la operación que realmente asigna la plaza. No basta con comprobar la disponibilidad al abrir la pantalla. Pide al equipo de desarrollo que muestre cómo su solución evita dos aceptaciones incompatibles cuando las solicitudes llegan prácticamente al mismo tiempo y qué respuesta recibe la que no puede continuar.
La implementación depende del almacenamiento y de las transacciones elegidas. Lo relevante para la aceptación del proyecto es el resultado observable: una única plaza asignada y ninguna solicitud perdida en un estado ambiguo. No conviertas una explicación general sobre concurrencia en una promesa sobre la solución concreta sin haber ejecutado el escenario.
Relacionar la reserva con el pago pendiente
Si el pago se confirma después de caducar la retención, el negocio necesita una decisión definida. Puede requerirse una revisión u otra respuesta prevista por el servicio. La aplicación no debe inventar disponibilidad ni pedir otro pago mientras el anterior sigue sin aclararse. Cada operación debe permanecer vinculada a la solicitud inicial.
Explica al cliente qué se sabe y qué falta por resolver. Distingue una plaza confirmada de una solicitud pendiente de revisión. El personal debe consultar el mismo estado y conocer la siguiente acción autorizada. Así, una incidencia técnica no se convierte en varias versiones contradictorias de la reserva.
Ensayar dos recorridos completos
Abre dos sesiones separadas y solicita la última plaza. Interrumpe una antes de confirmar, deja vencer una retención y simula una respuesta tardía del entorno de pruebas de pago. Revisa el calendario, las solicitudes, los mensajes y la vista administrativa. El resultado debe ser consistente en todos esos puntos.
Comparte este recorrido con Brainbaby Labs al preparar una aplicación de reservas. Aporta las reglas de aforo, cancelación y espera de tu servicio. Con ellas puede definirse una primera entrega que incluya la competencia por recursos y la recuperación de incidencias. La demostración normal y la prueba concurrente deben formar parte del mismo criterio de aceptación.