Какие знаешь способы обмена данными?

Способы обмена данными между системами

REST API

Наиболее популярный способ обмена данными по HTTP/HTTPS протоколу. Использует стандартные методы: GET (получение), POST (создание), PUT/PATCH (обновление), DELETE (удаление).

Преимущества:

• Простота реализации
• Универсальность (работает везде)
• Хорошая поддержка инструментами
• Эффективен для синхронного обмена

Недостатки:

• Синхронный (клиент ждёт ответ)
• Над-overhead из-за HTTP заголовков
• Не оптимален для real-time данных

gRPC

Современная альтернатива REST, использует бинарный протокол Protocol Buffers. Позволяет двусторонние потоки данных (streaming).

Преимущества:

• Очень быстро (бинарный формат)
• Поддерживает streaming
• Меньше overheads
• Типизация и контракты

Недостатки:

• Сложнее отладить
• Требует специальных инструментов
• Браузеры требуют gRPC-web

Message Queues (Очереди сообщений)

Асинхронный обмен через посредника (RabbitMQ, Kafka, AWS SQS). Отправитель кладёт сообщение в очередь, получатель берёт когда готов.

Преимущества:

• Асинхронность
• Надёжность (сообщение сохраняется)
• Развязка систем
• Масштабируемость

Недостатки:

• Задержка доставки
• Нужна дополнительная инфраструктура
• Сложнее отладить

Webhooks

Система А регистрирует URL у системы Б. Когда в системе Б происходит событие, она отправляет HTTP POST запрос на зарегистрированный URL.

Пример: Когда платёж прошёл в системе платежа, она отправляет POST с данными платежа в мой приложение.

Преимущества:

• Real-time уведомления
• Простота
• Не нужно polling

Недостатки:

• Клиент должен быть доступен (нужен публичный URL)
• Нужно обработать retry и reliability

Event Streaming (Kafka, Kinesis)

Поток событий, который приложение может читать с любого момента. Больше, чем очередь — это лента событий.

Пример: Все события о заказах логируются в Kafka: "OrderCreated", "OrderPaid", "OrderShipped". Несколько приложений могут читать эту ленту независимо.

Преимущества:

• Множественные подписчики
• История событий
• Может быть переиграна
• Масштабируемость

WebSocket

Двусторонняя постоянная коммуникация по одному соединению. Типично используется для real-time приложений (чат, notifications, live updates).

Преимущества:

• Low latency
• Двусторонний обмен
• Экономия ресурсов (одно соединение)

Недостатки:

• Сложнее серверную часть
• Трудно масштабировать
• Требует stateful серверов

Batch Processing (Пакетная обработка)

Периодическая выгрузка/загрузка данных в виде файлов (CSV, JSON, Parquet). Типично раз в сутки или час.

Пример: Каждую ночь выгружаем отчёт из системы А в файл, загружаем в систему Б.

Преимущества:

• Простота
• Можно обработать большие объёмы
• Меньше overheads

Недостатки:

• Не real-time
• Задержка
• Нужно хранить файлы

FTP / SFTP

Традиционный способ обмена файлами. SFTP — защищённая версия с шифрованием.

Когда использовать:

• Обмен большими файлами
• Legacy системы
• Когда HTTP не подходит

EDI (Electronic Data Interchange)

Стандартный формат для электронного обмена между организациями (заказы, счета, отправки). Типично используется в B2B.

Формат:

• EDIFACT (более распространён в Европе)
• X.12 (более распространён в США)
• XML/JSON (современные варианты)

GraphQL

Декларативный способ запроса данных. Клиент говорит, какие данные ему нужны, и получает только их (избегает over-fetching и under-fetching).

Пример:

query {
  user(id: 1) {
    name
    orders { id, total }
  }
}

Преимущества:

• Гибкость
• Меньше API endpoints
• Типизация

Недостатки:

• Сложнее реализовать
• Сложнее кешировать
• Может быть медленнее

Direct Database Connection

Прямое подключение к БД другой системы (через SQL). Редко используется из-за рисков.

Почему избегать:

• Тесная связанность
• Сложно управлять версионированием схемы
• Сложно масштабировать
• Рисков безопасности

Выбор способа

REST API — по умолчанию для большинства случаев

gRPC — когда нужна высокая производительность и streaming

Message Queues — когда нужна асинхронность и надёжность

Webhooks — для real-time уведомлений

Batch — для больших объёмов и не-срочных данных

WebSocket — для real-time UI обновлений

GraphQL — когда нужна гибкость в запросах

EDI — для B2B интеграций

Выбор зависит от требований к задержке, объёму, надёжности и архитектуре систем.