It is worth to say you need to pay attention to the COULD keyword, and yes it is the bait title – there are many better candidates on what you could do LAST with your application. The point is caching is way to often overrated. I’d also suggest to:

– It is good to use cache to improve capacity of the system, but not relay on it for response time. In too many cases uncached path is bad and visitors are suffering. There are cases like with Opcode Cache when you can get effectively 100% hit ratio so it is less of the problem.

– Think about warmup. Whatever cache is it can be lost and you may need to start operating with empty cache. The behavior of application in such case often comes as surprise. Best test it.

– Disable caching (memcache, mysql query cache etc) for development so you can see performance of uncached execution path. You need to test things with caching too to ensure it works well fo course.

It’s good to see that it has stampeding protection, but it will still stuffer the reduced visibility / not working for all visitors problem If I inherit an application and I’m stuck in the same situation again, this will be one of the tools I try.

.. but if I am in charge of designing architecture for a new application, caches will be still be disabled

I agree 100%. It’s all too tempting to do the easier option — using memcached is far less work than doing the methodical (and boring) work of optimizing each and every single query that is actually used.

mk-query-digest is an awesome tool — I use it to do query reviews for clients, and it’s tedious, but very beneficial. But like anything, you have to do the work, and in the long run, shortcuts will just add to the problems.