Какие методы нельзя кэшировать?

Методы, которые нельзя или не рекомендуется кэшировать

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

1. Методы с побочными эффектами (Non-idempotent operations)

Это самый важный класс методов, которые ни в коем случае нельзя кэшировать. Кэширование таких методов приведёт к некорректному поведению системы и потере данных.

• Методы, изменяющие состояние системы (мутаторы):

    *   `POST`, `PUT`, `DELETE` запросы в REST API.
    *   Методы, выполняющие запись в базу данных, файловую систему или отправку сообщений.

```java
// НЕЛЬЗЯ КЭШИРОВАТЬ!
public void saveUser(User user) {
    userRepository.save(user); // Побочный эффект - запись в БД
}

public Order createOrder(Cart cart) {
    // Побочный эффект - создание сущности и списание товаров
    return orderService.process(cart);
}
```

• Методы, зависящие от уникальных или изменяющихся идентификаторов:

    *   Генерация уникальных ключей (UUID, временные метки).
    *   Методы, возвращающие случайные значения.

```python
# НЕЛЬЗЯ КЭШИРОВАТЬ!
def generate_session_token():
    import secrets
    return secrets.token_hex(32)  # Всегда должен быть новым

def get_current_time():
    return datetime.now()  # Значение постоянно меняется
```

2. Методы с динамическим или контекстно-зависимым выводом

Результат этих методов зависит от контекста, который не является частью "ключа" кэша, или меняется слишком часто, делая кэш бесполезным.

• Методы, возвращающие актуальные (live) данные:

    *   Котировки акций, показатели датчиков IoT, позиция курьера на карте.

```javascript
// Кэшировать бессмысленно или очень опасно (короткий TTL)
async function getBitcoinPrice() {
    const response = await fetch('https://api.coingecko.com/live-price');
    return response.json(); // Данные меняются каждую секунду
}
```

• Методы, зависящие от состояния сессии или пользователя:

    *   Персонализированные данные (`getUserNotifications()`, `getCurrentCart()`), если только ключ кэша не включает `userId` и состояние не обновляется слишком часто.
    *   Методы с зависимостью от прав доступа (role-based data).

3. Методы, где точность и актуальность критичны

Даже если технически метод детерминирован, бизнес-логика может запрещать кэширование.

• Операции, связанные с безопасностью и аудитом:

    *   Проверка одноразовых паролей (OTP), текущих ACL (Access Control Lists).
    *   Методы, возвращающие журнал (лог) событий за последний период.

• Финансовые операции и расчёты в реальном времени:

    *   Проверка остатка на счёте перед транзакцией, расчёт комиссии на момент оплаты.

4. Методы с очень низкой стоимостью выполнения

Кэширование добавляет накладные расходы: чтение из кэша, сериализация, управление инвалидацией. Если метод выполняется быстро и редко, кэширование не окупится.

public class SimpleCalculator {
    // Кэшировать не имеет смысла - операция тривиальна
    public int add(int a, int b) {
        return a + b;
    }

    // Даже если это геттер сложного объекта, но он уже оптимизирован
    public String getConstantConfigValue() {
        return AppConfig.TITLE; // Чтение из статического поля
    }
}

5. Методы с недетерминированным выводом

Если метод при одинаковых входных параметрах может возвращать разные результаты, его кэширование приведёт к ошибкам.

• Методы, использующие недетерминированные внешние источники: (как уже упоминалось).
• Методы с внутренним недетерминированным поведением:

  import random
  def shuffle_items(items_list):
      random.shuffle(items_list) # Использует внутренний RNG
      return items_list
  

Критерии для принятия решения о кэшировании

Прежде чем кэшировать, задайте вопросы:

1. Идемпотентен ли метод? Вызов с одними данными всегда даёт один результат без побочных эффектов?
2. Детерминирован ли он? Одинаковые входные параметры → одинаковый вывод?
3. Насколько дорого выполнение? Доступ к БД, сложный расчёт, внешний API-вызов?
4. Как часто меняются данные? Возможно ли установить адекватный TTL (Time To Live)?
5. Насколько критична актуальность? Допустима ли устаревшая (stale) data?
6. Как часто метод вызывается? Будет ли кэш "прогреваться" и использоваться?

Стратегии для "пограничных" случаев

Иногда методы можно сделать кэшируемыми:

• Разделение команд и запросов (CQRS): Метод getUser(id) (запрос) можно кэшировать, а updateUser(id, data) (команда) — нет. При обновлении инвалидируйте кэш для этого id.
• Кэширование с агрессивной инвалидацией: Для динамических данных используйте очень короткий TTL (например, 1-5 секунд).
• Учёт всех зависимостей в ключе кэша: Включите в ключ userId, role, locale, чтобы разделять данные для разных контекстов.

Вывод: Категорически нельзя кэшировать неидемпотентные методы с побочными эффектами (изменяющие состояние) и строго недетерминированные методы. Для остальных — необходим взвешенный анализ по критериям стоимости, частоты и допустимой актуальности данных. Слепая оптимизация через кэширование может привести к трудноотлавливаемым ошибкам и порче данных.