Skip to content

Design a Nearby POI Service

Published 3 October 2026

A popular OpenAI system design question.

Problem Description

Design a nearby POI service that allows users to search for restaurants, gas stations, parks, hospitals, and other places around a geographic location.

The system stores approximately 200 million POIs globally and must answer nearby searches at high read volume. A request may ask for all matching POIs within a specified radius or for the nearest K results, optionally filtered by category or keyword. Results should be ordered primarily by geographic distance.

The main challenge is avoiding a scan of the entire global POI dataset for every request. The system needs a spatial index that quickly narrows the search to a small set of geographic cells and candidate POIs before performing exact distance calculations and ranking.

POI writes are comparatively rare and come only from business owners or platform administrators. Updates may take 30–60 seconds to appear in search, so the transactional write path can remain strongly durable while the search index and caches are updated asynchronously.

The central design tension is low-latency, highly available geospatial reads versus authoritative, durable POI updates. Slightly stale search results are acceptable; unavailable search results are generally not.

Functional Requirements

  • Given a latitude and longitude, users should be able to retrieve nearby POIs either within a specified radius or as the nearest K results. Searches may include category and keyword filters.
  • Search results should be ranked by geographic distance and contain enough summary information for a search-results page, while detailed POI information can be retrieved separately.
  • Users should be able to retrieve a POI detail record containing fields such as name, address, coordinates, category, operating hours, and a rating snapshot.
  • Authorized business owners and platform administrators should be able to create and update POI records. The authoritative write should be durable before acknowledgement, while the change may propagate asynchronously into the nearby-search index.
  • Users should be able to paginate beyond the initial nearby result set without repeating or skipping results unnecessarily as they browse.
  • If a regional cache or search replica is temporarily unavailable, the platform should prefer serving the most recent known-good, potentially stale result rather than returning no nearby data.

Non-Functional Requirements

  • Nearby search and POI-detail reads should target approximately 99.95% availability.
  • Nearby searches should complete within approximately 200 ms at p95, while POI-detail reads should complete within approximately 100 ms at p95.
  • POI create and update requests should normally be acknowledged within approximately 300 ms at p95.
  • The platform should support approximately 200M POIs, 50K search requests/sec at peak, and roughly 500 POI writes/sec.
  • Traffic is heavily read dominated at roughly 100:1 reads to writes, with substantial geographic skew toward major metropolitan areas.
  • The authoritative POI record must survive failures. Geospatial indexes, caches, and search replicas should be rebuildable derived state.
  • Search-index freshness may lag authoritative writes by approximately 30–60 seconds.