Что будет, если сервис упадёт в момент, когда вы собираете батч для записи? Как обрабатывали отставание консьюмера?

Если сервис падает в момент сбора батча для записи, возможна потеря данных, если не реализована надёжная обработка ошибок и сохранение состояния. Чтобы минимизировать риски, обычно применяют следующие подходы:

• Транзакционная запись: батч собирается и записывается атомарно, либо полностью, либо не записывается вовсе.
• Журналирование (write-ahead log): перед записью батча данные логируются, чтобы после рестарта можно было восстановить незавершённые операции.
• Идempotent операции: чтобы при повторной записи не возникало дублирования.

Для обработки отставания консьюмера (consumer lag) в системах с очередями или стримами (например, Kafka) применяют:

• Мониторинг отставания и алерты.
• Автоматическое масштабирование консьюмеров.
• Оптимизацию обработки сообщений (параллелизм, батчи).
• Временное сохранение состояния, чтобы после падения продолжить с последней обработанной позиции.

Пример в Go для записи батча с обработкой ошибок:

func writeBatch(batch []Data) error {
    // Попытка записи батча
    err := db.Write(batch)
    if err != nil {
        // Логируем ошибку, возможно, сохраняем батч для повторной попытки
        log.Printf("Failed to write batch: %v", err)
        return err
    }
    return nil
}

В реальной системе добавляют retry, транзакции и сохранение состояния для устойчивости.