Nominatim: escalar el servicio sin ocultar el estado
La capa de aplicación sin estado puede escalar horizontalmente. Nominatim, en cambio, depende de datos persistentes en PostgreSQL/PostGIS y de un proceso explícito de importación y actualización.
Separar servicio, caché y datos
- Clientesbúsqueda · reverse geocoding
- Gatewayauth · rate limit · trazas
- Aplicaciónsin estado · normalización
- Rediscaché opcional · TTL
- Nominatimmotor de búsqueda geográfica
- PostgreSQL/PostGISíndices y datos persistentes
Qué puede ser stateless
El gateway y la capa HTTP pueden evitar sesiones locales y derivar cada respuesta de la solicitud, caché y servicios persistentes. Eso facilita réplicas y despliegues; no convierte el conjunto en un sistema sin estado.
- Balanceo entre réplicas de aplicación.
- Configuración y secretos externos al proceso.
- Timeouts y cancelación hacia Nominatim.
- Rate limits por consumidor.
Dónde vive el estado
PostgreSQL/PostGIS conserva los datos geoespaciales, índices y estructuras que Nominatim consulta. Importaciones, actualizaciones y backups son operaciones stateful que necesitan capacidad, ventanas y recuperación.
- Volúmenes persistentes y backup probado.
- Separación entre importación y consulta.
- Monitoreo de tamaño, índices y consultas.
- Política de actualización de datos OpenStreetMap.
Redis es una función, no un trofeo
Redis puede cachear búsquedas normalizadas, coordinar rate limits o absorber lecturas repetidas. TTL, cardinalidad y estrategia de invalidación deben definirse; si la tasa de acierto no justifica la complejidad, se elimina.
- Claves normalizadas y acotadas.
- TTL según frescura aceptable.
- Métricas de hit rate y memoria.
- Fallback correcto ante caída de caché.