AURA&CO: Entwicklung eines Multi-Region-Fashion-Storefronts auf Medusa

Plattform

Medusa 2.18

Storefront

Next.js 15 · React 19

Datenebene

PostgreSQL · Redis · Meilisearch

Regionen

Indien (₹) und Vereinigte Staaten ($)

Live-Site

AURA&CO Storefront

Medusa liefert die Commerce-Basiselemente — Produkte, Varianten, Warenkörbe, Bestellungen, Bestand, Zahlungen, Regionen — als Module hinter einer API und endet dort bewusst. Was fehlt, ist alles, was ein Fashion-Händler unter dem Shop versteht: ein dreistufiges Mega-Menü, filterbare Produktattribute, Größentabellen, redaktionelle Startseitenbereiche, Store-Bestandssuche, Bewertungen. AURA&CO ist unser Referenzprojekt für genau diese Lücke — ein Fashion-, Homeware- und Kids-Katalog mit fünf Abteilungen über zwei Regionen, bei dem jedes handelsrelevante Verhalten ein eigenes Modul ist, das wir entwickelt haben, statt auf ein Plugin zu hoffen.

Warum Medusa für kataloglastigen Handel

Das Argument für Medusa ist Kontrolle ohne leeres Blatt. Eine SaaS-Plattform liefert ein Checkout, das Sie nicht anpassen können, und ein Datenmodell, an das Sie Ihren Katalog anpassen müssen. Ein Framework gibt Ihnen alles zum Selberbauen. Medusa liegt dazwischen: Der Commerce-Kern ist ausgereift, getestet und jemand anderes kümmert sich um die Wartung, während alles Branchenspezifische als eigenes Modul mit eigenen Tabellen, Migrationen und Services integriert wird — und vom System als vollwertig behandelt wird.

Genau diese Trennung prägt die Architektur hier. Sieben eigene Module decken den Funktionsumfang eines mittelgroßen Fashion-Händlers ab — ohne dass wir Medusa selbst forken oder patchen mussten.

Das Backend: Sieben Module für den Handel

Katalog: Attribute, Facetten und Größentabellen

Fashion-Produkte haben Attribute, zu denen Medusa keine Meinung hat — Passform, Ausschnitt, Ärmellänge, Kleidungs­länge, Material, Muster, Anlass, Nachhaltigkeit. Wir haben sie als Attributsystem ähnlich wie bei Magento EAV modelliert: eine Definition mit maschinenlesbarem Code, Eingabetyp und Werteliste, verknüpft mit Produkten und auf Kategorien begrenzt.

Der Vorteil der Zentralisierung: Eine Definition steuert drei Oberflächen gleichzeitig. Ein Schalter legt fest, ob ein Attribut im Produktseiten-Akkordeon angezeigt wird (und in welchem — Beschreibung, Materialien oder Details), ein zweiter, ob es als Facette auf Kategorieseiten erscheint, ein dritter, ob es in den Suchindex aufgenommen wird. „Ausschnitt“ einmal anlegen, und es erscheint konsistent an allen drei Stellen, statt dreimal zu existieren und auseinanderzulaufen.

• Kategoriespezifische Facetten — die Filter bei Dresses unterscheiden sich von denen bei Bedding, weil Attribute an Kategorien gebunden sind und nicht global gelten
• Größentabellen — als Zeilen gespeicherte Maßtabellen, pro Kategorie zugeordnet, von der Produktseite aus abrufbar
• Produktbezogene Ausnahmen — Freitext-Attributwerte für Fälle, die sich nicht mit festen Wertelisten abbilden lassen

Inhalte und Navigation: Die Bereiche, die das Merchandising-Team steuert

Zwei Module sorgen dafür, dass das Shop-Team für saisonale Änderungen keinen Entwickler benötigt. Das Content-Modul bildet eine Seite als geordnete Liste typisierter Abschnitte ab — Ankündigungsleiste, Hero-Slider, Sale-Teaser, Stage-Teaser, Produktkarussell, Banner-Grid, Kategoriekacheln, Rich Text, USP-Leiste, Newsletter. Jeder Abschnitt enthält eine JSON-Konfiguration, ein optionales Zeitfenster für die Ausspielung und eine optionale Regionsbeschränkung. So kann z. B. ein Diwali-Banner vorab erstellt, auf die Region Indien begrenzt und automatisch ein- und ausgeblendet werden.

Abschnittskonfigurationen liegen als JSON vor, nicht als Spalten, da zehn Abschnittstypen kaum gemeinsame Felder haben. Der Verzicht auf Schema-Validierung wird an beiden Enden ausgeglichen: Im Admin gibt es pro Abschnittstyp ein typisiertes Formular, im Storefront einen typisierten Renderer.

Das Navigation-Modul verwaltet das Mega-Menü als dreistufigen Baum: oberste Abteilung, Spaltenüberschrift, Link. Links verweisen entweder auf eine Kategorie oder eine URL. Jeder Knoten kann für die Darstellung in der Akzentfarbe markiert werden. Das Werbepanel rechts im Menü — Bild, Überschrift und Call-to-Action — ist Teil derselben Datenstruktur.

Wunschliste, Bewertungen und Filialbestand

Die übrigen Module lösen jeweils ein Problem, das erst bei der Umsetzung seinen Aufwand zeigt.

• Wunschliste — funktioniert für Gäste mit einem anonymen Token und wird beim Login mit der Kundenliste zusammengeführt. Ohne diese Zusammenführung gehen alle gespeicherten Artikel beim Registrieren verloren — genau in dem Moment, in dem der Kunde sich entscheidet.
• Bewertungen — werden auf das Produkt und nicht auf die Variante bezogen, damit fünf Bewertungen nicht auf fünf Größen verteilt werden. Neue Bewertungen landen als ausstehend und erscheinen erst nach Freigabe durch einen Moderator im Storefront. Das „verifizierter Käufer“-Abzeichen wird bei der Abgabe gegen die Bestellhistorie geprüft und gespeichert, sodass eine spätere Rückerstattung es nicht nachträglich entfernt.
• Filialsuche — jede Filiale ist mit einem Medusa-Lagerstandort verknüpft, sodass „im Geschäft finden“ denselben Bestand abfragt, den auch der Checkout reserviert — und nicht eine zweite, abweichende Lagerstatistik.

Die Datenbank-Indizes spiegeln die Logik im Code: Bewertungen sind auf dem Storefront-Hotpath (freigegebene Bewertungen für ein Produkt), in der Moderationswarteschlange und mit einem partiellen eindeutigen Index versehen, der eine Bewertung pro Kunde und Produkt zulässt, Gäste aber nicht einschränkt — da Gäste keine Identität haben, auf die eingeschränkt werden könnte.

Das Storefront: Struktur und Routing

Das Storefront basiert auf Next.js 15 mit App Router und rendert standardmäßig auf dem Server. Jede Route ist unter einem Länderkürzel verschachtelt, sodass Region, Währung und verfügbare Zahlungsarten aus der URL abgeleitet werden — nicht aus einem Cookie, das ein Crawler nie setzt. /in/ zeigt Preise in Rupien, /us/ in Dollar, beide vollständig indexierbar.

Kategorien-URLs sind bewusst flach gehalten: /ladies-dresses.html statt /categories/ladies-dresses. Eine Catch-all-Route löst sie nach den benannten Routen auf, sodass /cart und /account Vorrang haben. Produkte liegen nur in Blattkategorien, daher fasst eine Abteilungsauflistung den gesamten Unterbaum zusammen — der Baum wird aus der flachen Kategorieliste aufgebaut, da die API Kindbeziehungen nur eine Ebene tief liefert.

• Startseite — vom Admin zusammengestellte, geordnete und terminierte Abschnitte
• Abteilungs- und Kategorielisten — 36 pro Seite, mit Facetten, Unterkategoriekacheln und SEO-Text
• Produktseiten — Auswahl von Variante und Größe, Größentabelle, Attribut-Akkordeons, Bewertungen, Filialsuche, „Andere kauften auch“, zuletzt angesehen
• Suche — vollständige Ergebnisseite plus Autovervollständigung im Header
• Favoriten, Filialen und CMS-Seiten — Filialsuche, Wunschliste und redaktionelle Inhalte
• Warenkorb, dreistufiger Checkout und Konten — Adressen, Bestellhistorie, Bestelldetails und Bestellübertragung zwischen Konten

Inhalte werden zwischengespeichert und statisch ausgeliefert, dann per Tag invalidiert: Ein Backend-Abonnent benachrichtigt das Storefront, wenn ein Admin speichert, und die betroffenen Tags werden entfernt. Ohne diesen Mechanismus speichert ein Merchandiser ein Banner, aber die Seite zeigt weiter die alte Version — was für ihn wie „meine Änderung hat nichts bewirkt“ aussieht.

Suche, Facettierung und Merchandising

Listing und Suche laufen als identische Anfrage gegen einen Meilisearch-Index. Karten werden direkt aus den zurückgegebenen Dokumenten gerendert, sodass eine Seite mit 36 Produkten nur eine Anfrage benötigt — nicht eine Suche plus einen Abruf pro Karte. Facet-Zählungen kommen direkt mit den Treffern, ohne zweite Aggregation. Preise für beide Währungen, Bestand nach Größe, Farbkombinationen, Labels und Bewertungen sind im Dokument enthalten. Sortierung nach Bewertung funktioniert, weil Produkte ohne Bewertung mit null indiziert werden und automatisch nach unten rutschen — ohne Filterung.

Die Empfehlungsleiste ist der Bereich, auf den wir besonders achten. „Andere kauften auch“ basiert auf realer Bestellhistorie: Es werden Bestellungen mit diesem Produkt gesucht, die weiteren Artikel gezählt und nach Häufigkeit sortiert. Ist die Historie dünn, wird aus derselben Kategorie aufgefüllt. Die API gibt an, welche Artikel aus welcher Quelle stammen, sodass das Storefront die Leiste korrekt kennzeichnen kann — und nicht Kaufdaten vortäuscht, die nicht existieren. Eine Neuheitenleiste als Empfehlung zu deklarieren, ist eine irreführende Überschrift.

Performance: Was die Architektur bringt

Serverseitiges Rendering, eine einzige Suchanfrage pro Listing, Bildoptimierung am Framework-Rand und kein clientseitiger Daten-Wasserfall ergeben messbare Vorteile. Gemessen auf der Startseite mit Google PageSpeed Insights:

Ein Cumulative Layout Shift von null auf einer bildlastigen Fashion-Startseite ist kein Zufall — jeder Medienplatz reserviert seine Abmessungen, bevor das Bild geladen wird. Eine Total Blocking Time von 40 ms auf einem gedrosselten Mittelklasse-Android ist das Ergebnis von serverseitigem Rendering: Es bleibt kaum JavaScript zum Ausführen, weil die Seite nicht als leeres Gerüst zum Hydrieren ankommt. Diese Disziplin wenden wir auch bei Page-Speed-Optimierungen auf jeder Plattform an.

Was das Admin-Team tatsächlich bekommt

Eigene Module bringen wenig, wenn ihre Bedienung SQL erfordert. Jedes Modul erhält eine Administrationsoberfläche direkt im Medusa-Dashboard, nicht als angeflanschte Zweitlösung: Attribut- und Größentabellenverwaltung mit Kategorie-spezifischer Facettenauswahl, ein Bereichs-Builder für die flexible Gestaltung und Terminierung von Start- und Landingpages, eine per Drag-and-drop sortierbare Navigationsstruktur, die Moderationswarteschlange für Bewertungen sowie die Shopverwaltung.

Produkt- und Kategorieseiten erhalten direkt integrierte Widgets – Attributwerte am Produkt, Inhalts- und Facettenkonfiguration an der Kategorie – sodass die Arbeit dort stattfindet, wo das Merchandising-Team ohnehin ist. Das ist der Praxistest für einen composable Ansatz: Das Einkaufsteam ändert den Shop selbstständig, ohne ein Ticket einzureichen, und das Engineering-Team wird nicht zum Engpass für ein Banner.

Die benennenswerten Abwägungen

Composable ist nicht kostenlos. Sie verantworten die selbst entwickelten Module, deren Migrationen und deren Upgrades. Redis ist ab mehr als einem Prozess unverzichtbar – Cache, Event-Bus und Workflow-Engine laufen darauf, weil die In-Memory-Standardeinstellungen Ereignisse verlieren, sobald Server und Worker getrennt werden. Die Suche ist ein zweites System, das betrieben und neu indiziert werden muss. Die Co-Purchase-Rangfolge wird im Arbeitsspeicher über einen begrenzten Zeitraum aktueller Bestellungen berechnet – bei dieser Kataloggröße sinnvoll, bei zehnfachem Volumen aber nicht mehr, dann sollte sie bei Abschluss einer Bestellung vorab berechnet werden.

Das spricht nicht gegen den Stack. Es spricht dafür, die Betriebskosten von Anfang an klar zu beziffern – so definieren wir den Umfang jeder headless commerce-Umsetzung.

Überlegen Sie Medusa für Ihren Katalog?

Wenn Sie einen composable Ansatz gegen eine SaaS-Lösung abwägen, ist die entscheidende Frage nicht die Plattform, sondern welche Teile Ihrer Commerce-Logik wirklich individuell sind und welche Standard. Sprechen Sie mit unserem Engineering-Team; wir melden uns innerhalb eines Werktags mit einer ehrlichen Einschätzung zu Umfang, Ablauf und Kosten.