Das Problem mit API-Schlüsseln, die nie ablaufen
Ein Schlüssel, der vor Jahren ausgestellt, nie rotiert wurde und heute noch gültig ist, ist keine Bequemlichkeit. Er ist ein Risiko, das sich seit Jahren niemand mehr angesehen hat.
Was Standortdaten "in Echtzeit" tatsächlich erfordern
„Echtzeit“ wird vielen Standortdatenprodukten als Kurzform für schnelle Antwortzeiten angehängt, und Geschwindigkeit ist etwas Reales und Lohnendes, das man optimieren sollte. Es ist aber eine völlig andere Aussage als das, was „Echtzeit“ bei Daten, die etwas über den aktuellen Zustand der Welt beschreiben, eigentlich bedeuten sollte: dass die Antwort widerspiegelt, was genau jetzt zutrifft, und nicht eine schnelle Abfrage mit geringer Latenz gegen einen Datenbestand ist, der selbst vor einiger Zeit erstellt und seitdem nicht nennenswert aktualisiert wurde.
Diese Unterscheidung ist gerade für die IP-Geolokalisierung am wichtigsten, denn die Zuordnung zwischen IP-Adressbereichen und ihrem physischen Standort ändert sich im Laufe der Zeit, wenn Adressblöcke von den regionalen Internet-Registrierungsstellen, die sie verwalten, neu zugewiesen, umverteilt oder umgewidmet werden. Eine Abfrage, die in wenigen Millisekunden gegen eine veraltete Zuordnung antwortet, ist schnell und falsch zugleich, und die Geschwindigkeit ändert nichts an der Fehlerhaftigkeit. Echte IP-Geolokalisierung in Echtzeit erfordert, dass die zugrunde liegende Zuordnung selbst aktuell gehalten wird, mit einem Live-Abfrageprozess und einem Cache, der aufgefrischt wird, statt als feste, einmalige Momentaufnahme behandelt zu werden.
Wir haben unsere IP-Geolokalisierung gezielt um diese Unterscheidung herum gebaut: Sie läuft live, wobei Caching die Antwortzeiten niedrig hält und nicht als Ersatz für Aktualität dient, und ein Hintergrundprozess für Wiederholungsversuche arbeitet kontinuierlich Daten ab, die erneut geprüft werden müssen, statt dass ein regelmäßiger Cronjob als einziger Mechanismus dafür herhalten muss, die Zuordnung aktuell zu halten. Das Ziel ist, dass der Cache das System schnell macht, ohne es veralten zu lassen, und das ist ein anderes Designziel als ein Cache, der nur dazu existiert, nie wieder etwas neu berechnen zu müssen, ob aktuell oder nicht.
Dieselbe Unterscheidung gilt in anderer Form für Zeitzonendaten. Eine schnelle Antwort mit einem Versatz, der eine kürzliche Umstellung auf Sommer- oder Winterzeit oder eine kürzliche Regeländerung einer Regierung nicht berücksichtigt, ist in keinem sinnvollen Sinne Echtzeit, selbst wenn sie nach zehn Millisekunden zurückkam. Echtzeit bedeutet hier, dass die zugrunde liegende Referenz, in diesem Fall die IANA-Zeitzonendatenbank, verfolgt und angewendet wird, während sie sich ändert, und nicht, dass die Antwort schnell aus einer Tabelle kam, die in letzter Zeit niemand angefasst hat.
Wir finden, „Echtzeit“ sollte in erster Linie als Aussage über die Aktualität der Daten und erst in zweiter Linie über die Antwortlatenz verstanden werden, auch wenn die Latenz der Teil ist, der sich am leichtesten messen und vorführen lässt. Ein Anbieter kann die Antwortzeit tatsächlich auf Bruchteile einer Sekunde optimieren und die zugrunde liegenden Daten gleichzeitig still monatelang veralten lassen, und von außen sehen eine schnelle falsche und eine schnelle richtige Antwort gleich aus, bis etwas Nachgelagertes von dem Unterschied abhängt. Die schwierigere, weniger sichtbare Arbeit besteht darin, die Daten selbst aktuell zu halten. Das ist der Teil, der die Bezeichnung tatsächlich verdient, und zugleich der Teil, den ein Kunde nicht einfach durch das Messen einer Anfrage überprüfen kann.