Проблема API-ключей, которые никогда не истекают
Ключ, выданный много лет назад, ни разу не заменённый и до сих пор действующий, это не удобство. Это риск, на который никто не смотрел уже много лет.
Что на самом деле требуется для данных о местоположении «в реальном времени»
Ярлык «в реальном времени» приклеивают ко многим продуктам с данными о местоположении как сокращение для быстрого ответа, а скорость действительно стоит оптимизировать. Но это совсем другое утверждение, чем то, что «реальное время» должно на самом деле означать для данных, описывающих что-то о текущем состоянии мира: что ответ отражает то, что верно прямо сейчас, а не быстрый поиск с низкой задержкой по набору данных, который сам был составлен какое-то время назад и с тех пор толком не обновлялся.
Это различие особенно важно именно для геолокации IP, потому что соответствие между диапазонами IP-адресов и их физическим местоположением со временем меняется: блоки адресов переназначаются, перераспределяются или используются по-новому региональными интернет-регистраторами, которые ими управляют. Поиск, отвечающий за несколько миллисекунд по устаревшему соответствию, одновременно быстрый и неверный, и скорость никак не исправляет эту неверность. Настоящая геолокация IP в реальном времени требует, чтобы само соответствие поддерживалось в актуальном состоянии, с живым процессом поиска и кешем, который обновляется, а не рассматривается как фиксированный разовый снимок.
Мы построили нашу геолокацию IP именно вокруг этого различия: она работает вживую, кеш используется для низкого времени ответа, а не как замена свежести, а фоновый процесс повторных попыток продолжает обрабатывать данные, требующие перепроверки, вместо периодической задачи cron в роли единственного механизма поддержания соответствия в актуальном состоянии. Цель в том, чтобы кеш делал поиск быстрым, не делая его устаревшим, а это другая цель проектирования, чем кеш, который существует исключительно для того, чтобы никогда ничего не пересчитывать, актуально оно или нет.
То же различие в другой форме относится к данным о часовых поясах. Быстрый ответ со смещением, которое не учитывает недавний переход на летнее время или недавнее изменение правил правительством, не является ответом в реальном времени в каком-либо осмысленном смысле, даже если он пришёл за десять миллисекунд. Реальное время здесь означает, что лежащий в основе справочник, в данном случае база данных часовых поясов IANA, отслеживается и применяется по мере изменений, а не что ответ быстро пришёл из таблицы, к которой давно никто не прикасался.
Мы считаем, что «реальное время» заслуживает того, чтобы рассматриваться прежде всего как утверждение об актуальности данных и лишь во вторую очередь о задержке ответа, хотя задержку легче всего измерить и продемонстрировать. Провайдер может действительно оптимизировать время ответа до доли секунды, незаметно позволяя лежащим в основе данным месяцами устаревать, и снаружи быстрый неверный ответ и быстрый верный ответ выглядят одинаково, пока что-то дальше по цепочке не начнёт зависеть от разницы. Более трудная и менее заметная работа состоит в том, чтобы поддерживать актуальность самих данных. Именно эта часть действительно заслуживает такого ярлыка, и именно её клиент не может проверить, просто замерив время запроса.