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