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

Все ноды зелёные, Meta отдала 200 OK, а клиентка осталась без ответа. Разбираем баг ИИ-агента на n8n

Часть моей работы — помогать джунам разбираться с архитектурными решениями.

Иногда у нас возникают обсуждения на тему: «Зачем заморачиваться с WebFlux, если можно продолжать писать на Spring MVC?». Чтобы предметно обсуждать эту тему, мы с командой провели внутренний бенчмарк, написали методичку и решили поделиться некоторыми соображениями в этом цикле статей.

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

Дисклеймер: для Java-сеньоров в этой статье скорее всего ничего нового не будет.

Архитектурный и OPSEC-разбор для CTO, CISO, системных инженеров и разработчиков распределённых систем.

В SLA облачных провайдеров привычно фигурируют высокие показатели доступности, а продуктовая документация годами продвигает мультизональность (Multi-AZ) как серебряную пулю. Но в октябре 2026 года математические модели отказоустойчивости столкнулись с суровой физической реальностью: череда инцидентов на опорных площадках в сочетании с сетевым сбоем показала, где именно заканчиваются возможности автоматического восстановления.

События 8–11 октября 2026 года — бесценный материал для инженерного аудита. Без эмоций, конспирологии и политики разберём: что подтверждено официальными данными, почему Multi-AZ упирается в физический потолок свободных мощностей (Capacity Exhaustion) и как пересобрать архитектуру сервисов и данных, чтобы авария внешнего провайдера не ставила бизнес на паузу.

Продолжение серии «Автоматизация для новичков на примере малых предприятий».
В прошлой главе я уже продал Азизу CRM и разъяснил вам основные термины интеграторов ERP простым языком обывателя. Настало время вновь заглянуть в Непревзойдённую шаверму и познать чем же так важны Фефа и Фифа в пищевом бизнесе.

Все вокруг кричат про тотальную цифровую трансформацию, маркировку и ЭДО. Наш ресторан купил красивое готовое решение для импорта документов/поставок, из ЕГАИС в StoreHouse, и импорт документов/поставок из ЭДО в StoreHouse, и другое.

Круто? Да, но только на бумаге.

Крупные федеральные поставщики присылают документы в ЭДО или ЕГАИС, каждый день. Эти документы спокойно импортируются в StoreHouse. А вот мелкие локальные контрагенты (крафтовые производители зелени, сыроварни, поставщики свежего мяса) до сих пор живут в прошлом веке. Им ЭДО не обязателен. Максимум, на что они способны — забить накладную в свой Excel и скинуть менеджеру в Telegram, самый плохой вариант — это мягкие накладные, написанные непонятным почерком.

Итог: каждый день бухгалтер‑калькулятор вынужден руками вбивать по 100–300 строк в StoreHouse.

Привет, Хабр!

Меня зовут Дмитрий, руководитель отдела рекламы и продвижения в Аспро. Мы запускаем интернет-магазины и развиваем систему управления бизнесом Аспро.Cloud.

Частая ситуация у клиента: сайт работает, заявки идут, реклама крутится — а потом приходит письмо от РКН или ФАС. Грешат на подрядчика. Но обычно дело в том, что законы для сайта пришли после его запуска.

Разберем, какие требования действуют в 2027 году, за что уже штрафуют и с чего начать проверку.

Где заканчивается парсинг и начинается решение

Предыстория: около месяца назад подробно обсуждал архитектуру этого проекта в личке с хабровчанкой (не имею права раскрывать ник). Она набросала мощные хардкорные идеи: прикрутить предохранитель на объем выдачи, внедрить счетчик пропусков missed_runs для отсечения ложных удалений и использовать сессии Telethon. До реализации её паттернов руки всё никак не доходили (да и заказчик активно пользовался проектом). Момент настал, а вчера OpenAI выкатила GPT-6 Luna Decisions с её Decisions API. И тут мне в голову пришла альтернативная мысль, о которой эта статья. Мне крайне интересно мнение со стороны касательно изменения проекта.

В мониторинге объявлений, сбор данных - только половина задачи. Можно регулярно забирать выдачу, сравнивать цены и присылать сводку. Но затем возникает другой вопрос: о каком изменении стоит сообщить отдельно, а какое можно оставить в журнале?

Мне интересна именно эта граница. В схеме на n8n изменения находит обычный код, а текстовая модель составляет отчёт. Пока человек читает весь отчёт, это удобное разделение. Если хочется отправлять отдельные уведомления, оценку из текста уже нужно переделать в машинное решение.

В описании Luna Decisions на OpenRouter меня заинтересовал подход: модель возвращает типизированные оценки, а приложение само выбирает действие. Не «напиши, насколько это интересно», а отдельный результат, который можно проверить, сохранить и сравнить с порогом.

Но из этого ещё не следует, что такой API нужен в моём случае. Ниже разберу, куда его можно встроить, чего не хватает во входных данных и с чем я бы сравнивал результат. Возможно, после сравнения окажется, что достаточно нескольких условий в Code-ноде. Это тоже полезный исход.

Документ провёлся. Ошибок в коде нет. Тест зелёный.

Открываю оборотно-сальдовую ведомость по 19-му счёту — и вижу, что часть НДС оказалась на 91-м. С точки зрения программы операция завершилась успешно. С точки зрения бухгалтера учёт уже разъехался.

Всем привет! Меня зовут Ольга Сумерина, я старший инженер по тестированию 1С в Ozon. Три года до этого я работала бухгалтером: считала амортизацию, контролировала расчёты с поставщиками, закрывала период.

В этой статье я расскажу о своём пути, о навыках и инструментах, необходимых тестировщику 1С, и про баги, которые было бы сложно заметить без бухгалтерского опыта. Разберу причины, покажу, где их искать, а в конце соберу из них чек-лист. Думаю, материал будет в первую очередь полезен тестировщикам и разработчикам 1С без бухгалтерского бэкграунда.

В прошлой статье я рассказывал, как устроено ядро нашего поиска: триграммы, crc32, словарь болей и два сита. В конце был короткий раздел «А где же нейросеть?», и он заслуживает отдельного разговора. Сегодня про то, как модель встроена сверху и почему мы с самого начала исходили из того, что она когда-нибудь подведёт.

Коротко о контексте. Мы делаем поиск для сайтов, которому человек пишет своими словами: «нужно вырыть траншею под кабель на даче», «подарок папе, он рыбачит». Без модели поиск работает на словаре и векторах. С моделью он начинает понимать, чего человек хочет, задаёт уточняющий вопрос и объясняет, почему предложил именно этот вариант.

/

Мы уже научились писать код с помощью AI. Но гораздо интереснее другое - как именно мы встроили AI разработку в свою работу. Я попробовал вспомнить все свои наблюдения и составил небольшую небольшую классификацию - от Воина до Некроманта. Надеюсь этот опрос вас немного порадует.

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

Я проектирую интеграции 1С с внешними системами: сайтами, CRM, своими программами заказчиков. Ниже — как я бы устроил загрузку заказов с сайта в 1С, если сайт сделан на Tilda, InSales или написан с нуля.

Покупатель пишет в чат магазина «подарок брату, ему 30, любит настолки, до $70». Помощник спрашивает, когда у брата день рождения. Покупатель отвечает, что в пятницу. До пятницы 5 рабочих дней, а по правилам магазина в этом случае на заказ дается скидка 20%. Поэтому в $70 влезли три подарка на $83.99, со скидкой вышло $67.19.

Отвечает покупателю qwen 9B, а сумму, скидку и корзину считает обычный код. Исходники с прогонами лежат в опенсорсе.

8 сентября Ozon отключил метод финансовых операций — через два месяца после анонсированной даты, без сигнала в самом API. Синк это заметил сразу, я — через две недели. Разбираю, чем заменять, где в новом API яма на 1,2 % и почему зелёный мониторинг ничего не значит.

Разбираем интеграцию интернет-магазина с МойСкладом на собственном движке, Next.js и PostgreSQL, после переезда с InSales. Если ваш магазин живёт в связке с МойСкладом и вы собираетесь уходить с платформы, эти места стоит проверить до запуска. У нас они всплыли на живых заказах, и два самых неприятных нашли сотрудники заказчика, а не наши тесты.

Перенос каталога, заказов и адресов с InSales здесь не разбираем, это отдельная тема. Всё ниже про то, что начинается после: остатки, резервы, статусы и деньги в двух системах, которые должны показывать одно и то же.

Рассказываем о кейсе внедрения компьютерного зрения в ресторане быстрого питания. Ценность кейса для бизнеса: запись с камеры длиной в 24 часа превращается в 30-секундный эпизод, который проверяющий может разобрать за минуту.

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

Из‑за этого разрыва возникает масса неприятностей: недостачи, жалобы покупателей на забытые блюда и споры о реальном времени обслуживания. Получается, что бизнес QSR (Quick Service Restaurants) становится не таким уж быстрым и гостеприимным, как должен быть.

Для нашего клиента из QSR мы собрали систему, которая связывает чеки с видеопотоком и нарезает для проверяющего готовые эпизоды с ошибками. 

По причине NDA, все фотографии и схемы в статье созданы искусственно и служат только примерами: это не съёмка ресторана заказчика и не снимки рабочего интерфейса. Названия блюд, номера заказов и время на иллюстрациях условные. Числовые результаты испытаний взяты из материалов проекта.

Меня зовут Павел Седаков, я директор и сооснователь «Оджетто». 18 лет наша компания занимается eCommerce, и все эти годы мы работаем прицельно с энтерпрайз-сегментом. В этой статье я расскажу, почему проекты идут не по плану и как Composable Commerce может это поменять. Заодно покажу, как это выглядит в реальной сборке: что за платформа появилась у нас и почему именно такая.

За последние десять лет в электронной коммерции произошло изменение, которое легко не заметить, если смотреть только на обороты рынка. Уменьшилась сама единица взаимодействия. Раньше онлайн‑покупка была событием: человек собирал корзину, делал относительно крупный заказ и некоторое время ждал следующей покупки. Сегодня заказать одну упаковку кофе, зарядный кабель или продукты на ужин — обычное повседневное действие. Коммерция стала состоять из гораздо большего количества гораздо меньших транзакций.

Особенно хорошо это видно на развитии доставки. Несколько дней ожидания сначала сменились доставкой «завтра», затем — «сегодня», появились часовые интервалы и доставка продуктов за 15–30 минут. Вместо большой закупки раз в неделю возникает множество небольших покупок по мере появления потребности. В eGrocery этот эффект уже хорошо виден: покупатели заказывают чаще и меньшими корзинами.

Для ИТ это принципиальное изменение. Системы обрабатывают не рубли оборота. Они обрабатывают заказы, строки заказа, резервы, остатки, статусы, этикетки, отмены, возвраты, уведомления и обращения к API. Продажа на 10 000 рублей одним заказом и десять продаж по 1000 рублей дают одинаковый оборот, но совершенно разную нагрузку на инфраструктуру. На каждый рубль продаж постепенно приходится всё больше отдельных действий, а значит повышаются требования к архитектуре и производительности систем.

Итог по кабинету сходится с отчётом Wildberries до копейки, а прибыль по артикулам посчитана неверно. Разбираю, почему совпадение «сверху» ничего не доказывает, как устроена сверка двумя независимыми источниками, какие инварианты ловят ошибки по товарам, и где мой движок ошибался: чужая колонка, потерянный знак, файл, который врёт о своём размере.

Всякий разработчик-авантюрист, развивающий какой бы то ни было проект, и при этом неважно, в какой конкретно сфере, будь то создание ПО, видеоигры или интернет-сервиса, сталкивается рано или поздно с ситуацией, когда индивидуальные ресурсы истощаются всё заметнее и заметнее, а кода становится всё больше и больше. Ведь расширение проекта – это что такое? Прежде всего: добавление новых функций, внедрение таковых в имеющиеся процессы при необходимости, улучшение пользовательского интерфейса (всё-таки всё делается исключительно ради положительного пользовательского опыта, не так ли?), в т.ч. добавление вызова данных функций в уже сложившийся интерфейс.

Проблема понятна: человеческий мозг – штука крайне эффективная, но мышление как процесс достаточно энергозатратен. Мозг может истощаться, требует кислорода и других питательных веществ, отдыха, а задача – т.е. расширение имеющего проекта с учётом его и без того переходящего за все грани масштаба, – наоборот, требует абсолютной концентрации и понимания, где какая функция лежит и за что ответственна в каждом отдельном процессе, вплоть до нюансов. В противном же случае код либо превратится в нечитаемую кашу, которую не разобрать уже ни тебе, ни другим программистом даже при желании, а в случае бага все твои наработки так или иначе придётся перебирать и переделывать. Гораздо проще изначально сделать нечто, не требующее... скажем, капитального ремонта и генеральной уборки в коде одновременно.

И здесь происходит развилка на две тропы: продолжать проект, но масштабировать его уже не только за счёт лишь собственных интеллектуальных средств, неминуемо начав привлекать дополнительную помощь извне, либо же пустить проект на самотёк – и захотят доблестные отдельные разработчики-энтузиасты продолжать, так и продолжат уже в своём режиме и в своих целях.

Привет, Хабр! Я Влад Силантьев — основатель digital‑агентства Silantev Studio. Мы много работаем с платным трафиком и постоянно ищем способы получать больше заявок без увеличения рекламного бюджета.

Недавно решили протестировать для этого ИИ‑квалификатор на сайте. Первые результаты оказались интересными: +33% квалифицированных лидов и около 300.000 ₽ дополнительной выручки за первые две недели.

В этом кейсе расскажу, как проводили тест, что именно делал ИИ и за счёт чего удалось получить такой прирост.

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