# Кеш и фоновые задачи Версия источника: 4880e8b4372c96001c2e052be28b68a95d31252b Синхронизировано: 2026-11-09T11:15:07.649Z Источник: https://github.com/sergey-from-riders/vibecoding-base/tree/4880e8b4372c96001c2e052be28b68a95d31252b ## Оглавление - [Источник истины кеша](#caching-source-of-truth) - [TTL и инвалидация](#caching-freshness) - [Изоляция кеша](#caching-private-cache) - [Идемпотентность worker](#caching-idempotent-worker) - [Transactional outbox](#caching-outbox) - [Dead-letter queue](#caching-dead-letter) - [Redis: persistence и восстановление](#caching-redis-persistence) # Источник истины кеша ## Коротко Кеш ускоряет чтение и должен быть воспроизводим из основного источника. ## Плохо ```text Данные есть только в Redis, резервной копии нет. ``` ## Хорошо ```text Оригинал — БД или Git. Кеш можно пересобрать по версии источника. ``` ## Почему Очистка кеша не должна уничтожать единственный экземпляр данных. ## Когда применять Хранилище может быть основным, но тогда для него нужны соответствующие гарантии сохранности. ## Как проверить - Удалите тестовый кеш и восстановите его из источника. ## Человек Выбирает источник восстановления и допустимое поведение при недоступности кеша. ## Агент Реализует восстановление и обработку повторов, проверяет сбой зависимости и возвращение в рабочее состояние. Контроль результата: - Удалите тестовый кеш и восстановите его из источника. ## Источники - [Cache-Aside Pattern - Azure Architecture Center](https://learn.microsoft.com/en-us/azure/architecture/patterns/cache-aside) Уровень: Рекомендуется. Проверено: 2026-11-09. Изменено: 2026-11-09. [Исходный файл](https://github.com/sergey-from-riders/vibecoding-base/blob/4880e8b4372c96001c2e052be28b68a95d31252b/registry/standards/backend/worker/rules/source-of-truth.md) --- # TTL и инвалидация ## Коротко Укажите допустимую задержку, ключ версии и поведение при недоступном источнике. ## Плохо ```text Кеш бессрочный; никто не знает, когда он обновлён. ``` ## Хорошо ```text Версия источника + время загрузки. Проверка обновлений. Показ последнего исправного снимка. ``` ## Почему Быстрый ответ бесполезен, если он незаметно устарел. ## Когда применять Старые справочные данные могут быть допустимы. Для прав доступа, остатков и цены допустимость отдельная. ## Как проверить - Проверьте обновление и отказ источника. ## Человек Задаёт допустимый возраст данных для каждого сценария. ## Агент Реализует восстановление и обработку повторов, проверяет сбой зависимости и возвращение в рабочее состояние. Контроль результата: - Проверьте обновление и отказ источника. ## Источники - [RFC 9111: HTTP Caching](https://www.rfc-editor.org/rfc/rfc9111.html) Уровень: Рекомендуется. Проверено: 2026-11-09. Изменено: 2026-11-09. [Исходный файл](https://github.com/sergey-from-riders/vibecoding-base/blob/4880e8b4372c96001c2e052be28b68a95d31252b/registry/standards/backend/worker/rules/freshness.md) --- # Изоляция кеша ## Коротко Ключ кеша и HTTP-политика должны учитывать пользователя, организацию и права. ## Плохо ```text /profile закеширован одинаково для всех. ``` ## Хорошо ```text Персональный ответ: private или no-store. При серверном кеше учитывается контекст доступа. ``` ## Почему Общий кеш может показать данные одного человека другому. ## Когда применять Выбор private/no-store зависит от чувствительности; no-cache означает проверку свежести, а не запрет хранения. ## Как проверить - Последовательно запросите данные двух разных пользователей. ## Человек Определяет границы пользователей, организаций и прав доступа. ## Агент Реализует восстановление и обработку повторов, проверяет сбой зависимости и возвращение в рабочее состояние. Контроль результата: - Последовательно запросите данные двух разных пользователей. ## Источники - [RFC 9111: HTTP Caching](https://www.rfc-editor.org/rfc/rfc9111.html) Уровень: Обязательно. Проверено: 2026-11-09. Изменено: 2026-11-09. [Исходный файл](https://github.com/sergey-from-riders/vibecoding-base/blob/4880e8b4372c96001c2e052be28b68a95d31252b/registry/standards/backend/worker/rules/private-cache.md) --- # Идемпотентность worker ## Коротко Повтор сообщения не должен повторять необратимый эффект. ## Плохо ```text Одно сообщение пришло дважды → отправлены два заказа. ``` ## Хорошо ```text message_id проверяется транзакционно. Повтор возвращает уже сохранённый результат. ``` ## Почему Успешная обработка и подтверждение доставки могут разделиться сетевым сбоем. ## Когда применять Не обещайте exactly-once без доказанной модели всей цепочки, включая внешние эффекты. ## Как проверить - Завершите процесс после эффекта, но до подтверждения сообщения. ## Человек Определяет уникальность задания и допустимые последствия повторов. ## Агент Реализует восстановление и обработку повторов, проверяет сбой зависимости и возвращение в рабочее состояние. Контроль результата: - Завершите процесс после эффекта, но до подтверждения сообщения. ## Источники - [Amazon SQS at-least-once delivery - Amazon Simple Queue Service](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/standard-queues-at-least-once-delivery.html) Уровень: Обязательно. Проверено: 2026-11-09. Изменено: 2026-11-09. [Исходный файл](https://github.com/sergey-from-riders/vibecoding-base/blob/4880e8b4372c96001c2e052be28b68a95d31252b/registry/standards/backend/worker/rules/idempotent-worker.md) --- # Transactional outbox ## Коротко Свяжите запись бизнеса и событие, чтобы сбой не потерял отправку. ## Плохо ```text Заказ сохранён. Сбой перед публикацией события. ``` ## Хорошо ```text Транзакция: заказ + запись outbox. Worker доставляет событие и отмечает результат. ``` ## Почему Outbox закрывает разрыв между сохранением БД и последующей отправкой. ## Когда применять Доставка всё равно может повториться; получатель должен поддерживать дедупликацию. ## Как проверить - После аварии событие доставляется без второго бизнес-эффекта? ## Человек Определяет требуемую гарантию доставки и процедуру сверки. ## Агент Реализует восстановление и обработку повторов, проверяет сбой зависимости и возвращение в рабочее состояние. Контроль результата: - После аварии событие доставляется без второго бизнес-эффекта? ## Источники - [Implement the Transactional Outbox pattern with Dataverse - Power Platform](https://learn.microsoft.com/en-us/power-platform/architecture/reference-architectures/transactional-outbox-pattern) Уровень: Зависит от задачи. Проверено: 2026-11-09. Изменено: 2026-11-09. [Исходный файл](https://github.com/sergey-from-riders/vibecoding-base/blob/4880e8b4372c96001c2e052be28b68a95d31252b/registry/standards/backend/worker/rules/outbox.md) --- # Dead-letter queue ## Коротко После ограниченных попыток сохраняйте причину и возможность безопасного разбора. ## Плохо ```text Одно повреждённое сообщение бесконечно блокирует очередь. ``` ## Хорошо ```text Ограниченные повторы → очередь разбора. Причина, попытки, безопасный повтор после исправления. ``` ## Почему Остальные задания должны продолжать выполняться. ## Когда применять В записи ошибки не должно быть секретов; повтор выполняется с исходной идентичностью операции. ## Как проверить - Проверьте повреждённое сообщение, восстановление и повтор. ## Человек Определяет ответственного за неисправимые сообщения и порядок повторного запуска. ## Агент Реализует восстановление и обработку повторов, проверяет сбой зависимости и возвращение в рабочее состояние. Контроль результата: - Проверьте повреждённое сообщение, восстановление и повтор. ## Источники - [Using dead-letter queues in Amazon SQS - Amazon Simple Queue Service](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html) Уровень: Рекомендуется. Проверено: 2026-11-09. Изменено: 2026-11-09. [Исходный файл](https://github.com/sergey-from-riders/vibecoding-base/blob/4880e8b4372c96001c2e052be28b68a95d31252b/registry/standards/backend/worker/rules/dead-letter.md) --- # Redis: persistence и восстановление ## Коротко Настройте восстановление Redis в соответствии с ролью данных. Кеш и единственная копия задания требуют разных гарантий. ## Плохо ```text Redis = единственная копия данных Persistence = off Восстановление = не проверено ``` ## Хорошо ```text Источник = GitHub / основная БД Redis = проверенная текущая и предыдущая версии AOF = everysec Восстановление = из источника или исправной копии ``` ## Почему AOF everysec уменьшает окно потери, но не гарантирует нулевую потерю при аварии. Репликация тоже не заменяет резервную копию. ## Когда применять Redis OSS, AOF и RDB. Для восстанавливаемого кеша persistence выбирается по требованиям запуска. Для очередей отдельно оценивайте потерю последних записей, повторную обработку и noeviction; не смешивайте их с вытесняемым кешем без анализа. ## Человек Определяет допустимую потерю данных, срок восстановления и владельца источника. ## Агент Настраивает persistence и лимиты, проверяет перезапуск и восстановление без изменения исходного источника. ## Пример применения Справочник хранит в Redis два проверенных снимка Markdown. Новый снимок публикуется атомарно, повреждённый отклоняется. При недоступности Redis сайт использует последнюю исправную дисковую копию. ## Как проверить - После перезапуска данные восстанавливаются. - Недоступность Redis имеет проверенный резервный сценарий. - Ограничение памяти не удаляет единственную копию задания. ## Источники - [Redis persistence](https://redis.io/docs/latest/operate/oss_and_stack/management/persistence/) - [Key eviction](https://redis.io/docs/latest/develop/reference/eviction/) Уровень: Рекомендуется. Проверено: 2026-11-09. Изменено: 2026-11-09. [Исходный файл](https://github.com/sergey-from-riders/vibecoding-base/blob/4880e8b4372c96001c2e052be28b68a95d31252b/registry/standards/backend/worker/rules/redis-persistence.md)