Разработка под e-commerce *

Проблема любого онлайн-движка исполнения кода в том, что он должен принять чужой код и выполнить его как есть — а этот код может оказаться вредоносным. Поэтому нужно спроектировать всё так, чтобы при запуске кода мы могли свести к минимуму негативные последствия, которые «враждебный» код может вызвать. Например, если кто-то попытается вызвать команду вроде rm -rf /, то это не удалит нам всю систему.

Можно быть хоть топ-1 в органической выдаче по всем коммерческим запросам, но ни разу не попасть в ИИ ответ от Google или Яндекс.

Я собрал собственный автоматический мониторинг видимости бренда на n8n (43 ноды): раз в месяц опрашиваем Яндекс, GPT, Gemini и Qwen, отделяем цитирование из выдачи от ответов модели по памяти и тратим меньше 100 рублей за полный прогон по всем категориям.

Внутри — разбор механики отслеживания, FNV-1a хэширование ответов, детект без второй LLM и ссылка на открытый GitHub с готовыми воркфлоу и шаблоном таблицы на 17 вкладок.

В финале прошлой статьи я обещал разбор контура генерации ответов с гибридным извлечением данных (LLM‑tools + regex). Но пока немного переиграем планы и переключимся в другую тему — причина практический инженерный эксперимент. Постараюсь вкратце и по существу.:‑)

Казалось бы, что может пойти не так с легковесными векторными анимациями? Вектор в Lottie, JSON весит копейки. Но тестирование на реальном телефоне закончилось фиаско: через пару минут скролла чип раскалился до 42 °C, а интерфейс ушёл в троттлинг.

Оказалось, что покадровый пересчёт кривых Безье в JS на мобильных экранах быстро превращает телефон в печку.

В кейсе разбор того, как мы перешли на аппаратно декодируемые видео‑спрайты, почему IntersectionObserver втихую крутил видео под непрозрачными модалками и как в итоге удалось сбить температуру обратно до стабильных 30 °C.

Первый файл, который я получил при переезде своего магазина с InSales, парсер прочитал как одну длинную строку мусора. Выгрузка заказов оказалась в UTF-16 LE с BOM и табуляцией вместо запятой — ни один разумный дефолт не подошёл.

Тогда это выглядело как разовая неприятность: поправил чтение, написал скрипт, ночь работы, всё уехало, скрипт лёг в репозиторий. На следующем проекте он не переиспользовался — другая платформа, другие колонки, другие правила. На третьем стало видно, что повторяется почти вся работа: связать заказ с клиентом, не создать дублей, не потерять адреса страниц, уметь перезапуститься. Разное только на входе — кодировка, формат, названия колонок, единицы измерения.

Отсюда вывод, к которому стоит прийти раньше, чем на третьем проекте: середина должна быть одна, а платформенная специфика — жить в тонком слое на входе. Ниже — как этот каркас устроен у меня, с кодом из работающего проекта: собственного магазина, который я перевёз с InSales на свой движок на Next.js и PostgreSQL.

Сразу оговорюсь про доставленные миграции: полностью пройдена одна — та, о которой пойдёт речь. Про требования к адаптерам под 1С‑выгрузки и товароучётные API дальше я говорю как о проектных требованиях к каркасу; готовыми кейсами они не являются. Это важно, чтобы вы правильно оценили вес каждого утверждения.

Резонный вопрос до всего остального: почему не готовый инструмент. Airbyte, n8n, коннекторы к товароучётным системам делают ровно это — вытащить, преобразовать, положить. Для регулярной синхронизации они и есть правильный выбор. Разовая миграция магазина отличается тем, что сложность сидит не в перекладывании строк, а в доменных правилах: как собрать заказ из нескольких строк, что делать с позицией, товара которой больше нет в каталоге, как при повторном прогоне не затереть свежие данные старыми. Эти правила всё равно пишутся руками, а в визуальной цепочке трансформаций их неудобно тестировать и нельзя перезапустить кусочком. Поэтому середина своя, а тонкими остаются края.

Задача была прикладная: мы переносим интернет‑магазины на свой движок и хотели понять, сколько в зоне .ru магазинов на каждой платформе и как их находить. Готовые сервисы вроде BuiltWith продают выгрузки по подписке, но нам нужен был воспроизводимый обход, который можно гонять когда угодно и по своим правилам.

Написали свой пробер, обошли 53 305 доменов и получили распределение платформ. Заодно собрали коллекцию ловушек, на каждой из которых успели ошибиться. Про них и статья — цифры без описания граблей мало чего стоят.

Всем привет!) Напомню: в первой статье я показал дебаунс на Redis, который склеивает дробные сообщения клиента. Во второй — модуль привязки «чат = сделка» и то, почему вебхуки стоит держать в изолированных ключах. Обе части заканчиваются примерно одинаково: «...и текст уходит ИИ‑агенту». Это, пожалуй, тот финал, на котором обычно ставят точку и заливают демо на GitHub... Но не в данном случае!)

Рутина в проверке конструкторской документации — головная боль: одни и те же проверки, одни и те же таблицы, одни и те же вопросы заказчику. Я решил передать часть этой рутины нейросетям. Рассказываю, что из этого вышло.

Заказ оплачен, товар можно отправлять — что может пойти не так? Например, через несколько дней деньги снова станут доступны покупателю, потому что магазин так и не подтвердил холд. Или клиент отменит заказ, а сумма продолжит «висеть» на карте из-за неправильно обработанной операции. Разберём, как устроено холдирование и почему проблемы часто возникают не в банке, а в логике платёжной интеграции.

В прошлой статье я показал, как простой дебаунс на Redis спасает бюджет от дробных сообщений: клиент строчит «привет» — «сколько стоит» — «а есть другой размер» пятью сообщениями подряд, а LLM получает один склеенный промпт.

Когда мы начали работать над AI‑консультантом для интернет‑магазина, идея была достаточно простой: помочь пользователю быстрее находить нужную информацию о товарах и упростить выбор.

В интернет‑магазинах уже есть поиск, фильтры и карточки товаров. Но этого часто недостаточно, когда человек приходит не с конкретным названием товара, а с задачей. Например: «Мне нужен инструмент для ремонта квартиры» или «Чем отличаются эти два товара и какой подойдет лучше?».

В офлайн‑магазине в такой ситуации можно обратиться к консультанту: объяснить задачу, уточнить детали и получить несколько вариантов. Мы хотели перенести похожий сценарий на сайт. Но довольно быстро стало понятно, что схема «пользователь → LLM → ответ» для этого не подходит.

Нужно понять запрос, сохранить контекст разговора, решить, нужен ли каталог, найти в нем товары, получить актуальную цену, при необходимости обратиться к базе знаний и только после этого дать модели данные для ответа.

Проект мы разрабатывали командой ASAP, и в этой статье разберем, как мы подошли к проектированию AI‑консультанта: устроили взаимодействие LLM с каталогом более чем из 200 тысяч товаров, какие задачи оставили коду, как работаем с актуальными ценами и остатками и почему вокруг языковой модели в итоге пришлось построить достаточно большой слой классической backend‑логики.

Я работаю аналитиком в e‑commerce крупной FMCG‑компании. В маркетплейсах это иногда ощущается как слон в посудной лавке: несколько юридических лиц на каждой площадке, большие объёмы поставок, ограничения по слотам на складах, сложная логистика, переупаковка и подготовка товаров под требования конкретного канала.

Отдельной болью, которую хотелось автоматизировать, был расчёт заказа на Ozon. Для менеджера маркетплейса это был регулярный и довольно трудоёмкий процесс: сначала нужно было собрать данные из разных выгрузок, а уже потом переходить к расчёту.

Сделал mmap-базу для 4 млн товаров и получил ~35k RPS. Поиск оказался настолько быстрым, что bottleneck пришлось искать уже после базы. В итоге оптимизировал JSON, получил ~1.8× прироста HTTP workload — и упёрся в w.Write.

Внешний счётчик ставится за пять минут, и обычно этого достаточно. Но у модели «сторонний скрипт с чужого домена» есть технический потолок, и на магазине я в него упёрся: запрос к третьему домену режут блокировщики и антитрекинг браузеров, на объёме включается сэмплирование, cookie тянет за собой баннер согласия (а все, кто его отклонил, выпадают из статистики целиком), и главное — поведение ваших покупателей лежит в чужой системе, рядом с которой нет ваших заказов.

Ниже — как устроен свой cookieless‑трекинг в двух проектах на Next.js: интернет‑магазин (Next.js 15.5, TypeScript, Prisma 6, PostgreSQL) и маркетплейс услуг (тот же Next.js, но pg без ORM). Код в статье — из работающих проектов, с теми решениями, которые оказались неочевидными, и с теми, которые пришлось переделать.

Сразу оговорка: это не «Метрика — зло». Для контентного сайта внешний счётчик закрывает вопрос целиком. Разговор начинается там, где аналитика — часть продукта.

В МФТИ 53% бюджетных мест в этом году заняли олимпиадники. На биоинженерии МГУ — все 35 из 35, туда не прошли даже стобалльники. При этом вся инфраструктура олимпиадной подготовки живёт в Москве и нескольких матлицеях, а я живу в городе на сорок тысяч человек. Рассказываю, как мы с супругой — оба бывшие олимпиадники — посмотрели на первый класс сына, посчитали и ушли на семейное обучение.

До AVM виртуализацией управляла сторонняя платформа. Иногда она зависала и переставала принимать задачи. Нагрузку распределили между несколькими экземплярами платформы, но зависания продолжились. До вмешательства операции клиентов не шли.

Привет, Хабр! Я разработчик из Минска (работаю официально, в статусе НПД). Занимаюсь автоматизацией на связке Self‑Hosted n8n + Redis. Внедряю автономных ИИ‑агентов для мессенджеров и связываю их с amoCRM.

Поделюсь, как говорится, «мясом» из своей практики. В статье я максимально постараюсь отразить и технический абсурд плавно переходящий в явное кидалово от инфомошенников.

Перед началом сразу обозначу, как говориться, на берегу: во‑первых — это не хейт и не попытка кого‑то «разоблачить». Ленты мессенджеров завалены рекламой от «ИИ‑агентств» и «продавцов успешного‑успеха», которые громко кричат про «...ваш цифровых сотрудников за пару дней...». У меня нет раскрученного профиля с красивыми публикациями, но, есть обычная практика. Данный разбор — это попытка показать (а может кому‑то и знакомо), что скрывается за красивыми нагенерированными видосами и контентом и почему, доверив реальный проект таким «спецам» обойдётся дорого. Во‑вторых — все упоминания брендов и платформ в статье — не реклама и не антиреклама. Названия систем я оставил исключительно ради сохранения контекста, да и в принципе живого отражения примера.

История статьи началась, наверное можно сказать в 2 этапа. На первом этапе, который был ещё наверное в марте этого года, ко мне обратился заказчик с интересным ТЗ: стек Instagram+ amoCRM + Google Sheets при плотном трафике до 5000 диалогов в месяц (таргет что тогда, что по сей день заходит «на ура»). Причём сёстры (заказчик — это семейный бренд ателье дизайнерских украшений) своими силами опробовали «...платформы где платишь подписку и в соответсвии с трафиком выбираешь соответствующий пакет услуг. Итог в который после первого дня триала по самым средним подсчётам вышел бы 1100$ в месяц расхода (!). Поскольку моя статья не о том какая архитектура была в итоге у них развёрнута, так что пойдём дальше.»

Благодаря искусственному интеллекту код удешевился. Но ошибочные архитектурные решения остаются такими же дорогими, как и раньше.

Время от времени я спорю сам с собой о том, какие аспекты программной инженерии остались особенно важными в наше время, когда ИИ бегло пишет код. Вывод, к которому я прихожу, не понравится многим опытным разработчикам. Паттерны реализации, на усвоение которых мы потратили годы, стремительно обесцениваются. Но что насчёт умения структурировать системы в духе правильного проектирования? Это умение становится всё более, а не менее востребованным.

Давайте объясню это на конкретном примере. Система электронных продаж, написанная на Java — как раз такая штука, с которой большинство бэкендеров сталкивались хотя бы раз на протяжении карьеры.

Всем привет! 

Меня зовут Дмитрий Шипилов, с вами команда поиска Uzum Market.

Мы уже рассказывали вам о нашем поисковом движке: о том, как вообще работает ранжирование и что у него под капотом и как мы получаем кандидатов с помощью векторного поиска. 

Но хороший поиск — это не только правильное ранжирование и мощная retrieval-часть. Хороший поиск — это набор различных инструментов и компонентов, собранных в сложную систему.  Поэтому в этой статье вы узнаете о важных вещах, без которых наш поиск не может обойтись, в том числе: как мы помогли опечаточнику понимать контекст нашего маркетплейса, почему безобидные синонимы могут привести к неожиданным эффектам, в каких случаях важно сужать количество товаров и как построить устойчивую LLM-систему для оценки качества ранжирования. 

Началось с простого желания: чтобы Claude мог написать письмо коллеге, не заставляя меня переключаться в браузер. Готовые решения есть — Zapier, всякие облачные коннекторы. Но там моя переписка проходит через чужую инфраструктуру, а мне этого не хотелось. Значит, свой MCP-сервер: пара сотен строк, Gmail API, за вечер.

Вечер растянулся на несколько дней и 300 тестов не потому, что задача сложная, а потому, что почта оказалась минным полем, где каждая вторая мелочь ломает всё молча и не сразу. Собрал грабли в кучу. Если будете делать что-то похожее — сэкономите себе несколько вечеров.