Co CartSome
ma pod maską.

Zbudowany przez ludzi,
którzy budują banki.

Szybkość mamy w DNA. Tak samo jak dbałość o to, żeby nie zgubić Twoich pieniędzy. CartSome tworzą ludzie, którzy budują banki, i widać to w mało efektownych miejscach: jedna usługa zapisująca pieniądze i stany magazynowe, ślad po każdej czynności, podgląd przed każdym dużym zapisem i liczba za każdą deklaracją.

• Najpierw poprawnie, potem szybkoPieniądze i stany magazynowe zapisuje tylko jedna usługa: shop-core. Płatności weryfikuje serwer – przeglądarce nigdy nie wierzymy na słowo – a sama przeglądarka liczy w pełnych centach.
• Wszystko zostawia śladKażde nadanie lub odebranie dostępu jest zapisywane w tej samej transakcji co sama czynność, a każda czynność operatora – w ścieżce audytu platformy.
• Nudne z premedytacjąPostgreSQL, Java, czysty SQL i Terraform: narzędzia, które za dziesięć lat wciąż tu będą, bez żadnej sprytnej warstwy do debugowania o 3 w nocy.
• Mierzone, nie zgadywaneKażda zmiana w tym, jak witryna czyta dane, przechodzi benchmark na katalogu 500 000 produktów, zanim trafi na produkcję. Przeczucie to miejsce, w którym benchmark się zaczyna, a nie kończy.

Szybko – a bramki pilnują, żeby tak zostało

• Renderowane na serwerze, buforowane na krawędziStrony przychodzą jako HTML w języku kupującego, a shop-core trzyma listy i strony produktów rozgrzane w Valkey.
• Budżet bajtów w CIPunkt wejścia witryny, jej powłoka i paczka każdej trasy mieszczą się w budżecie sprawdzanym przy każdej zmianie, a budżet może tylko maleć. Każdy język ma własną paczkę, więc kupujący pobiera tylko jedną.
• Bramka szybkości przed wydaniemBuduje main i zmianę obok siebie i oblewa stronę, która zrobiła się cięższa albo wolniejsza w Lighthouse – w ładowaniu, przesunięciach układu lub czasie blokowania.
• Bramka najgorszego przypadkuKażda opcja motywu w najcięższym wariancie, wszystkie typy sekcji naraz – a sklep i tak nie ma prawa zwolnić. Motywy to zmienne CSS, więc motyw nie dokłada ani bajta JavaScriptu.
• Lekkie zdjęciaKażde zdjęcie produktu jest skalowane do wariantów AVIF, a pliki statyczne wychodzą wstępnie skompresowane brotli.

Dwie połowy.
Twarda granica.

Większość platform dorabia się osobnej usługi na każdą funkcję. My przecięliśmy całość dokładnie w jednym miejscu: sklepy po jednej stronie, platforma po drugiej. Każda połowa ma własną aplikację, własne core, własny login do bazy danych i własną połowę klucza. A stara zasada obowiązuje po obu stronach: pisze tylko core.

• shop-core – komórka, Java 25 i Spring BootJedyna usługa, która zapisuje dane sklepów do PostgreSQL, Valkey i S3. Przechodzi przez nią każda zmiana w panelu, każdy import, każda płatność i każde zadanie sklepu. Nie jest wystawiona do publicznego internetu, sama weryfikuje każdy webhook płatności i każdy podpis i otwiera zapieczętowane sekrety sklepów.
• platform-core – płaszczyzna sterowaniaTen sam kod źródłowy, zbudowany jako druga aplikacja z własnym obrazem: zaplecze konsoli, rozliczenia, organizacje i uruchamianie sklepów, własna poczta platformy i zadania płaszczyzny sterowania. Jej login do bazy danych nie sięga do schematu żadnego sklepu, a ona sama nie uruchamia żadnych migracji.
• Między nimi: API komórki (Cell API)Obie usługi core rozmawiają przez dwoje wewnętrznych drzwi, po jednych w każdą stronę, każde z własnym sekretem. Każde drzwi trzymają tylko SHA-256 sekretu, który przyjmują, więc żadna z usług core nie ma niczego, co otwiera jej własne drzwi. Żadne żądanie kupującego nie czeka na płaszczyznę sterowania.
• shop web – TanStack Start, React, renderowanie na serwerzeRenderuje każdą witrynę w języku kupującego, panel sklepu, admin MCP i wejście do Trade API. Czyta Valkey oraz PostgreSQL – przez własny login sklepu do odczytu – a zapisuje wyłącznie sesje logowania; każdy inny zapis trafia do shop-core.
• Konsola – osobna aplikacjaOddzielna aplikacja z własnym obrazem dla admin.cartsome.com, MCP operatora, formularzy cartsome.com i webhooka Stripe. Nie ma sterownika bazy danych, nie trzyma sekretów żadnego sklepu i rozmawia wyłącznie z platform-core.
• Krawędź – CloudFront i WAFStrony są buforowane na krawędzi sieci, a obrazy idą prosto z S3. Balanser obciążenia za nią odpowiada wyłącznie CloudFront, kieruje każdy adres do aplikacji, która go obsługuje, a zalew ruchu wymierzony w jeden sklep zatrzymuje się już na krawędzi, osobno dla każdego adresu sklepu.
• Aurora PostgreSQL 18, czysty SQLŻadnego ORM-a, nigdzie. Wyszukiwanie pełnotekstowe też działa w PostgreSQL – w języku kupującego i wyrozumiale dla literówek. Żadnego osobnego klastra wyszukiwania do niańczenia.
• Valkey i S3Valkey trzyma strony, które shop-core rozgrzewa, zanim przyjdą kupujący. S3 trzyma zdjęcia produktów (warianty AVIF), fonty motywów, feed produktowy dla każdego języka i eksport sklepu, który od nas odchodzi.
• Kontenery na ARMCztery usługi działają na ECS Fargate, na procesorach Graviton, każda z własnego obrazu, a workery zdjęć działają na Lambda, również na ARM. Całość opisuje Terraform i nic nie jest wyklikane w konsoli.

Zdjęcia w kolejce

Sklep, który się do nas wprowadza, przywozi tysiące zdjęć, a nowy sklep nie powinien nikomu spowalniać kasy, kiedy są obrabiane. Dlatego shop-core sam ich nie obrabia.

• Core tylko zlecaShop-core wrzuca każde zadanie dla zdjęcia do SQS i zapisuje odpowiedzi, gdy wracają – partiami, w jednej transakcji na sklep. Workery nie mają żadnego loginu do bazy danych.
• Sprawiedliwa kolejka dla każdego sklepuKażdy sklep to osobna grupa w sprawiedliwych kolejkach SQS (fair queues), z pasem interaktywnym dla zdjęcia, które wgrywa administrator, i pasem masowym dla importów, a w każdym z nich obowiązuje limit na sklep. Duży import jednego sklepu nigdy nie stanie w kolejce przed jednym zdjęciem innego.
• Ten sam koder, więcej rąkWorkery na Lambda uruchamiają to samo kodowanie libvips co core, więc zdjęcie wygląda tak samo, bez względu na to, kto je obrobił. Pobieranie jest dawkowane osobno dla każdego hosta źródłowego, żeby nie zalać serwera dostawcy.
• Obrobione raz, użyte wszędzieZdjęcie rozpoznajemy po haszu jego bajtów. Jeśli którykolwiek sklep w komórce obrobił już to samo źródło, workery biorą jego pliki, zamiast kodować je od nowa.
• Gotowe na najazdFlota rośnie, gdy wiele sklepów wprowadza się naraz, a bezczynna nic nie kosztuje. Panel pokazuje każdy przebieg na żywo: gotowe, użyte ponownie, nieudane, czekające i jego miejsce w kolejce.

Całość
na jednej stronie.

Kto z kim rozmawia, od telefonu kupującego aż po dyski. Linie ciągłe niosą żądania i zapisy; przerywane tylko czytają.

Mapa słowami

1. Kto puka. Kupujący (ludzie i agenci zakupowi AI), systemy innych firm przez Trade API, asystent AI właściciela sklepu, administratorzy sklepu i operatorzy CartSome – wszyscy wchodzą przez krawędź sieci.
2. Krawędź. CloudFront buforuje strony, serwuje obrazy prosto z S3, trzyma certyfikaty dla każdego adresu *.cartsome.com i własnej domeny każdego sklepu, a jego WAF limituje każdy adres sklepu osobno.
3. Balanser obciążenia odpowiada wyłącznie CloudFront. Adres każdego sklepu kieruje do shop web, a admin.cartsome.com i API cartsome.com – do konsoli.
4. Shop web renderuje witrynę, panel administracyjny i admin MCP, publiczne MCP dla agentów zakupowych, które każdy sklep włącza sam, oraz wejście do Trade API. Czyta PostgreSQL i Valkey, a każdy zapis przekazuje do shop-core.
5. Konsola obsługuje admin.cartsome.com, MCP operatora, formularze cartsome.com i webhook Stripe, a rozmawia wyłącznie z platform-core.
6. Shop-core to komórka: jedyna usługa, która zapisuje dane sklepów do PostgreSQL, Valkey i S3. Weryfikuje webhooki, otwiera sejf sklepów i wrzuca obróbkę zdjęć do kolejek.
7. Platform-core to płaszczyzna sterowania: organizacje, uruchamianie sklepów, rozliczenia, poczta platformy i jej zadania, na własnym loginie do bazy danych. Do komórki sięga wyłącznie przez API komórki, z jednym sekretem w każdą stronę.
8. Workery zdjęć pobierają zadania ze sprawiedliwych kolejek SQS, z osobną grupą dla każdego sklepu, kodują zdjęcia na Lambda i zapisują pliki do S3.
9. Dane: Aurora PostgreSQL ze schematem platformy i osobnym schematem dla każdego sklepu, Valkey z rozgrzanymi stronami każdego sklepu oraz S3 na obrazy, fonty, feedy i eksporty.
10. Komórka 1 obsługuje dziś to wszystko w Sztokholmie. Komórka 2 to ten sam stos jeszcze raz, otwierany, gdy będzie potrzebny, w tym regionie AWS, którego potrzebują jej sklepy.

Życie jednego żądania

Twój sklep.
Twój schemat.

Wiele sklepów, jeden klaster bazy danych, zero wspólnych tabel sklepowych. Każdy sklep dostaje własny schemat PostgreSQL, a sąsiadów trzyma z daleka sama baza danych.

• Schemat i dwa loginySklep n mieszka we własnym schemacie, zbudowanym z jednego wzorca. Shop web loguje się loginem sklepu do odczytu, shop-core – loginem do zapisu, i żaden z nich nie sięga do innego sklepu. Login platform-core nie sięga do żadnego sklepu.
• Nie ma kolumny sklepu, o której można zapomniećTabele zachowują swój kształt wewnątrz schematu: żadnego id sklepu w każdym wierszu, żadnego filtra, który zapytanie mogłoby pominąć. Klucze obce nigdy nie wychodzą poza schemat.
• Zapytania nigdy nie podają schematuO tym, który to sklep, decyduje login połączenia, a jedno połączenie obsługuje jeden sklep przez całe swoje życie. Statyczna kontrola przerywa budowanie, gdy w zapytaniu pojawi się nazwa schematu.
• Pule otwierane na żądanieKażdy sklep dostaje własne małe pule połączeń, otwierane przy jego pierwszym żądaniu i zamykane, gdy ruch ucichnie, więc budżet połączeń bazy danych ogranicza to, ile sklepów jest naraz zajętych, a nie to, ile ich w ogóle istnieje. Każdy sklep ma też własny budżet żądań, a sklep, który go przekroczy, słyszy „spróbuj ponownie” – i to tylko on.
• Cache i linki znają swój sklepKażdy wpis w cache ma w kluczu swój sklep. Sesje, linki do zamówień, linki do kart podarunkowych i tokeny wypisu są podpisane własnymi kluczami sklepu, więc link jednego sklepu zostanie odrzucony w innym.
• Testy wycieków, które sprawdzają każde drzwiZakładają wiersz w każdej tabeli sklepowej dla dwóch sklepów i czytają każdy z nich jako ten drugi, na połączeniach shop-core i shop web, a potem wywołują każdy endpoint core, który przyjmuje id. Uruchamiają się przy każdej zmianie.

Komórki, a nie
jeden wielki kloc.

Skalujemy się komórkami. Komórka to kompletny stos: własny klaster Aurora, własne shop-core i shop web, schematy jej sklepów, własne kolejki i workery zdjęć. Gdy jedna się zapełni, otwieramy kolejną. Płaszczyzna sterowania stoi z boku i rozmawia z komórką wyłącznie przez API komórki. Rośnie platforma – żadna pojedyncza komórka nie musi.

Co znaczy „pełna”

Komórka nie przyjmuje nowego sklepu, gdy którykolwiek z tych sygnałów osiągnie swój limit. Przy 80 procentach dowolnego limitu planujemy następną komórkę; strona Komórka w konsoli pokazuje bieżące zapełnienie i wskazuje sygnał.

• Duży sklep dostaje własną komórkęSklep, który wyrośnie ze wspólnej komórki, dostaje komórkę tylko dla siebie. Autotools zostaje w komórce 1.
• Przenośny z samej konstrukcjiWszystko, co należy do sklepu, nosi jego nazwę: schemat z własnymi kluczami i sekwencjami, wiersze w sejfie zapieczętowane w ramach jego organizacji, klucze cache, pliki feedów. Nic nie przywiązuje go do komórki, w której się urodził.
• Szczerze mówiącPrzeniesienie sklepu między komórkami to jeszcze nie jest jeden przycisk. Pojawi się razem z drugą komórką, a drogi nie blokuje nic współdzielonego.

Domyślnie zamknięte.
Nudne z premedytacją.

Najciekawszą częścią sklepu powinny być produkty. Oto ta nudna część, z takim poziomem szczegółów, jaki chętnie publikujemy.

• Izolacja w bazie danychSchematy i loginy na sklep, egzekwowane uprawnieniami PostgreSQL, a nie kodem, który musi pamiętać o filtrze. Płaszczyzna sterowania ma własny login, a login shop-core nie ma żadnych uprawnień do tabel płaszczyzny sterowania.
• Zapieczętowany sejf dla każdej organizacjiKlucze płatności, przewoźników i poczty leżą w sejfie, każdy zapieczętowany AES-256-GCM świeżym kluczem danych z klucza KMS, którego mogą używać tylko obie usługi core, i przypisany do swojej organizacji i nazwy. Skopiowany wiersz nigdzie się nie otworzy. Sekrety nigdy nie mieszkają w kodzie.
• Każda usługa core ma połowę kluczaShop-core otwiera sekrety sklepów, a platform-core – własne sekrety platformy, takie jak klucze do Stripe i księgowości. Polityka klucza nie da żadnej z nich połowy tej drugiej.
• Dwoje drzwi, dwa sekretyUsługi core wywołują się nawzajem z jednym sekretem na kierunek, a każde drzwi przechowują tylko SHA-256 sekretu, który przyjmują, więc żadna z usług nie trzyma tego, co otwiera jej własne drzwi.
• Klucze dostępu dla ludzi, którzy tym zarządzająOperatorzy logują się kluczami dostępu i potwierdzają każdą zmianę na platformie ponownym użyciem klucza. Nadawanie dostępu nigdy nie jest narzędziem: żaden token i żadne AI nie doda operatora.
• Zapisy AI, które widzisz i możesz cofnąćZapisy masowe i widoczne na zewnątrz najpierw idą jako podgląd, a wykonują się po potwierdzeniu powiązanym z tym, co zostało Ci pokazane; jeśli sklep w międzyczasie się zmienił, potwierdzenie zostaje odrzucone. A potem każdy zapis odpowiada przepisem na własne cofnięcie.
• Tokeny z najmniejszym pękiem kluczyKażdy token i każde połączenie admin MCP mają zakresy i widzą tylko narzędzia, na które te zakresy pozwalają. Zwroty, sekrety i administratorzy wymagają osobnego zakresu każdy.
• Klienci zostają poza czatemOdpowiedź narzędzia trafia do dostawcy AI, więc odpowiedzi pomijają imiona i nazwiska kupujących, e-maile, telefony, adresy i numery podatkowe. Nieliczne wyjątki, takie jak treść komentarza do zamówienia, są wymienione w zasadach.
• Ślad każdej czynności operatoraKażda zmiana wprowadzona przez operatora i każdy odczyt obejmujący wiele sklepów trafia do ścieżki audytu platformy.

314 operacji.
Zero formularzy.

Admin MCP daje asystentowi AI 314 operacji w sklepie, a każda z nich jest też w panelu administracyjnym. Podłącz Claude, ChatGPT, Cursor, Gemini albo dowolnego innego asystenta obsługującego MCP – przez logowanie lub wklejony token. Przełącznik jest wyłączony, dopóki administrator go nie włączy.

Model bezpieczeństwa

Zakresy wyznaczają powierzchnię

Token widzi tylko narzędzia ze swoich zakresów, więc wąski token to zarazem mała powierzchnia i mała władza. Tagi i menu to osobne zakresy, bo opublikowane menu od razu zmienia to, co widzą kupujący. Napisanie szkicu wpisu i jego publikacja to dwa różne zakresy. Nic, co może zrobić AI, nie zatwierdza księgowania – robi to człowiek w panelu administracyjnym.

Przykłady

↑ Przykładowe prośby · wymienione narzędzia są prawdziwe

Od sklepu do sklepu.
Bez pośrednika.

Każdy sklep może otworzyć dla swoich klientów biznesowych Trade API: neutralne, wersjonowane API HTTP, które ich własne systemy wywołują, żeby czytać katalog w ich cenach i składać zamówienia. A każdy sklep może kupować od każdego innego sklepu, który je obsługuje – jak od kolejnego dostawcy.

• Protokół, nie markaWykrywanie pod /.well-known/trade-api, API pod /trade/v1, dokument OpenAPI 3.1 i nigdzie w nim nazwy żadnej platformy. Sprzedawca, który je obsługuje, jest po prostu sprzedawcą, bez względu na to, na czym działa.
• Klucze tworzy klientAdministrator zatwierdza firmę jako konto hurtowe, przypina poziom cenowy, w którym kupuje, i zezwala na API. Klient sam generuje i unieważnia swoje klucze na stronie swojego konta; sklep trzyma tylko hasz, a żaden administrator nigdy nie widzi klucza.
• Ich ceny, prawdziwe stanyKażdy produkt ma dokładnie taką cenę, jaką witryna pokazuje temu klientowi po zalogowaniu, a obok stan dostępny do sprzedaży w witrynie, z górnym limitem.
• Zamówienia, które się nie zdublująKażde zamówienie niesie klucz idempotencji: ten sam klucz i ta sama treść zwracają pierwsze zamówienie, a inna treść zostaje odrzucona. Od tej chwili to zwykłe zamówienie sklepu – fakturowane, pakowane i wysyłane jak zawsze.
• Kupuj od dowolnego sklepuUniwersalny konektor dostawcy z Trade API robi ze sprzedawcy kolejnego dostawcę: jego stany i ceny są czytane według harmonogramu, zamówienia wychodzą z kluczem idempotencji, a potwierdzenia i dostawy są odczytywane z powrotem. Konektor wywołuje publiczny adres sprzedawcy jak każdy obcy – nigdy żadnym skrótem wewnątrz komórki.
• Krótka smyczLimity żądań i zamówień na klucz, górny limit nieopłaconych zamówień, a klucz jednego sklepu jest w innym obcym. Każda czynność dotycząca konta, dostępu i kluczy trafia do ścieżki audytu sklepu, a klient dowiaduje się o każdym nowym kluczu.
• Szczerze mówiącNa razie bez webhooków: kupujący sam odpytuje o zmiany. Zamówienia są na razie opłacane z góry, na fakturę proforma; zakupy z odroczonym terminem płatności przyjdą później.

Sklep w kilka minut.
Otwierasz, kiedy chcesz.

Nie ma instalatora ani serwera do wybrania. Dodajemy Twoją organizację w konsoli platformy, sklep buduje się sam, a dalej przejmujesz stery.

Języki na przełącznik. Nowy sklep startuje ze swoim głównym językiem i estońskim. Włącz dowolny z 8, gdy jego tłumaczenia będą gotowe – w sekcji Ustawienia › Języki albo przez manage_languages. Produkt ma ten sam adres w każdym języku.

Przenieś sklep.
Pozycje w Google zostają.

Autotools przeniósł się z Shopify i ma dziś w CartSome 25 000+ produktów. Narzędzia, których użył, to narzędzia, które dostajesz.

• Produkty konwertuje AI, a sprawdza człowiekTwój asystent AI czyta format importu, słownictwo sklepu i dane dostawcy, po czym pisze plik, który przechodzi przez własny walidator sklepu. Zatrzymuje się i nazywa każdą lukę, zamiast wymyślać kategorię. Człowiek przegląda, co się dopasowało, a co jest nowe, i wykonywany jest tylko ten import, który sam wskaże – przez potwierdzenie przeczytanego podglądu.
• Ukryte, dopóki nie powiesz „pokaż”Nowe produkty przychodzą ukryte. Jedno wywołanie z podglądem pokazuje całą serię, nawet do 5 000 produktów.
• Stare adresy przekierowanePrzekaż eksport przekierowań z Shopify albo dowolną listę w dwóch kolumnach. Każdy wiersz jest dopasowywany tak, jak witryna wyszukuje adresy, łańcuchy są składane w jedno stałe przekierowanie, a każdy cel jest sprawdzany na stronach samego sklepu.
• Zestaw do przejścia z ShopifyNasze narzędzia robią migawkę starej strony, budują mapę starych adresów na nowe wraz z raportem tego, co zostało, a potem odpytują nowy sklep o każdy wiersz, wymagając jednego przekierowania 301 na stronę, która odpowiada. Tak Autotools przeniósł 12 598 starych adresów.
• Zgody na newsletter przeniesione razLista marketingowa trafia do rejestru zgód sklepu z odpowiedzią każdej osoby dokładnie taką, jakiej udzieliła. Przy przenosinach nic nie zostaje wysłane.
• Co zostaje na miejscuDawne zamówienia zostają na starej platformie. Zachowaj ich eksport do księgowości.

Przykładowa przeprowadzka

↑ Przykład · tempo wyznacza wielkość Twojego katalogu