Edge Computing und CDN-Architektur für globale Shops

1. Was Edge Functions und Edge Workers wirklich sind

Eine Edge Function (auch Edge Worker genannt) ist ein kleines Stück Code, das nicht auf einem zentralen Origin-Server läuft, sondern direkt auf einem CDN-Knoten in unmittelbarer Nähe des Nutzers, einem sogenannten Point of Presence (PoP). Technisch handelt es sich meist um V8-Isolates oder WebAssembly-Sandboxes, nicht um vollständige Container oder virtuelle Maschinen. Das erklärt den entscheidenden Vorteil: Kaltstartzeiten liegen im einstelligen Millisekundenbereich, weit unter denen klassischer Serverless-Funktionen wie AWS Lambda in einer festen Region. Die Laufzeitumgebung ist bewusst eingeschränkt: kein Dateisystemzugriff, kein persistenter Zustand zwischen Requests und ein striktes CPU-Zeitbudget von oft nur 10 bis 50 Millisekunden pro Anfrage.

Der Unterschied zum klassischen CDN ist fundamental. Ein traditionelles CDN liefert nur statische Assets aus einem Cache aus und leitet jede dynamische Anfrage unverändert an den Origin weiter. Ein Edge Worker hingegen kann Requests inspizieren, Header umschreiben, Antworten generieren und sogar externe APIs aufrufen, bevor überhaupt eine Verbindung zum Origin-Server aufgebaut wird. Für einen Magento-Shop bedeutet das: Logik, die früher zwingend in app/code auf dem Origin-Server laufen musste, etwa einfache Redirects oder Header-Anpassungen, kann jetzt näher am Nutzer und ohne Origin-Roundtrip ausgeführt werden.

2. Praxis-Use-Cases: A/B-Testing, Geo-Redirects und Bildtransformation

Drei Anwendungsfälle zeigen den praktischen Nutzen von Edge Functions in E-Commerce-Umgebungen besonders deutlich. Geolocation-Redirects leiten Besucher anhand ihrer IP-Adresse automatisch auf die passende Store-View um, noch bevor die Anfrage den Origin-Server erreicht. Das Ländercode-Feld, das die meisten CDN-Anbieter direkt am Edge bereitstellen, macht einen externen Geo-IP-Dienst überflüssig. Für A/B-Testing übernimmt der Edge Worker die Bucket-Zuweisung per Cookie: Ein Besucher wird beim ersten Kontakt zufällig einer Variante zugewiesen, die Zuweisung wird in einem Cookie persistiert und bei jedem weiteren Request konsistent ausgewertet, ganz ohne dass der Origin-Server involviert ist.

Die dritte Kategorie ist Bildtransformation an der Edge: Statt vorab jedes Produktbild in allen benötigten Formaten, Auflösungen und Kompressionsstufen zu generieren, übernimmt der Edge-Dienst die Transformation on-the-fly anhand von URL-Parametern und cached das Ergebnis anschließend am jeweiligen PoP. Das reduziert den Storage-Bedarf im Magento-Media-Verzeichnis drastisch und liefert automatisch das für das anfragende Gerät passende Format, etwa AVIF für moderne Browser und JPEG als Fallback. Der folgende Edge-Worker-Code kombiniert Geolocation-Redirect und A/B-Test-Bucketing in einer einzigen Funktion.

// Edge worker: geolocation redirect + A/B test bucketing
export default {
  async fetch(request, env, ctx) {
    const url = new URL(request.url);
    const country = request.cf?.country || request.headers.get('CF-IPCountry') || 'DE';

    // Region-based redirect to the correct store view
    const storeMap = { US: 'us_en', GB: 'uk_en', FR: 'fr_fr', DE: 'de_de' };
    const targetStore = storeMap[country] || 'de_de';

    if (url.pathname === '/' && !url.searchParams.has('store')) {
      const redirectUrl = new URL(`/${targetStore}${url.pathname}`, url.origin);
      return Response.redirect(redirectUrl.toString(), 302);
    }

    // Deterministic A/B bucket via cookie, assigned once per visitor
    let bucket = getCookie(request, 'ab_bucket');
    if (!bucket) {
      bucket = Math.random() < 0.5 ? 'control' : 'variant';
    }

    const response = await fetch(request);
    const newResponse = new Response(response.body, response);
    newResponse.headers.append('Set-Cookie', `ab_bucket=${bucket}; Path=/; Max-Age=2592000`);
    newResponse.headers.set('X-AB-Bucket', bucket);
    return newResponse;
  }
};

function getCookie(request, name) {
  const cookie = request.headers.get('Cookie') || '';
  const match = cookie.match(new RegExp(`${name}=([^;]+)`));
  return match ? match[1] : null;
}

Die Bildauslieferung selbst bleibt deklarativ im Template und kommt ohne eigene Edge-Funktion aus, sofern der CDN-Anbieter native Bildtransformation über URL-Parameter unterstützt:

<!-- Edge image transformation: resize, format and quality via URL params -->
<picture>
  <source
    type="image/avif"
    srcset="https://cdn.mironsoft.de/media/catalog/product/hero.jpg?width=800&format=avif&quality=75 1x,
            https://cdn.mironsoft.de/media/catalog/product/hero.jpg?width=1600&format=avif&quality=75 2x">
  <source
    type="image/webp"
    srcset="https://cdn.mironsoft.de/media/catalog/product/hero.jpg?width=800&format=webp&quality=80 1x,
            https://cdn.mironsoft.de/media/catalog/product/hero.jpg?width=1600&format=webp&quality=80 2x">
  <img
    src="https://cdn.mironsoft.de/media/catalog/product/hero.jpg?width=800&format=jpg&quality=80"
    width="800"
    height="450"
    loading="eager"
    fetchpriority="high"
    alt="Product hero image, transformed at the edge">
</picture>

3. Edge-Rendering vs. Origin-Rendering: der Trade-off

Nicht jede Logik gehört an die Edge. Der grundlegende Trade-off: Edge-Rendering ist extrem schnell und global verteilt, läuft aber in einer eingeschränkten Umgebung ohne Zugriff auf die volle Magento-Codebasis, ohne Datenbankverbindung, ohne PHP-Interpreter und ohne Zugriff auf den Objektmanager. Origin-Rendering hat vollen Zugriff auf Kundendaten, Preislogik, Lagerbestände und personalisierte Inhalte, ist dafür aber an die physische Serverposition gebunden und für weit entfernte Nutzer entsprechend langsamer. Die Kunst liegt darin, jede Anfrage der richtigen Ebene zuzuordnen, statt pauschal alles an die Edge oder alles an den Origin zu delegieren.

Eine bewährte Faustregel: Alles, was rein anhand von Request-Metadaten entscheidbar ist, etwa Land, Sprache, Gerät oder Cookie-Wert, gehört an die Edge. Alles, was Zugriff auf Kundenkonto, Warenkorb, Preisregeln oder Lagerbestand benötigt, bleibt am Origin oder wird über Edge Side Includes (ESI) in ein am Edge gecachtes HTML-Gerüst eingefügt. Magentos eigener Full Page Cache nutzt genau dieses Muster bereits lokal: Statische Blöcke werden gecacht, der Mini-Cart wird per AJAX nachgeladen. Bei einer CDN-Architektur wird dasselbe Prinzip nur eine Ebene weiter nach außen verschoben, auf globale PoPs statt auf den lokalen Varnish-Server.

<!-- Layout XML: mark block as edge-cacheable, exclude personalized block from edge cache -->
<page xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:noNamespaceSchemaLocation="urn:magento:framework:View/Layout/etc/page_configuration.xsd">
    <body>
        <referenceBlock name="product.info.main">
            <arguments>
                <!-- Fully cacheable at every edge PoP, region-agnostic -->
                <argument name="cache_lifetime" xsi:type="number">86400</argument>
            </arguments>
        </referenceBlock>

        <!-- Personalized block stays uncacheable, resolved at origin only -->
        <referenceBlock name="minicart.link" template="Magento_Checkout::cart/minicart.phtml">
            <arguments>
                <argument name="cache_lifetime" xsi:type="number">0</argument>
            </arguments>
        </referenceBlock>
    </body>
</page>

4. Latenzreduktion für global verteilte Kundschaft

Physik lässt sich nicht durch Software umgehen: Ein Datenpaket von Sydney nach Frankfurt benötigt allein durch die Signallaufzeit über Glasfaser rund 140 bis 160 Millisekunden pro Weg, selbst bei perfekter Netzwerkauslastung. Bei einem klassischen Origin-only-Setup mit Server in Deutschland bedeutet das für australische Kunden eine Round-Trip-Zeit von rund 300 Millisekunden allein für die Netzwerkstrecke, bevor der Server überhaupt mit der Verarbeitung beginnt. Mit TLS-Handshake, DNS-Auflösung und mehreren Requests für Assets summiert sich das schnell auf über eine Sekunde reine Netzwerklatenz vor dem ersten sichtbaren Pixel.

Ein globales CDN mit Edge-PoPs in Sydney, Singapur oder Tokio reduziert diese Distanz auf wenige Kilometer für den ersten Request. Der TLS-Handshake terminiert lokal am PoP, statische Assets werden aus dem lokalen Cache ausgeliefert, und selbst dynamische Anfragen profitieren von einer optimierten Backbone-Verbindung zwischen PoP und Origin, die deutlich stabiler ist als eine Verbindung über das öffentliche Internet. In der Praxis lässt sich die wahrgenommene Ladezeit für weit entfernte Nutzer dadurch oft um 40 bis 60 Prozent senken, ganz ohne Änderungen an der Magento-Anwendung selbst.

5. Multi-Region-Architektur für Magento in der Praxis

Magento selbst ist nicht für Multi-Master-Datenbankbetrieb über mehrere Regionen hinweg ausgelegt. Die MySQL-Datenbank und der Elasticsearch-Cluster bleiben in einer primären Region, typischerweise dort, wo der Großteil des Bestellvolumens anfällt. Für eine Multi-Region-Architektur bedeutet das: Der Origin-Server bleibt zentral, aber die Edge-Schicht wird global verteilt. Statische Assets, gecachte Kategorieseiten und Produktbilder werden an jedem PoP repliziert, während schreibende Operationen wie Checkout und Kontoverwaltung weiterhin über die zentrale Region laufen, meist mit einer zusätzlichen Latenz von 100 bis 200 Millisekunden für weit entfernte Nutzer.

Read-Replicas in Sekundärregionen sind für Magento nur mit Vorsicht sinnvoll, da der Großteil der Anwendungslogik von synchronen Lesevorgängen ausgeht und Replikationsverzögerungen zu inkonsistenten Lagerbeständen führen können. Ein pragmatischerer Ansatz: Die Edge-Schicht übernimmt möglichst viel der Last durch aggressives Caching von Kategorieseiten und Produktdetailseiten, während Checkout-Flows bewusst als origin-only markiert und nicht am Edge terminiert werden. Die folgende Konfiguration zeigt, wie ein Routing-Layer Regionen auf Origins und PoPs abbildet und im Fehlerfall automatisch auf die nächste gesunde Region ausweicht.

{
  "service": "mironsoft-edge-routing",
  "regions": [
    {
      "code": "eu-central",
      "origin": "https://origin-eu.mironsoft.de",
      "edgePops": ["fra", "ams", "par"],
      "primaryFor": ["DE", "AT", "CH", "FR", "NL"]
    },
    {
      "code": "us-east",
      "origin": "https://origin-us.mironsoft.de",
      "edgePops": ["iad", "ord", "atl"],
      "primaryFor": ["US", "CA"]
    },
    {
      "code": "apac",
      "origin": "https://origin-apac.mironsoft.de",
      "edgePops": ["sin", "nrt", "syd"],
      "primaryFor": ["SG", "JP", "AU"]
    }
  ],
  "failover": {
    "strategy": "nearest-healthy-region",
    "healthCheckPath": "/health",
    "healthCheckIntervalSeconds": 15
  },
  "database": {
    "mode": "single-write-region",
    "writeRegion": "eu-central",
    "readReplicas": ["us-east", "apac"]
  }
}

6. CDN-Cache-Strategie: TTLs, Surrogate Keys und Stale-While-Revalidate

Eine funktionierende CDN-Cache-Strategie unterscheidet konsequent zwischen dem Browser-Cache (Cache-Control) und dem Edge-Cache (Surrogate-Control beziehungsweise CDN-Cache-Control je nach Anbieter). Der Browser-Cache sollte kurz gehalten werden, oft nur wenige Minuten, damit Preisänderungen und Lagerbestände zeitnah sichtbar werden. Der Edge-Cache dagegen kann deutlich länger stehen bleiben, etwa 24 Stunden für Kategorieseiten, weil er durch gezielte Invalidierung bei Bedarf sofort geleert werden kann, statt auf den Ablauf der TTL warten zu müssen.

Stale-while-revalidate ist das Muster, das Nutzer vor langsamen Cache-Misses schützt: Der Edge-PoP liefert die zwischengespeicherte, leicht veraltete Version sofort aus und holt im Hintergrund eine frische Kopie vom Origin, die den Cache für den nächsten Request aktualisiert. So sieht kein einziger Nutzer eine langsame Origin-Antwort, selbst wenn der Cache-Eintrag technisch bereits abgelaufen ist. Für Magento-Shops mit stark schwankendem internationalem Traffic ist das der entscheidende Unterschied zwischen einer gleichmäßigen Antwortzeit und sporadischen Latenzspitzen direkt nach jeder Cache-Invalidierung.

#!/usr/bin/env bash
# Verify edge cache headers and purge a URL across all PoPs
set -euo pipefail

TARGET_URL="https://www.mironsoft.de/de_de/catalog/product/hero.jpg"

echo "Checking cache headers..."
curl -sI "$TARGET_URL" | grep -Ei 'cache-control|surrogate-control|x-cache|age'

# Surrogate-Control lets the edge cache longer than the browser cache
# Cache-Control: public, max-age=300
# Surrogate-Control: max-age=86400, stale-while-revalidate=3600

echo "Purging by surrogate key across all edge PoPs..."
curl -sX POST "https://api.cdn-provider.com/v1/purge" \
  -H "Authorization: Bearer ${CDN_API_TOKEN}" \
  -H "Content-Type: application/json" \
  -d '{"surrogate_keys": ["product-1234", "category-55"]}'

echo "Done. Propagation to all PoPs typically completes within seconds."

7. Cache-Invalidierung über mehrere PoPs hinweg

Der größte operative Unterschied zwischen einem einzelnen Varnish-Server und einem globalen CDN ist die Invalidierung. Bei einem lokalen Full Page Cache genügt ein PURGE-Request an einen einzigen Server. Bei einem CDN mit hunderten PoPs weltweit muss dieselbe Invalidierung an jeden einzelnen Knoten propagiert werden, was je nach Anbieter zwischen wenigen Sekunden und einer Minute dauern kann. Surrogate Keys, auch Cache-Tags genannt, lösen das Problem der granularen Invalidierung: Statt einzelne URLs zu purgen, wird jede Response mit Tags wie product-1234 oder category-55 versehen, sodass bei einer Preisänderung gezielt nur die betroffenen Seiten global invalidiert werden, nicht der gesamte Cache.

Ein Instant Purge ist bei den meisten CDN-Anbietern nicht wirklich instant: Es gibt praktisch immer eine kleine Propagationsverzögerung zwischen PoPs, in der ein Nutzer in Tokio bereits die neue Version sieht, während ein Nutzer in São Paulo noch die alte aus dem Cache erhält. Für preiskritische Inhalte wie Lagerbestand und Rabattaktionen sollte diese Verzögerung explizit in den Testplan einfließen. In Magento löst man das oft über einen Plugin-Hook auf afterSave bei Produkt- und Preisänderungen, der automatisch die passenden Surrogate Keys an die Invalidierungs-API des CDN sendet, statt manuell oder zeitgesteuert zu purgen.

8. Monitoring und Observability an der Edge

Edge Functions laufen per Definition verteilt über hunderte PoPs, was klassisches Server-Monitoring mit SSH-Zugriff und lokalen Logdateien unmöglich macht. Die meisten CDN-Anbieter bieten stattdessen aggregierte Metriken wie Requests pro PoP, Fehlerraten, CPU-Zeitverbrauch pro Invocation und Cache-Trefferquote nach Region. Entscheidend ist, diese Metriken mit den bestehenden Magento-Metriken zu korrelieren, etwa über eine gemeinsame Request-ID, die am Edge generiert und als Header an den Origin weitergereicht wird, sodass ein Request über die gesamte Kette von PoP bis Datenbank-Query nachvollziehbar bleibt.

Für Real User Monitoring (RUM) ist die Edge-Ebene ideal positioniert, weil sie die tatsächliche geografische Verteilung der Kundschaft ohne zusätzlichen Tracking-Code sieht. Viele CDN-Anbieter liefern regionale Latenz-Dashboards direkt mit, die zeigen, ob ein Performance-Problem am Origin liegt, erkennbar an hoher TTFB über alle Regionen hinweg, oder an einem einzelnen PoP, erkennbar an einem isolierten Latenz-Ausreißer nur in einer Region. Alerts auf Cache-Trefferquote pro Region sind ebenfalls sinnvoll: Ein plötzlicher Abfall in einer einzelnen Region deutet häufig auf eine fehlerhafte Cache-Konfiguration oder ein defektes Edge-Worker-Deployment für genau diesen PoP hin.

9. Edge- und CDN-Architektur im direkten Vergleich

Die folgende Übersicht fasst die zentralen Trade-offs zwischen Origin-Rendering und Edge-Rendering für eine international ausgerichtete Magento-Architektur zusammen. Keine der beiden Ebenen ersetzt die andere vollständig, die Empfehlung zeigt jeweils, welche Ebene für welchen Aspekt die bessere Wahl ist.

In der Praxis kombinieren die erfolgreichsten Multi-Region-Setups beide Ebenen gezielt: Edge für alles, was sich aus Request-Metadaten ableiten lässt, Origin für alles, was echten Zugriff auf Geschäftslogik und Kundendaten benötigt. Diese Aufteilung, konsequent umgesetzt, ist der Unterschied zwischen einem Shop, der in Sydney genauso schnell wirkt wie in Frankfurt, und einem Shop, der außerhalb Europas spürbar hinterherhinkt.

10. Zusammenfassung

Edge Computing verändert nicht die Kernlogik von Magento, sondern verlagert einen gezielten Teil der Anfrageverarbeitung dorthin, wo die Latenz tatsächlich entsteht: so nah wie möglich am Nutzer. Geolocation-Redirects, A/B-Test-Bucketing und Bildtransformation lassen sich vollständig an der Edge lösen, ohne den Origin-Server überhaupt zu kontaktieren. Für alles, was echten Zugriff auf Kundendaten, Preislogik oder Lagerbestand benötigt, bleibt der Origin-Server zuständig, ergänzt durch aggressives Edge-Caching mit granularer Invalidierung über Surrogate Keys.

Der entscheidende Erfolgsfaktor ist nicht die Wahl eines bestimmten CDN-Anbieters, sondern die konsequente Trennung zwischen edge-fähiger und origin-gebundener Logik, kombiniert mit durchgängigem Monitoring über beide Ebenen hinweg. Wer diese Architektur sauber umsetzt, senkt die Latenz für international verteilte Kundschaft spürbar, ohne die Komplexität der Magento-Kernanwendung selbst zu erhöhen.

11. FAQ: Edge Computing und CDN-Architektur für globale Shops