Интеграция систем: как связать CRM, склад и сайт без хаоса

Типичная картина в выросшей компании: сайт, CRM, складская программа, бухгалтерия и сервис рассылок. Каждая система появилась отдельно, обмен данными настраивался по случаю. В результате заказ с сайта доходит до склада, но не доходит до бухгалтерии, а причину никто не может найти, потому что журнала обмена нет.

Три способа связать системы

Прямой вызов

Система А обращается к API системы Б и ждёт ответа. Просто в реализации и уместно, когда ответ нужен немедленно: проверка остатка на складе перед оформлением заказа. Недостаток очевиден — если Б недоступна, операция в А не проходит.

Вебхук

Система Б сама сообщает о событии по указанному адресу. Хорошо подходит для уведомлений: платёж прошёл, статус заказа изменился. Здесь важно помнить, что вебхук может прийти дважды, поэтому обработчик обязан быть идемпотентным.

export async function POST(request: Request) {
  const event = await request.json()

  // Проверка подписи: без неё обработчик принимает
  // запросы от кого угодно
  if (!verifySignature(request, event)) {
    return new Response("Invalid signature", { status: 401 })
  }

  // Повторная доставка — нормальное поведение, а не сбой.
  // Уникальный индекс по event_id делает повтор безопасным.
  const inserted = await db.webhookEvents.insertIfAbsent({
    id: event.id,
    type: event.type,
    payload: event,
  })

  if (!inserted) {
    // Уже обработали ранее: отвечаем успехом, чтобы отправитель
    // прекратил повторы
    return new Response("Already processed", { status: 200 })
  }

  await handleEvent(event)
  return new Response("OK", { status: 200 })
}

Очередь сообщений

Система А кладёт сообщение в очередь, система Б забирает его, когда готова. Обмен перестаёт зависеть от одновременной доступности систем: если склад на техобслуживании, заказы просто ждут в очереди и обработаются позже.

Что делает интеграцию надёжной

1. 01Идемпотентность. Повторная обработка того же события не должна создавать дубль. Проще всего добиться уникальным индексом по идентификатору события.
2. 02Повторные попытки с растущей паузой. Сетевые сбои кратковременны, разумная стратегия повторов закрывает большинство из них без вмешательства.
3. 03Журнал обмена. Каждое отправленное и принятое сообщение сохраняется с результатом. Без журнала разбор инцидента невозможен.
4. 04Очередь неудачных сообщений. То, что не удалось обработать за несколько попыток, откладывается для ручного разбора, а не теряется.

export async function withRetry<T>(
  operation: () => Promise<T>,
  attempts = 4,
): Promise<T> {
  let lastError: unknown

  for (let attempt = 1; attempt <= attempts; attempt++) {
    try {
      return await operation()
    } catch (error) {
      lastError = error
      // Ошибки клиента повторять бессмысленно: данные не изменятся
      if (error instanceof HttpError && error.status < 500) throw error

      // Пауза растёт: 1, 2, 4 секунды. Случайная добавка
      // разводит одновременные повторы
      const delay = 1000 * 2 ** (attempt - 1) + Math.random() * 300
      await new Promise((resolve) => setTimeout(resolve, delay))
    }
  }

  throw lastError
}

Ошибка проектирования: связи «каждый с каждым»

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

Тогда добавление шестой системы — это одна интеграция с шиной, а не пять с существующими. Мы применяем этот подход начиная с четвёртой системы в контуре: раньше он избыточен, позже — уже болезненно внедряется.