Что у CartSome
под капотом.

Делают люди,
которые строят банки.

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

• Сначала правильно, потом быстроДеньги и остатки записывает только один сервис — shop-core. Платежи проверяются на сервере, а не принимаются на веру от браузера, и браузер считает суммы в целых центах.
• Всё оставляет следКаждая выдача или отзыв доступа записывается в той же транзакции, что и само действие, а каждое действие оператора — в журнал платформы.
• Скучно — и это нарочноPostgreSQL, Java, чистый SQL и Terraform: инструменты, которые никуда не денутся и через десять лет, и никакого хитроумного слоя, который придётся отлаживать в 3 часа ночи.
• Измеряем, а не гадаемКаждое изменение в том, как витрина читает данные, до релиза проходит бенчмарк на каталоге из 500 000 товаров. Догадка — это то, с чего бенчмарк начинается, а не то, чем он заканчивается.

Быстро. И проверки не дают замедлиться

• Рендер на сервере, кэш на краю сетиСтраницы приходят готовым HTML на языке покупателя, а shop-core держит списки и страницы товаров прогретыми в Valkey.
• Бюджет в байтах прямо в CIТочка входа витрины, её оболочка и каждый чанк маршрута при каждом изменении укладываются в бюджет, а бюджет может только уменьшаться. Каждый язык лежит в отдельном чанке, так что покупатель скачивает только один.
• Проверка скорости перед релизомОна собирает main и изменение бок о бок и бракует страницу, которая стала тяжелее или медленнее в Lighthouse — по загрузке, смещению макета или времени блокировки.
• Проверка худшего случаяВсе опции темы на максимум, все типы секций разом — и магазин всё равно не имеет права тормозить. Темы — это CSS-переменные, поэтому тема не добавляет ни строчки JavaScript.
• Лёгкие картинкиКаждое изображение товара пережимается в варианты AVIF, а статические файлы отдаются заранее сжатыми brotli.

Две половины.
Жёсткая граница.

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

• shop-core — ячейка, на Java 25 и Spring BootЕдинственный, кто пишет данные магазинов в PostgreSQL, Valkey и S3. Через него проходит каждое изменение в админке, каждый импорт, платёж и фоновая задача магазина. Он недоступен из публичного интернета, сам проверяет каждый платёжный вебхук и каждую подпись и открывает запечатанные секреты магазинов.
• platform-core — управляющий контурТа же кодовая база, собранная как второе приложение со своим образом: бэкенд консоли, биллинг, организации и подключение новых магазинов, собственная почта платформы и фоновые задачи управляющего контура. Его логин в базе данных не дотягивается ни до одной схемы магазина, и миграций он не запускает.
• API ячейки между нимиДва ядра общаются через две внутренние двери, по одной на каждое направление, и у каждой свой секрет. Каждая дверь хранит только SHA-256 секрета, который принимает, так что ни одно ядро не держит ничего, что открыло бы его собственную дверь. Ни один запрос покупателя не ждёт ответа от управляющего контура.
• shop web — TanStack Start, React, рендер на сервереРендерит каждую витрину на языке покупателя, админку магазина, admin MCP и дверь Trade API. Читает Valkey, а PostgreSQL — под собственным логином магазина для чтения, и не пишет ничего, кроме сессий входа; любая другая запись уходит в shop-core.
• Консоль — своё приложениеОтдельное приложение и образ для admin.cartsome.com, MCP оператора, форм cartsome.com и вебхука Stripe. У неё нет драйвера базы данных и нет секретов магазинов, а разговаривает она только с platform-core.
• Край сети — CloudFront и WAFСтраницы кэшируются на краю сети, изображения идут прямо из S3. Балансировщик нагрузки за ним принимает запросы только от CloudFront и отправляет каждый адрес в приложение, которое его обслуживает, а шквал запросов, нацеленный на один магазин, останавливается уже на краю сети — отдельно для каждого адреса магазина.
• Aurora PostgreSQL 18, чистый SQLНикакой ORM, нигде. Полнотекстовый поиск тоже работает в PostgreSQL — на языке покупателя и снисходительно к опечаткам. Никакого отдельного поискового кластера, за которым нужно присматривать.
• Valkey и S3В Valkey лежат страницы, которые shop-core прогревает заранее, до прихода покупателей. В S3 — изображения товаров (варианты AVIF), шрифты тем, товарный фид на каждом языке и экспорт магазина, который уходит.
• Контейнеры на ARMВсе четыре сервиса работают на ECS Fargate, на Graviton, каждый из своего образа, а воркеры изображений — на Lambda, тоже на ARM. Всё описано в Terraform, и ничего не собрано кликами в консоли.

Картинки — через очередь

Переезжающий магазин привозит тысячи картинок, и новый магазин не должен тормозить ничьё оформление заказа, пока их пережимают. Поэтому shop-core сам их не пережимает.

• Ядро только ставит в очередьShop-core кладёт каждую задачу по картинке в SQS и записывает ответы по мере их возвращения — пачками, одной транзакцией на магазин. У воркеров вообще нет логина в базу данных.
• Справедливая очередь для каждого магазинаКаждый магазин — отдельная группа в справедливых очередях SQS: интерактивная полоса для картинки, которую загружает администратор, массовая полоса для импорта и лимит на магазин в каждой. Большой импорт одного магазина никогда не встанет перед единственным фото другого.
• Тот же кодировщик, больше рукВоркеры на Lambda выполняют то же кодирование libvips, что и ядро, поэтому картинка выглядит одинаково, кто бы её ни пережал. Скачивание идёт в своём темпе для каждого исходного хоста, чтобы не завалить сервер поставщика.
• Пережато раз — годится вездеКартинку узнают по хешу её байтов. Если какой-то магазин в ячейке уже пережал тот же исходник, воркеры берут готовые файлы, а не кодируют заново.
• Готово к наплывуПарк воркеров разрастается, когда переезжает сразу много магазинов, и ничего не стоит в простое, а админка показывает каждый прогон вживую: готово, переиспользовано, с ошибкой, в ожидании и место в очереди.

Вся система —
на одной странице.

Кто с кем разговаривает — от телефона покупателя до самых дисков. Сплошные линии — запросы и записи, пунктирные — только чтение.

Карта словами

1. Кто стучится. Покупатели (люди и ИИ-агенты для покупок), системы других компаний через Trade API, ИИ-клиент владельца магазина, администраторы магазинов и операторы CartSome — все заходят через край сети.
2. Край сети. CloudFront кэширует страницы, отдаёт изображения прямо из S3, хранит сертификаты для каждого адреса *.cartsome.com и собственного домена каждого магазина, а его WAF ограничивает каждый адрес магазина по отдельности.
3. Балансировщик нагрузки принимает запросы только от CloudFront. Адрес каждого магазина он отправляет в shop web, а admin.cartsome.com и API cartsome.com — в консоль.
4. Shop web рендерит витрину, админку и admin MCP, публичный MCP для ИИ-агентов покупателей, который каждый магазин включает сам, и дверь Trade API. Он читает PostgreSQL и Valkey и передаёт каждую запись в shop-core.
5. Консоль обслуживает admin.cartsome.com, MCP оператора, формы cartsome.com и вебхук Stripe и разговаривает только с platform-core.
6. Shop-core — это ячейка: единственный, кто пишет данные магазинов в PostgreSQL, Valkey и S3. Он проверяет вебхуки, открывает хранилище магазинов и ставит работу с картинками в очереди.
7. Platform-core — это управляющий контур: организации, подключение новых магазинов, биллинг, почта платформы и её фоновые задачи, под собственным логином в базе данных. До ячейки он дотягивается только через API ячейки, по одному секрету в каждую сторону.
8. Воркеры изображений берут задачи из справедливых очередей SQS, по группе на магазин, кодируют картинки на Lambda и пишут файлы в S3.
9. Данные: Aurora PostgreSQL со схемой платформы и отдельной схемой на каждый магазин, Valkey с тёплыми страницами каждого магазина и S3 для изображений, шрифтов, фидов и экспортов.
10. Ячейка 1 сегодня держит всё это в Стокгольме. Ячейка 2 — тот же стек ещё раз; её откроют, когда она понадобится, в том регионе AWS, который нужен её магазинам.

Жизнь одного запроса

Ваш магазин.
Ваша схема.

Много магазинов, один кластер базы данных и ноль общих таблиц магазинов. Каждый магазин получает собственную схему PostgreSQL, а соседей к нему не пускает сама база данных.

• Схема и два логинаМагазин n живёт в собственной схеме, построенной по единому эталону. Shop web входит под логином магазина для чтения, shop-core — под логином для записи, и ни один из них не дотягивается до другого магазина. А логин platform-core не дотягивается ни до одного магазина вообще.
• Нет колонки магазина, о которой можно забытьВнутри схемы таблицы сохраняют свою форму: никакого id магазина в каждой строке и никакого фильтра, который запрос мог бы пропустить. Внешние ключи никогда не выходят за пределы схемы.
• Запросы никогда не называют схемуМагазин определяется логином, под которым входит соединение, а соединение обслуживает один магазин всю свою жизнь. Статическая проверка валит сборку, если в запросе встретится имя схемы.
• Пулы, которые открываются по требованиюКаждый магазин получает собственные небольшие пулы соединений: они открываются при его первом запросе и закрываются, когда он затихает, поэтому бюджет соединений базы данных ограничивает, сколько магазинов заняты одновременно, а не сколько их всего. У каждого магазина есть и свой бюджет запросов, и магазин, который его превысил, просят повторить попытку — только его одного.
• Кэш и ссылки знают свой магазинКлюч каждой записи в кэше включает магазин. Сессии, ссылки на заказы и подарочные карты, токены отписки подписываются собственными ключами магазина, поэтому ссылку одного магазина другой отклонит.
• Тесты на утечки, которые дёргают все двериОни создают строку в каждой таблице магазина для двух магазинов и читают каждую от имени другого — через соединения и shop-core, и shop web, — а затем вызывают каждый эндпоинт ядра, принимающий id. Запускаются при каждом изменении.

Ячейки, а не
один большой ком.

Мы масштабируемся ячейками. Ячейка — это полный стек: свой кластер Aurora, свои shop-core и shop web, схемы её магазинов, свои очереди и воркеры изображений. Когда одна заполняется, мы открываем следующую. Управляющий контур стоит отдельно и говорит с ячейкой только через API ячейки. Растёт платформа, а не каждая отдельная ячейка.

Что значит «заполнена»

Ячейка перестаёт принимать новые магазины, как только любой из этих показателей упирается в свой предел. При 80 процентах любого предела мы планируем следующую ячейку; страница «Ячейка» в консоли показывает текущее заполнение и называет сигнал.

• Крупному магазину — своя ячейкаМагазин, который перерос общую ячейку, получает ячейку в единоличное пользование. Autotools остаётся в ячейке 1.
• Переносимость заложена в устройствоВсё, чем владеет магазин, названо по магазину: его схема со своими ключами и последовательностями, его строки в хранилище, запечатанные под его организацией, его ключи кэша, его файлы фидов. Ничто не привязывает его к ячейке, в которой он родился.
• Если честноПеренести магазин между ячейками пока нельзя одной кнопкой. Эта возможность появится вместе со второй ячейкой, а мешать ей нечему: общего на этом пути нет ничего.

Закрыто по умолчанию.
Скучно — нарочно.

Самое интересное в магазине — это товары. А вот скучная часть, ровно в том объёме, который мы готовы опубликовать.

• Изоляция в базе данныхОтдельные схемы и логины для каждого магазина; изоляцию обеспечивают привилегии PostgreSQL, а не код, который должен не забыть про фильтр. У управляющего контура свой логин, а у логина shop-core нет никаких прав на таблицы управляющего контура.
• Запечатанное хранилище для каждой организацииКлючи платёжных систем, перевозчиков и почты лежат в хранилище, каждый зашифрован AES-256-GCM свежим ключом данных от ключа KMS, которым могут пользоваться только два ядра, и привязан к своей организации и имени. Скопированная строка не откроется нигде. Секреты никогда не живут в коде.
• У каждого ядра своя половина ключаShop-core открывает секреты магазинов, а platform-core — собственные секреты платформы, например её ключи Stripe и бухгалтерии. Политика ключа не пускает ни одно из ядер в чужую половину.
• Две двери, два секретаЯдра вызывают друг друга с отдельным секретом на каждое направление, и каждая дверь хранит только SHA-256 секрета, который принимает, так что ни одно ядро не держит того, что открывает его собственную дверь.
• Ключи доступа для тех, кто управляет платформойОператоры входят по ключам доступа (passkey) и каждое изменение платформы заново подтверждают ключом. Выдать доступ через инструмент нельзя: ни токен, ни ИИ не может добавить оператора.
• Записи ИИ, которые видно и можно откатитьМассовые и обращённые вовне записи сначала выполняются как предпросмотр и применяются по подтверждению, привязанному к тому, что вы видели; если магазин за это время изменился, запись отклоняется. А каждая выполненная запись сразу сообщает, как её отменить.
• Токены с минимальной связкой ключейКаждый токен или подключение admin MCP несёт набор прав и видит только те инструменты, которые эти права разрешают. Для возвратов, секретов и администраторов нужно по отдельному праву.
• Покупатели остаются за пределами чатаОтвет инструмента уходит к провайдеру ИИ, поэтому в ответах нет имён, электронной почты, телефонов, адресов и налоговых номеров покупателей. Немногие оговорённые исключения, например текст комментария к заказу, перечислены в правилах.
• След от каждого действия оператораКаждое изменение, которое вносит оператор, и каждое чтение данных сразу нескольких магазинов попадает в журнал аудита платформы.

314 действий.
Ноль форм.

Admin MCP даёт ИИ-клиенту 314 действий в магазине, и каждое из них есть и в веб-админке. Подключите Claude, ChatGPT, Cursor, Gemini или любой другой MCP-клиент — через вход в аккаунт или вставленный токен. Переключатель выключен, пока его не включит администратор.

Модель безопасности

Права определяют поверхность

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

Примеры

↑ Примеры запросов · инструменты настоящие

Магазин — магазину.
Без посредников.

Каждый магазин может открыть своим бизнес-клиентам Trade API: нейтральный версионируемый HTTP API, через который их собственные системы читают каталог по их ценам и оформляют заказы. А любой магазин может покупать у любого другого магазина, который говорит на этом протоколе, — как у ещё одного поставщика.

• Протокол, а не брендОбнаружение по адресу /.well-known/trade-api, сам API под /trade/v1, документ OpenAPI 3.1 — и нигде в нём нет названия какой-либо платформы. Продавец, который говорит на этом протоколе, — просто продавец, на чём бы он ни работал.
• Ключи делает сам клиентАдминистратор открывает компании аккаунт бизнес-клиента, закрепляет ценовой уровень, по которому она покупает, и разрешает ей API. Клиент сам выпускает и отзывает свои ключи на странице аккаунта; магазин хранит только хеш, и ни один администратор никогда не видит ключа.
• Их цены, настоящие остаткиЦена каждого товара — ровно та, которую витрина показала бы этому клиенту после входа, а рядом — доступный к продаже остаток витрины, с верхним пределом.
• Заказы, которые не задвоятсяКаждый заказ несёт ключ идемпотентности: тот же ключ и то же тело возвращают первый заказ, а другое тело отклоняется. Дальше это обычный заказ магазина: счёт, сборка и отправка идут привычным путём.
• Покупайте у любого магазинаУниверсальный коннектор торгового поставщика делает продавца ещё одним поставщиком: его остатки и цены читаются по расписанию, заказы уходят с ключом идемпотентности, а подтверждения и отгрузки считываются обратно. Он обращается к публичному адресу продавца, как любой посторонний, и никогда не срезает путь внутри ячейки.
• Короткий поводокЛимиты на запросы и заказы для каждого ключа, потолок неоплаченных заказов, а ключ одного магазина для другого — посторонний. Каждое действие с аккаунтом, доступом и ключом попадает в журнал аудита магазина, а клиент узнаёт о каждом новом ключе.
• Если честноВебхуков пока нет: покупатель сам опрашивает, что изменилось. Пока заказы оплачиваются по счёту на предоплату; отсрочка платежа появится позже.

Магазин за минуты.
Откры­вайтесь, когда готовы.

Ни установщика, ни выбора сервера. Мы добавляем вашу организацию в консоли платформы, магазин собирается сам, а дальше — ваш ход.

Языки — переключателем. Новый магазин стартует с основным языком и эстонским. Включайте любой из 8, когда для него готовы переводы, — в разделе «Настройки › Языки» или через manage_languages. У товара один и тот же адрес на всех языках.

Перевозите магазин.
Google едет с вами.

Autotools переехал с Shopify и сегодня держит на CartSome 25 000+ товаров. Инструменты, которые для этого понадобились, — ровно те, что получаете вы.

• Товары: конвертирует ИИ, проверяет человекВаш ИИ-клиент читает формат импорта, словарь магазина и данные поставщика и пишет файл, который проходит собственный валидатор магазина. Вместо того чтобы выдумывать категорию, он останавливается и называет каждый пробел. Человек просматривает, что совпало и что новое, и применяется только тот импорт, который он назвал, — подтверждением прочитанного им предпросмотра.
• Скрыто, пока вы не скажете «показать»Новые товары приходят скрытыми. Один вызов с предпросмотром показывает целую линейку — до 5 000 товаров.
• Старые адреса — с переадресациейПередайте экспорт переадресаций из Shopify или любой список из двух колонок. Каждая строка сопоставляется так же, как витрина ищет адреса, цепочки сворачиваются в одну постоянную переадресацию, а каждая цель сверяется с собственными страницами магазина.
• Набор для ухода с ShopifyНаши инструменты переключения делают снимок старого сайта, строят карту «старый адрес → новый» с отчётом о том, что осталось, а затем проверяют на новом магазине каждую строку, требуя ровно одну переадресацию 301 на работающую страницу. Так Autotools перенёс 12 598 старых адресов.
• Согласия на рассылку — переносятся один разСписок рассылки переходит в журнал согласий магазина с ответом каждого человека в том виде, в каком он был дан. При переносе ничего не отправляется.
• Что остаётсяПрошлые заказы остаются на старой платформе. Сохраните её экспорт для бухгалтерии.

Пример переезда

↑ Пример · темп задаёт размер вашего каталога