Laravel Geocode Cache Laravel Package

Product Decisions This Supports

• Build vs. buy on the geocoding layer. Geocoding via Google is a commodity; the cache is the only thing you'd otherwise build. This package is the "don't build it" answer for the narrow job of "same address, resolved repeatedly."
• Unit-economics modelling. Every cache hit is a billable request avoided. The new 29-day retention ceiling sets a hard floor on refresh frequency, so cost models should assume worst-case volume of roughly unique addresses × (30/29) per month rather than treating the cache as permanent storage. That changes the shape of a spend forecast, not just its magnitude.
• Compliance as a product constraint, not an implementation detail. Google's terms cap how long geocoding results may be stored (~30 days). v0.2.0 enforces that in code, which means a security review or privacy-policy question ("what location data do we retain, and for how long?") can be answered from the codebase instead of an engineering research spike.
• Feature scoping. Supports anything that resolves the same addresses repeatedly: store locators, delivery ETA estimation, address validation at checkout, map pins on listings. If a feature resolves addresses once per user action with little overlap, the cache pays for itself only marginally.
• Vendor exit strategy. An address-keyed cache is a natural seam if you later switch providers — with the caveat that cached payloads are provider-shaped, so a migration isn't free.
• Data-retention policy commitments. What you can promise customers about stored location data is now bounded by the dependency, not by your own policy ambition.

When to Consider This Package

Adopt when all of the following hold:

• Laravel/PHP stack, geocoding through Google, and the same or similar addresses get resolved more than once.
• Per-request billing is material enough that hit rate is worth instrumenting.
• You want a drop-in cache rather than a bespoke repository plus pruning job.
• You can live with a ~29-day ceiling on cached results. If the product genuinely needs to persist geocodes indefinitely, this is the wrong tool — you need a licensed dataset, a provider whose terms permit persistence, or a design that stores provider IDs rather than coordinates.

Look elsewhere or build in-house when:

• You need sub-day freshness (moving targets, live routing).
• You need batch/bulk geocoding pipelines — this is a thin caching wrapper, not an orchestration or failover layer.
• You need multi-provider redundancy or automatic failover.
• You are not on Laravel.
• You need semver stability: this is pre-1.0, and v0.2.0 is proof that breaking changes ship in minor versions. Pin the version and schedule the upgrade deliberately.

Caveat: this assessment is derived from release notes only, not from a review of the package internals. Cache-key strategy, collision behaviour, and driver assumptions are unverified and should be read before adoption.

How to Pitch It (Stakeholders)

For executives (one paragraph): We pay Google per geocoding request, and we currently pay repeatedly for the same addresses. This package caches those results inside our existing Laravel cache — no new infrastructure. More importantly, the new v0.2.0 release enforces Google's ~30-day retention limit in code, which removes a quiet compliance exposure: we can now demonstrate that we aren't warehousing licensed location data. Cost impact is a straightforward function of cache hit rate; risk is low because a cache miss degrades to latency and spend, never to incorrect behaviour.

For engineering: Small dependency, standard Laravel cache driver, no operational surface added. v0.2.0 is a breaking change: TTLs configured above 29 days are now clamped, so audit configuration before upgrading — and expect a one-time cold-cache effect where previously long-lived entries expire and billable calls spike for a short window after deploy. Validate the cache key derivation before rolling out broadly; address normalisation differences ("St." vs "Street") directly determine hit rate, and therefore the entire business case. Treat the package as pre-1.0: pin it, read the diff on minor bumps, and keep a thin wrapper of our own around the call site so an exit stays cheap.

Decision requested: Approve a bounded pilot — internal tools or one low-traffic customer-facing surface — instrument hit rate and spend for one billing cycle, then decide on broader rollout with real numbers rather than the vendor's estimate.