El problema de las claves de API que nunca caducan
Una clave emitida hace años, que nunca se ha rotado y que hoy sigue siendo válida, no es una comodidad. Es un riesgo que nadie ha revisado de verdad en años.
Qué exigen realmente los datos de ubicación "en tiempo real"
"En tiempo real" se asocia a muchos productos de datos de ubicación como forma abreviada de decir tiempos de respuesta rápidos, y la velocidad es algo real y que merece la pena optimizar. Pero es una afirmación completamente distinta de lo que "en tiempo real" debería significar para unos datos que describen algo sobre el estado actual del mundo: que la respuesta refleja lo que es cierto ahora mismo, no una consulta rápida y de baja latencia contra un conjunto de datos que se compiló hace tiempo y no se ha actualizado de forma significativa desde entonces.
Esta distinción importa sobre todo en la geolocalización de IP, porque la correspondencia entre los rangos de direcciones IP y su ubicación física cambia con el tiempo a medida que los registros regionales de internet que los gestionan reasignan, redistribuyen o dan otro uso a los bloques de direcciones. Una consulta que responde en unos milisegundos contra una correspondencia desactualizada es rápida y errónea a la vez, y la velocidad no arregla en nada el error. Una geolocalización de IP realmente en tiempo real requiere que la propia correspondencia subyacente se mantenga al día, con un proceso de consulta en vivo y una caché que se actualiza en lugar de tratarse como una instantánea fija y única.
Construimos nuestra geolocalización de IP precisamente en torno a esta distinción: funciona en vivo, con una caché que se usa para mantener bajos los tiempos de respuesta, no como sustituto de la actualidad de los datos, y un proceso de reintento en segundo plano que sigue revisando los datos que necesitan volver a comprobarse, en lugar de una tarea cron periódica como único mecanismo para mantener al día la correspondencia. El objetivo es que la caché la haga rápida sin dejarla desactualizada, que es un objetivo de diseño distinto al de una caché que existe solo para no volver a calcular nunca nada, esté al día o no.
La misma distinción se aplica, de otra forma, a los datos de zona horaria. Una respuesta rápida que describe un desfase sin tener en cuenta una transición reciente del horario de verano o un cambio reciente en las normas de un gobierno no es en tiempo real en ningún sentido significativo, aunque se haya devuelto en diez milisegundos. Aquí, tiempo real significa que la referencia subyacente, en este caso la base de datos de zonas horarias de la IANA, se sigue y se aplica a medida que cambia, no que la respuesta llegó rápido contra una tabla que nadie ha tocado últimamente.
Creemos que "en tiempo real" merece tratarse primero como una afirmación sobre la actualidad de los datos y después sobre la latencia de respuesta, aunque la latencia sea la parte más fácil de medir y demostrar. Un proveedor puede optimizar de verdad el tiempo de respuesta hasta una fracción de segundo mientras deja discretamente que los datos subyacentes se queden desactualizados durante meses, y desde fuera una respuesta rápida y errónea y una respuesta rápida y correcta parecen idénticas hasta que algo que depende de ellas nota la diferencia. El trabajo más difícil y menos visible es mantener los propios datos al día. Esa es la parte que realmente se gana la etiqueta, y también la parte que un cliente no puede verificar solo cronometrando una solicitud.