Чем отличается синхронная интеграция от асинхронной? Когда лучше использовать каждый подход?

Синхронная vs Асинхронная интеграция

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

Синхронная интеграция (Synchronous Integration)

Определение

При синхронной интеграции система A отправляет запрос системе B и ждёт ответа. Процесс блокируется до получения результата.

Синхронный поток:

Система A                          Система B
    │                                  │
    │────── Request ─────────────────> │
    │ (ждёт, блокирована)              │
    │                           (обрабатывает)
    │ <────── Response ────────────────│
    │ (продолжает работу)              │
    │                                  │

Примеры синхронной интеграции:

• REST API вызовы (HTTP)
• SOAP Web Services
• gRPC вызовы
• Database хранилище (прямое обращение к БД)
• Function вызовы (если синхронные)

Плюсы синхронной интеграции

Простота и предсказуемость — прямое взаимодействие

• Вызвал функцию, получил результат
• Понятный поток выполнения
• Легко отладить
• Не нужна дополнительная инфраструктура (очереди, message brokers)

Немедленный feedback — сразу знаем успех или ошибку

• Если Payment Service вернул ошибку, сразу обрабатываем
• Нет задержек в обработке
• User видит результат сразу

ACID консистентность — легче гарантировать

• Транзакция либо успешна, либо откатывается
• Нет eventual consistency
• Данные всегда в консистентном состоянии

Простое обработка ошибок — оборачиваем в try-catch

try:
    payment_response = payment_service.process_payment(order_id, amount)
    if payment_response.success:
        order.mark_as_paid()
    else:
        order.mark_as_failed()
except TimeoutError:
    order.mark_as_failed()

Простой мониторинг — один request = один ответ

• Легко отследить время ответа
• Полная trace request-response
• Понятные metrics

Минусы синхронной интеграции

Tight coupling — системы сильно связаны

• A зависит от B: если B упадёт, A не сработает
• Нельзя обновлять B (A будет ждать или вернёт ошибку)
• Нельзя масштабировать A независимо
• Cascade failures — отказ B сломает A

Производительность — только столько, сколько сможет обработать самая медленная система

• A ждёт B
• Если B обрабатывает 100 req/sec, A максимум 100 req/sec
• Network latency добавляет задержку
• Timeout ограничивает максимальное время обработки

Масштабируемость ограничена — нельзя обработать peaks

• 10,000 запросов в секунду
• B может обработать только 1,000
• Остальные 9,000 ждут (очередь растёт)
• Timeout → много ошибок

Затруднительны долгие операции

• Если Payment обработка 5 минут, клиент ждёт 5 минут
• Browser может timeout
• Соединение может разорваться

Требует точного timing

• Обе системы должны быть up одновременно
• Если B упадёт на 30 минут, A полностью сломана
• Плохая resilience

Пример проблемы:

1. User отправляет Order
2. Order Service вызывает Payment Service (ждёт)
3. Payment Service перегружена (1 минута ответа)
4. User ждёт 1 минуту (плохой UX)
5. Payment Service упала
6. Order Service получает timeout → возвращает ошибку
7. User видит "Order failed" хотя платёж может быть обработан

Асинхронная интеграция (Asynchronous Integration)

Определение

При асинхронной интеграции система A отправляет сообщение системе B через message broker и не ждёт ответа. Продолжает работу параллельно.

Асинхронный поток:

Система A          Message Broker        Система B
    │                   │                      │
    │──── Message ──────> │                    │
    │ (сразу продолжает)  │                    │
    │                     │──── Message ──────> │
    │                     │              (обрабатывает)
    │                     │ <── Acknowledgment ─│
    │                     │                    │

Примеры асинхронной интеграции:

• Message queues (RabbitMQ, AWS SQS)
• Event streams (Apache Kafka, Google Pub/Sub)
• Webhooks (callback URL)
• Background jobs (Celery, Bull)
• Event buses (в microservices)

Плюсы асинхронной интеграции

Loose coupling — системы независимы

• A не зависит от B
• B может быть offline, A продолжает работать
• Можно обновлять B без влияния на A
• Нет cascade failures

Высокая производительность — не ждём ответа

• A отправляет message и продолжает
• Может обработать больше запросов
• Network latency не влияет на A

Простое масштабирование — системы масштабируются независимо

• A получает 10,000 req/sec → масштабируем A
• B может обрабатывать медленнее → добавляем worker процессы для B
• Queue распределяет нагрузку

Долгие операции — B может обрабатывать долго

• Payment обработка 5 минут — нормально
• A продолжает работу, не ждёт
• User видит "Order received, processing..." (оптимистичный ответ)

Хорошая resilience — отказоустойчивость

• B упала на 30 минут → сообщения накопились в queue
• B поднялась → обрабатывает очередь
• Ничего не потеряно
• Guaranteed delivery (если использовать reliable queue)

Retry и compensation logic

• Message может быть переповторен
• Можно реализовать компенсирующие транзакции
• Payment не вышел? → Отправляем Refund событие

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

1. User отправляет Order
2. Order Service создаёт Order в БД
3. Order Service отправляет OrderCreated event в queue
4. Order Service возвращает "Order received!" клиенту
5. Payment Service берёт event из queue (когда готова)
6. Payment Service обрабатывает платёж
7. Payment Service отправляет PaymentProcessed event
8. Order Service получает event и обновляет Order статус
9. Все работает даже если Payment Service была неготова

Минусы асинхронной интеграции

Сложность — требуется дополнительная инфраструктура

• Message broker (RabbitMQ, Kafka)
• Consumer процессы
• Error handling logic
• Monitoring очередей

Eventual consistency — данные не консистентны сразу

• A знает что сообщение отправлено
• B может быть ещё не обработал
• Временный период когда состояние неконсистентно
• Требуется compensating logic

Сложная отладка — поток выполнения не линейный

• A отправляет message, потом B обрабатывает
• Время между ними не определено
• Сложнее отследить ошибку
• Требуется distributed tracing

Дублирование обработки — сообщение может быть обработано дважды

• Network может потерять acknowledge
• Message может быть переповторен
• Нужна idempotency (обработка дважды = один результат)

Out of order обработка — сообщения могут приходить не по порядку

• Message 1, затем Message 3, затем Message 2
• Нужно handle такие сценарии
• Может потребоваться корректирующая логика

Задержка — сообщения обрабатываются не сразу

• User видит "Processing" но не знает когда будет готово
• Может потребоваться polling или WebSocket для updates
• Не подходит для операций требующих немедленный результат

Мониторинг сложнее — нужно отслеживать очереди

• Сколько сообщений в очереди?
• Есть ли зависания?
• Есть ли dead letter queues?
• Требуется специальный мониторинг

Пример проблемы:

1. User отправляет Order
2. Order Service отправляет OrderCreated event
3. Order Service возвращает "Order received!"
4. User закрывает браузер
5. Payment Service обрабатывает платёж 5 минут спустя
6. Payment Service отправляет PaymentFailed event
7. Но user не видит (offline)
8. Order остался в "pending" состоянии

Сравнение таблица

Когда использовать синхронную интеграцию?

✓ Требуется немедленный результат

• User регистрация → сразу вернуть token
• Get user profile → вернуть данные сразу
• Check inventory → сразу узнать есть ли товар

✓ Простые, быстрые операции

• Database lookups
• Cache queries
• API calls <100ms

✓ ACID консистентность критична

• Финансовые операции (если в одной системе)
• Критичные данные
• Нельзя допустить inconsistency

✓ Tight coupling приемлемо

• Monolithic приложение
• Компоненты сильно зависят друг от друга
• Вся система controlled by одна team

✓ Простота важнее

• Маленькая система
• Мало интеграций
• Нет нужды в high availability

✓ Real-time требование

• Chat приложение
• Gaming
• Live updates
• Требуется немедленный response

Когда использовать асинхронную интеграцию?

✓ Долгие операции

• Email отправка
• Report генерация
• Image processing
• Может занять минуты или часы

✓ Peaks в нагрузке

• 10x traffic в определённое время
• Очередь буферизирует load
• Обработка выравнивается

✓ Независимое масштабирование

• Разные системы растут по-разному
• Нужна гибкость
• Loose coupling

✓ High availability требуется

• 99.99% uptime
• Graceful degradation
• One system can be down

✓ Требуется resilience

• Guaranteed delivery важна
• Retry logic нужна
• Compensation transactions

✓ Eventual consistency приемлема

• Данные синхронизируются со временем
• Нет strict ACID requirement
• Система может работать в eventually consistent mode

✓ Интеграция с external системами

• Webhook callbacks
• Third-party APIs
• Нельзя рассчитывать на их availability

Гибридный подход

Synchronous для queries (read) — нужны данные прямо сейчас

• GET /user/123 — синхронный запрос
• Нужны данные сразу

Asynchronous для commands (write) — не нужен результат сразу

• POST /order — асинхронное создание
• OrderCreated event → дальше обрабатывается async

Пример:
Client ──sync GET──> User Service (returns 200 OK with data)
Client ──sync POST──> Order API (returns 202 Accepted with order_id)
                      └──async──> Payment Service
                      └──async──> Inventory Service
                      └──async──> Notification Service

CQRS (Command Query Responsibility Segregation)

• Query (read) — синхронный
• Command (write) — асинхронный

Это popular паттерн для современных систем.

Вывод

Выбор между синхронной и асинхронной интеграцией зависит от требований:

• Синхронная: когда нужен результат NOW
• Асинхронная: когда результат может быть потом

Большинство систем используют гибридный подход: синхронную для queries и асинхронную для долгих операций.

Системный аналитик должен анализировать каждый случай и рекомендовать оптимальный подход.