Onlihub
Техническая ответственность за commerce-платформу
Интеграции e-commerce и маркетплейсов
Подключение магазина должно создавать рабочий бизнес-процесс: товары сопоставлены, остатки понятны, заказы движутся к исполнению. Как CTO Onlihub, я работаю с предметной моделью, backend и границами интеграций. Сложность — в согласованной работе систем, которые меняются независимо.
Как подхожу к работе
Определить источники и сопоставления
Описать связи товаров с листингами и заказов с исполнением. Явно хранить внешние ID и возможности провайдера. До синхронизации определить источник остатков, цен и статусов.
Сделать фоновую работу восстанавливаемой
Сохранять намерение операции, ограничивать владение задачей и фиксировать повторы. Кейс Onlihub показывает ключи идемпотентности, outbox и lease задач в PostgreSQL. Локальный захват задачи не гарантирует однократный внешний эффект.
Предусмотреть сверку
Webhooks быстро сообщают об изменениях; периодические проверки и явные ошибки помогают восстановить пропущенное. Отделять адаптеры провайдеров от доменных сервисов, чтобы особенности маркетплейса не распространялись на всё приложение.
Что стоит решить вначале
Мгновенная согласованность везде — редко правильное обещание. Стоит согласовать допустимую задержку, лимиты API и правила восстановления для каждой операции. Публичные страницы интеграций подтверждают продукты, а не личные сертификации.
Связанные работы
MySellerHub
Общая модель независимых каналов продаж
Onlihub Catalog
Разные пути данных для разных нагрузок
Zipurch
Торговая активность на карте
Расскажите о своей задаче
Назовите платформы, данные для обмена и места, где синхронизация сейчас ломается. Добавьте примерные объёмы, если известны; учётные данные для обсуждения архитектуры не нужны.
Обсудить задачу