Concevoir un système évolutif de réservation de billets de concert

# Système de réservation de billets de concert évolutif — Plan de conception ## 1. Hypothèses - Région cloud unique (par exemple, AWS us-east-1) avec 3 zones de disponibilité ; services gérés préférés. - Le catalogue (événements, lieux, plans de sièges) est fortement lu et change peu fréquemment. - Les réservations constituent le chemin critique ; les paiements sont hors chemin critique via des rappels asynchrones. - "Ne jamais vendre en excès" est un invariant strict ; une indisponibilité brève est préférable à une double vente. - Un fournisseur de paiement externe (par exemple, Stripe/Adyen) gère la portée PCI ; nous ne stockons que des jetons. - Taille moyenne des événements 30k sièges ; les pics durent de quelques minutes à environ 1 heure. ## 2. Architecture de haut niveau Clients (web/mobile) → CDN (CloudFront) → API Gateway / Équilibreur de charge L7 → Authentification Edge (JWT) → Microservices sans état sur Kubernetes (EKS) dans 3 zones de disponibilité. Services principaux : - **Service d'identité** : inscription, connexion, émission de JWT, MFA. - **Service de catalogue** : événements, lieux, métadonnées de plan de sièges ; optimisé en lecture. - **Service d'inventaire/sièges** : état faisant autorité des sièges, réservations temporaires, réservations ; l'ancre de cohérence. - **Service de réservation** : orchestre la réservation temporaire → paiement → intention de paiement. - **Service de paiement** : s'intègre au fournisseur, traite les rappels de webhook de manière idempotente. - **Service de billetterie** : émet des billets numériques signés (JWT/QR) après succès du paiement. - **Service de notification** : e-mail/push (SES/SNS). - **Service de salle d'attente / File d'attente virtuelle** : limite l'entrée lors des pics de mise en vente. - **Worker d'expiration** : libère les réservations temporaires impayées après 10 minutes. - **Service d'administration/mise en vente** : configuration des événements, téléchargement des plans de sièges, planification des mises en vente. Transversal : Kafka (MSK) pour les événements, Redis (ElastiCache, mode cluster) pour l'état critique et les verrous, PostgreSQL (Aurora Multi-AZ) pour les données transactionnelles, DynamoDB pour les clés d'idempotence et le magasin de billets, S3 pour les JSON/images de plans de sièges, OpenSearch pour la recherche d'événements. ## 3. Magasins de données - **Aurora PostgreSQL (Multi-AZ, 1 écrivain + 2 lecteurs)** : événements, utilisateurs, réservations, paiements, billets (système de référence). Sauvegarde continue ; PITR. - **Cluster Redis (Multi-AZ, avec réplicas)** : état de réservation temporaire par siège, cache de bitmap de sièges par événement, limites de débit, jetons de salle d'attente. Utilisé pour les opérations CAS rapides sur les réservations temporaires. - **DynamoDB** : clés d'idempotence de paiement, déduplication de webhook, recherche de billets émis (faible latence, multi-AZ par défaut). - **Kafka (MSK)** : événements de domaine (`SeatHeld`, `ReservationCreated`, `PaymentSucceeded`, `PaymentFailed`, `ReservationExpired`, `TicketIssued`). Facteur de réplication 3 entre les zones de disponibilité. - **S3** : artefacts de plan de sièges statiques, PDF de billets. - **CDN** : met en cache les listes d'événements, le squelette du plan de sièges (pas la disponibilité en direct). - **OpenSearch** : recherche/filtrage d'événements. ## 4. Modèle de données principal **events**(event_id PK, venue_id, name, onsale_at, status, version). **seats**(seat_id PK, event_id, section, row, number, price_tier, status ENUM[available, held, reserved, sold], hold_id NULL, version BIGINT). Index composite (event_id, status). Versionnement au niveau de la ligne pour le verrouillage optimiste. **reservations**(reservation_id PK, user_id, event_id, seat_ids[], state ENUM[pending_payment, confirmed, expired, cancelled], created_at, expires_at, payment_intent_id, idempotency_key UNIQUE). **payments**(payment_id PK, reservation_id, provider_ref UNIQUE, status, amount, currency, received_at). Contrainte unique sur provider_ref pour une déduplication au moins une fois. **tickets**(ticket_id PK, reservation_id, seat_id, qr_payload, issued_at, signature). **outbox**(id, aggregate, payload, published_at) pour le modèle de boîte d'envoi transactionnelle → Kafka. Clés Redis : - `event:{id}:seat:{seat_id}` → status + propriétaire de la réservation temporaire + TTL 600s. - `event:{id}:availability` → bitmap/HLL pour des comptages rapides. - `hold:{reservation_id}` → liste des sièges, TTL 600s. ## 5. API principales (REST + en-têtes d'idempotence) - `GET /events?filters` → liste paginée (cacheable par CDN, TTL 30s). - `GET /events/{id}` → détails de l'événement. - `GET /events/{id}/seatmap` → disposition statique (cache long). - `GET /events/{id}/availability` → disponibilité grossière (sections) ; cache 1–5s. - `GET /events/{id}/seats?section=A` → état détaillé des sièges (cache court ou en direct). - `POST /reservations` (Idempotency-Key) → `{event_id, seat_ids[]}` → crée une réservation temporaire de 10 minutes. - `GET /reservations/{id}` → état, expires_at. - `DELETE /reservations/{id}` → l'utilisateur annule, libère les sièges. - `POST /reservations/{id}/checkout` → crée une intention de paiement chez le fournisseur, renvoie le secret client. - `POST /webhooks/payments` → rappel du fournisseur (signé, idempotent). - `GET /tickets/{id}` → billet numérique signé. - Admin : `POST /events`, `POST /events/{id}/seats:bulk`, `POST /events/{id}/onsale`. ## 6. Flux de requêtes ### Navigation Client → CDN (cache hit pour catalogue/plan de sièges) → en cas de cache miss, API → Service de catalogue → lecteur Aurora / OpenSearch. Les comptages de disponibilité sont servis depuis Redis avec une latence de 1 à 5 secondes ; les états individuels des sièges sont extraits en direct pour la section que l'utilisateur visualise. ### Réservation (temporaire) 1. Le client envoie `POST /reservations` avec l'Idempotency-Key et les sièges cibles. 2. L'API Gateway vérifie le jeton de la salle d'attente ; limite le débit par utilisateur/IP. 3. Le Service de réservation valide le statut de l'événement et les identifiants des sièges. 4. **Acquisition des réservations temporaires atomiquement** via un script Lua Redis : pour chaque clé de siège, `SETNX` avec hold_id et TTL 600s ; si un siège échoue, annule ceux qui ont réussi et renvoie 409 avec les sièges conflictuels. 5. Persiste la ligne de réservation dans Aurora en état `pending_payment` (transaction unique avec événement outbox). Utilise le verrouillage optimiste sur les sièges : `UPDATE seats SET status='held', hold_id=?, version=version+1 WHERE seat_id=? AND status='available'`. Aurora est la vérité durable ; Redis est le garde rapide. Les deux doivent être d'accord. 6. Renvoie la réservation avec `expires_at`. p95 < 800 ms. ### Paiement 1. Le client appelle `POST /reservations/{id}/checkout` ; le Service de paiement crée un PaymentIntent chez le fournisseur, stocke `provider_ref` indexé par reservation_id (idempotent). 2. Le client finalise le paiement via le SDK du fournisseur directement (nous restons hors de la portée PCI). 3. Le fournisseur envoie un webhook → `POST /webhooks/payments`. 4. Gestionnaire de webhook : vérifie la signature → insère/met à jour dans `payments` en utilisant `provider_ref` UNIQUE (déduplication). Utilise une mise à jour conditionnelle DynamoDB sur event_id pour une idempotence supplémentaire. 5. En cas de succès (`succeeded`) : mise à jour transactionnelle — réservation→`confirmed`, sièges→`sold`, écriture des `tickets`, ajout de l'événement outbox `TicketIssued`. Sécurité hors séquence : le gestionnaire compare les horodatages des événements et ignore les transitions obsolètes (machine à états : pending → confirmed/failed/expired, les états terminaux absorbent les doublons tardifs). 6. Le Service de billetterie consomme `TicketIssued`, génère un QR/PDF signé, stocke dans S3 + DynamoDB ; le Service de notification envoie un e-mail à l'utilisateur. ### Expiration - Principal : le TTL Redis expire la clé `hold:*` → une notification de keyspace déclenche le worker d'expiration ; le worker exécute une transaction Aurora libérant les sièges uniquement si la réservation est toujours `pending_payment` (CAS sur l'état). - Secours : une tâche planifiée toutes les 30 secondes scanne `reservations WHERE state='pending_payment' AND expires_at < now() - 30s` et libère. Rappel tardif arrivant après expiration : si le siège a déjà été revendu, marquer le paiement comme `refund_required` et déclencher un remboursement automatique ; si le siège est toujours libre, éventuellement reconfirmer — mais la politique par défaut est le remboursement, car nous ne pouvons pas retenir un siège potentiellement revendu. Le délai de 5 minutes du fournisseur de paiement est dans la fenêtre de réservation temporaire de 10 minutes, donc le cas normal n'a pas de conflit. ## 7. Prévention de la survente (Cohérence) - Le siège est une ressource unique possédée : chaque transition d'état utilise la **concurrence optimiste** dans Aurora (`WHERE status=expected_status AND version=expected_version`). - Redis SETNX fournit un rejet rapide de première ligne à 8k RPS sans surcharger la base de données ; la mise à jour de ligne Aurora est la deuxième ligne et la vérité légale. - Toutes les écritures côté paiement sont idempotentes via l'unicité de `provider_ref` + table de déduplication DynamoDB. - Le modèle Outbox garantit que les événements de domaine sont publiés exactement une fois vers Kafka par rapport aux commits de la base de données. - Cohérence forte au sein d'une seule ligne de siège ; la cohérence éventuelle est acceptable uniquement pour les comptages agrégés de disponibilité affichés dans les vues de navigation. ## 8. Stratégie de mise à l'échelle pour les pics - **Salle d'attente virtuelle** : lorsque `concurrent_users > seuil`, les nouveaux utilisateurs obtiennent un jeton de file d'attente ; seuls N jetons/sec sont admis aux points d'accès de réservation. Maintient le système à une capacité connue (par exemple, admettre 10k/sec pour absorber 8k tentatives de réservation/sec). - **Mise à l'échelle horizontale automatique** (HPA sur EKS) sur CPU et métriques RPS personnalisées ; préchauffer les pods 15 minutes avant les mises en vente annoncées. - **Partitionnement des événements critiques** : partitionner les clés Redis par `event_id` afin qu'un seul événement majeur atterrisse sur un shard dédié ; peut pré-provisionner des shards pour les mises en vente connues. - **Mise à l'échelle en lecture** : réplicas de lecture Aurora + Redis pour la disponibilité + CDN pour les données statiques du plan de sièges. - **Backpressure** : quotas de requêtes API Gateway par utilisateur ; 429 avec Retry-After. - **Fan-out asynchrone** : Kafka découple la génération de billets, les e-mails, l'analyse du chemin critique. - **Groupement de connexions** : RDS Proxy / PgBouncer pour éviter les tempêtes de connexions Aurora. - **Défense contre les bots** : WAF, CAPTCHA sur `POST /reservations` pendant les mises en vente, empreinte digitale de l'appareil. ## 9. Fiabilité et reprise après sinistre - Multi-AZ pour chaque composant avec état (Aurora, Redis avec réplicas + basculement automatique, MSK RF=3, DynamoDB). - Aurora : sauvegarde continue vers S3, PITR à toute seconde dans la période de rétention → RPO ≤ 1 min atteint ; basculement ~30–60s → RTO ≤ 15 min atteint. - Redis : Multi-AZ avec basculement automatique ; les données sont reconstructibles à partir d'Aurora (les réservations temporaires peuvent être reconstruites au redémarrage à froid à partir de `reservations WHERE state='pending_payment'`). - Kafka : stockage hiérarchisé, RF=3, ISR min=2. - Procédure de reprise après sinistre : réplica Aurora Global Database inter-régions (RPO ~ secondes) pour la récupération après une défaillance à l'échelle de la région ; procédure de promotion documentée. - Exercices de chaos : panne de zone de disponibilité, arrêt du primaire Redis, simulation de panne de fournisseur de paiement trimestrielle. - Vérifications de santé au niveau ALB ; disjoncteurs (type Resilience4j) entre les services et vers le fournisseur de paiement. - Dégradation gracieuse : si Redis indisponible, retour au chemin base de données uniquement avec une limite de débit plus stricte ; si le fournisseur de paiement est en panne, mise en file d'attente des paiements et notification à l'utilisateur. ## 10. Surveillance et alertes - **Métriques (Prometheus + CloudWatch)** : RPS, latence p50/p95/p99 par point d'accès, taux de succès des réservations, taux de conflit d'acquisition de réservation temporaire, retard du webhook de paiement, retard du worker d'expiration, retard du réplica Aurora, CPU/mémoire/évictions Redis, retard du consommateur Kafka. - **SLO** : disponibilité de 99,95 % pendant la fenêtre de mise en vente ; navigation p95 < 300 ms ; réservation p95 < 800 ms ; alertes de consommation du budget d'erreur. - **Traçage** : OpenTelemetry de bout en bout (client → API → service → DB). - **Journalisation** : JSON structuré vers CloudWatch/Elastic ; identifiants de corrélation. - **Tableaux de bord métier** : réservations temporaires/sec, conversion (temporaire → payant), compteur de survente (doit être 0 — alerte en cas de valeur non nulle). - **Alertes** : violation de survente=0 (P0), backlog de webhook > 1 min, réservation p95 > 800 ms pendant 5 min, basculement Aurora, basculement Redis, baisse du taux de succès des paiements > 2σ. ## 11. Compromis clés et alternatives - **Redis comme autorité de réservation temporaire vs. base de données seule** : l'approche pure base de données est plus simple et plus robuste mais ne pouvait pas supporter 8k RPS sur des points chauds de ligne unique ; Redis en première ligne absorbe le pic, la mise à jour de ligne Aurora garantit l'exactitude. - **Verrous pessimistes (SELECT FOR UPDATE)** : envisagé ; rejeté car la contention de verrouillage sur les sections populaires aurait fait chuter le débit. Le verrouillage optimiste avec nouvelles tentatives s'adapte mieux. - **Sièges réservés vs. admission générale par compteur** : la conception ci-dessus est par siège. Pour l'admission générale, un simple compteur décrémenté (`DECR` dans Redis avec un plancher de 0, reflété dans la base de données) est utilisé à la place. - **Région unique vs. actif-actif multi-régions** : la contrainte indique une région. L'actif-actif compliquerait le "ne jamais vendre en excès" (consensus inter-régions nécessaire). Nous utilisons un réplica de lecture inter-régions uniquement pour la reprise après sinistre. - **Kafka vs. SQS** : Kafka choisi pour un journal d'événements ordonné et rejouable (utile pour le traitement des paiements hors séquence et la reconstruction de l'état). - **Paiement synchrone vs. webhook uniquement** : le webhook uniquement choisi pour rester léger en PCI et tolérer la latence du fournisseur ; les retards de webhook jusqu'à 5 minutes rentrent toujours dans la fenêtre de réservation de 10 minutes. - **Salle d'attente vs. mise à l'échelle automatique pure** : la mise à l'échelle automatique seule ne peut pas protéger les magasins d'état en aval ; la file d'attente offre une forme de charge déterministe et une meilleure expérience utilisateur que des 503 massifs. - **Émission de billets synchrone vs. asynchrone** : asynchrone via Kafka maintient le gestionnaire de rappel de paiement rapide et résilient ; l'utilisateur voit le billet en quelques secondes via push/rafraîchissement. Cette conception répond aux SLO énoncés, empêche la survente grâce à une concurrence optimiste en couches, absorbe les pics de mise en vente via une file d'attente virtuelle + réservations temporaires frontées par Redis, et satisfait les objectifs RPO/RTO grâce à des magasins gérés Multi-AZ avec PITR et basculement répété.

## Conception du Système : Système Évolutif de Réservation de Billets de Concert ### 1. Services Principaux et Magasins de Données **Services :** * **API Gateway :** Point d'entrée pour toutes les requêtes client, gère l'authentification, la limitation de débit et le routage des requêtes. * **Service Utilisateur :** Gère l'enregistrement des utilisateurs, les profils et l'authentification. * **Service Événement :** Gère les détails des événements, les plannings et le contenu statique. * **Service Siège :** Gère l'inventaire des sièges, la disponibilité et les données de plan de salle pour les événements. * **Service Réservation :** Gère la logique de réservation des sièges, gère les cycles de vie des réservations (en attente, confirmée, expirée). * **Service Paiement (Interne) :** Orchestre les interactions avec les fournisseurs de paiement externes, traite les rappels et gère les enregistrements de paiement internes. * **Service Notification :** Envoie les billets numériques, les e-mails de confirmation et d'autres notifications aux utilisateurs. * **Service de Mise en File d'Attente (Kafka) :** Communication asynchrone entre les services, gère les événements à haut débit (par exemple, rappels de paiement, expiration des réservations). * **Service Cache (Redis) :** Accès rapide aux données pour la disponibilité des sièges, les détails des événements et les verrous distribués. * **Service de Travailleurs d'Arrière-plan :** Traite les tâches asynchrones telles que l'expiration des réservations, les nouvelles tentatives de rappels de paiement et le nettoyage des données. **Magasins de Données :** * **PostgreSQL (Base de Données Relationnelle) :** Magasin de données principal pour les utilisateurs, les événements, les sièges, les réservations et les paiements. Choisi pour ses fortes propriétés ACID cruciales pour éviter la survente. * *Déploiement :* Configuration multi-AZ, primaire-réplique avec réplication synchrone pour les tables critiques (sièges, réservations) et asynchrone pour les autres. * **Redis (Magasin de Données en Mémoire) :** Utilisé pour : * Mise en cache de la disponibilité des sièges et des détails des événements. * Verrous distribués pour la réservation et la confirmation des sièges. * Minuteurs d'expiration de réservation temporaires (clés TTL). * **Kafka (Plateforme de Streaming Distribué) :** Pour une messagerie et une source d'événements fiables et asynchrones. * **Stockage Objet (par exemple, S3) :** Stocke les actifs statiques tels que les images d'événements, les photos d'artistes et potentiellement les PDF de billets numériques. ### 2. API Principales **Service Utilisateur :** * `POST /users/register` : Enregistrer un nouvel utilisateur. * `POST /users/login` : Authentifier un utilisateur. * `GET /users/{id}` : Récupérer le profil utilisateur. **Service Événement :** * `GET /events` : Parcourir tous les événements (paginés). * `GET /events/{id}` : Récupérer les détails d'un événement spécifique. * `GET /events/{id}/seatmap` : Récupérer le plan de salle et la disponibilité actuelle pour un événement. **Service Réservation :** * `POST /events/{id}/reserve` : Réserver des sièges spécifiques pour un événement. Entrée : `event_id`, `seat_ids`, `user_id`. Sortie : `reservation_id`, `expires_at`. * `GET /reservations/{id}` : Récupérer les détails de la réservation. * `DELETE /reservations/{id}` : Annuler une réservation en attente. * `POST /reservations/{id}/confirm` : Confirmer une réservation après un paiement réussi (API interne, déclenchée par le Service Paiement). **Service Paiement :** * `POST /payments/initiate` : Initier le paiement d'une réservation. Entrée : `reservation_id`, `amount`, `user_id`. Sortie : URL de redirection du fournisseur de paiement. * `POST /payments/callback` : Point de terminaison webhook pour les rappels des fournisseurs de paiement externes (interne). **Service Billets (partie du Service Notification/Réservation) :** * `GET /tickets/{id}` : Récupérer un billet numérique. ### 3. Modèle de Données pour les Sièges et les Réservations **Table : `users`** * `user_id` (PK, UUID) * `username` (VARCHAR, UNIQUE) * `email` (VARCHAR, UNIQUE) * `password_hash` (VARCHAR) * `created_at` (TIMESTAMP) **Table : `events`** * `event_id` (PK, UUID) * `name` (VARCHAR) * `venue` (VARCHAR) * `date_time` (TIMESTAMP) * `total_seats` (INT) * `image_url` (VARCHAR) **Table : `seats`** * `seat_id` (PK, UUID) * `event_id` (FK vers `events.event_id`) * `section` (VARCHAR) * `row_number` (VARCHAR) * `seat_number` (VARCHAR) * `price` (DECIMAL) * `status` (ENUM : 'available', 'reserved', 'sold') * `version` (INT, pour verrouillage optimiste) **Table : `reservations`** * `reservation_id` (PK, UUID) * `user_id` (FK vers `users.user_id`) * `event_id` (FK vers `events.event_id`) * `status` (ENUM : 'pending', 'confirmed', 'expired', 'cancelled') * `reserved_at` (TIMESTAMP) * `expires_at` (TIMESTAMP) * `payment_id` (FK vers `payments.payment_id`, nullable) * `total_amount` (DECIMAL) * `created_at` (TIMESTAMP) * `updated_at` (TIMESTAMP) **Table : `reservation_seats` (Table de Jonction)** * `reservation_id` (FK vers `reservations.reservation_id`) * `seat_id` (FK vers `seats.seat_id`) * (PK Composite : `reservation_id`, `seat_id`) **Table : `payments`** * `payment_id` (PK, UUID) * `reservation_id` (FK vers `reservations.reservation_id`) * `user_id` (FK vers `users.user_id`) * `amount` (DECIMAL) * `currency` (VARCHAR) * `provider_transaction_id` (VARCHAR, UNIQUE) * `status` (ENUM : 'initiated', 'pending', 'succeeded', 'failed', 'refunded') * `created_at` (TIMESTAMP) * `updated_at` (TIMESTAMP) ### 4. Flux de Requête **A. Parcourir les Événements et Afficher la Disponibilité des Sièges :** 1. **Requête Utilisateur :** Navigateur/application de l'utilisateur demande `/events` ou `/events/{id}/seatmap`. 2. **CDN :** Sert les actifs statiques (images d'événements, JS/CSS) s'ils sont mis en cache. 3. **API Gateway :** Authentifie l'utilisateur, route la requête vers le Service Événement ou le Service Siège. 4. **Service Événement :** Récupère les détails de l'événement depuis PostgreSQL (ou le cache Redis). 5. **Service Siège :** Récupère le plan de salle et la disponibilité depuis le cache Redis. Si non trouvé dans le cache, interroge la table `seats` de PostgreSQL, met à jour le cache et renvoie les données. 6. **Réponse :** Données renvoyées à l'utilisateur. (Latence P95 < 300 ms). **B. Réserver des Sièges :** 1. **Requête Utilisateur :** L'utilisateur sélectionne des sièges et clique sur 'Réserver', envoyant `POST /events/{id}/reserve` avec `event_id`, `seat_ids`, `user_id`. 2. **API Gateway :** Route vers le Service Réservation. 3. **Service Réservation :** * **Verrou Distribué :** Acquiert un verrou distribué dans Redis pour chaque `seat_id` afin d'empêcher les modifications concurrentes. (par exemple, `LOCK:seat:{seat_id}`). * **Vérification du Statut du Siège :** Interroge la table `seats` (ou le cache Redis) pour vérifier que les sièges sélectionnés sont 'available'. * **Transaction :** Démarre une transaction de base de données. * **Mise à Jour des Sièges :** Met à jour le `status` des sièges sélectionnés à 'reserved' dans la table `seats`. * **Création de Réservation :** Insère un nouvel enregistrement dans la table `reservations` avec `status='pending'`, `reserved_at`, et `expires_at` (heure actuelle + 10 minutes). * **Liaison des Sièges :** Insère des enregistrements dans `reservation_seats` pour chaque siège réservé. * **Validation de la Transaction.** * **Définition du TTL Redis :** Définit une clé Redis (par exemple, `RESERVATION_EXPIRY:{reservation_id}`) avec un TTL de 10 minutes. Cela agit comme un déclencheur d'expiration rapide. * **Libération des Verrous :** Libère les verrous distribués pour les sièges. 4. **Réponse :** Renvoie `reservation_id` et `expires_at` à l'utilisateur. (Latence P95 < 800 ms hors paiement). **C. Payer une Réservation :** 1. **Action Utilisateur :** L'utilisateur initie le paiement d'une réservation `pending`. 2. **Requête Utilisateur :** Le navigateur/application envoie `POST /payments/initiate` avec `reservation_id` au Service Paiement. 3. **Service Paiement (Interne) :** * Crée un enregistrement `payment` avec `status='initiated'`. * Appelle l'API du Fournisseur de Paiement externe (par exemple, Stripe, PayPal) avec les détails de la réservation et le montant. * Redirige l'utilisateur vers la page du Fournisseur de Paiement. 4. **Fournisseur de Paiement Externe :** Traite le paiement. 5. **Rappel du Fournisseur de Paiement :** Après un paiement réussi/échoué, le fournisseur externe envoie un webhook asynchrone `POST /payments/callback` au Service Paiement. 6. **Service Paiement (Interne) - Gestionnaire de Rappel :** * **Vérification d'Idempotence :** Utilise `provider_transaction_id` pour s'assurer que le rappel est traité une seule fois. * Met à jour le statut de l'enregistrement `payment` (`succeeded` ou `failed`). * Publie un événement `PaymentConfirmed` ou `PaymentFailed` sur Kafka, incluant `reservation_id` et `payment_id`. 7. **Service Réservation - Consommateur Kafka :** * Consomme l'événement `PaymentConfirmed`. * **Verrou Distribué :** Acquiert un verrou pour `reservation_id`. * **Transaction :** Démarre une transaction de base de données. * **Mise à Jour Réservation :** Met à jour la table `reservations` : `status='confirmed'`, lie `payment_id`. * **Mise à Jour Sièges :** Met à jour le `status` des sièges associés dans la table `seats` à 'sold'. * **Validation de la Transaction.** * **Suppression du TTL Redis :** Supprime la clé `RESERVATION_EXPIRY:{reservation_id}` de Redis. * **Libération du Verrou.** * Publie un événement `TicketIssued` sur Kafka. 8. **Service Notification - Consommateur Kafka :** Consomme l'événement `TicketIssued`, génère le billet numérique et envoie un e-mail/notification push à l'utilisateur. **D. Expiration des Réservations :** 1. **Événements Keyspace Redis / Travailleur d'Arrière-plan :** * **Chemin Rapide (TTL Redis) :** Lorsqu'une clé `RESERVATION_EXPIRY:{reservation_id}` expire dans Redis, un événement keyspace est déclenché. Un microservice dédié ou un travailleur d'arrière-plan consomme cet événement. * **Chemin Robuste (Scan BDD) :** Un Service de Travailleurs d'Arrière-plan scanne périodiquement (par exemple, toutes les 30 secondes) la table `reservations` pour les enregistrements où `status='pending'` et `expires_at < current_time`. 2. **Logique du Travailleur :** * Pour chaque réservation `pending` expirée : * **Verrou Distribué :** Acquiert un verrou pour `reservation_id`. * **Vérification du Statut :** Vérifie que la réservation est toujours `pending` (pour éviter d'expirer des réservations déjà payées en raison de conditions de concurrence ou d'événements retardés). * **Transaction :** Démarre une transaction de base de données. * **Mise à Jour Réservation :** Met à jour la table `reservations` : `status='expired'`. * **Mise à Jour Sièges :** Met à jour le `status` des sièges associés dans la table `seats` à 'available'. * **Validation de la Transaction.** * **Libération du Verrou.** ### 5. Stratégie de Mise à l'Échelle pour les Pics de Trafic * **Services Sans État :** Tous les services applicatifs (Utilisateur, Événement, Siège, Réservation, Paiement, Notification) sont conçus pour être sans état, permettant une mise à l'échelle horizontale. * **Groupes d'Auto-Mise à l'Échelle (ASG) :** Les services sont déployés dans des ASG qui ajoutent/suppriment automatiquement des instances en fonction de métriques telles que l'utilisation du CPU, la profondeur de la file d'attente des requêtes ou des métriques personnalisées (par exemple, réservations actives). * **Équilibreurs de Charge :** Les équilibreurs de charge d'application (ALB) distribuent le trafic entrant entre les instances saines de chaque service dans plusieurs zones de disponibilité. * **CDN :** Le réseau de diffusion de contenu met en cache les actifs statiques (images d'événements, JS, CSS) pour décharger le trafic des services backend et réduire la latence pour les utilisateurs. * **Mise en Cache (Redis) :** L'utilisation intensive de Redis pour la mise en cache des données fréquemment consultées (disponibilité des sièges, détails des événements) réduit considérablement la charge de la base de données, en particulier lors des vues de navigation et de plans de salle à forte lecture. * **Files d'Attente (Kafka) :** Kafka agit comme un tampon, découplant les services et absorbant les pics de trafic. Les opérations asynchrones (rappels de paiement, notifications, traitement de l'expiration des réservations) sont envoyées à Kafka, permettant aux services de les traiter à leur propre rythme sans bloquer les requêtes des utilisateurs. * **Répliques de Lecture de Base de Données :** Les instances PostgreSQL sont configurées avec plusieurs répliques de lecture. Les services à forte lecture (Service Événement, Service Siège pour les plans de salle) peuvent diriger leurs requêtes vers ces répliques, déchargeant la base de données principale. * **Partitionnement de Base de Données (Potentiel Futur) :** Si une seule instance PostgreSQL devient un goulot d'étranglement pour les écritures, le partitionnement par `event_id` ou `user_id` pourrait être envisagé. Cela impliquerait de distribuer les données sur plusieurs instances de base de données. * **Pool de Connexions :** Gestion efficace des connexions à la base de données pour minimiser la surcharge et maximiser le débit. * **Limitation de Débit :** Implémentée au niveau de l'API Gateway pour protéger les services backend contre le trafic abusif ou les pics soudains et accablants. ### 6. Approche de Fiabilité et de Reprise après Sinistre * **Déploiement Multi-Zone de Disponibilité (Multi-AZ) :** Tous les services et magasins de données sont déployés dans au moins trois zones de disponibilité au sein de la région cloud. Cela offre une résilience contre les pannes au niveau des zones de disponibilité. * **Réplication et Basculement de Base de Données :** * **PostgreSQL :** Configuration primaire-réplique. Les données critiques (sièges, réservations) utilisent la réplication synchrone pour garantir un RPO < 1 minute. Mécanismes de basculement automatisés (par exemple, Patroni, basculement RDS géré par le cloud) promeuvent une réplique en primaire en cas de défaillance du primaire, atteignant un RTO < 15 minutes. * **Redis :** Mode Sentinel ou Cluster pour une haute disponibilité, avec des données répliquées entre les nœuds dans différentes AZ. * **Durabilité Kafka :** Les courtiers Kafka sont déployés dans plusieurs AZ avec un facteur de réplication > 1 (par exemple, 3) pour garantir la durabilité des messages et la disponibilité même en cas de défaillance d'une AZ ou d'un courtier. * **Sauvegardes Automatisées :** Sauvegardes régulières et automatisées de PostgreSQL vers le stockage objet avec des capacités de récupération à un instant T. Instantanés pour Redis. * **Services Sans État :** Les services sont conçus pour être sans état, ce qui signifie que toute instance peut être remplacée ou redémarrée sans perte de données, contribuant ainsi à une haute disponibilité. * **Disjoncteurs et Nouvelles Tentatives :** Implémentés dans la communication inter-services pour prévenir les défaillances en cascade. Les services dégraderont gracieusement ou retenteront les requêtes échouées. * **Dégradation Gracieuse :** En cas de charge extrême, les fonctionnalités non critiques (par exemple, recommandations personnalisées) pourraient être temporairement désactivées pour privilégier la fonctionnalité principale (réservation, paiement). * **Objectif de Point de Récupération (RPO) < 1 minute :** Atteint par la réplication synchrone de la base de données pour les données critiques et la journalisation durable des messages de Kafka avec des paramètres de réplication appropriés. * **Objectif de Temps de Récupération (RTO) < 15 minutes :** Atteint par le basculement automatisé de la base de données, l'auto-mise à l'échelle des services applicatifs et des instances pré-chauffées ou des capacités de provisionnement rapides. ### 7. Choix de Cohérence qui Empêchent la Survente Empêcher la survente est primordial et nécessite une forte cohérence pour les mises à jour du statut des sièges. * **Verrous Distribués (Redis) :** Lorsqu'un utilisateur tente de réserver des sièges, le Service Réservation acquiert un verrou distribué pour chaque `seat_id` spécifique dans Redis. Cela garantit qu'une seule tentative de réservation peut modifier le statut d'un siège donné à la fois. Le verrou est détenu pendant la durée de la transaction de base de données qui met à jour le statut du siège et crée la réservation. * **Transactions ACID (PostgreSQL) :** Toutes les mises à jour du statut des `seats` et la création/mise à jour des enregistrements `reservations` sont effectuées dans une seule transaction ACID dans PostgreSQL. Cela garantit l'atomicité, la cohérence, l'isolation et la durabilité. Si une partie de la transaction échoue (par exemple, un autre utilisateur a déjà réservé un siège), l'ensemble de la transaction est annulée, garantissant qu'il n'y a pas de mises à jour partielles et empêchant la survente. * **Contrôle de Concurrence Optimiste (Numéros de Version) :** Pour la table `seats`, une colonne `version` peut être ajoutée. Lors de la mise à jour du statut d'un siège, la requête `UPDATE` inclut une clause `WHERE version = <old_version>`. Si la version ne correspond pas, cela signifie qu'une autre transaction a modifié le siège, et la transaction actuelle peut être retentée ou rejetée. Cela offre une couche de protection supplémentaire contre les conditions de concurrence, surtout si les verrous distribués échouent ou ne sont pas parfaitement implémentés. * **Traitement Idempotent des Rappels de Paiement :** Les rappels des fournisseurs de paiement sont `au moins une fois` et peuvent être désordonnés. Le Service Paiement traite ces rappels de manière idempotente, en utilisant le `provider_transaction_id` pour s'assurer qu'un paiement réussi n'est appliqué qu'une seule fois à une réservation, empêchant la double confirmation ou les mises à jour de statut incorrectes. * **Logique d'Expiration des Réservations :** Le processus d'expiration vérifie explicitement si une réservation est toujours `pending` avant de la marquer comme `expired` et de libérer les sièges. Cela évite une condition de concurrence où un paiement pourrait arriver juste au moment où le processus d'expiration est sur le point de s'exécuter. ### 8. Surveillance et Alertes * **Collecte de Métriques :** Utiliser Prometheus/Grafana ou une surveillance native au cloud (par exemple, CloudWatch, Stackdriver) pour collecter les métriques de tous les services, bases de données, caches et files d'attente. Métriques clés : * **Métriques Système :** Utilisation du CPU, utilisation de la mémoire, E/S disque, E/S réseau. * **Métriques Applicatives :** Taux de requêtes, taux d'erreurs (5xx), latence (p95, p99) pour tous les points de terminaison API, profondeurs de file d'attente, connexions actives, garbage collection. * **Métriques de Base de Données :** Latence des requêtes, utilisation du pool de connexions, taux de transactions, retard de réplication, interblocages. * **Métriques de Cache :** Taux de succès/échec du cache, utilisation de la mémoire. * **Métriques Kafka :** Retard producteur/consommateur, taux de messages, santé des courtiers. * **Journalisation Centralisée :** Agréger les journaux de tous les services dans un système de journalisation centralisé (par exemple, pile ELK, Splunk, Datadog). Utiliser la journalisation structurée pour une analyse et un traitement plus faciles. * **Traçage Distribué :** Implémenter le traçage distribué (par exemple, OpenTelemetry, Jaeger) pour visualiser les flux de requêtes à travers plusieurs services, identifier les goulots d'étranglement et déboguer les interactions complexes. * **Alertes :** Configurer des alertes pour les seuils critiques : * Taux d'erreurs élevés (par exemple, 5% d'erreurs 5xx sur 5 minutes). * Latence élevée (par exemple, latence API p95 > 800 ms). * Indisponibilité de service ou instances non saines. * Retard de réplication de base de données dépassant les seuils. * Accumulation de files d'attente. * Échecs des rappels de paiement ou des expirations de réservation. * Épuisement des ressources (CPU, mémoire, disque). * **Tableaux de Bord :** Créer des tableaux de bord en temps réel pour la visibilité opérationnelle, affichant les métriques clés et la santé des services. ### 9. Compromis Clés ou Alternatives * **Choix de la Base de Données :** * **Alternative :** Base de données NoSQL (par exemple, Cassandra, DynamoDB) pour une évolutivité d'écriture extrême. **Compromis :** Bien que le NoSQL puisse gérer une échelle massive, obtenir une forte cohérence pour des opérations transactionnelles complexes comme les réservations de sièges (qui impliquent plusieurs mises à jour et vérifications) est beaucoup plus difficile et nécessite souvent une logique complexe au niveau de l'application. Les propriétés ACID de PostgreSQL simplifient la prévention de la survente, et son évolutivité peut être gérée par des répliques de lecture et le partitionnement. * **Mécanisme de Verrouillage :** * **Alternative :** Verrous de ligne au niveau de la base de données. **Compromis :** Peut entraîner une contention plus élevée et des interblocages potentiels dans des scénarios de haute concurrence, affectant les performances. Les verrous distribués Redis sont généralement plus rapides et déchargent le mécanisme de verrouillage de la base de données, mais nécessitent une implémentation soignée (par exemple, gestion de l'expiration des verrous, garantie de l'atomicité de l'acquisition/libération des verrous). * **Expiration des Réservations :** * **Alternative :** S'appuyer uniquement sur les événements keyspace TTL de Redis. **Compromis :** Bien que rapide, les événements keyspace de Redis ne sont pas garantis d'être livrés (par exemple, si Redis redémarre ou si des événements sont manqués). L'approche choisie combine le TTL Redis pour un chemin rapide avec un travailleur d'arrière-plan robuste scannant la base de données pour une cohérence éventuelle, garantissant qu'aucune réservation ne reste bloquée en permanence en `pending`. * **Gestion des Rappels de Paiement :** * **Alternative :** Rappel synchrone du fournisseur de paiement. **Compromis :** Ceci est rarement proposé par les fournisseurs externes et nécessiterait que la plateforme soit hautement disponible et réactive au fournisseur de paiement, introduisant un couplage étroit. L'approche asynchrone, `au moins une fois`, via Kafka est standard et plus résiliente, mais nécessite un traitement idempotent et la gestion des messages désordonnés. * **Microservices vs Monolithe :** * **Alternative :** Architecture monolithique. **Compromis :** Plus simple à développer initialement, mais plus difficile à mettre à l'échelle individuellement, à déployer indépendamment et à gérer pour de grandes équipes. Les microservices offrent une meilleure évolutivité, une isolation des pannes et une diversité technologique, mais introduisent une complexité opérationnelle (transactions distribuées, surveillance, déploiement). ### 10. Hypothèses * **Authentification Utilisateur :** Les utilisateurs sont authentifiés avant d'effectuer des actions nécessitant une identité (par exemple, réserver des sièges, consulter des billets). * **Conformité PCI :** Le fournisseur de paiement externe gère toutes les exigences de conformité PCI DSS ; le Service Paiement interne ne fait qu'orchestrer et stocker des données de paiement minimales et non sensibles. * **Capacité de la Région Cloud :** La région cloud choisie dispose d'une capacité de calcul, réseau et stockage suffisante pour gérer les charges de pointe spécifiées. * **Latence Réseau :** La latence réseau interne au sein de la région cloud et entre les zones de disponibilité est suffisamment faible pour respecter les objectifs de latence. * **Sécurité :** Des pratiques de sécurité standard (par exemple, chiffrement en transit et au repos, validation des entrées, contrôle d'accès, analyse des vulnérabilités) sont implémentées dans tout le système, bien que non détaillées dans cette conception. * **Fiabilité du Fournisseur de Paiement Externe :** Le fournisseur de paiement externe est supposé être hautement disponible et fiable pour traiter les paiements et envoyer des rappels.