Caso de estudio del sistema de reserva de LINE para clínicas: control de concurrencia, sincronización en tiempo real y prueba de 130+.

Contexto del problema

El mayor peligro del sistema de reserva no es la apariencia de la interfaz, sino la competencia en la capa de datos: dos pacientes envían solicitudes para el mismo horario, la clínica cierra temporalmente pero el paciente sigue viendo el horario anterior, o las reglas de reserva se actualizan pero la aplicación LINE sigue permitiendo la reserva. Estos escenarios no ocurren en la demostración, pero sí en el tráfico real. El núcleo de este caso es separar el concepto de "parece que se puede reservar en la interfaz" del "realmente se ha reservado en la base de datos", y garantizar que cualquier cambio en el backend se refleje inmediatamente en el cliente.

Método de implementación

• —Reserva simultánea basada en la base de datos: al realizar la reserva, se consulta y se bloquea el horario dentro de la transacción. Cuando dos personas envían solicitudes simultáneamente, solo la que obtiene el bloqueo primero tiene éxito, y la otra recibe un mensaje de error claro.
• —Estado de no confianza en el frontend: Los horarios disponibles en la pantalla son solo una referencia. La única forma de confirmar una reserva es mediante una verificación posterior en el servidor: ¿el horario sigue disponible, ¿el paciente cumple con las reglas, ¿no hay conflictos con reservas existentes? Todo esto se verifica nuevamente en el servidor.
• —Uso de la sincronización en tiempo real de Supabase: Cuando se cierra la consulta, se ajustan los horarios o se modifican las reglas, los cambios se envían inmediatamente a la interfaz del paciente, reduciendo la discrepancia de información. Sin embargo, la verificación final siempre se realiza en el servidor. Realtime se encarga de la experiencia, pero no de la exactitud.
• —Creación de pruebas de extremo a extremo para escenarios excepcionales: La posibilidad de reservar simultáneamente, cancelar inmediatamente después de la reserva, cerrar la consulta temporalmente, volver a verificar después de cambiar las reglas y reenviar después de una interrupción de la conexión, todo debe ser un conjunto de pruebas que se puedan ejecutar repetidamente. Cada modificación puede ser verificada ejecutando todo el conjunto de pruebas.

Alcance real de Falcon

• Proceso de reserva de pacientes a través de LINE LIFF
• Panel de administración de horarios y reservas de la clínica
• Sincronización en tiempo real con Supabase Realtime
• Control de concurrencia de bases de datos y pruebas de extremo a extremo

Proceso de reserva y control de concurrencia de LINE

1. 01El paciente abre la interfaz de reserva de LINE LIFF, cargando los horarios disponibles en ese momento. Esta lista es solo una referencia visual, no la base definitiva.
2. 02Cuando se envía una reserva, el servidor verifica nuevamente el estado de disponibilidad del horario, las reglas de reserva y los conflictos con horarios específicos, y solo se guarda si todo es válido.
3. 03Cuando dos personas intentan reservar el mismo horario simultáneamente, la base de datos determina quién tiene éxito. El servidor que falla recibe un mensaje claro y vuelve a cargar los horarios disponibles más recientes.
4. 04Realtime sincroniza los cambios de horario y las modificaciones en el panel de administración con el cliente y la interfaz de administración de la clínica, de modo que ambas vean el mismo estado.

Limitaciones, fallos y alternativas

• —Cuando varias personas eligen el mismo horario simultáneamente, el resultado de la transacción en el servidor determina quién tiene éxito. El servidor que falla debe volver a elegir, sin asumir que "primero llega, primero se sirve".
• —No se puede asumir que una reserva tiene éxito cuando hay una interrupción de la conexión. La pantalla debe volver a consultar el estado real en el servidor para mostrar los resultados.
• —El momento de aplicación de los cambios en las reglas se basa en el servidor. Si la pantalla del cliente aún no se ha actualizado, la reserva seguirá siendo rechazada por el servidor.
• —Los casos anónimos no revelan información sobre pacientes, clínicas, cantidades de reservas ni información médica. Tampoco se afirma sobre los resultados médicos o operativos.

Cómo verificar la evidencia

• ✓Los escenarios cubiertos por las pruebas de extremo a extremo de 130+: Reserva y cancelación normales, concurrencia de reservas en el mismo horario, cambios de horario y cierre temporal en el panel de administración, verificación de reservas después de cambiar las reglas, reenvío después de una interrupción de la conexión.
• ✓Los números de prueba representan el número de casos documentados en las obras públicas existentes, no indican la ausencia de defectos.
• ✓El bloqueo de bases de datos, las transacciones y Realtime describen el diseño del sistema, no representan ningún compromiso operativo.
• ✓Los nombres de los clientes, los datos de los pacientes, las cantidades de reservas y los indicadores operativos no se han divulgado.

Mediciones y capacidades disponibles públicamente