• Оглавление
  • Зачем бизнесу кэш и где он ломает деньги
  • Слои кэша: от браузера и CDN до Redis
  • Стратегии кэширования: когда что применять
  • Инвалидация без боли: версии ключей, события, TTL и SWR
  • Что нельзя кэшировать: персональные данные, авторизация, цены
  • Кэш на периметре: Cache-Control, ETag, NGINX/CDN
  • Redis на практике: защита от штормов, версии ключей, пример на Go
  • Измеряем пользу: метрики и алерты
  • Экономика: быстрый калькулятор выгоды
  • Чек‑лист внедрения и анти‑паттерны

Зачем бизнесу кэш и где он ломает деньги

Кэш — это «быстрый снимок» данных, который позволяет отвечать клиенту за миллисекунды и разгружать дорогие ресурсы: базу, микросервисы, внешние платёжки. Правильно выстроенный кэш сокращает счёт за инфраструктуру, выдерживает трафиковые пики и уменьшает хвостовые задержки (p95/p99), что напрямую влияет на конверсию и выручку.

Но кэш, настроенный абы как, делает обратное: показывает клиенту старые цены, не учитывает отмены, портит отчёты и вызывает инциденты с откатами. Ключевая сложность — не «что кэшировать», а «как безопасно инвалидировать и обновлять».

Слои кэша: от браузера и CDN до Redis

Слои есть почти всегда — даже если вы о них не думаете:

• Браузер: кэширует ответы по Cache-Control, ETag, Last-Modified.
• CDN/Edge: кэш на периметре (Cloudflare, Fastly и др.), снимает до 80–95% нагрузки со стойки.
• Прокси/шлюз: NGINX/Envoy могут кэшировать GET и отдавать статику, автовставлять заголовки.
• Приложение: память процесса и локальный кэш (LRU) для «горячих» данных.
• Внешний кэш: Redis/KeyDB/MemoryDB — основной источник правды для частых чтений.
• База данных: тут лучше избегать «встроенных» кэшей, опираться на явный Redis и контролируемую инвалидацию.

Важно понимать, что любой слой может случайно кэшировать приватные данные, если вы не выставляете правильные заголовки. Слои должны работать согласованно.

Стратегии кэширования: когда что применять

Cache-aside (ленивая загрузка)

• Чтение: попытались взять из кэша → если промах, достали из БД → положили в кэш.
• Запись: записали в БД → удалили или обновили кэш.
• Плюсы: простота, контроль TTL. Минусы: риск штормов при массовых промахах.

Read-through/Write-through

• Приложение обращается к кэшу как к «обёртке» над хранилищем; кэш сам ходит в БД и обновляет.
• Плюсы: единая точка логики. Минусы: сложность и зависимость от провайдера кэша.

Write-back (write-behind)

• Пишем только в кэш, фоновой задачей сбрасываем в БД.
• Быстро, но риск потери данных при сбое. Применять аккуратно только там, где допустима задержка консистентности и потеря не критична (не про деньги и не про заказы).

Инвалидация без боли: версии ключей, события, TTL и SWR

Версионирование ключей (namespace)

Не удаляйте тысячу ключей — измените «версию пространства имён» и начните писать под новым префиксом. Старое само умрёт по TTL.

• Префикс: tenant:{tenantId}:product
  :id:{id}
• Версию храним в отдельном ключе и увеличиваем при крупных изменениях.

Событийная инвалидация

При изменении данных (создание/апдейт товара) публикуйте событие. Подписчики (приложение, воркер) точечно очищают или обновляют кэш. Это снижает TTL и даёт ближе к «read-your-writes» для критичных сценариев.

TTL: жёсткий и мягкий, stale-while-revalidate

• Жёсткий TTL (hard TTL): время жизни ключа в Redis. После него ключ исчезает.
• Мягкий TTL (soft TTL): отметка в значении, после которой можно отдать «устаревшее, но ещё допустимое» и фоном обновить.
• stale-while-revalidate: отдаём старые данные мгновенно, запускаем обновление; пользователь не видит задержку.
• stale-if-error: если источник (БД/сервис) упал, можно отдавать старое N минут, чтобы не ронять фронт.

Защита от штормов кэша (cache stampede)

• Коалесcинг запросов: одновременно один «ведущий» строит значение, остальные ждут или получают старое.
• Локальные мьютексы и singleflight в коде, плюс короткий джиттер в TTL, чтобы не истекали все ключи одновременно.

Что нельзя кэшировать: персональные данные, авторизация, цены

• Приватные ответы: если есть заголовок Authorization или персональные куки, по умолчанию не кэшируем на периметре. Для CDN — используйте правила обхода кэша.
• Персонализированные цены/скидки/валюта: включайте в ключ кэша измерения (страна, валюта, роль, тариф, tenant). Иначе утечка бизнеса.
• PII (персональные данные): если кэшируете, то с шифрованием и короткими TTL. В CDN — лучше вообще не кэшировать.

Кэш на периметре: Cache-Control, ETag, NGINX/CDN

Начните с корректных заголовков. Пример для публичных GET-эндпоинтов каталога:

curl -i https://api.example.com/v1/catalog/popular
# Должно вернуться что-то вроде:
# Cache-Control: public, max-age=60, stale-while-revalidate=30, stale-if-error=300
# ETag: "a1b2c3d4"
# Vary: Accept-Encoding

Конфиг NGINX для кэша публичных GET без авторизации:

proxy_cache_path /var/cache/nginx keys_zone=api_cache:100m max_size=1g inactive=10m use_temp_path=off;

map $http_authorization $skip_cache {
    default 1;   # если есть Authorization — не кэшируем
    ""      0;   # без Authorization — можно кэшировать
}

server {
    listen 80;
    server_name api.example.com;

    location /v1/catalog/ {
        proxy_pass http://backend;

        # Ключ кэша: метод+хост+URI, добавьте важные query-параметры через $arg_
        proxy_cache_key "$scheme$request_method$host$request_uri";

        proxy_cache            api_cache;
        proxy_cache_bypass     $skip_cache;
        proxy_no_cache         $skip_cache;
        proxy_cache_valid 200  60s;    # базовый TTL
        proxy_cache_use_stale  error timeout updating http_500 http_502 http_503 http_504;

        add_header Cache-Control 'public, max-age=60, stale-while-revalidate=30, stale-if-error=300' always;
        add_header Vary 'Accept-Encoding' always;
    }
}

Если у вас CDN, переносим эти правила туда, а на NGINX оставляем как fallback.

Redis на практике: защита от штормов, версии ключей, пример на Go

Ниже — минимальный, но рабочий пример на Go: cache-aside + мягкий/жёсткий TTL, коалесcинг запросов и версионирование ключей по tenant.

package main

import (
	"context"
	"encoding/json"
	"errors"
	"fmt"
	"log"
	"os"
	"strconv"
	"time"

	"github.com/redis/go-redis/v9"
	"golang.org/x/sync/singleflight"
)

// Доменные данные
 type Product struct {
	ID        string    `json:"id"`
	Name      string    `json:"name"`
	Price     int64     `json:"price"`
	UpdatedAt time.Time `json:"updated_at"`
}

// Обёртка значения в кэше с мягким/жёстким TTL и версией
 type cachedItem struct {
	Data    Product `json:"data"`
	SoftTTL int64   `json:"soft_ttl"` // unix seconds
	HardTTL int64   `json:"hard_ttl"` // unix seconds
	Version int64   `json:"version"`
}

var (
	ctx     = context.Background()
	rdb     *redis.Client
	sfGroup singleflight.Group
)

func main() {
	redisAddr := getenv("REDIS_ADDR", "127.0.0.1:6379")
	rdb = redis.NewClient(&redis.Options{Addr: redisAddr})
	if err := rdb.Ping(ctx).Err(); err != nil {
		log.Fatalf("redis ping failed: %v", err)
	}
	defer rdb.Close()

	tenant := "t1"
	id := "p42"

	// Пример: многократные запросы, демонстрация кэша и SWR
	for i := 0; i < 5; i++ {
		p, stale, err := GetProduct(ctx, tenant, id)
		if err != nil {
			log.Printf("get error: %v", err)
			continue
		}
		log.Printf("got product: %+v (stale=%v)", p, stale)
		time.Sleep(2 * time.Second)
	}

	// Пример инвалидации: bump версии tenant (массовая инвалидация пространства)
	if err := BumpTenantVersion(ctx, tenant); err != nil {
		log.Printf("bump version error: %v", err)
	}

	p, stale, err := GetProduct(ctx, tenant, id)
	log.Printf("after bump: %+v (stale=%v) err=%v", p, stale, err)
}

func getenv(k, def string) string {
	if v := os.Getenv(k); v != "" {
		return v
	}
	return def
}

// --- БД-симуляция ---
func fetchProductFromDB(id string) (Product, error) {
	// Здесь обращение к реальной БД. Мы симулируем задержку.
	time.Sleep(50 * time.Millisecond)
	if id == "" {
		return Product{}, errors.New("empty id")
	}
	return Product{
		ID:        id,
		Name:      "Demo Product",
		Price:     1990,
		UpdatedAt: time.Now(),
	}, nil
}

// --- Версионирование tenant ---
func tenantVersionKey(tenant string) string {
	return fmt.Sprintf("tenant:%s:version", tenant)
}

func getTenantVersion(ctx context.Context, tenant string) (int64, error) {
	vk := tenantVersionKey(tenant)
	v, err := rdb.Get(ctx, vk).Result()
	if err == redis.Nil {
		// Инициализируем версию = 1
		if err := rdb.Set(ctx, vk, 1, 0).Err(); err != nil {
			return 0, err
		}
		return 1, nil
	}
	if err != nil {
		return 0, err
	}
	iv, _ := strconv.ParseInt(v, 10, 64)
	if iv == 0 {
		iv = 1
	}
	return iv, nil
}

func BumpTenantVersion(ctx context.Context, tenant string) error {
	vk := tenantVersionKey(tenant)
	return rdb.Incr(ctx, vk).Err()
}

// --- Кэш ---
func productCacheKey(tenant string, version int64, id string) string {
	return fmt.Sprintf("tenant:%s:product:v%d:%s", tenant, version, id)
}

// GetProduct: cache-aside + soft/hard TTL + singleflight
func GetProduct(ctx context.Context, tenant, id string) (p Product, stale bool, err error) {
	ver, err := getTenantVersion(ctx, tenant)
	if err != nil {
		return p, false, err
	}
	key := productCacheKey(tenant, ver, id)

	// Попытка чтения из кэша
	raw, err := rdb.Get(ctx, key).Bytes()
	if err == nil {
		var ci cachedItem
		if json.Unmarshal(raw, &ci) == nil {
			now := time.Now().Unix()
			// Проверим soft/hard TTL
			if now <= ci.HardTTL {
				stale = now > ci.SoftTTL
				if stale {
					// Фоновое обновление (коалесcинг), не блокируем выдачу
					go func() { _, _ = sfGroup.Do(key+":refresh", func() (interface{}, error) {
						return refreshAndSet(ctx, tenant, id)
					}) }()
				}
				return ci.Data, stale, nil
			}
		}
	}
	if err != nil && err != redis.Nil {
		log.Printf("redis get error: %v", err)
	}

	// Промах или hard TTL истёк — коалесcинг, чтобы не штормить БД
	res, err, _ := sfGroup.Do(key+":miss", func() (interface{}, error) {
		return refreshAndSet(ctx, tenant, id)
	})
	if err != nil {
		return p, false, err
	}
	ci := res.(cachedItem)
	return ci.Data, false, nil
}

func refreshAndSet(ctx context.Context, tenant, id string) (cachedItem, error) {
	ver, err := getTenantVersion(ctx, tenant)
	if err != nil {
		return cachedItem{}, err
	}
	p, err := fetchProductFromDB(id)
	if err != nil {
		return cachedItem{}, err
	}
	softTTL := time.Now().Add(30 * time.Second).Unix() // отдаём stale после 30с
	hardTTL := time.Now().Add(5 * time.Minute).Unix()  // ключ живёт до 5 минут
	ci := cachedItem{Data: p, SoftTTL: softTTL, HardTTL: hardTTL, Version: ver}
	b, _ := json.Marshal(ci)
	key := productCacheKey(tenant, ver, id)
	// EX = hard TTL, Redis сам удалит ключ после.
	err = rdb.Set(ctx, key, b, 5*time.Minute).Err()
	return ci, err
}

Что здесь важно для продакшена:

• singleflight предотвращает лавину обращений в БД при промахах.
• Мягкий TTL + фоновое обновление поддерживают низкую задержку.
• Версии по tenant дают быструю массовую инвалидацию без перебора ключей.
• Добавляйте джиттер к TTL, чтобы ключи не протухали одновременно.
• На запись в БД вызывайте либо точечное удаление ключа, либо bump версии при массовых изменениях.

Измеряем пользу: метрики и алерты

• Cache hit ratio (по слоям: CDN, NGINX, Redis) — целевой ориентир: 70–95% для публичных GET.
• Tail latency p95/p99 до и после внедрения.
• Нагрузка на исходники (RPS/CPU/IO) до/после.
• Ошибки 5xx/таймауты на бэкенде при истечении TTL — индикатор штормов.
• Размер кэша, скорость эвикций, пропорция ключей «вечнозелёных» (это плохо).

Алерты:

• Резкое падение hit ratio более чем на X% за Y минут.
• Рост p99 > целевого SLO.
• Эвикции Redis > порог (памяти не хватает).

Экономика: быстрый калькулятор выгоды

Предположим, у вас 10 000 RPS на публичные GET, 60% из них кэшируемы. Стоимость обработки 1 запроса на бэкенде — 0,02 ₽ (CPU, БД, сеть). CDN+NGINX+Redis дают 80% hit на этой доле:

• Снимаем 0,6 × 10 000 × 0,8 = 4 800 RPS с бэкенда.
• Экономим 4 800 × 0,02 ₽ = 96 ₽ в секунду, 345 600 ₽ в час пиков.
• Доп. бонус — ниже задержки → выше конверсия.

Даже если цифры скромнее, инвестиция окупается очень быстро.

Чек‑лист внедрения и анти‑паттерны

Чек‑лист:

• Определите кэширующиеся эндпоинты (без авторизации, с предсказуемым ответом).
• Включите правильные заголовки Cache-Control/ETag и Vary.
• Настройте CDN/NGINX, замерьте hit ratio и p95.
• Добавьте Redis cache-aside для «горячих» данных.
• Реализуйте soft/hard TTL и singleflight/коалесcинг.
• Выберите стратегию инвалидации: события + версионирование ключей.
• Введите метрики/алерты и дашборды.
• Пропишите политику для приватных данных (не кэшировать на периметре).

Анти‑паттерны:

• «Поставим TTL на сутки» — ломает консистентность, приводит к инцидентам.
• Кэширование ответов с Authorization на CDN — утечка данных.
• Ключи без измерений (валюта, регион, роль) — неправильные ответы клиентам.
• Массовое DEL по миллионам ключей — удар по Redis. Лучше версионирование.
• Кэш без метрик и алертов — «чёрный ящик», сломается — не заметите.

Итоги

Кэш — это про бизнес-результат: меньше затрат, быстрее ответы, выше конверсия. Чтобы он не ломал заказы и отчёты, используйте простые и надёжные практики: правильные заголовки на периметре, cache-aside в приложении, мягкие/жёсткие TTL, коалесcинг и версионирование ключей. С метриками и чек‑листом вы получите ускорение без сюрпризов и с контролируемой консистентностью.