Nominatim: scale the service without hiding state
A stateless application layer can scale horizontally. Nominatim depends on persistent PostgreSQL/PostGIS data and an explicit import and update process.
Separate service, cache, and data
- Clientssearch · reverse geocoding
- Gatewayauth · rate limit · traces
- Applicationstateless · normalization
- Redisoptional cache · TTL
- Nominatimgeographic search engine
- PostgreSQL/PostGISindexes and persistent data
What can be stateless
The gateway and HTTP application can avoid local sessions and derive every response from the request, cache, and persistent services. That enables replicas and deployment; it does not make the whole system stateless.
- Load balancing across application replicas.
- Configuration and secrets outside the process.
- Timeout and cancellation toward Nominatim.
- Rate limits per consumer.
Where state lives
PostgreSQL/PostGIS stores geospatial data, indexes, and structures queried by Nominatim. Imports, updates, and backups are stateful operations requiring capacity, windows, and recovery.
- Persistent volumes and tested backup.
- Separate import and query workloads.
- Monitor size, indexes, and queries.
- OpenStreetMap data update policy.
Redis is a function, not a trophy
Redis can cache normalized searches, coordinate rate limits, or absorb repeated reads. TTL, cardinality, and invalidation must be defined; remove it if hit rate does not justify complexity.
- Normalized, bounded keys.
- TTL based on acceptable freshness.
- Hit-rate and memory metrics.
- Correct fallback when cache is unavailable.