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.
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.
It depends on your stack. I built a PHP app that could handle 100+ req/s per server with only app config data cached and a reasonable level of MySQL table cache.
For an MVC framework like Rails, however, cache is going to be needed much earlier. I'd launch without it but once I got some traction it's one of the first things I'd work on. Since Rails has built in cache support it's pretty easy to setup some basic caching.
I'm with you on that one. I wouldn't submit a site to Show HN without at least memcached sitting in front of it. And to run a legitimate service sans cache? That's just asking for trouble.
I don't know about that when you can simply go horizontal (automatically, even) if the need arises.
Building with cache: guaranteed added upfront cost, complexity, and time to ship, without knowing if/where caching will serve you best.
Building without cache: Guaranteed upfront savings, faster time to ship, with automatic horizontal scaling as a backstop if the need ever arises, while you work to integrate the cache.
And, remember, databases cache too. Throwing extra RAM and tweaking the DB cache config can also be a viable backstop short-term.
You don't really need caching if your back end is fast enough. It's just that the current trend is to use slow architectures with caching, because it's usually cheaper and faster to get version 1 out the door.
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.