Migrar una automatización de Zapier o Make a un nuevo host de geocodificación
Las automatizaciones sin código basadas en un paso de geocodificación necesitan un enfoque de migración distinto al del código propio. Así puedes gestionar ese cambio.
Reasignar los resultados en caché tras cambiar de proveedor
El almacenamiento en caché es una optimización sensata y habitual en geocodificación, ya que las mismas direcciones suelen consultarse una y otra vez y hay pocos motivos para pagar o esperar una consulta nueva cada vez. Pero una caché acumulada durante meses o años con los resultados de un proveedor crea un problema concreto durante una migración: qué ocurre con todos esos datos en caché cuando cambia el proveedor que hay detrás.
La postura general más segura es que los resultados en caché ligados a la precisión de coordenadas, las convenciones de formato de direcciones o la confianza de coincidencia de un proveedor concreto no deben tratarse en silencio como equivalentes a los resultados de un nuevo proveedor, aunque este sea en general preciso. La precisión de las coordenadas en particular puede diferir sutilmente entre proveedores, y una aplicación que guarda en caché una latitud y una longitud con varios decimales puede estar dependiendo de características de precisión propias del proveedor que generó originalmente ese número.
Algunos enfoques prácticos, más o menos en orden creciente de exhaustividad:
- Etiqueta las entradas en caché con su proveedor de origen. Si tu caché aún no registra qué proveedor generó cada resultado almacenado, añade ese campo antes de migrar, para poder distinguir en adelante las entradas antiguas de las nuevas en lugar de tratar toda la caché como un único conjunto indiferenciado
- Fija una caducidad para las entradas en caché antiguas. En lugar de invalidar toda la caché de golpe, lo que puede provocar un pico repentino de solicitudes en tiempo real al nuevo proveedor, deja que las entradas antiguas caduquen de forma natural según el TTL que ya use tu caché, para que la transición a resultados nuevos del nuevo proveedor se produzca de forma gradual
- Vuelve a verificar selectivamente las entradas en caché de más valor. Para las direcciones que importan de forma desproporcionada (una ubicación principal del negocio, una dirección de envío muy usada), vale la pena hacer una nueva consulta explícita al nuevo proveedor en lugar de esperar a que la caché caduque de forma natural, ya que son las entradas en las que más se notaría una discrepancia sutil
Como los resultados de geocodificación directa en particular pueden variar entre proveedores en su formato exacto y su precisión, este es un caso en el que probar una muestra significativa de tus direcciones reales en caché contra el nuevo proveedor antes del cambio completo tiene más valor que probar con direcciones sintéticas o escogidas a mano. Los datos reales en caché reflejan tus patrones de uso reales, casos excepcionales incluidos.
Los hosts de compatibilidad de My Geocode devuelven los datos con la misma estructura de campos que el proveedor original, así que el código que lee y guarda las entradas de caché por nombre de campo no debería necesitar reestructurarse durante una migración; solo los valores en sí pueden diferir ligeramente entre proveedores para una dirección determinada. Las cabeceras de cuota presentes en cada respuesta, entre ellas X-Quota-Used y X-Credits-Remaining, documentadas en /docs/rate-limits/, también conviene tenerlas en cuenta en un plan de invalidación de caché, ya que una oleada repentina de fallos de caché se traduce directamente en un pico de volumen de solicitudes, y dosificar esa oleada según tu cuota es una parte pequeña pero realmente útil de la planificación de la migración.
Tratar la migración de la caché como un pequeño proyecto propio, y no como algo secundario que ocurre automáticamente cuando el cambio de proveedor ya está en marcha, evita un tipo de problemas sutiles de calidad de datos que son mucho más difíciles de diagnosticar a posteriori que de planificar de antemano.