Our team was tasked with thinking over and developing a fast yet flexible geospatial search using open-source location data.
The use of Google Maps API was not possible, and the application worked on the basis of an open-source service called Pelias.
This API used the services of the world’s biggest open-source places database, WhosOnFirst, which had problems with data duplication at the time.
Finally, the Roomster team wanted the user to be able to specify many different parameters when searching.
General search flow design
We have optimized the search flow so that it consisted of 3 main stages:
- The user enters freeform text in the search field.
- This action triggers an API call to Pelias autocomplete API.
- This city ID is sent to our search API that returns all apartments matching the ID.
Data schema design
We created our internal city (state, block, room, etc.) IDs and mapped them to external ones (coming from Pelias).
It allowed us to get rid of data duplication while interacting with the current API and with any other geocoder in the future.
Choosing a database to improve performance
We chose ElasticSearch which was definitely the best choice for the sake of a high-load search.
It allowed using both simple city IDs (just integers) and geopoints for fully-fledged geospatial search.
By adding Kubernetes, as the most mature enterprise-ready orchestration system, our team managed to install the most configurable container orchestration system for microservices.
Choosing the right data schema, database engine and orchestration system allowed us to satisfy our client's functional and non-functional requirements.
Despite using an open-source service with messy data, we managed to build a flexible, scalable, and resilient search system.