Le problème des clés d'API qui n'expirent jamais
Une clé émise il y a des années, jamais renouvelée et toujours valide aujourd'hui n'est pas une commodité. C'est un risque que personne n'a vraiment examiné depuis des années.
Ce qu'exigent réellement des données de localisation « en temps réel »
« En temps réel » est accolé à de nombreux produits de données de localisation comme raccourci pour désigner des temps de réponse rapides, et la vitesse est une chose réelle qui mérite d'être optimisée. C'est aussi une affirmation totalement différente de ce que « temps réel » devrait vraiment signifier pour des données décrivant l'état actuel du monde : que la réponse reflète ce qui est vrai maintenant, et non une recherche rapide, à faible latence, dans un jeu de données compilé il y a un certain temps et qui n'a pas été véritablement mis à jour depuis.
Cette distinction compte surtout pour la géolocalisation d'IP, car la correspondance entre les plages d'adresses IP et leur emplacement physique évolue au fil du temps, à mesure que les blocs d'adresses sont réattribués, réalloués ou réaffectés par les registres internet régionaux qui les gèrent. Une recherche qui répond en quelques millisecondes à partir d'une correspondance périmée est à la fois rapide et fausse, et la vitesse ne corrige en rien l'erreur. Une véritable géolocalisation d'IP en temps réel exige que la correspondance sous-jacente elle-même soit tenue à jour, avec un processus de recherche en direct et un cache qui est actualisé au lieu d'être traité comme un instantané figé et ponctuel.
Nous avons construit notre géolocalisation d'IP précisément autour de cette distinction : elle fonctionne en direct, avec un cache utilisé pour garder des temps de réponse faibles, et non comme substitut à la fraîcheur des données, ainsi qu'un processus de relance en arrière-plan qui continue de traiter les données à revérifier, au lieu d'une tâche cron périodique servant de seul mécanisme pour tenir la correspondance à jour. L'objectif est que le cache rende le service rapide sans le rendre obsolète, ce qui est un objectif de conception différent d'un cache qui n'existe que pour éviter de jamais rien recalculer, à jour ou non.
La même distinction s'applique, sous une autre forme, aux données de fuseau horaire. Une réponse rapide décrivant un décalage qui n'a pas pris en compte un passage récent à l'heure d'été ou d'hiver ou un changement de règle récent décidé par un gouvernement n'est pas en temps réel au sens utile du terme, même si elle est arrivée en dix millisecondes. Ici, le temps réel signifie que la référence sous-jacente, en l'occurrence la base de données des fuseaux horaires de l'IANA, est suivie et appliquée au fil de ses changements, et non que la réponse est arrivée vite à partir d'une table que personne n'a touchée récemment.
Nous pensons que « temps réel » mérite d'être traité d'abord comme une affirmation sur la fraîcheur des données, et seulement ensuite sur la latence de réponse, même si la latence est la partie la plus facile à mesurer et à démontrer. Un fournisseur peut réellement optimiser son temps de réponse à une fraction de seconde tout en laissant discrètement les données sous-jacentes devenir obsolètes pendant des mois, et de l'extérieur, une mauvaise réponse rapide et une bonne réponse rapide se ressemblent jusqu'à ce que quelque chose en aval dépende de la différence. Le travail le plus difficile et le moins visible consiste à tenir les données elles-mêmes à jour. C'est la partie qui justifie réellement le label, et c'est aussi celle qu'un client ne peut pas vérifier simplement en chronométrant une requête.