Что мы на нём делаем
В Redis лежит то, что сервису нужно мгновенно и что он смог бы восстановить, если бы потерял. Закэшированные результаты запросов, которые иначе били бы в базу на каждый запрос, состояние сессий, счётчики лимитов, короткоживущие блокировки и очереди задач, выносящие медленную работу из пути запроса.
Последнее обычно даёт продукту больше всего. Отправка письма, генерация документа или вызов стороннего API не должны происходить внутри HTTP-запроса, которого ждёт пользователь, — вынос этого в очередь и есть то, что сохраняет отзывчивость страницы, когда у смежного сервиса плохой день.
Где он нужен
Перед PostgreSQL, а не вместо неё. Схема, которую мы используем, намеренно скучная: реляционная база владеет истиной, Redis владеет тем, что не хочется пересчитывать, и у каждого ключа есть срок жизни — чтобы устаревший кэш был временной проблемой, а не постоянной.
Когда мы его рекомендуем
Когда конкретный запрос измеримо горячий, когда нужны фоновые задачи или когда состояние надо разделить между несколькими экземплярами сервиса.
Но не первым шагом. Кэш, добавленный до того, как вы знаете, что именно тормозит, покупает вам вторую систему в эксплуатацию и новый класс багов — данные, корректные в одном месте и неверные в другом. Сначала измерьте, потом кэшируйте то, на что показал профайлер.