Откуда берётся идентификатор, по которому сервер понимает, что повторно отправленное сообщение уже было сохранено?

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

Кто генерирует идентификатор

• Клиент (producer) — самый частый вариант. Клиент создаёт уникальный ключ (UUID, хэш бизнес-данных) и кладёт его в заголовок или тело сообщения. При ретрае используется тот же ключ.
• Брокер — например, Kafka с включённым идемпотентным продюсером присваивает producer id и sequence number, а брокер дедуплицирует по паре (producerId, sequence).
• Сервер-получатель — генерирует id при первом приёме и возвращает клиенту, чтобы тот использовал его при повторе.

Как работает дедупликация

Сервер хранит множество уже обработанных ключей — в памяти, Redis или таблице БД с уникальным индексом. При приходе сообщения он проверяет ключ: если он есть, сообщение игнорируется и возвращается прежний результат; если нет — обрабатывается и ключ сохраняется.

// Пример на Node.js с Redis
async function handleMessage(msg) {
  const key = msg.idempotencyKey;
  const exists = await redis.set(key, '1', 'NX', 'EX', 86400);
  if (!exists) {
    return { status: 'duplicate' }; // уже обрабатывали
  }
  await saveToDb(msg);
  return { status: 'ok' };
}

Важные детали

• Ключ должен быть уникален для логической операции, а не для попытки отправки.
• Хранилище ключей нужно ограничивать по TTL, иначе оно растёт бесконечно.
• Проверка и запись ключа должны быть атомарными, иначе гонка приведёт к дублю.

Итог: идентификатор — это контракт между клиентом и сервером, позволяющий безопасно повторять отправку. Применяйте такой подход в платежах, очередях и любых API, где важна идемпотентность.