slotline
Une plateforme de réservation de ressources (salles, courts, équipement) sur Spring Boot. Le coeur garantit qu'un créneau ne sera jamais réservé deux fois - même en forte concurrence.
Une plateforme de réservation de ressources (salles, courts, matériel) sur Spring Boot. Elle paraît triviale jusqu'à ce que deux personnes cliquent sur le même créneau à la même milliseconde. Le cœur garantit qu'un créneau n'est jamais réservé deux fois, même sous forte concurrence.
Introduction
Réserver un créneau ressemble à l'insertion d'une ligne, et beaucoup de développeurs l'écrivent exactement ainsi. Le problème est que la vraie difficulté ne réside pas dans le cas typique mais dans la seule milliseconde où deux personnes attrapent le même créneau libre. slotline est construit autour de cette seule milliseconde, pas autour du formulaire de réservation.
Tout le reste de la plateforme, les ressources, le calendrier et les vues, enveloppe une seule garantie : qu'un créneau a exactement un gagnant. C'est cela qui décide si le système est sérieux ou s'il fait seulement semblant de fonctionner jusqu'à la première foule.
Toute la difficulté tient dans une milliseconde
Une implémentation naïve fait deux étapes : elle vérifie si le créneau est libre, puis l'écrit. Entre ces étapes il y a une faille où un second utilisateur parvient à voir le même créneau comme libre. Les deux passent la vérification, les deux écrivent, et vous avez deux réservations pour un créneau dont personne ne savait qu'elles étaient possibles.
slotline traite cela comme le problème principal à résoudre, pas comme un cas limite. Le modèle du domaine est clair précisément pour que cette seule garantie soit évidente à la lecture du code, et non enterrée quelque part dans une couche de service.
Vérifier la disponibilité et écrire la réservation ne sont pas deux opérations distinctes. Si elles le sont, vous avez une course. La garantie vient de la base de données, via une contrainte unique sur ressource plus créneau horaire, pas d'une vérification dans le code applicatif.
La contrainte unique déplace la décision vers le seul endroit où la concurrence est vraiment sérialisée : le moteur de la base. Peu importe combien d'utilisateurs cliquent en même temps, car le gagnant est décidé par une écriture atomique, et les perdants reçoivent une erreur de conflit propre au lieu d'une double réservation silencieuse.
Un test qui peut vraiment échouer
Il est facile d'écrire un test qui réserve une fois et vérifie que cela a marché. Cela ne prouve rien, car il ne touche jamais la condition censée tenir. Le test qui a de la valeur lance de nombreux threads sur le même créneau en même temps et vérifie qu'exactement un gagne tandis que les autres reçoivent une erreur de conflit propre.
Ruée simultanée sur un créneau (indicatif)
La vérification est contrefactuelle : retirez la contrainte unique et le même test se met à laisser passer deux réservations. Si le test reste vert une fois la protection retirée, il ne gardait rien.
Un gagnant, toujours
Le résultat est une plateforme qui se comporte sous charge exactement comme avec un seul utilisateur : un créneau a un propriétaire, point final. Il n'y a pas d'état où deux personnes repartent avec le même créneau, car cette possibilité a été découpée à la source, dans la base, et non rafistolée dans l'interface.
Plus de projets
D'autres réalisations de la même catégorie - découvrez comment nous abordons des défis similaires.
Vous avez un projet similaire ?
Contactez-nous - le devis est gratuit et arrive sous une heure.