Meet Owen. Owen leads our engineering team, spearheading all the new features and enhancements in Stitch. When Owen isn’t elbows deep in code, he is playing with his adorable King Charles Spaniel, Dominic. Dominic is also an honorary member of the engineering team, providing moral support and a welcomed distraction when in the office.
As most of our customers have probably noticed, our search just became lightning fast. This was no small feat. So I sat down with Owen to learn all about the search turbo-boost.
Why did you decide to overhaul our search?
Simply put, our search as it was currently built was slowing down. This was actually a good thing as it meant that both Stitch customers and Stitch itself were outgrowing the initial design. As our customers were increasing the number of orders, products, and contacts in their accounts, the process of indexing and searching all that data was starting to become too much for our search process. Since we want our customers to keep growing at faster and faster paces, we wanted search functionality that could accommodate their needs.
Why is search so important in Stitch?
A major benefit of Stitch is that we help customers understand how the various pieces of their business are interconnected. We help them see not only that they sold $5,000 in revenue, but how that $5,000 was divided into products sold, across channels and between customers. In order to do this we have to be precise about the connection. For example, it is important when a customer is searching a product to find its quantity committed of that specific product and that it shows up and not a free text variation that is subject to inaccuracies. Think blue shirts vs blue shirt vs bleu shirt. We have a lot of one-to-many relationships that we need to get right.
So, what did you do to improve search?
We started by investigating the effort to build a more scalable solution ourselves. However, at the same time, we saw that various startups had recently started providing this as a service. After evaluating the feature set and flexibility of these services, we decided to integrate with a company called Algolia, rather than build it ourselves. Algolia is a hosted search company with incredibly talented engineers who are solely focused on ways to index and improve search. Algolia handles all of the data indexing and then makes that indexed data available for searching over their API. Since Algolia would now handle all of the indexing and searching, all that was left was build a system that could efficiently get them the data.
Actually a highlight of this whole process for me was the ability to research and talk to all these different companies to really understand who was leading the way in search. At Stitch we pride ourselves on being cutting edge in both the product we provide and the technology we use to create it. So, when we saw the unique ways that the Algolia team was using to optimize search indexing and providing incredibly fast search results, it got the whole engineering team really excited to be able to bring that technology into Stitch. At the end of the day, Algolia won out because of their flexibility and feature set regarding security and data protection.
We did quite a bit of research on the optimal search technology. We have a lot of experience with ElasticSearch (open source search product) in house for various other systems, but the overhead to ensure security for ElasticSearch was high. This is where Algolia came in. They had a lot of the technical and security related issues already sorted out, alleviating those concerns for us and speeding up our time to deployment. Rather than focusing engineering efforts on re-inventing the wheel we focus our efforts on getting the right data into Algolia.
How fast is the search?
90% of our search results are less than 1 millisecond. 99% of them are under 2 milliseconds. To put that in perspective, the human eye blinks at roughly 300 milliseconds. We are returning results as fast as you can type them in. It’s pretty incredible.
What did it take to implement Algolia?
What I love about our engineering team is that they really like to get their hands dirty and push stuff to the limits. Our product is better because of them. Our approach to Algolia was no different. We ended up spending a lot of our time focused on how we fast we could get the sheer amounts of data into Algolia. We are striving for near real time. This is pretty ambitious considering we send over hundreds of millions of rows of data into Algolia.
That’s a ton of data! How are you doing it?
There are two parts to the search, first is build time; which means getting the data to be searchable and secondly, searching. There is always a tradeoff between these two, but we wanted both of them to be as fast as possible.
We spent a lot of time optimizing the queue or order of the data that was sent over. For example, if something is manually added, chances are it might need to be searchable immediately. If they were adding a new supplier, they were probably looking to add that to an purchase order right away. If data was being brought in via syncing with a partner channel, it is less likely to be searched as quickly. So we created sophisticated ways of prioritizing the queue. We also helped to optimize the indexing on the Algolia end by adding insights unique to Stitch customer usage. We are constantly building and indexing. The second anything is changed in Stitch it gets added to the queue.