Kas CartSome
ir zem pārsega.

To būvē cilvēki,
kas būvē bankas.

Ātrums ir mūsu gēnos. Tāpat kā prasme nepazaudēt tavu naudu. CartSome būvē cilvēki, kas būvē bankas, un tas redzams neuzkrītošās vietās: viens naudas un krājumu rakstītājs, pēdas no katras darbības, priekšskatījums pirms katras lielas izmaiņas un skaitlis aiz katra apgalvojuma.

• Vispirms pareizi, tad ātriNaudai un krājumiem ir viens rakstītājs – shop-core. Maksājumi tiek pārbaudīti serverī, pārlūkam uz vārda netic nekad, un pārlūks visas summas rēķina veselos centos.
• Viss atstāj pēdasKatra piekļuves piešķiršana vai atņemšana tiek reģistrēta tajā pašā transakcijā, kurā notiek pati darbība, un katra operatora darbība nonāk platformas audita žurnālā.
• Garlaicīgi ar nodomuPostgreSQL, Java, tīrs SQL un Terraform: rīki, kas būs te arī pēc desmit gadiem, un nekāda gudra slāņa, ko atkļūdot pulksten 3 naktī.
• Izmērīts, nevis minētsKatra izmaiņa tajā, kā vitrīna lasa datus, pirms laišanas klajā tiek pārbaudīta ar etalontestu uz 500 000 preču kataloga. Ar nojautu etalontests sākas, nevis beidzas.

Ātrs – un vārti to tādu notur

• Renderēts serverī, kešots tīkla malāLapas pienāk kā HTML pircēja valodā, un shop-core tur saraksta un preču lapas siltas Valkey kešatmiņā.
• Baitu budžets CIVitrīnas ieejas failam, čaulai un katram maršruta fragmentam pie katras izmaiņas ir budžets, un tas kustas tikai uz leju. Katra valoda ir savā fragmentā, tāpēc pircējs lejupielādē tikai vienu.
• Ātruma vārti pirms laidienaTie uzbūvē main zaru un izmaiņu blakus un noraida lapu, kas kļuvusi smagāka vai Lighthouse mērījumos lēnāka ielādē, izkārtojuma nobīdē vai bloķēšanas laikā.
• Sliktākā scenārija vārtiKatra tēmas opcija tās smagākajā variantā, visi sadaļu veidi vienlaikus – un veikals tik un tā nedrīkst kļūt lēns. Tēmas ir CSS mainīgie, tāpēc tēma nesatur ne baita JavaScript.
• Viegli attēliKatras preces attēls tiek pārveidots AVIF variantos, un statiskie faili tiek sūtīti jau iepriekš saspiesti ar brotli.

Divas puses.
Stingra robeža.

Lielākajai daļai platformu katrai funkcijai izaug savs serviss. Mēs dalām tieši vienā vietā: veikali vienā pusē, platforma otrā. Katrai pusei ir sava lietotne, savs core, savs datubāzes lietotājs un sava atslēgas puse. Un vecais likums ir spēkā abās pusēs: raksta tikai core.

• shop-core – šūna, Java 25 un Spring BootVienīgais veikalu datu rakstītājs PostgreSQL, Valkey un S3. Caur to iet katra pārvaldības izmaiņa, imports, maksājums un veikala fona uzdevums. Tas nav sasniedzams no publiskā interneta, pats pārbauda katru maksājuma webhook un parakstu un atver veikalu aizzīmogotos noslēpumus.
• platform-core – vadības plakneTā pati koda bāze, uzbūvēta kā otra lietotne ar savu konteinera attēlu: konsoles aizmugursistēma, rēķini, organizācijas un jaunu veikalu pievienošana, platformas pašas e-pasts un vadības plaknes fona uzdevumi. Tās datubāzes lietotājs netiek klāt nevienai veikala shēmai, un tā nepalaiž migrācijas.
• Šūnas API starp tiemAbi core sazinās caur divām iekšējām durvīm, pa vienām katram virzienam, katrām savs noslēpums. Katras durvis glabā tikai pieņemamā noslēpuma SHA-256, tāpēc neviens no core netur neko, kas atvērtu tā paša durvis. Neviena pircēja pieprasījums negaida uz vadības plakni.
• shop web – TanStack Start, React, renderēts serverīRenderē katru vitrīnu pircēja valodā, veikala pārvaldības paneli, admin MCP un Trade API durvis. Tas lasa Valkey un PostgreSQL ar veikala paša lasīšanas lietotāju un neraksta neko, izņemot pieteikšanās sesijas; katra cita rakstīšana iet uz shop-core.
• Konsole – atsevišķa lietotneAtsevišķa lietotne un konteinera attēls vietnei admin.cartsome.com, operatoru MCP, cartsome.com veidlapām un Stripe webhook. Tai nav datubāzes draivera, tā neglabā neviena veikala noslēpumus un runā tikai ar platform-core.
• Tīkla mala – CloudFront un WAFLapas tiek kešotas tīkla malā, un attēli nāk tieši no S3. Aiz tās esošais slodzes līdzsvarotājs atbild tikai CloudFront, katru adresi nosūta lietotnei, kas to apkalpo, un uz vienu veikalu vērsti pieprasījumu plūdi tiek apturēti jau tīkla malā, katrai veikala adresei atsevišķi.
• Aurora PostgreSQL 18, tīrs SQLNekāda ORM, nekur. Arī pilnteksta meklēšana notiek PostgreSQL – pircēja valodā un piedodot drukas kļūdas. Nav atsevišķa meklēšanas klastera, ko auklēt.
• Valkey un S3Valkey glabā lapas, ko shop-core sasilda, pirms ierodas pircēji. S3 glabā preču attēlus (AVIF variantus), tēmu fontus, preču plūsmu katrā valodā un aizejoša veikala eksportu.
• Konteineri uz ARMČetri servisi darbojas ECS Fargate uz Graviton, katrs no sava konteinera attēla, un attēlu apstrādātāji darbojas Lambda, arī uz ARM. Terraform apraksta visu, un nekas netiek saklikšķināts konsolē.

Attēli – rindā

Veikals, kas pārceļas pie mums, atnes tūkstošiem attēlu, un jaunam veikalam nevajadzētu nevienam palēnināt norēķinus, kamēr tie tiek apstrādāti. Tāpēc shop-core tos neapstrādā.

• Core tikai ieliek rindāShop-core ieliek katru attēla uzdevumu SQS rindā un pieraksta atbildes, kad tās atgriežas – partijās, vienā transakcijā katram veikalam. Apstrādātājiem nav nekāda datubāzes lietotāja.
• Taisnīga rinda katram veikalamKatrs veikals ir sava grupa SQS taisnīgajās rindās, ar interaktīvu joslu attēlam, ko augšupielādē administrators, un masveida joslu importiem, un katrā no tām ir limits katram veikalam. Viena veikala lielais imports nekad nestāv priekšā cita veikala vienīgajam foto.
• Tas pats kodētājs, vairāk rokuLambda apstrādātāji darbina to pašu libvips kodēšanu, ko core, tāpēc attēls izskatās vienādi neatkarīgi no tā, kurš to apstrādāja. Lejupielādes tiek dozētas katram avota serverim atsevišķi, lai piegādātāja serveris netiktu appludināts.
• Apstrādāts vienreiz, izmantots visurAttēlu atpazīst pēc tā baitu jaucējvērtības. Ja kāds šūnas veikals to pašu avotu jau ir apstrādājis, apstrādātāji atkārtoti izmanto tā failus, nevis kodē vēlreiz.
• Gatavs pieplūdumamApstrādātāju flote paplašinās, kad daudz veikalu pārceļas vienlaikus, un dīkstāvē neko nemaksā, bet pārvaldības panelis katru palaišanu rāda tiešraidē: gatavs, atkārtoti izmantots, neizdevies, gaida un tā vieta rindā.

Viss kopā,
vienā lapā.

Kas runā ar ko – no pircēja telefona līdz pat diskiem. Nepārtrauktās līnijas nes pieprasījumus un rakstīšanu; raustītās tikai lasa.

Karte vārdos

1. Kas klauvē. Pircēji (cilvēki un MI iepirkšanās aģenti), citu uzņēmumu sistēmas caur Trade API, veikala īpašnieka MI klients, veikalu administratori un CartSome operatori – visi ienāk caur tīkla malu.
2. Tīkla mala. CloudFront kešo lapas, piegādā attēlus tieši no S3, glabā sertifikātus katrai *.cartsome.com adresei un katra veikala paša domēnam, un tā WAF ierobežo katru veikala adresi atsevišķi.
3. Slodzes līdzsvarotājs atbild tikai CloudFront. Katra veikala adresi tas nosūta uz shop web, bet admin.cartsome.com un cartsome.com API – uz konsoli.
4. Shop web renderē vitrīnu, pārvaldības paneli un admin MCP, publisku MCP iepirkšanās aģentiem, ko katrs veikals ieslēdz pats, un Trade API durvis. Tas lasa PostgreSQL un Valkey un katru rakstīšanu nodod shop-core.
5. Konsole apkalpo admin.cartsome.com, operatoru MCP, cartsome.com veidlapas un Stripe webhook un runā tikai ar platform-core.
6. Shop-core ir šūna: vienīgais veikalu datu rakstītājs PostgreSQL, Valkey un S3. Tas pārbauda webhook, atver veikalu seifu un ieliek attēlu darbu rindās.
7. Platform-core ir vadības plakne: organizācijas, jaunu veikalu pievienošana, rēķini, platformas e-pasts un tās fona uzdevumi, ar savu datubāzes lietotāju. Šūnu tas sasniedz tikai caur šūnas API, ar vienu noslēpumu katrā virzienā.
8. Attēlu apstrādātāji ņem uzdevumus no SQS taisnīgajām rindām, kur katram veikalam ir sava grupa, kodē tos Lambda un raksta failus S3.
9. Dati: Aurora PostgreSQL ar platformas shēmu un shēmu katram veikalam, Valkey ar katra veikala siltajām lapām un S3 attēliem, fontiem, plūsmām un eksportiem.
10. Šūna 1 šodien to visu darbina Stokholmā. Šūna 2 ir tas pats steks vēlreiz, ko atver, kad tas vajadzīgs, tajā AWS reģionā, kas vajadzīgs tās veikaliem.

Pieprasījuma dzīve

Tavs veikals.
Tava shēma.

Daudz veikalu, viens datubāzes klasteris, nulle kopīgu veikalu tabulu. Katrs veikals saņem savu PostgreSQL shēmu, un kaimiņus ārā tur pati datubāze.

• Shēma un divi lietotājiVeikals n dzīvo savā shēmā, kas izveidota no vienas bāzlīnijas. Shop web pieslēdzas ar veikala lasīšanas lietotāju, shop-core – ar tā rakstīšanas lietotāju, un neviens no tiem netiek klāt nevienam citam veikalam. Platform-core lietotājs netiek klāt nevienam veikalam vispār.
• Nav veikala kolonnas, ko aizmirstTabulas shēmā saglabā savu formu: nekāda veikala id katrā rindā, nekāda filtra, ko vaicājums varētu izlaist. Ārējās atslēgas nekad neiziet ārpus shēmas.
• Vaicājumi nekad nenosauc shēmuVeikalu izvēlas lietotājs, ar kuru savienojums pieslēdzas, un savienojums visu savu mūžu apkalpo vienu veikalu. Statiska pārbaude apstādina būvējumu, ja vaicājumā parādās shēmas nosaukums.
• Pūli, kas atveras pēc vajadzībasKatrs veikals saņem savus nelielus savienojumu pūlus, kas tiek atvērti pie tā pirmā pieprasījuma un aizvērti, tiklīdz tas apklust, tāpēc datubāzes savienojumu budžets ierobežo to, cik veikalu ir aizņemti vienlaikus, nevis to, cik to pastāv. Katram veikalam ir arī savs pieprasījumu budžets, un veikalam, kas to pārsniedz, tiek lūgts mēģināt vēlreiz – tikai tam vienam.
• Kešatmiņa un saites zina savu veikaluKatra kešatmiņas ieraksta atslēgā ir veikals. Sesijas, pasūtījumu saites, dāvanu karšu saites un atrakstīšanās marķieri ir parakstīti ar veikala paša atslēgām, tāpēc viena veikala saite citā tiek noraidīta.
• Noplūžu testi, kas izmēģina durvisTie izveido rindu katrā veikala tabulā diviem veikaliem un nolasa katru no otra veikala puses ar shop-core un shop web savienojumiem, un tad izsauc katru core galapunktu, kas pieņem id. Tie darbojas pie katras izmaiņas.

Šūnas, nevis
viens liels kamols.

Mēs mērogojamies ar šūnām. Šūna ir pilns steks: savs Aurora klasteris, savs shop-core un shop web, tās veikalu shēmas, savas attēlu rindas un apstrādātāji. Kad viena piepildās, atveram nākamo. Vadības plakne atrodas atsevišķi un ar šūnu runā tikai caur šūnas API. Platforma aug; nevienai atsevišķai šūnai tas nav jādara.

Ko nozīmē „pilna”

Šūna vairs nepieņem jaunus veikalus, tiklīdz jebkurš no šiem rādītājiem sasniedz savu limitu. Pie 80 procentiem no jebkura limita mēs plānojam nākamo šūnu; konsoles lapa „Šūna” rāda aktuālo piepildījumu un nosauc signālu.

• Lielam veikalam – sava šūnaVeikals, kuram koplietotā šūna kļūst par šauru, saņem šūnu tikai sev. Autotools paliek šūnā 1.
• Pārnesams pēc būtībasViss, kas pieder veikalam, ir nosaukts veikala vārdā: tā shēma ar savām atslēgām un sekvencēm, tā seifa rindas, aizzīmogotas zem tā organizācijas, tā kešatmiņas atslēgas, tā plūsmu faili. Nekas to nepiesien šūnai, kurā tas dzimis.
• Godīgi sakotVeikala pārcelšana starp šūnām vēl nav poga. Tā nāks kopā ar otro šūnu, un ceļā nestāv nekas kopīgs.

Aizslēgts pēc noklusējuma.
Garlaicīgs ar nodomu.

Veikala interesantākajai daļai vajadzētu būt precēm. Lūk, garlaicīgā daļa – tik detalizēti, cik mēs to labprāt publicējam.

• Izolācija datubāzēShēmas un lietotāji katram veikalam, ko nodrošina PostgreSQL tiesības, nevis kods, kam jāatceras filtrs. Vadības plaknei ir savs lietotājs, un shop-core lietotājam nav nekādu tiesību uz vadības plaknes tabulām.
• Aizzīmogots seifs katrai organizācijaiMaksājumu, pārvadātāju un pasta atslēgas glabājas seifā, katra aizzīmogota ar AES-256-GCM ar jaunu datu atslēgu no KMS atslēgas, ko var izmantot tikai abi core, un piesaistīta savai organizācijai un nosaukumam. Nokopēta rinda neatveras nekur. Noslēpumi nekad nedzīvo kodā.
• Katram core – sava atslēgas puseShop-core atver veikalu noslēpumus, bet platform-core – platformas pašas, piemēram, tās Stripe un grāmatvedības atslēgas. Atslēgas politika katram no tiem atsaka otra pusi.
• Divas durvis, divi noslēpumiAbi core izsauc viens otru ar vienu noslēpumu katrā virzienā, un katras durvis glabā tikai pieņemamā noslēpuma SHA-256, tāpēc neviens no core netur to, kas atver tā paša durvis.
• Piekļuves atslēgas tiem, kas to vadaOperatori pieslēdzas ar piekļuves atslēgām un katru platformas izmaiņu apstiprina ar jaunu. Piekļuves piešķiršana nekad nav rīks: neviens marķieris un neviens MI nevar pievienot operatoru.
• MI izmaiņas, ko redzi un vari atsauktMasveida un uz āru vērstas izmaiņas vispirms darbojas kā priekšskatījums un tiek piemērotas pēc apstiprinājuma, kas piesaistīts tieši tam, ko redzēji; ja veikals pa to laiku mainījies, tās tiek noraidītas. Pēc tam katra izmaiņa atbild ar savu atsaukšanu.
• Marķieri ar mazāko atslēgu saišķiKatram admin MCP marķierim vai savienojumam ir tvērumi, un tas redz tikai tos rīkus, ko šie tvērumi atļauj. Atmaksām, noslēpumiem un administratoriem katram vajadzīgs savs tvērums.
• Klienti paliek ārpus sarunasRīka atbilde nonāk pie MI pakalpojuma sniedzēja, tāpēc atbildēs nav pircēju vārdu, e-pastu, tālruņu, adrešu un nodokļu maksātāju numuru. Dažus noteiktus izņēmumus, piemēram, pasūtījuma komentāra tekstu, noteikumi nosauc skaidri.
• Pēdas no katras operatora darbībasKatra operatora veiktā izmaiņa un katra lasīšana pāri veikaliem nonāk platformas audita žurnālā.

314 darbības.
Nulle veidlapu.

Admin MCP dod MI klientam 314 veikala darbības, un katra no tām ir pieejama arī tīmekļa pārvaldības panelī. Pievieno Claude, ChatGPT, Cursor, Gemini vai jebkuru citu MCP klientu, pieslēdzoties vai ielīmējot marķieri. Slēdzis ir izslēgts, līdz administrators to ieslēdz.

Drošības modelis

Tvērumi veido virsmu

Marķieris redz tikai tos rīkus, ko nes tā tvērumi, tāpēc šaurs marķieris ir gan maza virsma, gan maza vara. Birkas un izvēlnes ir atsevišķi tvērumi, jo publicēta izvēlne uzreiz maina to, ko redz pircēji. Ieraksta melnraksts un tā publicēšana ir divi atsevišķi tvērumi. Nekas, ko var izdarīt MI, neapstiprina grāmatojumu; to pārvaldības panelī dara cilvēks.

Piemēri

↑ Pieprasījumu piemēri · nosauktie rīki ir īsti

Veikals veikalam.
Bez starpnieka.

Katrs veikals var atvērt saviem biznesa klientiem Trade API: neitrālu, versionētu HTTP API, ko izsauc viņu pašu sistēmas, lai lasītu katalogu ar savām cenām un veiktu pasūtījumus. Un jebkurš veikals var pirkt no jebkura cita veikala, kas runā šo API, – kā no vēl viena piegādātāja.

• Protokols, nevis zīmolsAtklāšana adresē /.well-known/trade-api, API zem /trade/v1, OpenAPI 3.1 dokuments, un tajā nekur nav nevienas platformas nosaukuma. Pārdevējs, kas to runā, ir pārdevējs, lai kas to darbinātu.
• Atslēgas, ko izveido klientsAdministrators apstiprina uzņēmumu kā B2B kontu, piesaista cenu līmeni, ar kādu tas pērk, un atļauj API. Klients pats izveido un anulē savas atslēgas sava konta lapā; veikals glabā tikai jaucējvērtību, un neviens administrators atslēgu nekad neredz.
• Viņu cenas, īsti krājumiKatrai precei ir tieši tāda cena, kādu vitrīna rāda šim klientam, kad tas pieteicies, un blakus – vitrīnas pārdodamie krājumi ar augšējo robežu.
• Pasūtījumi, kas nedubultojasKatram pasūtījumam ir idempotences atslēga: ar to pašu atslēgu un saturu atgriežas pirmais pasūtījums, bet atšķirīgs saturs tiek noraidīts. No tā brīža tas ir parasts veikala pasūtījums – ar rēķinu, iepakots un nosūtīts kā ierasts.
• Pērc no jebkura veikalaVispārīgs Trade API piegādātāja savienotājs padara pārdevēju par vēl vienu piegādātāju: tā krājumi un cenas tiek nolasīti pēc grafika, pasūtījumi tiek sūtīti ar idempotences atslēgu, un apstiprinājumi un piegādes tiek nolasīti atpakaļ. Tas izsauc pārdevēja publisko adresi kā jebkurš svešinieks, nekad ne pa īsceļu šūnas iekšienē.
• Īsa pavadaLimiti katrai atslēgai pieprasījumiem un pasūtījumiem, griesti neapmaksātiem pasūtījumiem, un viena veikala atslēga citā veikalā ir svešiniece. Katra darbība ar kontu, piekļuvi un atslēgām nonāk veikala audita žurnālā, un klients uzzina par katru jaunu atslēgu.
• Godīgi sakotWebhook vēl nav: pircējs pats periodiski vaicā, kas mainījies. Pagaidām pasūtījumus apmaksā ar priekšapmaksas rēķinu; pēcapmaksa nāks vēlāk.

Veikals minūtēs.
Atver, kad gatavs.

Nav ne instalētāja, ne servera, ko izvēlēties. Mēs pievienojam tavu organizāciju platformas konsolē, veikals uzbūvē sevi pats, un tālāk viss ir tavās rokās.

Valodas – ar slēdzi. Jauns veikals sāk ar savu galveno valodu un igauņu valodu. Ieslēdz jebkuru no 8, kad tās tulkojumi ir gatavi – sadaļā Iestatījumi › Valodas vai ar manage_languages. Precei visās valodās ir viena un tā pati adrese.

Atnes savu veikalu.
Paturi savu Google.

Autotools pārcēlās no Shopify un šodien CartSome platformā tur 25 000+ preču. Rīki, kas tam bija vajadzīgi, ir tie paši rīki, ko saņem tu.

• Preces: konvertē MI, pārbauda cilvēksTavs MI klients izlasa importa formātu, veikala vārdnīcu un piegādātāja datus un uzraksta failu, ko pieņem veikala paša validators. Tas apstājas un nosauc katru robu, nevis izdomā kategoriju. Cilvēks pārskata, kas sakrita un kas ir jauns, un tiek piemērots tikai tas imports, ko viņš nosauc, apstiprinot izlasītu priekšskatījumu.
• Paslēptas, līdz tu saki „rādīt”Jaunas preces ienāk paslēptas. Viens priekšskatīts izsaukums parāda visu klāstu – līdz pat 5 000 preču.
• Vecās adreses – pāradresētasIedod Shopify pāradresāciju eksportu vai jebkuru divu kolonnu sarakstu. Katra rinda tiek salīdzināta tieši tā, kā vitrīna meklē adreses, ķēdes tiek saīsinātas līdz vienai pastāvīgai pāradresācijai, un katrs mērķis tiek pārbaudīts pret veikala paša lapām.
• Shopify pārejas komplektsMūsu pārejas rīki uzņem vecās vietnes momentuzņēmumu, izveido vecās-jaunās adrešu karti ar atskaiti par to, kas vēl palicis, un tad pārbauda jaunajā veikalā katru rindu, prasot vienu 301 uz lapu, kas atbild. Autotools šādi pārnesa 12 598 vecas adreses.
• Jaunumu piekrišanas – pārceltas vienreizMārketinga saraksts pāriet veikala piekrišanu reģistrā ar katras personas atbildi tādu, kāda tā sniegta. Pārcelšanas laikā netiek nosūtīts nekas.
• Kas paliek vecajā vietāIepriekšējie pasūtījumi paliek vecajā platformā. Saglabā tās eksportu savai grāmatvedībai.

Pārcelšanās piemērs

↑ Piemērs · tempu nosaka tava kataloga apjoms