12. Stop using Algolia for non-search

• Date: 2020-11-24
• Driver: Wisen Tanasa
• Contributor: Harsh S. Kulshrestha
• Approver: Wisen Tanasa

Status

Accepted

Context

Seekers are now able to create a shortlist by adding listings into it. Once a shortlist is created, they can compare the listings they have in a specific page where all the listings will be shown on a side by side view. The data that will be shown here will be different to what we currently have in our search page and building page. This means, with the addition of this feature, we'll have 3 pages where we require different form of data.

As we are adding Listing to our shortlist, the most straight forward way to retrieve the data at the moment is from Algolia. This is currently our approach in the building page, and we did this because:

• It made understanding the data model easier i.e. the model used on the search page is the same with the building page
• It made our architecture simpler, where there are no other systems that we need to interact with on the building page in the scenario where we have to show the building details + suggested similar spaces.

Unfortunately though, Algolia has 10KB payload size limit. If we're about to store a listing with the following data, we are hitting 9.5KB:

• 2000 characters building description (new)
• 40 images (current)
• 24 facilities (current)
• 5 nearby places (current - which is fairly low if we want to add more type of places other than stations)

This is getting very close to the ceiling of the limit! This limit though, is something that we currently have because we're sticking to Algolia legacy plan. Algolia had introduced a new plan, and in it's Standard plan, it does support a limit of 100KB by default.

Note: We have done a rough calculation of size in the other ADR, but we didn't calculate the building description and nearby places.

Decision

We will constrain the usage of Algolia only for searching. Any features that can be supported by querying data by ID, should be supported by other means.

Consequences

• + The search page will remain fast. Any extra attribute that we add that is not used on the search is a waste. Even though Algolia's newer plan support 100KB, the performance implication of increasing the payload size is undesirable. If we have 24 listings with size 100KB on the search page, users will have to download 2.4 MB to proceed!

• + We will gain better flexibility in terms of what we want to show in the listing card in the future. This gain is possible as we'll not have the need to store building description in Algolia. 2000 characters itself will take up 2KB, and we are still not sure if this is the character limit that we're going to impose.

• + We save cost on Algolia (Caveat: The billing works kind of differently).

  • To support 300,000 search a month, we'll incur $270 per month on the new Standard plan. In the legacy plan, this would only cost us $30 per month.
  • To support 2,000,000 search a month, we'll incur $1550 per month on the new Standard plan. In the legacy plan, this would only cost us $200 per month.

• - Additional technical effort will have to be done to support the query.

• - The model that we play around with will be different on every pages.