Étude de cas du système de prise de rendez-vous par LINE pour un cabinet médical | Gestion des conflits, synchronisation en temps réel et test 130+

Contexte du problème

Le danger principal d'un système de prise de rendez-vous n'est pas l'apparence de l'interface, mais la concurrence dans la couche de données : deux patients soumettent la même demande au même moment, le cabinet ferme temporairement mais le patient voit toujours l'ancien créneau, les règles de prise de rendez-vous sont mises à jour sur le côté de la caisse, mais cela n'est pas encore reflété sur LINE. Ces situations ne se produisent pas lors de la démonstration, mais sont inévitables dans un trafic réel. Le cœur de ce projet est de traiter séparément "l'apparence de la possibilité de prendre rendez-vous" et "la prise de rendez-vous réelle dans la base de données", et de refléter instantanément toute modification dans la plateforme du patient.

Méthode de mise en œuvre

• —Prise de rendez-vous simultanée en utilisant une base de données et en gérant les transactions : lors de la prise de rendez-vous, la période est recherchée et verrouillée à nouveau dans la transaction, et seul le premier qui obtient le verrou peut réussir, tandis que l'autre reçoit un message d'échec clair, évitant ainsi l'illusion que les deux ont réussi.
• —État de non-confiance pour la planification : Les plages horaires affichées sont simplement des références. La planification ne devient officielle qu'après une vérification effectuée par le serveur : la plage est-elle toujours disponible, le patient respecte-t-il les règles, y a-t-il des conflits avec des réservations existantes ? Tout cela est vérifié une nouvelle fois côté serveur.
• —Utilisation de la synchronisation Supabase Realtime : Lorsque le cabinet ferme, ajuste les horaires ou modifie les règles, les changements sont immédiatement diffusés aux patients connectés. Cela réduit les incohérences d'informations. Cependant, la vérification côté serveur reste la référence, et la synchronisation Realtime est uniquement pour l'expérience utilisateur, et non pour la vérification de la validité.
• —Création de tests bout-en-bout pour les situations exceptionnelles : La planification simultanée, l'annulation immédiate après la planification, la fermeture temporaire du cabinet, la vérification après modification des règles, et la réexpédition après une interruption de connexion doivent être transformées en tests reproductibles. Chaque modification peut ainsi être vérifiée en exécutant l'ensemble des tests.

Portée réelle de Falcon

• Flux de planification des patients via LINE LIFF
• Interface de gestion des horaires et des réservations du cabinet
• Synchronisation en temps réel avec Supabase Realtime
• Contrôle de la concurrence des bases de données et tests bout-en-bout

Flux de planification et de contrôle de la concurrence via LINE

1. 01Le patient ouvre l'interface de planification LINE LIFF, qui affiche les plages horaires disponibles. Cette liste est uniquement une référence visuelle, et non la seule source de vérité.
2. 02Lors de la soumission de la réservation, le serveur vérifie à nouveau l'état de disponibilité des plages horaires, les règles de réservation et les conflits, et ne les enregistre que si toutes les conditions sont remplies.
3. 03Si deux personnes tentent de réserver la même plage horaire, la transaction de la base de données détermine laquelle réussit. La transaction échouée reçoit un message clair et recharge les plages horaires disponibles les plus récentes.
4. 04La synchronisation Realtime transmet les changements d'horaires et les modifications côté serveur aux patients et à l'interface de gestion du cabinet, de sorte que les deux parties voient le même état.

Limitations, échecs et alternatives

• —Si plusieurs personnes choisissent la même plage horaire, la transaction côté serveur détermine laquelle réussit. La transaction échouée doit choisir à nouveau, sans faire l'hypothèse "premier arrivé, premier servi".
• —En cas de coupure de connexion, il ne faut pas supposer que la réservation a réussi. L'écran doit être mis à jour avec l'état réel côté serveur avant d'afficher les résultats.
• —Le délai d'application des modifications des règles est déterminé côté serveur. Si l'écran du patient n'est pas mis à jour, la réservation sera toujours vérifiée par le serveur.
• —Les exemples anonymes ne divulguent aucune information sur les patients, les cabinets, les volumes de réservations ou les données médicales, et ne prétendent pas à des résultats médicaux ou opérationnels.

Comment vérifier les preuves

• ✓Les catégories de scénarios couverts par les tests bout-en-bout 130+ : Planification et annulation normales, planification simultanée et concurrence, modifications des horaires côté serveur et fermeture temporaire, vérification de la planification après modification des règles, réexpédition après interruption de connexion.
• ✓Les chiffres de test représentent le nombre d'exemples documentés dans les publications publiques, et ne garantissent pas l'absence de défauts.
• ✓Le verrouillage de la base de données, les transactions et la synchronisation Realtime décrivent la conception du système, et ne représentent aucun engagement opérationnel.
• ✓Les noms des clients, les données des patients, les volumes de réservations et les indicateurs opérationnels ne sont pas divulgués.

Mesures et capacités disponibles