Зачем нужно кэширование и какие у него главные риски?

Зачем. Многие данные читают намного чаще, чем меняют. Ответ из памяти — микросекунды, из базы — миллисекунды, из внешнего сервиса — десятки. Кэш снижает задержку и разгружает источник: при доле попаданий 95% в базу идёт двадцатая часть запросов.

Где кэшируют: в браузере (Cache-Control), на CDN, в памяти экземпляра (быстро, но у каждого экземпляра своя копия), в общем кэше (Redis), в самой базе (буферный кэш).

Шаблоны:

• cache-aside (самый частый): приложение читает кэш; при промахе идёт в базу и кладёт результат с TTL; при изменении данных пишет в базу и удаляет ключ;
• read-through / write-through — кэш сам ходит в источник или пишет в него;
• write-back — запись сначала в кэш, в базу позже: быстро, но риск потери.

Риски:

• устаревание — между изменением в базе и обновлением кэша пользователи видят старое. TTL ограничивает окно, удаление при записи сокращает;
• гонки при одновременном чтении и записи оставляют в кэше старое значение надолго;
• давка — популярный ключ истёк, и сотни запросов разом идут в базу;
• зависимость — база перестаёт выдерживать нагрузку без кэша, и его падение превращается в аварию;
• память — без лимита и политики вытеснения кэш растёт.