# 0e. Space level Algolia index
Date: 2020-01-20
Driver: Wisen Tanasa
# Status
Accepted
# Context
We have decided to use Algolia for our search. We need to make sure that we are able to show listings in our search page by using Algolia. The listings that we show in our search page are shown per building, which means we will not show two listings that are from the same building. We need to decide what kind of data do we want to store in Algolia to support our needs.
Based on different search criteria, these are the scenarios that will influence the technical decision:
- Show matching space details, image, and price for a particular building
- Show the maximum capacity and minimum price for a particular building
There are two approaches that we have considered:
# Approach 1: Store building level index
This approach stores a building as the top-level object in the index. As a building may have multiple spaces, the record will contain all of the spaces available in that building too.
# Approach 2: Store space level index
This approach stores a space as the top-level object in the index. As we may need to show building level data, such as the building location, we'll also be storing the associated building object in the record (minus all of the other spaces).
# Decision
We're going with Approach 2: We'll be storing space level data in Algolia index, and it'll have a link to the building.
# Consequences
| Business upside | Business downside |
|---|---|
| Unlimited number of spaces in a building | Costlier Algolia usage |
| Easier to show building more than once | Harder to reason about |
| Easier to find space match | Harder to show aggregate data |
# + Unlimited number of spaces in a building
As we're storing the record on space level, the record size we'll be storing in Algolia will be very predictable and won't exceed the 10KB limit.
# + Easier to show building more than once
Should we want to show more 1 building more than once in the search page, we'll be able to do so easily. This is a supported feature in Algolia.
In contrast if we store building record data, should there be a need for us to show a building more than once, it'll not be possible to do that at all.
# + Easier to find space match
We want to show the best matching space based on the seeker's search criteria. Because we'll be storing our records on space level, what we get back from Algolia will be the matching space. What we get back from Algolia is what we're showing to the seeker.
When we store our records in building level, we'll have to execute a second search on the client-side (the first search is for building record retrieval from Algolia). Even though this is technically feasible, we're not leveraging our search engine properly.
# - Costlier Algolia usage
Algolia charges us per number of records and operations. Assuming we have 500 buildings, we'll be storing 5000 spaces if we have 10 spaces per building.
# - Harder to reason about
Our current use case says that we'll never show a building more than once in the search page. This implies that the listing we're showing is a building. Further, when the listing is clicked, we will open a building page. This makes it more logical for us to store building level record. This is the reason why it feels very unnatural to store our records on the space level.
# - Harder to show aggregate data
When we need to show the maximum capacity allowed in a building, we can easily calculate this on a building level as the data is already available. If we're storing our records on space level, we will not have any other spaces data available on query time, therefore we'll not be able to run any aggregate functions easily to a building.