[ericflo]

I absolutely think it is.

Why add extra complexity into your system (and complexity which I've seen the smartest of engineers get wrong on the invalidation side just by overlooking one small detail) before you know your macro-level bottlenecks and product questions like "how many users will even use this feature"? Additionally caching can mask more serious systemic performance issues like missing database indices and accidental extra round trips to the database.

Better to focus on fundamentals and keep your code simple, then add caching only when it's needed.

[jmstout]

Good points, but I can't help but feel like these issues should be considered and addressed during the early development of a service.

You're right, you can get into some serious trouble putting the cart before the horse. But, what gets me in this particular instance, is that 42floors is a service that's been on the market for well over a year. Their core competency, hell, core business, is search, and they still haven't implemented any form of caching.

I can't shake the feeling that caching search results, especially in this scenario, should have been a huge priority.

It seems like too many developers hear the mantra of avoiding "premature optimization" and interpret it as "unnecessary optimization."

Then they end up over a year into their business without having addressed something that should already be an integral part of their architecture.