Если ваш Битрикс тормозит, а Laravel кажется из другой вселенной — эта статья для вас.

Привет, хабровчане! На связи Алиса — тимлид в e-commerce агентстве KISLOROD. Мы ежедневно имеем дело с большими каталогами, сложной коммерцией и 1С, которая дышит в затылок. И однажды мы решили сделать невозможное: подружить Битрикс с Laravel. Так, чтобы Битрикс остался каноном и привычной админкой, а Laravel стал помощником — взял на себя API, тяжёлую бизнес-логику и все, что тормозит. Без форка ядра, слез SEO-шника и без утечек в 1С. Да, это реально.

Что будет внутри:

1. Архитектура «соседнего сервиса» — покажем, как Laravel становится полноценным соседом Битрикса, а не его врагом. Где провести границы, чтобы не сломать ничего важного.

2. JWT, SSO и Redis Streams без боли — авторизация, события и наблюдаемость: как соединить две платформы так, чтобы всё было прозрачно и надежно.

3. Очереди, вебхуки, кеш, наблюдаемость — разберем, как мы внедряли очереди событий, обрабатывали вебхуки с проверкой подписи и делали наблюдаемость без костылей.

4. Пошаговый план миграции с откатами и фича-флагами — как эволюционно мигрировать проект с Битрикса на Laravel, не выведя прод из строя.

5. Код, конфиги и живые примеры — не будет абстракций: только продовые конфиги, API-контракты и трейсинг с боевого проекта.

Кода будет много. Теории — ровно столько, чтобы вы могли повторить это у себя. Погнали!

Почему вообще это нужно

«Не трожь Битрикс — сломаешь 1С» — старая народная мудрость.

Если ваш проект на Битриксе вырос за пределы его изначальных возможностей, вы это чувствуете:

• медленные каталоги, листинги, фильтры;

• сложно внедрять новые бизнес-фичи без риска все сломать;

• нет нормального API для фронтов и партнеров;

• любая сложная логика превращается в компонент с бизнес-логикой размером с модуль CRM;

• любая интеграция с внешними сервисами переходит в мини-движок с кастомным API, который сложно сопровождать.

Знакомо? Тогда давайте покажу, как мы пошли другим путем: без форка, без слома — через архитектурное разделение и разумный headless-подход.

Архитектура «Соседний сервис»: кто где живет и зачем

Представьте, что Битрикс — это Морфеус, а Laravel — Нео. Один знает, как устроен мир, второй — как его менять. В нашей архитектуре:

• Битрикс продолжает управлять админкой, корзиной, UI, бизнес-логикой скидок, регистрацией заказов.

• Laravel берет на себя все, что требует производительности, API-first мышления и легкой масштабируемости: каталог, фильтры, уведомления, интеграции.

Принципы взаимодействия:

• Nginx маршрутизирует /bitrix/* в Битрикс, а /api/* в Laravel;

• аутентификация и авторизация — через JWT (RS256) с публикацией JWK из Битрикса;

• обмен событиями — через Redis Streams, в стиле outbox pattern.

Ножницы владения данными:

• Битрикс пишет только в свои b_* таблицы;

• Laravel — в svc_*;

• взаимодействие строго через REST/AsyncAPI.

Шаг А: Аутентификация, события, наблюдаемость

Цель: создать фундамент для headless-подхода: единая авторизация, корректная передача событий и наблюдаемость всей архитектуры.

Что делаем:

• реализуем мост SSO: пользователи логинятся через Битрикс, получают JWT в HttpOnly cookie, Laravel использует кастомный guard;

• внедряем outbox-слой в Битрикс, чтобы гарантировать доставку событий в очередь (Redis Streams, RabbitMQ);

• настраиваем наблюдаемость: X-Request-Id, трассировка запросов с OpenTelemetry, метрики Prometheus и алерты в Sentry.

Шаг Б: Каталог и OpenSearch

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

Что делаем:

• создаем денормализованный индекс в OpenSearch на основе таблиц svc_catalog_*, заранее подготавливая структуру под фасеты и фильтрацию;

• Laravel раздает быстрые ответы по эндпоинтам /api/catalog/search, /api/products/{id} — с поддержкой сортировки, фасетных фильтров, fulltext и nested-атрибутов;

• админка больше не «висит»: ленивые вкладки, кеш метаданных, быстрые справочники и автокомплиты позволяют работать без ожидания перезагрузки страницы;

• подключаем отдельный медиасервис — он делает асинхронные ресайзы, готовит WebP и AVIF, отдает через CDN-ссылки.

Контракты и события:

• REST: /api/catalog/search, /api/products/{id};

• события: catalog.element.updated, price.changed, stock.changed.

Метрики:

• TTFB каталог: < 150 мс на кэше, < 400 мс на миссе;

• лаг реиндексации: < 10 с.

Риски: если OpenSearch упал — Laravel отдает кеш из Redis или заглушку.

Шаг В: Коммерция — корзина, цены, заказы

Цель: ускорить путь пользователя от выбора товара до успешного заказа и при этом существенно разгрузить Битрикс в самых уязвимых точках — корзине, расчете цен и создании заказов.

Что делаем:

• переносим корзину в Redis, сохраняя полную совместимость с логикой sale. Пользователь продолжает работать с привычным интерфейсом, но данные обрабатываются быстрее и устойчивее;

• цены и остатки теперь отдаются через API: мгновенный ответ из кэша, плюс персонализация (скидки, правила, группы пользователей), если нужно — с запросом к внутренним сервисам;

• заказ создается с минимальным набором данных в b_sale_order для совместимости с UI и административкой. Вся остальная логика, маршруты, статусы, уведомления и интеграции уходят в Laravel и обрабатываются асинхронно.

Контракты: /api/cart, /api/pricing, /api/inventory, /api/orders

Метрики:

• операции с корзиной P95: < 120 мс;

• расчет цен P95: < 120 мс (кэш), < 300 мс (реальный вызов);

• заказ: запись в Битрикс < 400 мс, саги Laravel < 60 с.

Риски:

• конфликт логики скидок — проверка на стороне Битрикс;

• откат — по флагу, данные совместимы.

Шаг Г: Интеграции и уведомления

Цель: собрать все внешние вызовы в одно место и вытащить из админки логику, которую туда когда-то «временно» положили. Больше никаких скриптов в init.php, чтобы синкать заказы с CRM или вручную слать уведомления.

Что делаем:

• разворачиваем единый шлюз интеграций, через который проходят все внешние взаимодействия — 1С, CRM, платёжные шлюзы, доставки. Все это оформлено в отдельные каналы с retry, паузами, fallback и таймингами;

• оборачиваем все в очередь с DLQ (dead letter queue), чтобы не терять события при сбоях. Плюс мониторим лаги и ошибки;

• уведомления выносим в отдельный сервис, который работает через REST, поддерживает шаблоны писем и сообщений, учитывает приоритеты и предпочтения пользователя.

Контракты:

• /api/integrations/*, /api/notify;

• события статусов обратно в Битрикс и ERP.

Метрики:

• интеграции P95: < 30 с;

• уведомления: >98% доставляемости.

Риски:

• если провайдер лег, очередь ставится на паузу;

• спам — скоростные лимиты и троттлинг.

Шаг Д: Headless API и SDK

Цель: вытащить API наружу, чтобы фронты больше не зависели от внутренних модулей, бизнес-логики и тонкостей реализации. Меняем концепцию: не «Лезь в Битрикс за JSON», а «Обратись в стабильный API и получи то, что нужно».

Что делаем:

• API Gateway на Laravel — единая точка входа (/v1/*) с версияцией, лимитами, ключами партнеров и всем, что положено продовому API;

• SDK для фронтов — готовая библиотека с типами из OpenAPI, встроенными ретраями, трейсингом и логикой повторов. Работает одинаково на вебе и в мобильных.

Метрики:

• Доля 5xx — менее 0,2%;

• P95 отклика по кэшу — до 150 мс;

• SDK покрыт автотестами и валидируется при CI-доставке.

Откат: если SDK вдруг перестал работать — фронт может напрямую ходить по REST, пока не починим. Все маршруты стабильны, структура API не меняется без версии. Теперь API — это контракт, не фреймворк. Вы можете менять фронт, деплоить виджеты, выносить в мобилки — и не трогать бэкенд вовсе.

Laravel и Битрикс — разные, но вместе работают круче. Headless-подход не требует рвать все на части — он требует осознанности, фича-флагов и нормальной архитектуры.

Так проект становится гибче, быстрее, масштабируемее. А главное — не превращается в «спагетти-код с криками в комментариях».

Продолжение следует...

Если статья зашла — покажите её тем, кто сомневается: а можно ли сделать современную архитектуру рядом с Битриксом? Можно. И нужно.