When I implemented search-as-you-type on my blog, I decided to wait for the current search suggestion request to complete before doing a new one. Seemed like a reasonable balance between responsiveness and not overloading the server.

When I implemented one I simply filtered the results that came back from previous requests to see if they matched what the user had typed in the mean time. That way the UI might get relevant results with lower latency than would otherwise be possible with no risk that a non-matching result would show up to confuse the user.

The video showing the problem in the article seems to show an avalanche of queries towards the server, I'm surprised no one cared about it, but I guess it's frontend people thinking "It's the backend/ops that have to deal with the problem!".

I wait about 250 ms before firing the request, if the user (well, me) continues typing, then the timer gets cancelled and the app waits another 250ms.

The earlier search will be on a shorter input which will find more results; imagine waiting for everything that contains "e" before you can get the one result for "europa" that you wanted. Isn't that pattern going to happen most of the time - waiting for a large amount of useless generated and transferred and disposed-of, before the search you want will run?

Firing queries all the time is especially annoying if your users are in another continent, and you don't have proper state management to only show results for the latest query, as opposed to the latest response.

RTT from Europe to AWS us-* can easily get to multiple seconds during peak times.