Backend platform / Search & discovery
A backend discovery system that combines location data from multiple external providers into a consistent search experience.
/ 01 — Overview
The platform needed to combine location and place information from multiple external providers, primarily Google Places and TripAdvisor. Each provider exposed different identifiers, schemas, category structures, ratings, review information, images, and geographic results.
Simply combining provider responses would produce inconsistent result shapes and duplicate locations. The backend therefore needed to provide a unified representation of places while handling provider-specific differences internally.
The discovery experience also needed to support geographic search, proximity, categories, ratings, result ranking, deduplication, and caching.
/ 02 — Architecture
A simplified view of the discovery boundary, not a complete production topology.
/ 03 — Normalization
Provider data was mapped into a unified internal representation so the rest of the application could work with a consistent API model instead of being tightly coupled to each external provider.
Google Places
TripAdvisor
/ 04 — Engineering challenges
The same physical place could appear in both providers with different provider IDs and slightly different metadata. Results required proximity-based matching together with place identity and name information before returning a unified result set.
Discovery supported coordinates, radius-based searches, proximity, location names, categories, and geographic filtering. TripAdvisor searches could cover areas through tiled searches around a center point, while Google results were incorporated into the same pipeline.
Returning each provider's original order would not produce a useful unified list. After normalization, results could be combined and interleaved using signals such as rating, review volume, and proximity without exposing exact scoring weights.
External location APIs are comparatively expensive and network-dependent. Caching provider responses and/or merged discovery results reduced unnecessary requests, improved repeat discovery behavior, and made the backend less dependent on provider response times.
/ 05 — Implementation areas
Provider identifiers and selected place information could be persisted so the application could maintain references to external places and support fallback and retrieval behavior. MongoDB and PostgreSQL were part of the broader backend stack.
Coordinates, radius-based discovery, proximity, location names, categories, and geographic filtering.
A consistent response boundary for consumers, independent of each provider's response shape.
Provider identity remains available alongside normalized place information.
/ 06 — Engineering decisions
External provider differences should be absorbed by the discovery layer rather than propagated throughout the application.
Provider IDs cannot identify the same real-world location across independent providers.
A unified ranking layer makes results from different providers comparable.
Third-party APIs should not be treated like local databases.
Normalization should not remove the ability to trace a result back to its original provider.
/ 07 — Takeaways
Integrating multiple external APIs is less about calling each API and more about designing the boundary between external data and your own system.
Normalization creates provider independence. Geographic identity is different from provider identity. Ranking needs to happen after heterogeneous data has a common shape, and caching keeps third-party dependencies from defining every request.
Continue exploring
