Préparer un entretien : Back-End Developer

La classe rendue est la suivante :

class LimiteurDebit:
    def __init__(self, max_requetes, fenetre_secondes):
        self.max_requetes = max_requetes
        self.fenetre = fenetre_secondes
        self.historique = {}

def autoriser(self, cle, maintenant): journal = self.historique.setdefault(cle, []) seuil = maintenant - self.fenetre while journal and journal[0] <= seuil: journal.pop(0) if len(journal) >= self.max_requetes: return False journal.append(maintenant) return True ```

Chaque clé possède son propre journal d'horodatages dans le dictionnaire historique, ce qui isole les compteurs entre clients. À chaque appel, les horodatages plus anciens que maintenant moins fenetre_secondes sont retirés du début du journal (fenêtre glissante, pas fenêtre fixe), avant de comparer sa longueur au maximum autorisé. Si le journal a atteint le maximum après nettoyage, la requête est refusée sans être enregistrée ; sinon elle est acceptée et son horodatage est ajouté. Cette implémentation est une création pédagogique Avanttoi ; elle ne reproduit pas le test réel demandé par Stuart, dont le contenu exact n'est pas publié.

La fenêtre est bien glissante (basée sur maintenant - fenetre_secondes) et non fixe, chaque clé a un compteur indépendant, une requête refusée n'est pas comptabilisée dans le journal, et le code s'exécute sans erreur sur des appels avec des instants croissants.

La conception repose sur une clé d'idempotence stable, ici l'identifiant d'événement fourni par le fournisseur de paiement (par exemple event_id). Avant tout traitement métier, le point d'entrée tente d'insérer cet event_id dans une table ou un index dédié avec une contrainte d'unicité, dans la même transaction que l'effet métier (par exemple la mise à jour du statut de la commande). Si l'insertion réussit, l'événement est traité normalement et la transaction est validée. Si l'insertion échoue à cause de la contrainte d'unicité, cela signifie que l'événement a déjà été reçu : le point d'entrée renvoie alors un statut de succès (par exemple 200) sans rejouer l'effet métier, car du point de vue du fournisseur de paiement l'événement a bien été reçu avec succès la première fois. Stocker la clé et appliquer l'effet métier dans la même transaction évite la fenêtre de risque où un doublon arriverait entre l'enregistrement de la clé et l'application de l'effet. Renvoyer une erreur sur un doublon serait incorrect, car cela inciterait le fournisseur à renvoyer indéfiniment le même événement.

La clé d'idempotence est l'identifiant d'événement du fournisseur (pas un hachage du corps de la requête, plus fragile), l'enregistrement de la clé et l'effet métier sont dans la même transaction, et un doublon renvoie un succès sans rejouer l'effet plutôt qu'une erreur.

Le scénario de vente en trop se produit ainsi : la requête A lit la quantité disponible (par exemple 1), la juge positive ; avant qu'elle n'écrive la nouvelle valeur, la requête B lit à son tour la même quantité encore égale à 1, la juge également positive ; les deux requêtes décrémentent alors chacune de leur côté et écrivent 0, alors que deux ventes ont été acceptées pour un seul article en stock. Le problème vient de la séparation entre la lecture et l'écriture, qui laisse une fenêtre où deux requêtes peuvent lire la même valeur avant qu'aucune n'ait écrit. Le correctif recommandé n'ajoute pas de verrou applicatif en mémoire, qui ne protège pas plusieurs instances du service, mais utilise une opération atomique côté base de données : une mise à jour conditionnelle du type UPDATE stock SET quantite = quantite - 1 WHERE article_id = ? AND quantite > 0, puis vérification du nombre de lignes affectées. Si aucune ligne n'est affectée, cela signifie que le stock était déjà insuffisant au moment de l'écriture, et la vente doit être refusée ; la base de données garantit l'atomicité de la lecture-vérification-écriture pour cette ligne, ce qu'aucun verrou en mémoire de processus ne peut garantir sur plusieurs instances.

La fenêtre de compétition entre lecture et écriture est expliquée avec un scénario concret à deux requêtes, le correctif utilise une opération atomique côté base de données (mise à jour conditionnelle ou équivalent) plutôt qu'un verrou applicatif en mémoire, et la vérification du nombre de lignes affectées est mentionnée comme moyen de détecter l'échec.