Проектирование эффективной системы кэширования для высоконагруженной системы

Но все-таки прежде чем проектировать что-то свое, не лучше ли определиться с требованиями и поискать готовое решение?

Если говорить про веб - есть кеширующий http прокси который будет хранить страницы целиком и отдать готовые страницы если на сервере нет изменений. И не зачем отдельный огород городить.

Также стоит заметить что запрос к базе данных не должно быть какой-то сложностью для веб приложения и незачем отдельно кэшировать ответы СУБД. Например есть предусмотренный субд кэш где, как правило, хранятся результаты выполнения запросов.

Ну и много где ещё есть свой кеш который можно просто использовать.

Например есть предусмотренный субд кэш где, как правило, хранятся результаты выполнения запросов.

Сомнительно, что такое будет работать. Базад данных обычно подкидывает часто используемые данные в память, так как основная задержка идет на чтение с диска. Но запоминать ответ на конкретный запрос стремно, так как с момента выполнения последнего запроса данные могли поменяться, а в силу декларативности SQL (естественно написанное касается реляционных баз) обратная связь от изменений данных к кешу затруднена

Бэкенд обычно (этого нет в статье, но я думаю, автор в курсе) контролирует акутальность кеша по ключам и сбрасывает его, если по ключу прошло изменение

Если говорить про веб - есть кеширующий http прокси который будет хранить страницы целиком и отдать готовые страницы если на сервере нет изменений.

Кроме статики, есть и динамика а статья больше о ней. Задачу быстро отдавать статику человечество уже решило практически до идеального состояния

Также стоит заметить что запрос к базе данных не должно быть какой-то сложностью для веб приложения и незачем отдельно кэшировать ответы СУБД. 

Веб-приложению действительно несложно закинуть запрос в базу. Проблема воникает именно за базе (или в общем случае "источнике данных). Вот его кеш и разгружает