So ist CartSome
verdrahtet.

Gebaut von Leuten,
die Banken bauen.

Tempo liegt uns in der DNA. Dein Geld nicht zu verlieren auch. CartSome wird von Leuten gebaut, die Banken bauen, und das merkt man an den unspektakulären Stellen: ein einziger Schreiber für Geld und Bestand, eine Spur für jeden Eingriff, eine Vorschau vor jedem großen Schreibvorgang und eine Zahl hinter jeder Behauptung.

• Erst korrekt, dann schnellGeld und Bestand haben genau einen Schreiber: shop-core. Zahlungen werden auf dem Server geprüft, nie dem Browser geglaubt, und der Browser rechnet in ganzen Cent.
• Alles hinterlässt eine SpurJede Vergabe und jeder Entzug eines Zugriffs wird in derselben Transaktion festgehalten wie der Vorgang selbst, und jeder Eingriff eines Operators im Audit-Trail der Plattform.
• Langweilig mit AbsichtPostgreSQL, Java, rohes SQL und Terraform: Werkzeuge, die es auch in zehn Jahren noch gibt, und keine clevere Schicht, die man um 3 Uhr nachts debuggen muss.
• Gemessen, nicht geratenJede Änderung daran, wie die Storefront liest, wird vor dem Release gegen einen Katalog mit 500.000 Produkten gebenchmarkt. Ein Bauchgefühl ist der Anfang eines Benchmarks, nie sein Ende.

Schnell – und Gates halten es so

• Auf dem Server gerendert, an der Edge gecachtSeiten kommen als HTML in der Sprache des Kunden an, und shop-core hält Listen- und Produktseiten in Valkey warm.
• Ein Byte-Budget in der CIEinstieg, Shell und jeder Route-Chunk der Storefront werden bei jeder Änderung an einem Budget gemessen, und das Budget kennt nur eine Richtung: nach unten. Jede Sprache kommt in einem eigenen Chunk, ein Kunde lädt also nur eine herunter.
• Ein Speed-Gate vor dem ReleaseEs baut main und die Änderung nebeneinander und lässt jede Seite durchfallen, die schwerer wird oder in Lighthouse beim Laden, bei der Layout-Verschiebung oder bei der Blockierzeit langsamer.
• Ein Worst-Case-GateJede Theme-Option am schwersten Anschlag, jeder Sektionstyp auf einmal, und der Shop darf trotzdem nicht langsam werden. Themes sind CSS-Variablen, ein Theme bringt also überhaupt kein JavaScript mit.
• Leichte BilderJedes Produktbild wird in AVIF-Varianten skaliert, und statische Dateien gehen vorkomprimiert mit brotli raus.

Zwei Hälften.
Eine harte Grenze.

Die meisten Plattformen legen sich pro Feature einen Dienst zu. Wir trennen an genau einer Stelle: die Shops auf der einen Seite, die Plattform auf der anderen. Jede Hälfte hat ihre eigene App, ihren eigenen Core, ihren eigenen Datenbank-Login und ihre eigene Hälfte des Schlüssels. Und die alte Regel gilt auf beiden Seiten: Nur ein Core schreibt.

• shop-core – die Zelle, in Java 25 und Spring BootDer einzige Schreiber für die Daten der Shops in PostgreSQL, Valkey und S3. Jede Admin-Änderung, jeder Import, jede Zahlung und jeder Shop-Job läuft über ihn. Er hängt nicht am öffentlichen Internet, prüft jeden Zahlungs-Webhook und jede Signatur selbst und öffnet die versiegelten Secrets der Shops.
• platform-core – die SteuerungsebeneDieselbe Codebasis, gebaut als zweite Anwendung mit eigenem Image: das Backend der Konsole, Abrechnung, Organisationen und Onboarding, die eigene Mail der Plattform und die Jobs der Steuerungsebene. Sein Datenbank-Login erreicht das Schema keines Shops, und er führt keine Migrationen aus.
• Die Zell-API dazwischenDie beiden Cores sprechen über zwei interne Türen miteinander, eine pro Richtung, jede mit einem eigenen Secret. Jede Tür speichert nur einen SHA-256 des Secrets, das sie annimmt, also hält kein Core etwas, das seine eigene Tür öffnet. Keine Anfrage eines Kunden wartet auf die Steuerungsebene.
• shop web – TanStack Start, React, serverseitig gerendertRendert jede Storefront in der Sprache des Kunden, den Adminbereich des Shops, das Admin-MCP und die Tür der Trade API. Er liest Valkey, dazu PostgreSQL über den eigenen Lese-Login des Shops, und schreibt nichts außer Anmelde-Sessions; jeder andere Schreibvorgang geht an shop-core.
• Die Konsole – eine eigene AppEine separate App mit eigenem Image für admin.cartsome.com, das Operator-MCP, die Formulare von cartsome.com und den Webhook von Stripe. Sie hat keinen Datenbanktreiber, hält keine Secrets irgendeines Shops und spricht nur mit platform-core.
• Die Edge – CloudFront und WAFSeiten werden an der Edge gecacht, Bilder kommen direkt aus S3. Der Load Balancer dahinter antwortet nur CloudFront und schickt jede Adresse an die App, die sie bedient, und eine Flut, die auf einen Shop zielt, wird schon an der Edge gestoppt, pro Shop-Adresse.
• Aurora PostgreSQL 18, rohes SQLKein ORM, nirgends. Auch die Volltextsuche läuft in PostgreSQL, in der Sprache des Kunden und nachsichtig bei Tippfehlern. Kein separater Suchcluster, den man babysitten muss.
• Valkey und S3Valkey hält die Seiten, die shop-core vorwärmt, bevor Kunden kommen. S3 hält Produktbilder (AVIF-Varianten), Theme-Schriften, einen Produktfeed pro Sprache und den Export eines Shops, der geht.
• Container auf ARMDie vier Dienste laufen auf ECS Fargate, auf Graviton, jeder aus seinem eigenen Image, und die Bild-Worker laufen auf Lambda, ebenfalls auf ARM. Terraform beschreibt alles, und nichts wird in einer Konsole zusammengeklickt.

Bilder, in der Warteschlange

Ein Shop, der einzieht, bringt Tausende Bilder mit, und ein neuer Shop soll niemandes Checkout bremsen, während sie berechnet werden. Darum berechnet shop-core sie nicht.

• Der Core reiht nur einShop-core legt jede Bildaufgabe auf SQS und hält die Antworten fest, sobald sie zurückkommen, in Stapeln, eine Transaktion pro Shop. Die Worker haben überhaupt keinen Datenbank-Login.
• Eine faire Warteschlange pro ShopJeder Shop ist eine eigene Gruppe in den SQS Fair Queues, mit einer interaktiven Spur für ein Bild, das ein Admin hochlädt, einer Massenspur für Importe und in jeder Spur einer Obergrenze pro Shop. Der große Import eines Shops drängelt sich nie vor das eine Foto eines anderen.
• Gleicher Encoder, mehr HändeDie Lambda-Worker kodieren mit demselben libvips wie der Core, ein Bild sieht also gleich aus, egal wer es berechnet hat. Downloads werden pro Quell-Host gedrosselt, damit der Server eines Lieferanten nicht überflutet wird.
• Einmal berechnet, überall genutztEin Bild wird am Hash seiner Bytes erkannt. Hat irgendein Shop in der Zelle dieselbe Quelle schon berechnet, verwenden die Worker dessen Dateien wieder, statt neu zu kodieren.
• Gebaut für den AnsturmDie Flotte skaliert hoch, wenn viele Shops auf einmal einziehen, und kostet im Leerlauf nichts, und der Adminbereich zeigt jeden Lauf live: erledigt, wiederverwendet, fehlgeschlagen, wartend und seinen Platz in der Warteschlange.

Das Ganze
auf einer Seite.

Wer mit wem spricht, vom Handy eines Kunden bis hinunter zu den Platten. Durchgezogene Linien tragen Anfragen und Schreibvorgänge; gestrichelte lesen nur.

Die Karte in Worten

1. Wer anklopft. Kunden (Menschen und KI-Shopping-Agenten), die Systeme anderer Firmen über die Trade API, der KI-Client eines Shopbetreibers, die Admins der Shops und die Operatoren von CartSome kommen alle über die Edge herein.
2. Die Edge. CloudFront cacht Seiten, liefert Bilder direkt aus S3, hält die Zertifikate für jede *.cartsome.com-Adresse und für die eigene Domain jedes Shops, und ihre WAF begrenzt jede Shop-Adresse für sich.
3. Der Load Balancer antwortet nur CloudFront. Er schickt die Adresse jedes Shops an shop web, admin.cartsome.com und die API von cartsome.com an die Konsole.
4. Shop web rendert die Storefront, den Adminbereich und das Admin-MCP, dazu ein öffentliches MCP für Shopping-Agenten, das jeder Shop selbst einschaltet, und die Tür der Trade API. Er liest PostgreSQL und Valkey und reicht jeden Schreibvorgang an shop-core weiter.
5. Die Konsole bedient admin.cartsome.com, das Operator-MCP, die Formulare von cartsome.com und den Webhook von Stripe und spricht nur mit platform-core.
6. Shop-core ist die Zelle: der einzige Schreiber für die Daten der Shops in PostgreSQL, Valkey und S3. Er prüft Webhooks, öffnet den Tresor der Shops und legt Bildarbeit in die Warteschlangen.
7. Platform-core ist die Steuerungsebene: Organisationen, Onboarding, Abrechnung, die Mail der Plattform und ihre Jobs, über einen eigenen Datenbank-Login. Er erreicht die Zelle nur über die Zell-API, mit einem Secret je Richtung.
8. Die Bild-Worker holen Aufgaben aus den SQS Fair Queues, eine Gruppe pro Shop, kodieren sie auf Lambda und schreiben die Dateien nach S3.
9. Die Daten: Aurora PostgreSQL mit dem Plattformschema und einem Schema pro Shop, Valkey mit den warmen Seiten jedes Shops und S3 für Bilder, Schriften, Feeds und Exporte.
10. Zelle 1 betreibt all das heute in Stockholm. Zelle 2 ist derselbe Stack noch einmal, geöffnet, wenn er gebraucht wird, in der AWS-Region, die ihre Shops brauchen.

Das Leben einer Anfrage

Dein Shop.
Dein Schema.

Viele Shops, ein Datenbankcluster, null geteilte Tabellen. Jeder Shop bekommt sein eigenes PostgreSQL-Schema, und die Datenbank selbst hält die Nachbarn draußen.

• Ein Schema und zwei LoginsShop n lebt in seinem eigenen Schema, gebaut aus einer gemeinsamen Vorlage. Shop web meldet sich mit dem Lese-Login des Shops an, shop-core mit seinem Schreib-Login, und keiner von beiden erreicht einen anderen Shop. Der Login von platform-core erreicht überhaupt keinen Shop.
• Keine Mandantenspalte zum VergessenTabellen behalten im Schema ihre Form: keine Mandanten-ID in jeder Zeile, kein Filter, den eine Abfrage vergessen könnte. Fremdschlüssel verlassen das Schema nie.
• Abfragen nennen nie ein SchemaDer Login, mit dem sich eine Verbindung anmeldet, wählt den Shop, und eine Verbindung bedient ihr Leben lang nur diesen einen. Ein statischer Check lässt den Build scheitern, sobald eine Abfrage einen Schemanamen enthält.
• Pools, die bei Bedarf öffnenJeder Shop bekommt eigene kleine Verbindungspools, geöffnet bei seiner ersten Anfrage und geschlossen, sobald er still wird. So begrenzt das Verbindungsbudget der Datenbank, wie viele Shops gleichzeitig beschäftigt sind, nicht wie viele es gibt. Jeder Shop hat auch sein eigenes Anfragebudget, und ein Shop, der es überschreitet, soll es später noch einmal versuchen – nur er.
• Caches und Links kennen ihren ShopJeder Cache-Eintrag ist nach Shop geschlüsselt. Sessions, Bestelllinks, Geschenkkarten-Links und Abmelde-Tokens werden mit den eigenen Schlüsseln des Shops signiert, der Link des einen Shops wird beim anderen also abgelehnt.
• Eine Leak-Suite, die an allen Türen rütteltSie legt für zwei Shops in jeder mandantenbezogenen Tabelle eine Zeile an und liest jede als der jeweils andere, über die Verbindungen von shop-core und von shop web, und ruft dann jeden Core-Endpunkt auf, der eine ID annimmt. Sie läuft bei jeder Änderung.

Zellen statt
eines großen Klumpens.

Wir skalieren über Zellen. Eine Zelle ist ein kompletter Stack: ihr eigener Aurora-Cluster, ihr eigenes shop-core und shop web, die Schemas ihrer Shops, ihre eigenen Bild-Warteschlangen und Worker. Ist eine voll, öffnen wir die nächste. Die Steuerungsebene steht abseits und spricht mit einer Zelle nur über die Zell-API. Die Plattform wächst; keine einzelne Zelle muss es.

Was „voll“ bedeutet

Eine Zelle nimmt keinen neuen Shop mehr an, sobald eines dieser Signale seine Obergrenze erreicht. Bei 80 Prozent einer beliebigen Obergrenze planen wir die nächste Zelle; die Zellenseite der Konsole zeigt den aktuellen Füllstand und nennt das Signal.

• Ein großer Shop bekommt eine eigene ZelleEin Shop, der einer geteilten Zelle entwächst, bekommt eine Zelle für sich allein. Autotools bleibt in Zelle 1.
• Von Grund auf portabelAlles, was einem Shop gehört, trägt seinen Namen: sein Schema mit eigenen Schlüsseln und Sequenzen, seine Tresorzeilen, versiegelt unter seiner Organisation, seine Cache-Schlüssel, seine Feed-Dateien. Nichts bindet ihn an die Zelle, in der er geboren wurde.
• Ehrlich gesagtEinen Shop von einer Zelle in eine andere umzuziehen, ist noch kein Knopfdruck. Das kommt mit der zweiten Zelle, und im Weg steht nichts Geteiltes.

Standardmäßig dicht.
Langweilig mit Absicht.

Das Spannende an einem Shop sollten die Produkte sein. Hier kommt der langweilige Teil, so genau, wie wir ihn gern veröffentlichen.

• Isolation in der DatenbankSchemas und Logins pro Shop, durchgesetzt von PostgreSQL-Grants statt von Code, der hoffentlich an einen Filter denkt. Die Steuerungsebene hat einen eigenen Login, und der Login von shop-core hat keinerlei Recht auf die Tabellen der Steuerungsebene.
• Ein versiegelter Tresor pro OrganisationZahlungs-, Versand- und Mail-Schlüssel liegen im Tresor, jeder mit AES-256-GCM versiegelt, unter einem frischen Datenschlüssel aus einem KMS-Schlüssel, den nur die beiden Cores benutzen dürfen, und an seine Organisation und seinen Namen gebunden. Eine kopierte Zeile lässt sich nirgends öffnen. Secrets leben nie im Code.
• Jeder Core hält eine Hälfte des SchlüsselsShop-core öffnet die Secrets der Shops und platform-core die der Plattform selbst, etwa ihre Schlüssel für Stripe und die Buchhaltung. Die Policy des Schlüssels verweigert jedem der beiden die Hälfte des anderen.
• Zwei Türen, zwei SecretsDie Cores rufen einander mit einem Secret pro Richtung auf, und jede Tür speichert nur den SHA-256 des Secrets, das sie annimmt, also hält kein Core, was seine eigene Tür öffnet.
• Passkeys für die Leute, die alles betreibenOperatoren melden sich mit Passkeys an und bestätigen jede Änderung an der Plattform mit einem frischen. Zugriff zu vergeben ist nie ein Tool: Kein Token und keine KI kann einen Operator hinzufügen.
• KI-Schreibzugriffe, die du siehst und zurücknehmen kannstMassenänderungen und nach außen wirkende Schreibvorgänge laufen zuerst als Vorschau und werden erst nach einer Bestätigung angewendet, die an das Gesehene gebunden ist; hat sich der Shop dazwischen geändert, wird sie abgelehnt. Danach liefert jeder Schreibvorgang gleich mit, wie er sich rückgängig machen lässt.
• Tokens mit dem kleinsten SchlüsselbundJedes Admin-MCP-Token und jede Verbindung trägt Berechtigungen und sieht nur die Tools, die diese erlauben. Erstattungen, Secrets und Admins brauchen jeweils eine eigene Berechtigung.
• Kundendaten bleiben aus dem Chat rausDie Antwort eines Tools geht an den KI-Anbieter, darum lassen Antworten Namen, E-Mail-Adressen, Telefonnummern, Anschriften und Steuernummern von Kunden weg. Die wenigen ausdrücklichen Ausnahmen, etwa der Wortlaut eines Bestellkommentars, sind in den Regeln benannt.
• Eine Spur für jeden Operator-EingriffJede Änderung eines Operators und jeder Lesezugriff über Shops hinweg landet im Audit-Trail der Plattform.

314 Shop­funktionen.
Null Formulare.

Das Admin-MCP gibt einem KI-Client 314 Shopfunktionen, und jede davon gibt es auch im Adminbereich im Web. Verbinde Claude, ChatGPT, Cursor, Gemini oder jeden anderen MCP-Client per Anmeldung oder mit einem eingefügten Token. Der Schalter steht auf Aus, bis ein Admin ihn umlegt.

Das Sicherheitsmodell

Berechtigungen formen die Angriffsfläche

Ein Token sieht nur die Tools, die seine Berechtigungen hergeben, ein enges Token ist also eine kleine Angriffsfläche und zugleich eine kleine Macht. Tags und Menüs sind getrennte Berechtigungen, weil ein veröffentlichtes Menü sofort ändert, was Kunden sehen. Einen Beitrag entwerfen und ihn veröffentlichen: zwei Berechtigungen. Nichts, was eine KI tun kann, bestätigt eine Buchung in der Buchhaltung; das macht ein Mensch im Adminbereich.

Beispiele

↑ Beispielanfragen · die genannten Tools gibt es wirklich

Shop zu Shop.
Ohne Zwischenhändler.

Jeder Shop kann für seine Geschäftskunden eine Trade API öffnen: eine neutrale, versionierte HTTP-API, die deren eigene Systeme aufrufen, um den Katalog zu ihren Preisen zu lesen und Bestellungen aufzugeben. Und jeder Shop kann bei jedem anderen Shop einkaufen, der sie spricht – als ein Lieferant mehr.

• Ein Protokoll, keine MarkeDiscovery unter /.well-known/trade-api, die API unter /trade/v1, ein Dokument in OpenAPI 3.1 und nirgends darin der Name einer Plattform. Ein Verkäufer, der sie spricht, ist ein Verkäufer, egal was bei ihm läuft.
• Schlüssel macht der Kunde selbstEin Admin gibt ein Unternehmen als Händlerkonto frei, legt die Preisstufe fest, zu der es einkauft, und erlaubt die API. Der Kunde erstellt und widerruft seine Schlüssel selbst auf seiner Kontoseite; der Shop behält nur einen Hash, und kein Admin bekommt je einen Schlüssel zu sehen.
• Ihre Preise, echter BestandJedes Produkt kostet genau das, was die Storefront diesem Kunden im angemeldeten Zustand zeigt, daneben der verkaufbare Bestand der Storefront, gedeckelt.
• Bestellungen, die sich nicht verdoppelnJede Bestellung trägt einen Idempotenzschlüssel: Derselbe Schlüssel mit demselben Inhalt liefert die erste Bestellung zurück, ein anderer Inhalt wird abgelehnt. Ab da ist es eine ganz normale Bestellung des Shops, wie gewohnt in Rechnung gestellt, gepackt und verschickt.
• Bei jedem Shop einkaufenEin generischer Trade-Lieferanten-Connector macht aus einem Verkäufer einen Lieferanten mehr: Bestand und Preise werden nach Zeitplan gelesen, Bestellungen gehen unter einem Idempotenzschlüssel raus, Bestätigungen und Lieferungen werden zurückgelesen. Er ruft die öffentliche Adresse des Verkäufers auf wie jeder Fremde, nie über eine Abkürzung innerhalb der Zelle.
• Kurze LeineLimits pro Schlüssel für Anfragen und Bestellungen, eine Obergrenze für unbezahlte Bestellungen, und der Schlüssel des einen Shops ist beim anderen ein Fremder. Jeder Eingriff an Konten, Zugängen und Schlüsseln landet im Audit-Trail des Shops, und der Kunde erfährt von jedem neuen Schlüssel.
• Ehrlich gesagtNoch keine Webhooks: Ein Käufer fragt per Polling ab, was sich geändert hat. Bezahlt wird vorerst per Vorkasse-Rechnung; Kauf auf Rechnung kommt später.

Ein Shop in Minuten.
Offen, wenn du so weit bist.

Kein Installer, kein Server zum Aussuchen. Wir legen deine Organisation in der Plattformkonsole an, der Shop baut sich selbst, und ab da übernimmst du.

Sprachen auf Knopfdruck. Ein neuer Shop startet mit seiner Hauptsprache und Estnisch. Schalte jede der 8 ein, sobald ihre Übersetzungen fertig sind, unter Einstellungen › Sprachen oder mit manage_languages. Ein Produkt behält in jeder Sprache dieselbe Adresse.

Bring deinen Shop mit.
Google zieht mit.

Autotools ist von Shopify umgezogen und betreibt heute 25.000+ Produkte auf CartSome. Die Werkzeuge, die es dafür brauchte, bekommst du auch.

• Produkte, von KI konvertiert und von einem Menschen geprüftDein KI-Client liest das Importformat, das Vokabular des Shops und die Daten des Lieferanten und schreibt eine Datei, die der eigene Validator des Shops akzeptiert. Er hält an und benennt jede Lücke, statt eine Kategorie zu erfinden. Ein Mensch prüft, was zugeordnet wurde und was neu ist, und angewendet wird nur ein Import, den er ausdrücklich benennt, indem er eine Vorschau bestätigt, die er gelesen hat.
• Versteckt, bis du „zeigen“ sagstNeue Produkte kommen versteckt an. Ein einziger Aufruf mit Vorschau macht ein ganzes Sortiment von bis zu 5.000 sichtbar.
• Alte Adressen, weitergeleitetGib den Weiterleitungsexport von Shopify oder irgendeine zweispaltige Liste ab. Jede Zeile wird so zugeordnet, wie die Storefront Adressen auflöst, Ketten werden zu einer einzigen permanenten Weiterleitung zusammengefaltet, und jedes Ziel wird gegen die eigenen Seiten des Shops geprüft.
• Das Shopify-UmzugskitUnsere Umzugswerkzeuge machen einen Snapshot der alten Website, bauen die Zuordnung von alten zu neuen Adressen samt Bericht über den Rest und fragen dann beim neuen Shop jede Zeile ab: Verlangt ist genau eine 301 auf eine Seite, die antwortet. Autotools hat so 12.598 alte Adressen mitgenommen.
• Newsletter-Einwilligungen, einmal umgezogenDie Marketingliste zieht in das Einwilligungsregister des Shops um, mit der Antwort jeder Person genau so, wie sie gegeben wurde. Beim Umzug wird nichts verschickt.
• Was zurückbleibtFrühere Bestellungen bleiben auf der alten Plattform. Bewahre ihren Export für deine Buchhaltung auf.

Ein Beispielumzug

↑ Ein Beispiel · die Größe deines Katalogs bestimmt das Tempo