Кэширование и Redis
Если база медленная для «горячих» данных, ответ кладут в память: читается за миллисекунды, а базу не дёргаем. Redis — самое популярное хранилище ключ-значение для этого.
Кэшируем ответ API
// Схема «кэш на стороне»: сначала Redis, потом база
async function getPost(id) {
const cached = await redis.get("post:" + id);
if (cached) return JSON.parse(cached);
const post = await db.query("SELECT * FROM posts WHERE id=$1", [id]);
await redis.set("post:" + id, JSON.stringify(post), { EX: 300 }); // TTL 5 минут
return post;
}
TTL решает проблемы
- TTL (expire) — срок жизни ключа: данные сами «протухают», не нужно чистить вручную;
- варьируйте время: посты — минуты, справочники — часы;
- при обновлении данных — «инвалидируйте» кэш: сбросьте ключ, чтобы следующий запрос попал в базу.
Очереди задач
// Фоновые задачи: письма, ресайз картинок, отчёты
await redis.rPush("jobs:email", JSON.stringify({ to: "a@x.com", text: "Привет" }));
// Воркер слушает и обрабатывает по одному
while (true) {
const job = await redis.blPop("jobs:email", 0);
await sendEmail(JSON.parse(job[1]));
}
ℹ️
Redis in-memory — данные не переживают перезапуск без персистентности. Для кэша — норм, для кассов или истории — нужна надёжная база (в Redis это решается отдельной настройкой дозаписи).
💡
На собеседовании заспросят: «как ускорить медленный API?». Ответ: кэш в памяти с TTL + инвалидация при записи. Это и есть рабочая схема в большинстве продуктов.