Shopify Hydrogen Agentur: Architektur-Kriterien für die Auswahl

Problem Statement

```mermaid graph LR A[Input] --> B[Process] B --> C[Output] ``` ```typescript // Configuration Example export const config = { environment: 'production', apiEndpoint: 'https://api.example.com', timeout: 5000, retries: 3 }; ```

Viele Teams suchen eine Shopify Hydrogen Agentur, weil sie „Headless“ wollen. Und dann endet es in einem React-Projekt, das sich zwar modern anfühlt, aber architektonisch nicht trägt. Typische Symptome: Der Store ist schnell auf der Startseite, aber langsam in Collections. Die Content-Pipeline ist chaotisch. Releases passieren mit Bauchschmerzen. Und niemand kann sauber erklären, wo eigentlich die Wahrheit über Produkte, Preise, Verfügbarkeiten und Content liegt.

Hydrogen ist nicht „nur ein Frontend“. Hydrogen ist ein architekturelles Commitment: Datenpfade, Caching, Rendering-Strategien, Edge-Deployment, Observability und Integrationen müssen zusammenpassen. Genau daran entscheidet sich, ob eine Agentur den Job kann oder nur Komponenten zusammenklickt.

Ich habe in den letzten Projekten zwei Muster gesehen. Erstens: Agenturen, die Storefront-UI liefern, aber Integrationen und Betrieb ausblenden. Zweitens: Agenturen, die „Enterprise“ versprechen, aber keine klare Antwort auf Zuständigkeiten, Error-Budgets und Datenkonsistenz haben. Beides kostet später Wochen. Manchmal Monate.

Technical Background

Hydrogen basiert auf Remix und ist eng an das Shopify-Ökosystem gekoppelt. Der technische Kern ist simpel. Der Teufel sitzt in den Details: Storefront API, Cart/Checkout-Flows, Caching am Edge, asynchrone Integrationen (ERP/PIM/OMS), sowie Content (oft über ein CMS) und Suchsysteme.

Wenn ich eine Hydrogen-Agentur bewerte, schaue ich weniger auf Pixel-Perfektion. Ich schaue auf ihre Systemgrenzen. Wo endet Shopify, wo beginnt das externe System? Wer hat die Datenhoheit? Wie werden Fehler isoliert? Und: Wie wird das Ganze betrieben, wenn am Freitagabend eine Preisregel kippt?

Ein paar Architektur-Bausteine, die in der Praxis fast immer auftauchen:

Baustein	Warum relevant	Woran du eine gute Agentur erkennst
Storefront API Nutzung	Performance, Datenumfang, Rate Limits	Query-Disziplin, Fragment-Strategie, klare Fetch-Policies
Caching & Revalidation	TTFB, Stabilität bei Last, Kosten	Konkrete TTL/Tagging-Modelle, Umgang mit Stale-Content
Edge Deployment	Latenz, globale Nutzer, Failover	Rollout-Strategie, Canary/Blue-Green, Incident-Prozesse
Integrationen (ERP/PIM/OMS)	Preis/Bestand/Versand, Datenqualität	Event-getrieben, idempotent, klare Ownership der Daten
Observability	Debugging, SLOs, echte Betriebssicherheit	Tracing, strukturierte Logs, sinnvolle SLIs (p95/p99)

Nebenbei bemerkt: Viele Pitch-Decks reden über „Composable Commerce“. Interessanter ist: Kann die Agentur erklären, wie sie Schema-Änderungen in der Storefront API abfedert? Oder wie sie bei einem defekten Fulfillment-Webhook verhindert, dass der Checkout-Kanal „still“ kaputtgeht?

Zur Orientierung hier ein typisches Zielbild. Wichtig: Das Diagramm zeigt nicht „die“ richtige Lösung, sondern eine saubere Trennung der Verantwortlichkeiten.

Architekturdiagramm (Mermaid):