В каких случаях интеграция систем через общую базу данных оправдана?

Интеграция через общую БД (Database-as-an-Integration-Backbone) — это паттерн, где несколько приложений взаимодействуют, читая и записывая данные в одни и те же таблицы.

Сценарии применения:

• Интеграция с legacy-системами, у которых нет API, но есть прямой доступ к БД.
• Синхронизация данных между тесно связанными системами (например, основной сервис и отчетный модуль).
• Реализация простой асинхронной очереди на основе таблицы (паттерн "таблица-очередь").
• Высокопроизводительная пакетная обработка, где прямой доступ к данным критичен.

Пример реализации "таблицы-очереди":

-- Общая таблица для задач
CREATE TABLE integration_queue (
    id BIGSERIAL PRIMARY KEY,
    payload JSONB NOT NULL,
    status VARCHAR(20) DEFAULT 'PENDING',
    created_at TIMESTAMP DEFAULT NOW()
);

// Сервис-отправитель
jdbcTemplate.update(
    "INSERT INTO integration_queue (payload) VALUES (?::jsonb)",
    "{"type":"ORDER","id":123}"
);

// Сервис-получатель (обрабатывает пачками)
@Transactional
public void processMessages() {
    List<Message> messages = jdbcTemplate.query(
        "SELECT * FROM integration_queue WHERE status = 'PENDING' FOR UPDATE SKIP LOCKED LIMIT 10",
        new MessageRowMapper()
    );
    // Обработка messages...
    jdbcTemplate.update("UPDATE integration_queue SET status = 'DONE' WHERE id = ?", messageId);
}

Критические недостатки:

• Тесная связь (tight coupling): Системы зависят от единой схемы данных.
• Сложность масштабирования: БД становится узким местом.
• Риск блокировок и конфликтов.
• Нарушение инкапсуляции: Каждая система знает внутреннюю структуру данных другой.

Современная альтернатива: Использование асинхронных сообщений (брокеры) или событийно-ориентированной архитектуры для слабой связанности.