---
title: Multi-Layer Caching Strategy
impact: HIGH
impactDescription: Reduces database load and delivers sub-100ms responses
tags: performance, caching, redis, nextjs, revalidation
---
## Паспорт документа

- Статус документа: living standard
- Актуально на: 28 марта 2026 года
- Владелец: backend/platform-команда
- Пересмотр: при изменении инженерной практики, CI/CD, архитектурных правил или локального workflow
- Область применения: внутренние rule/reference-card документы для инженерной команды
- Связанные документы:
  - [Индекс Agents](../README.md)
  - [Команды разработки](../commands.md)
  - [Инженерные принципы](../../governance/engineering-principles.md)

## Multi-Layer Caching Strategy

**Impact: HIGH**

Use caching at multiple levels for optimal performance:

### Layer 1: Next.js Fetch Cache (Frontend)

```typescript
// Automatic caching with revalidation
const items = await fetch(`${API_URL}/catalog`, {
  next: { revalidate: 300 }, // Revalidate every 5 minutes
});

// For user-specific data — no cache
const leads = await fetch(`${API_URL}/seller/leads`, {
  cache: 'no-store',
  headers: { Authorization: `Bearer ${token}` },
});
```

### Layer 2: Redis Cache (Backend)

```typescript
// Cache popular catalog queries
async getPublishedItems(filters: CatalogFilters) {
  return this.cache.getOrSet(
    `catalog:${hash(filters)}`,
    300,
    () => this.catalogRepo.findPublished(filters),
  );
}
```

### Layer 3: PostgreSQL Query Cache

- Connection pooling via PgBouncer
- Prepared statements for repeated queries
- Read replicas for read-heavy workloads

### Rules
- Cache public data aggressively (catalog, reference data)
- Never cache user-specific or auth-dependent data in shared caches
- Always set TTL — no infinite caches
- Invalidate on writes — don't rely on TTL for critical freshness
- Use `cache: 'no-store'` for authenticated API calls on the frontend