Kas slypi
po CartSome kapotu.

Kuria žmonės,
kurie kuria bankus.

Greitis – mūsų DNR. Kaip ir tai, kad neprarandame jūsų pinigų. CartSome kuria žmonės, kurie kuria bankus, ir tai matyti neblizgančiose vietose: pinigus ir atsargas rašo tik vienas, kiekvienas veiksmas palieka pėdsaką, prieš kiekvieną didelį pakeitimą – peržiūra, o už kiekvieno teiginio – skaičius.

• Pirma teisingai, paskui greitaiPinigus ir atsargas rašo tik vienas – shop-core. Mokėjimai tikrinami serveryje, niekada nepasikliaujant tuo, ką sako naršyklė, o naršyklė skaičiuoja sveikais centais.
• Viskas palieka pėdsakąKiekvienas prieigos suteikimas ar atėmimas įrašomas toje pačioje transakcijoje kaip ir pats veiksmas, o kiekvienas operatoriaus veiksmas – į platformos audito žurnalą.
• Nuobodu – tyčiaPostgreSQL, Java, grynas SQL ir Terraform: įrankiai, kurie bus čia ir po dešimties metų, be jokio gudraus sluoksnio, kurį tektų derinti 3 val. nakties.
• Matuojama, o ne spėjamaKiekvienas pakeitimas, kaip vitrina skaito duomenis, prieš išleidžiant išbandomas su 500 000 prekių katalogu. Nuojauta – tai, nuo ko lyginamasis testas prasideda, bet niekada ne tai, kuo jis baigiasi.

Greita – ir vartai neleidžia sulėtėti

• Generuojama serveryje, laikoma tinklo kraštePuslapiai atkeliauja kaip HTML pirkėjo kalba, o shop-core laiko sąrašų ir prekių puslapius šiltus Valkey podėlyje.
• Baitų biudžetas CI proceseVitrinos įėjimo taškui, apvalkalui ir kiekvienai maršruto daliai su kiekvienu pakeitimu taikomas biudžetas, kuris gali tik mažėti. Kiekviena kalba keliauja atskira dalimi, tad pirkėjas atsisiunčia tik vieną.
• Greičio vartai prieš išleidimąJie greta sukompiliuoja main ir pakeitimą ir atmeta puslapį, kuris tampa sunkesnis arba Lighthouse vertinimu lėtesnis – įkėlimo, maketo poslinkio ar blokavimo laiko požiūriu.
• Blogiausio atvejo vartaiVisos temos parinktys – sunkiausios, visi sekcijų tipai – vienu metu, o parduotuvė vis tiek neturi teisės sulėtėti. Temos yra CSS kintamieji, todėl tema neatsineša nė eilutės JavaScript.
• Lengvi vaizdaiKiekvienas prekės vaizdas sumažinamas į AVIF variantus, o statiniai failai iškeliauja iš anksto suspausti brotli.

Dvi pusės.
Griežta riba.

Dauguma platformų kiekvienai funkcijai užsiaugina po paslaugą. Mes perskyrėme lygiai vienoje vietoje: parduotuvės vienoje pusėje, platforma – kitoje. Kiekviena pusė turi savo programą, savo core, savo duomenų bazės prisijungimą ir savo rakto pusę. O senoji taisyklė galioja abiejose pusėse: rašo tik core.

• shop-core – ląstelė, Java 25 ir Spring BootVienintelis, kuris rašo parduotuvių duomenis į PostgreSQL, Valkey ir S3. Per jį eina kiekvienas pakeitimas administravimo skydelyje, importas, mokėjimas ir parduotuvės užduotis. Jis nepasiekiamas iš viešojo interneto, pats tikrina kiekvieną mokėjimo webhook pranešimą bei parašą ir atrakina užsandarintas parduotuvių paslaptis.
• platform-core – valdymo plokštumaTa pati kodo bazė, sukompiliuota kaip antra programa su savu atvaizdu: konsolės serverinė dalis, sąskaitų išrašymas, organizacijos ir naujų parduotuvių paleidimas, pačios platformos paštas ir valdymo plokštumos užduotys. Jo duomenų bazės prisijungimas nepasiekia nė vienos parduotuvės schemos, o migracijų jis nevykdo.
• Ląstelės API tarp jųAbu core kalbasi per dvejas vidines duris, po vienas kiekvienai krypčiai, ir kiekvienos turi savo paslaptį. Kiekvienos durys saugo tik priimamos paslapties SHA-256, tad nė vienas core neturi nieko, kas atidarytų jo paties duris. Nė viena pirkėjo užklausa nelaukia valdymo plokštumos.
• shop web – TanStack Start, React, generuojama serveryjeGeneruoja kiekvieną vitriną pirkėjo kalba, parduotuvės administravimo skydelį, admin MCP ir Trade API duris. Jis skaito Valkey ir PostgreSQL (per pačios parduotuvės skaitymo prisijungimą), o rašo tik prisijungimo sesijas; kiekvienas kitas rašymas keliauja į shop-core.
• Konsolė – sava programaAtskira programa ir atvaizdas, skirti admin.cartsome.com, operatorių MCP, cartsome.com formoms ir Stripe webhook pranešimams. Ji neturi duomenų bazės tvarkyklės, nelaiko jokių parduotuvių paslapčių ir kalbasi tik su platform-core.
• Tinklo kraštas – CloudFront ir WAFPuslapiai laikomi krašto podėlyje, o vaizdai keliauja tiesiai iš S3. Už jo esantis apkrovos balansuotuvas atsako tik CloudFront, kiekvieną adresą siunčia jį aptarnaujančiai programai, o į vieną parduotuvę nukreiptas užklausų antplūdis sustabdomas jau krašte, pagal parduotuvės adresą.
• Aurora PostgreSQL 18, grynas SQLJokio ORM, niekur. Viso teksto paieška irgi vyksta PostgreSQL – pirkėjo kalba ir atlaidi rašybos klaidoms. Jokio atskiro paieškos klasterio, kurį reikėtų prižiūrėti.
• Valkey ir S3Valkey laiko puslapius, kuriuos shop-core iš anksto pašildo pirkėjams. S3 laiko prekių vaizdus (AVIF variantus), temų šriftus, prekių srautą kiekviena kalba ir išeinančios parduotuvės eksportą.
• Konteineriai ARM procesoriuoseKeturios paslaugos veikia ECS Fargate, Graviton procesoriuose, kiekviena iš savo atvaizdo, o vaizdus apdoroja Lambda funkcijos, irgi ARM procesoriuose. Visa tai aprašyta Terraform – konsolėje rankomis nieko nesukonfigūruota.

Vaizdai – per eilę

Persikelianti parduotuvė atsineša tūkstančius vaizdų, o nauja parduotuvė, kol jie apdorojami, neturėtų sulėtinti niekieno atsiskaitymo. Todėl shop-core teptuko į rankas neima.

• Core tik stato į eilęShop-core kiekvieną vaizdo užduotį deda į SQS ir užrašo atsakymus, kai šie grįžta – paketais, po vieną transakciją parduotuvei. Apdorojimo procesai neturi jokio duomenų bazės prisijungimo.
• Sąžininga eilė kiekvienai parduotuveiKiekviena parduotuvė yra atskira grupė SQS sąžiningose eilėse, su interaktyvia juosta vaizdui, kurį įkelia administratorius, ir masine juosta importams, o kiekvienoje juostoje parduotuvei taikoma riba. Vienos parduotuvės didelis importas niekada nestovi priešais kitos parduotuvės vienintelę nuotrauką.
• Tas pats koduotuvas, daugiau rankųLambda procesai vykdo tą patį libvips kodavimą, kurį vykdo core, tad vaizdas atrodo vienodai, kad ir kas jį apdorojo. Atsisiuntimų tempas ribojamas kiekvienam šaltinio serveriui atskirai, kad tiekėjo serveris nebūtų užtvindytas.
• Apdorota kartą, naudojama visurVaizdas atpažįstamas pagal jo baitų maišos reikšmę. Jei kuri nors ląstelės parduotuvė tą patį šaltinį jau apdorojo, procesai pakartotinai naudoja jos failus, užuot koduodami iš naujo.
• Sukurta antplūdžiuiProcesų būrys išsiplečia, kai vienu metu persikelia daug parduotuvių, o nieko neveikdamas nieko nekainuoja; administravimo skydelis kiekvieno apdorojimo eigą rodo realiuoju laiku: atlikta, panaudota pakartotinai, nepavyko, laukia ir vieta eilėje.

Viskas,
viename puslapyje.

Kas su kuo kalbasi – nuo pirkėjo telefono iki pat diskų. Ištisinės linijos neša užklausas ir rašymą; brūkšninės tik skaito.

Žemėlapis žodžiais

1. Kas beldžiasi. Pirkėjai (žmonės ir DI pirkimo agentai), kitų įmonių sistemos per Trade API, parduotuvės savininko DI klientas, parduotuvių administratoriai ir CartSome operatoriai – visi patenka per kraštą.
2. Tinklo kraštas. CloudFront laiko puslapius podėlyje, vaizdus pateikia tiesiai iš S3, saugo sertifikatus kiekvienam *.cartsome.com adresui ir kiekvienos parduotuvės nuosavam domenui, o jo WAF riboja kiekvieną parduotuvės adresą atskirai.
3. Apkrovos balansuotuvas atsako tik CloudFront. Kiekvienos parduotuvės adresą jis siunčia į shop web, o admin.cartsome.com ir cartsome.com API – į konsolę.
4. Shop web generuoja vitriną, administravimo skydelį ir admin MCP, viešą MCP pirkimo agentams, kurį kiekviena parduotuvė įsijungia pati, ir Trade API duris. Jis skaito PostgreSQL ir Valkey, o kiekvieną rašymą perduoda shop-core.
5. Konsolė aptarnauja admin.cartsome.com, operatorių MCP, cartsome.com formas ir Stripe webhook pranešimus, o kalbasi tik su platform-core.
6. Shop-core – tai ląstelė: vienintelis, kuris rašo parduotuvių duomenis į PostgreSQL, Valkey ir S3. Jis tikrina webhook užklausas, atrakina parduotuvių saugyklą ir deda vaizdų darbus į eiles.
7. Platform-core – tai valdymo plokštuma: organizacijos, naujų parduotuvių paleidimas, sąskaitų išrašymas, platformos paštas ir jos užduotys, su savu duomenų bazės prisijungimu. Ląstelę jis pasiekia tik per ląstelės API, su po vieną paslaptį kiekvienai krypčiai.
8. Vaizdų apdorojimo procesai ima užduotis iš SQS sąžiningų eilių, po grupę kiekvienai parduotuvei, apdoroja jas Lambda ir įrašo failus į S3.
9. Duomenys: Aurora PostgreSQL su platformos schema ir po schemą kiekvienai parduotuvei, Valkey su kiekvienos parduotuvės šiltais puslapiais ir S3 vaizdams, šriftams, srautams bei eksportams.
10. Ląstelė Nr. 1 šiandien visa tai vykdo Stokholme. Ląstelė Nr. 2 – tas pats rinkinys dar kartą, atidaromas, kai prireiks, tame AWS regione, kurio reikia jos parduotuvėms.

Užklausos kelias

Jūsų parduotuvė.
Jūsų schema.

Daug parduotuvių, vienas duomenų bazės klasteris, nė vienos bendros parduotuvių lentelės. Kiekviena parduotuvė gauna savo PostgreSQL schemą, o kaimynus už durų laiko pati duomenų bazė.

• Schema ir du prisijungimaiParduotuvė n gyvena savo schemoje, sukurtoje iš vieno bazinio šablono. Shop web jungiasi parduotuvės skaitymo prisijungimu, shop-core – rašymo, ir nė vienas nepasiekia jokios kitos parduotuvės. Platform-core prisijungimas nepasiekia nė vienos parduotuvės.
• Nėra parduotuvės stulpelio, kurį galima pamirštiLentelės schemos viduje išlaiko savo formą: jokio parduotuvės ID kiekvienoje eilutėje, jokio filtro, kurį užklausa galėtų praleisti. Išoriniai raktai niekada neišeina už schemos ribų.
• SQL sakiniai niekada neįvardija schemosParduotuvę parenka prisijungimas, kuriuo jungiasi jungtis, o viena jungtis visą savo gyvavimą aptarnauja vieną parduotuvę. Statinė patikra sustabdo kompiliavimą, jei užklausoje randa schemos pavadinimą.
• Telkiniai, kurie atsidaro pagal poreikįKiekviena parduotuvė gauna nedidelius savo jungčių telkinius, atidaromus su pirmąja jos užklausa ir uždaromus, kai ji nutyla, tad duomenų bazės jungčių biudžetas riboja, kiek parduotuvių dirba vienu metu, o ne kiek jų išvis yra. Kiekviena parduotuvė turi ir savo užklausų biudžetą, o jį viršijusiai parduotuvei – tik jai vienai – liepiama pabandyti vėliau.
• Podėliai ir nuorodos žino savo parduotuvęKiekvieno podėlio įrašo raktas apima parduotuvę. Sesijos, užsakymų nuorodos, dovanų kortelių nuorodos ir prenumeratos atsisakymo žetonai pasirašomi pačios parduotuvės raktais, tad vienos parduotuvės nuoroda kitoje atmetama.
• Nuotėkio testai, kurie bando visas durisJie kiekvienoje parduotuvės lentelėje dviem parduotuvėms sukuria po eilutę ir skaito kiekvieną kaip kita – per shop-core ir per shop web jungtis, tada iškviečia kiekvieną core galinį tašką, priimantį ID. Jie paleidžiami su kiekvienu pakeitimu.

Ląstelės, o ne
vienas didelis gniužulas.

Plečiamės ląstelėmis. Ląstelė – tai pilnas rinkinys: savas Aurora klasteris, savi shop-core ir shop web, jos parduotuvių schemos, savos vaizdų eilės ir apdorojimo procesai. Kai viena prisipildo, atidarome kitą. Valdymo plokštuma stovi atskirai ir su ląstele kalbasi tik per ląstelės API. Auga platforma, o ne kuri nors viena ląstelė.

Ką reiškia „pilna“

Ląstelė nebepriima naujų parduotuvių, kai bet kuris iš šių rodiklių pasiekia savo ribą. Pasiekus 80 procentų bet kurios ribos, planuojame kitą ląstelę; konsolės puslapis „Ląstelė“ rodo užpildymą realiuoju laiku ir įvardija signalą.

• Didelė parduotuvė gauna savo ląstelęParduotuvė, išaugusi bendrą ląstelę, gauna ląstelę tik sau. Autotools lieka ląstelėje Nr. 1.
• Perkeliama iš prigimtiesViskas, kas priklauso parduotuvei, pažymėta jos vardu: jos schema su savais raktais ir sekomis, jos saugyklos eilutės, užsandarintos jos organizacijai, podėlio raktai, srautų failai. Niekas jos nepririša prie ląstelės, kurioje ji gimė.
• SąžiningaiPerkelti parduotuvę į kitą ląstelę kol kas vienu mygtuku negalima. Tai atsiras kartu su antrąja ląstele, o kelyje nėra nieko bendro, kas trukdytų.

Užrakinta pagal nutylėjimą.
Nuobodu – tyčia.

Įdomiausia parduotuvėje turėtų būti prekės. Štai nuobodžioji dalis – tiek, kiek mielai skelbiame viešai.

• Izoliacija duomenų bazėjeKiekvienos parduotuvės schemos ir prisijungimai, kuriuos užtikrina PostgreSQL teisės, o ne kodas, turintis neužmiršti filtro. Valdymo plokštuma turi savo prisijungimą, o shop-core prisijungimas neturi jokių teisių į valdymo plokštumos lenteles.
• Užsandarinta saugykla kiekvienai organizacijaiMokėjimų, vežėjų ir pašto raktai laikomi saugykloje, kiekvienas užsandarintas AES-256-GCM nauju duomenų raktu iš KMS rakto, kurį gali naudoti tik du core, ir susietas su savo organizacija bei pavadinimu. Nukopijuota eilutė niekur neatsirakina. Paslaptys niekada negyvena kode.
• Kiekvienas core turi pusę raktoShop-core atrakina parduotuvių paslaptis, o platform-core – pačios platformos, pavyzdžiui, jos Stripe ir buhalterijos raktus. Rakto politika neleidžia nė vienam paimti kito pusės.
• Dvejos durys, dvi paslaptysAbu core vienas kitą kviečia su po vieną paslaptį kiekvienai krypčiai, o kiekvienos durys saugo tik priimamos paslapties SHA-256, tad nė vienas core neturi to, kas atidaro jo paties duris.
• Slaptaraktai tiems, kas valdo platformąOperatoriai prisijungia slaptaraktais ir kiekvieną platformos pakeitimą kaskart iš naujo patvirtina slaptarakčiu. Prieigos suteikimas niekada nėra įrankis: joks prieigos raktas ir joks DI negali pridėti operatoriaus.
• DI pakeitimai, kuriuos matote ir galite atšauktiMasiniai ir į išorę nukreipti pakeitimai pirmiausia vykdomi kaip peržiūra ir pritaikomi tik patvirtinus, o patvirtinimas susietas su tuo, ką matėte; jei parduotuvė tuo metu pasikeitė, jis atmetamas. Be to, kiekvienas pakeitimas atsako su savo atšaukimu.
• Mažiausias įmanomas raktų ryšulysKiekvienas admin MCP prieigos raktas ar jungtis turi teisių sritis ir mato tik tuos įrankius, kuriuos tos sritys leidžia. Grąžinimams, paslaptims ir administratoriams reikia atskirų sričių.
• Klientai lieka už pokalbio ribųĮrankio atsakymas keliauja DI teikėjui, todėl atsakymuose nėra pirkėjų vardų, el. pašto adresų, telefonų, adresų ir mokesčių mokėtojo kodų. Kelios aiškiai nurodytos išimtys, pavyzdžiui, užsakymo komentaro tekstas, įvardytos taisyklėse.
• Pėdsakas kiekvienam operatoriaus veiksmuiKiekvienas operatoriaus atliktas pakeitimas ir kiekvienas skaitymas per kelias parduotuves patenka į platformos audito žurnalą.

314 veiksmų.
Nulis formų.

Admin MCP suteikia DI klientui 314 parduotuvės veiksmų, o kiekvieną jų galima atlikti ir žiniatinklio administravimo skydelyje. Prijunkite Claude, ChatGPT, Cursor, Gemini ar bet kurį kitą MCP klientą prisijungę arba įklijavę prieigos raktą. Jungiklis išjungtas, kol jo neįjungia administratorius.

Saugumo modelis

Sritys formuoja paviršių

Prieigos raktas mato tik tuos įrankius, kuriuos apima jo sritys, todėl siauras raktas – tai ir mažas paviršius, ir maža galia. Žymos ir meniu – atskiros sritys, nes paskelbtas meniu iškart keičia tai, ką mato pirkėjai. Tinklaraščio įrašo rengimas ir paskelbimas – taip pat dvi. Nė vienas DI veiksmas nepatvirtina buhalterinio įrašo; tai administravimo skydelyje daro žmogus.

Pavyzdžiai

↑ Užklausų pavyzdžiai · nurodyti įrankiai tikri

Parduotuvė parduotuvei.
Be tarpininkų.

Kiekviena parduotuvė gali atverti savo verslo klientams Trade API – neutralią, versijuojamą HTTP sąsają, kurią kviečia jų pačių sistemos, kad skaitytų katalogą jų kainomis ir pateiktų užsakymus. O bet kuri parduotuvė gali pirkti iš bet kurios kitos ja kalbančios parduotuvės – kaip iš dar vieno tiekėjo.

• Protokolas, o ne prekės ženklasAptikimas adresu /.well-known/trade-api, sąsaja po /trade/v1, OpenAPI 3.1 dokumentas – ir niekur jame jokio platformos pavadinimo. Ja kalbantis pardavėjas yra tiesiog pardavėjas, kad ir ant ko jis veiktų.
• Raktus kuria klientasAdministratorius patvirtina įmonei verslo kliento paskyrą, priskiria kainų lygį, kuriuo ji perka, ir leidžia naudotis sąsaja. Klientas pats kuria ir panaikina savo raktus savo paskyros puslapyje; parduotuvė saugo tik maišos reikšmę, o joks administratorius rakto niekada nemato.
• Jų kainos, tikros atsargosKiekviena prekė įkainojama lygiai taip, kaip vitrina ją įkainotų tam prisijungusiam klientui, o šalia – vitrinoje parduodamas atsargų kiekis, apribotas iš viršaus.
• Užsakymai, kurie nepasidvigubinaKiekvienas užsakymas turi idempotentiškumo raktą: tas pats raktas ir turinys grąžina pirmąjį užsakymą, o kitoks turinys atmetamas. Nuo tada tai įprastas parduotuvės užsakymas – jam išrašoma sąskaita, jis supakuojamas ir išsiunčiamas įprastu būdu.
• Pirkite iš bet kurios parduotuvėsBendrinis Trade API tiekėjo konektorius paverčia pardavėją dar vienu tiekėju: jo atsargos ir kainos skaitomos pagal tvarkaraštį, užsakymai siunčiami su idempotentiškumo raktu, o patvirtinimai ir pristatymai nuskaitomi atgal. Jis kreipiasi į viešą pardavėjo adresą kaip bet kuris nepažįstamasis, niekada netrumpindamas kelio ląstelės viduje.
• Trumpas pavadėlisUžklausų ir užsakymų ribos kiekvienam raktui, neapmokėtų užsakymų riba, o vienos parduotuvės raktas kitoje – tik nepažįstamasis. Kiekvienas paskyros, prieigos ir rakto veiksmas patenka į parduotuvės audito žurnalą, o klientas sužino apie kiekvieną naują raktą.
• SąžiningaiWebhook pranešimų kol kas nėra: pirkėjas pats periodiškai tikrina, kas pasikeitė. Užsakymai kol kas apmokami pagal išankstinio apmokėjimo sąskaitą; pirkimas su mokėjimo atidėjimu atsiras vėliau.

Parduotuvė per minutes.
Atidarote, kai pasiruošę.

Jokio diegimo vedlio ir jokio serverio, kurį reikėtų pasirinkti. Platformos konsolėje pridedame jūsų organizaciją, parduotuvė susikuria pati, o toliau perimate jūs.

Kalbos – jungikliu. Nauja parduotuvė pradeda su pagrindine kalba ir estų kalba. Įjunkite bet kurią iš 8, kai jos vertimai paruošti, – skiltyje Nustatymai › Kalbos arba su manage_languages. Prekės adresas visomis kalbomis tas pats.

Persikelkite.
Google liks su jumis.

Autotools persikėlė iš Shopify ir šiandien CartSome platformoje turi 25 000+ prekių. Įrankiai, kuriais tai padaryta, – tie patys, kuriuos gaunate jūs.

• Prekės, konvertuotos DI ir patikrintos žmogausJūsų DI klientas perskaito importo formatą, parduotuvės žodyną ir tiekėjo duomenis ir parašo failą, kurį praleidžia pačios parduotuvės validatorius. Užuot išgalvojęs kategoriją, jis sustoja ir įvardija kiekvieną spragą. Žmogus peržiūri, kas sutapo ir kas nauja, ir pritaikomas tik jo nurodytas importas – patvirtinus perskaitytą peržiūrą.
• Paslėpta, kol liepsite rodytiNaujos prekės atkeliauja paslėptos. Vienas peržiūrėtas iškvietimas parodo visą asortimentą – iki 5 000 prekių.
• Seni adresai – peradresuotiPateikite Shopify peradresavimų eksportą arba bet kurį dviejų stulpelių sąrašą. Kiekviena eilutė sutapatinama taip, kaip vitrina ieško adresų, grandinės sutraukiamos į vieną nuolatinį peradresavimą, o kiekvienas tikslinis adresas sutikrinamas su pačios parduotuvės puslapiais.
• Shopify perėjimo rinkinysMūsų perėjimo įrankiai padaro senos svetainės momentinę kopiją, sudaro senų ir naujų adresų žemėlapį su ataskaita apie tai, kas liko, ir tada kiekvieną eilutę patikrina naujoje parduotuvėje, reikalaudami vieno 301 peradresavimo į atsakantį puslapį. Taip Autotools perkėlė 12 598 senus adresus.
• Naujienlaiškio sutikimai – perkeliami vieną kartąRinkodaros sąrašas perkeliamas į parduotuvės sutikimų registrą su kiekvieno žmogaus atsakymu tokiu, koks buvo duotas. Perkeliant nieko neišsiunčiama.
• Kas neperkeliamaAnkstesni užsakymai lieka senojoje platformoje. Pasilikite jos eksportą buhalterijai.

Perkėlimo pavyzdys

↑ Pavyzdys · tempą lemia jūsų katalogo dydis