Conception du Système de Réservation de Billets

Architecture d'un système de réservation de billets : de l'API à l'évolutivité

Un système de réservation de billets doit permettre la consultation d'événements, la recherche paramétrée et des réservations fiables sans double vente. L'accent est mis sur la disponibilité des données pour les lectures et une stricte cohérence pour les écritures. Charge attendue — jusqu'à 10 millions d'utilisateurs pour un événement populaire, latence de recherche inférieure à 500 ms, ratio lecture/écriture de 100:1.

Entités clés : Événement (avec date, description, type), Utilisateur, Artiste, Lieu (avec plan de salle), Billet (avec siège, prix, statut), Réservation (avec liste de billets et statut).

Conception des points de terminaison API

L'API est construite autour de trois fonctions prioritaires. Commencez par des endpoints simples, affinez au fur et à mesure de la conception.

Voir un événement :

GET /events/:id -> Événement & Lieu & Artiste & Billet[]

Retourne les détails de l'événement, le lieu, l'artiste et la liste des billets pour afficher le plan de salle côté client.

Recherche :

GET /events/search?keyword={mot-clé}&start={date_début}&end={date_fin}&pageSize={taille_page}&page={numéro_page} -> Événement[]

Filtrage par mots-clés, dates, pagination pour un débit élevé.

Réservation (version initiale) :

POST /bookings/:eventId -> bookingId
{
  "ticketIds": string[],
  "paymentDetails": ...
}

À scinder ultérieurement en réservation et confirmation pour une fiabilité transactionnelle.

Architecture de haut niveau

Composants du système

• Passerelle API : routage, authentification, limitation de débit, journalisation.
• Service Événement : lecture des données d'événement, de lieu et d'artiste depuis la base de données.
• Service de Recherche : gestion des requêtes de recherche avec filtrage.
• Service de Réservation : gestion des réservations avec transactions.
• Bases de données : PostgreSQL pour les transactions ACID (Réservations, Billets), NoSQL ou cache pour les lectures (Événements, Lieux).

Flux de visualisation : client → Passerelle → Service Événement → Base de données → réponse avec plan de salle.

Passage à l'échelle sous charge

Pour 10 millions d'utilisateurs actifs quotidiens par événement, utilisez :

• Cache : Redis pour les lectures fréquentes (événements, recherche).
• Partitionnement : par eventId dans Billets/Réservations.
• CQRS : séparation des lectures (réplicas de lecture) et des écritures (maître).
• Répartiteur de charge : distribution du trafic entre les services.

Le ratio 100:1 lecture/écriture dicte la priorité sur les réplicas de lecture et le CDN pour les données statiques (plans de salle).

Détails de la réservation et cohérence

Zone critique — éviter la double réservation. PostgreSQL avec transactions et isolation Serializable ou Contrôle d'Accès Concurrent Optimiste (CACO) sur les versions de billets.

Processus :

• Le client sélectionne des ticketIds.
• Le Service de Réservation démarre une transaction : SELECT FOR UPDATE sur Billets.
• Vérifie le statut (disponible), met à jour en réservé.
• Crée un enregistrement de Réservation.
• Confirmation de paiement → statut confirmé.

Exemple de table Billets :

| id | event_id | section | rang | siège | prix | statut | version |

|----|----------|---------|------|-------|------|--------|---------|

| 1 | 123 | A | 1 | 5 | 100 | disponible | 1 |

CACO : lors de la MISE À JOUR, vérifiez la version, rejetez en cas de conflit.

Pour une haute concurrence — réservations temporaires (TTL 10 min) dans Redis.

Optimisation de la recherche

Le filtrage SQL de base ne passe pas à l'échelle pour 10 millions. Transition vers :

• Elasticsearch pour la recherche en texte intégral par mot-clé, artiste, lieu.
• Indexation des Événements avec champs : nom, plage_dates, localisation.
• Recherche à facettes pour les filtres (date, type).

Flux : Service de Recherche → requête ES → agrégation → cache dans Redis.

Latence <500 ms atteinte par préchargement des événements populaires.

Approfondissement de l'évolutivité

Bases de données

• PostgreSQL Maître (Réservations, Billets) — partitionné par eventId.
• Réplicas de Lecture — 10+ pour la visualisation d'événements.
• Redis — sessions, réservations temporaires, événements populaires.
• Elasticsearch — recherche, analytique.

Migration des données : Service Événement écrit dans Kafka → CDC → réplicas/ES.

Surveillance et tolérance aux pannes

• Disjoncteurs dans les services.
• Contrôles de santé, mise à l'échelle automatique.
• Sauvegardes : archivage WAL vers S3.

Points clés à retenir

• Cohérence stricte uniquement dans les transactions de Réservation, cohérence à terme pour la recherche.
• CACO + verrous temporaires dans Redis préviennent 99 % des conflits sans blocage.
• CQRS/ES garantissent <500 ms de recherche sous charge 100:1.
• Partitionnement par eventId passe à l'échelle pour 10M+ utilisateurs actifs quotidiens.
• Passerelle API centralise sécurité et limitation.

— Editorial Team