Основная модель

Предрасчёт — это конвейер: входные изменения → вычисление → запись результата → быстрый онлайн-рид.

1) Определить, что именно предрасчитываем

Сначала фиксируем:

• какие вычисления “тяжёлые” (CPU/IO)

• какие данные нужны на запросе

• допустимая свежесть (например, “не старше 5 минут”)

Определение: Freshness — насколько “свежими” должны быть данные на момент ответа (задержка между изменением и обновлением витрины).

2) Выбор триггера предрасчёта

Есть два базовых способа:

1. Batch по расписанию

• проще, предсказуемо

• может быть “ступеньками” по свежести

2. Event-driven по изменениям (Kafka)

• обновления ближе к реальному времени

• сложнее, но лучше для динамичных данных

3) Архитектура event-driven пайплайна

Типичная схема:

1. Продьюсер пишет событие изменения (например, “пользователь сделал действие”)

2. Консьюмер читает события и обновляет агрегаты/витрину

3. Онлайн-сервис читает готовый результат

Ключевые аспекты:

• порядок обработки (per key ordering), если важно

• дедупликация/идемпотентность

• ретраи и DLQ (dead letter queue) для “ядовитых” сообщений

4) Идемпотентность и повторяемость

Определение: Idempotent consumer — обработчик, который можно безопасно повторить, не ломая результат.

Способы:

• хранить обработанные event-id (дорого, но надёжно)

• обновлять агрегаты “по факту состояния”, а не “прибавь всегда” (зависит от домена)

• делать записи в витрину с version/updated_at и принимать только “самое новое”

5) Витрина результатов

Витрина — это место, откуда читает онлайн:

• Redis для быстрых ключевых чтений

• отдельная таблица/коллекция под чтение

• иногда материализованные представления (если поддерживаются)

Важно:

• формат должен быть “готов к ответу” или требовать минимальной склейки

6) Контроль лагов и деградация

Нужно мониторить:

• consumer lag (насколько отстали обработчики)

• скорость обработки и ошибки

Если лаг растёт:

• включать деградацию (stale-данные, fallback)

• масштабировать консьюмеров (если порядок позволяет)

Вывод

Предрасчёт позволяет держать быстрый SLA: тяжёлое считаем асинхронно (batch или Kafka-события), складываем результат в витрину для чтения, а онлайн-запрос только читает готовые данные. Критично заранее определить допустимую freshness и обеспечить идемпотентность обработчиков.