Как обеспечить доставку сообщения на сервер без дублей, если сервер долго не отвечает или ответ вообще не пришёл?

В распределённых системах сеть ненадёжна: ответ может потеряться, даже если сервер успешно обработал запрос. Клиент, не получив подтверждение, вынужден повторить отправку, что порождает риск дубля. Решение строится на двух идеях: гарантированная повторная доставка (at-least-once) и идемпотентная обработка на сервере.

Ключевые механизмы

• Уникальный idempotency key, генерируемый клиентом для каждого логического сообщения.
• Хранение ключей и результатов обработки на сервере (в БД или Redis) с TTL.
• Повторные попытки с экспоненциальной задержкой и jitter.
• Подтверждение (ack) только после успешной записи результата.

Пример на Node.js

async function handlePayment(req, res) {
  const key = req.headers['idempotency-key'];
  const cached = await redis.get(key);
  if (cached) return res.json(JSON.parse(cached)); // повтор

  const result = await processPayment(req.body);
  await redis.set(key, JSON.stringify(result), 'EX', 86400);
  res.json(result);
}

// Клиент с retry
async function sendWithRetry(payload, key, attempts = 5) {
  for (let i = 0; i < attempts; i++) {
    try {
      return await fetch('/pay', {
        method: 'POST',
        headers: { 'Idempotency-Key': key },
        body: JSON.stringify(payload)
      });
    } catch (e) {
      await sleep(2 ** i * 100 + Math.random() * 100);
    }
  }
  throw new Error('Delivery failed');
}

В очередях (Kafka, RabbitMQ) аналогично используют deduplication id и consumer offset commit после обработки. Важно, чтобы запись результата и отметка об обработке были атомарны, иначе возможен дубль при падении между операциями.

Итог: применяйте idempotency key вместе с retry и хранилищем обработанных ключей, когда нужна надёжная доставка без дублей в платежах, заказах и любых критичных операциях.