[HN Search admin speaking] We disabled the rate-limit for now. A load-balancer experimentation that didn't behave as expected (the LB's IP getting rate-limited).
Let’s say it was a mix of HN alerting (hnwatcher), good timing (Friday evening) and luck :) very happy to have seen this in time. Have a nice WE as well!
We were experimenting some rate limiting settings and the load balancer IP in front of the hn cluster wasn't excluded, both features haven't been mixed before (doesn't make much sense to rate limit a search cluster behind a load balancer).
Sure thing, we’re experimenting with some Load-Balancing heuristics and instrumentations, and it looks it got rate-limited by the engine who got surprised all traffic was coming from a single IP /o\
(Sylvain from Algolia speaking) Thanks for sharing, our pricing & its transparency is actually something we are working on right now to address this perception. We've been iterating a few times already over the past 7 years, but this is one more signal for us to act!
The reality is that based on the number of objects you want to search in, your search traffic, your searches' complexity and your index/relevance configuration; the underlying resources can vary soo much, it's hard to have a single pricing that fits all use-case.
This has always been a major deterrent to me wanting to use Algolia. It's basically impossible for me to know whether for x number of users doing y number of searches Algolia will cost $100/month or $1,000/month or $10,000/month. It amazes me that anyone commits to investing development effort in using Algolia (with lock-in, to boot) when you have no idea whether it's something you can even afford.
It's very easy to start with so from time investment it will always be a good choice. I looked at several options for doc search and since I didn't want to invest more than 2 hours I just setup a Drone CI job to scrape and update index every night and added that search bar :) quite happy so far although self hosted solution would be preferable
As with all usage-based product, when you start it is cheap (much cheaper than building on your own), then as you grow your resources will hopefully scale with the number of users.
If your resources don't scale with usage, yes, you have a problem, but I'd say not limited to algolia
What's different is that with other products, i.e., those that have clear and understandable pricing, you can forecast the future costs and make a decision about whether it's an affordable solution for the particular product/business you're building. With Algolia, you can't.
Why would I want to build a product/business that uses Algolia technology as a key component when I have no idea whether the eventual cost of Algolia will be acceptable? I wouldn't, which is why despite Algolia's extremely attractive features, I have time and time again been unable to recommend its use.
Btw, part of this pricing rework is also about removing some of the feature gating. It's an approach we've taken to really get the feature right, first releasing it to a smaller set of (larger) customers before opening it up to the whole mass.
Yes, when sorting by date it's currently configured to disable typo-tolerance. This is to avoid having an old (but approximative, with typos) result BEFORE the correct ones.
Ah the old multi-factor sort problem. Fun figuring out how to handle those scenarios in Elastic Search too (or more generally any sorting UI). For example you want traditional Chinese food near you. What is better - traditional Chinese food 14km away or fusion 2km away? Well that depends on the wetware, but you have to guess what the user would want.
You should give it a try; Algolia has a FREE tier you can play with. You can also watch this 45sec video to get a grasp of it: https://youtu.be/IYY5RM1sBC0
