12. Google Places API Cache

Date: 2026-02-06

Status

Accepted

Context

Google Places API calls were being made without caching, resulting in excessive API consumption and costs. Each autocomplete query and place details lookup triggered a new API call, even for identical requests within short time periods.

Google Places data (addresses, place details) is static for practical purposes—locations don’t change frequently.

Decision

Implement Redis-based caching for Google Places API responses using Upstash Redis.

Implementation:

• withCache<T>(key, fn, ttl) helper in server/graphql/helpers/redisCache.ts
• SHA-256 hashing for cache keys (truncated to 32 chars) to handle variable-length query strings
• 30-day TTL (G_PLACES_TTL = 2592000 seconds) for all Places data
• Cache-aside pattern: check cache → miss triggers API call → store result
• Errors on cache operations reported to Sentry but don’t interrupt request flow

Cached Resolvers:

• googlePlaceDetails - cache key: place_details_{placeId}_{lang}
• googlePlacesAutocomplete - cache key: place_autocomplete_{lang}_{hash(query+lang)}

Why Upstash Redis:

• Already in use for other caching (KV store)
• Serverless-compatible (HTTP-based)
• Low latency

Consequences

Benefits

• Reduced Google Places API costs
• Faster response times for repeated queries
• Graceful degradation: cache failures don’t break functionality

Risks & Mitigations

• Stale data: Places data rarely changes; 30-day TTL is acceptable
  • Mitigation: Can manually invalidate cache if needed
• Cache key collisions: SHA-256 hash collisions are negligible
• Redis unavailability: API calls proceed without caching; errors logged to Sentry