Welche Remote-Version lädt der Host?

Remote A 1.0.0 wurde veröffentlicht.
Remote A 1.1.0 wurde veröffentlicht.

Welche Version lädt der Host?

Die naheliegende Antwort lautet häufig: die Version, auf deren Adresse seine Konfiguration zeigt.

Host-Konfiguration
└── Remote A → /remote-a/1.0.0/remoteEntry.js

Soll anschließend Version 1.1.0 geladen werden, muss diese Zuordnung geändert werden:

Host-Konfiguration
└── Remote A → /remote-a/1.1.0/remoteEntry.js

Ist die Adresse Bestandteil des gebauten Host-Artefakts, benötigt der Wechsel einen neuen Host-Build und eine erneute Veröffentlichung des Hosts. Das Remote wurde zwar unabhängig veröffentlicht. Es ist in diesem Modell aber noch nicht unabhängig aktivierbar.

Ein alternatives Modell verschiebt die konkrete Versionszuordnung aus dem Host-Bundle:

Host
└── löst zur Laufzeit eine freigegebene Produktkomposition auf
    └── Remote A → Version 1.1.0

Für den Wechsel einer bereits bekannten und kompatiblen Remote-Version ist dann kein neuer Host-Code-Release notwendig. Stattdessen wird eine neue Produktkomposition aktiviert.

Das bedeutet jedoch nicht, dass keine Releaseentscheidung mehr stattfindet. Die Aktivierung der neuen Produktkomposition ist selbst eine kontrollierte Releaseentscheidung.

Der entscheidende Unterschied liegt zwischen Veröffentlichung und Aktivierung: Ein Remote-Team veröffentlicht ein unveränderliches Artefakt. Erst eine davon getrennte Freigabe- und Aktivierungsentscheidung bestimmt, für welchen Nutzungskontext dieses Artefakt Bestandteil des Produkts wird.

Der Host sollte daher nicht automatisch die neueste verfügbare Version laden. Er sollte eine ausdrücklich freigegebene und reproduzierbare Produktkomposition auflösen.

Unabhängig veröffentlicht werden einzelne Remotes. Aktiviert wird eine Produktkomposition.

Wann ein Versionswechsel einen Host-Release benötigt

Ob der Wechsel von Remote A 1.0.0 auf Remote A 1.1.0 einen Host-Release benötigt, hängt nicht allein davon ab, ob das Remote dynamisch geladen wird. Entscheidend ist, wo die konkrete Versionszuordnung verwaltet wird.

Bei einer statisch eingebetteten Adresse ist die Zuordnung Bestandteil des Host-Artefakts:

Host-Build
└── Remote A → Version 1.0.0

Eine Änderung auf Version 1.1.0 verändert den Host. Selbst wenn das Remote-Artefakt bereits unter einer erreichbaren Adresse liegt, muss der Host neu gebaut oder zumindest mit einer geänderten Konfiguration erneut veröffentlicht werden.

Wird die Produktkomposition dagegen extern aufgelöst, bleibt der Host-Code unverändert:

Host
└── lädt Composition ID
    └── Remote A → Version 1.1.0

Der Host benötigt dann lediglich die Fähigkeit, eine Produktkomposition aufzulösen und die darin referenzierten Artefakte zu laden. Der Wechsel von Version 1.0.0 auf 1.1.0 erfolgt durch die Aktivierung einer anderen Composition ID.

Kein Host-Code-Release bedeutet dabei nicht keine Kontrolle. Die Produktaktivierung ersetzt den Host-Release nicht durch Beliebigkeit, sondern durch eine eigene, explizite Freigabeebene.

Ein Host-Release kann weiterhin notwendig sein, wenn ein völlig neues Remote erstmals in die Produktstruktur aufgenommen wird, sich der Mountvertrag ändert oder neue Routen und Layoutbereiche ausschließlich im Host definiert werden können. Gleiches gilt, wenn der Host eine neue Version des Kompositionsmanifests verstehen muss, sich gemeinsam genutzte Laufzeitabhängigkeiten inkompatibel verändern oder das Remote Fähigkeiten voraussetzt, die der bisherige Host nicht bereitstellt.

Die externe Aktivierung entkoppelt den Wechsel kompatibler Versionen. Sie macht Host und Remote nicht magisch von ihren Integrationsverträgen unabhängig.

Veröffentlicht ist nicht aktiviert

Eine belastbare Aktivierungssteuerung beginnt mit einer sauberen Begriffstrennung:

Build
→ erzeugt ein Artefakt

Veröffentlichung
→ stellt das Artefakt unter einer eindeutigen Adresse bereit

Freigabe
→ bestätigt die Eignung für einen definierten Kontext

Aktivierung
→ ordnet eine freigegebene Produktkomposition einem Channel oder Nutzungskontext zu

Auflösung
→ liefert dem Host die aktive Produktkomposition

Laden
→ lädt die darin referenzierten Remote-Artefakte

Build und Veröffentlichung gehören zum Lebenszyklus des Remotes. Freigabe und Aktivierung gehören zum Lebenszyklus der Produktkomposition. Der Host führt die aktivierte Zuordnung aus.

Diese Trennung ist mehr als sprachliche Genauigkeit. Ohne sie verschwimmen technische Bereitstellung, fachliche Freigabe und wirksame Produktänderung zu einem unscharfen Begriff wie „Deployment“. Damit wird unklar, welcher Schritt tatsächlich stattgefunden hat.

Eine Veröffentlichung macht ein Remote-Artefakt verfügbar. Sie sagt noch nichts darüber aus, ob es für Produktion, einen bestimmten Markt, einen Mandanten oder eine Pilotgruppe geeignet ist.

Eine Freigabe bestätigt diese Eignung für einen definierten Kontext. Eine Aktivierung macht die freigegebene Produktkomposition in diesem Kontext wirksam.

Veröffentlicht ist nicht aktiviert.

Der Host sollte diese Freigabeentscheidung nicht durch immer mehr Länder-, Mandanten- oder Channel-Verzweigungen selbst treffen. Er sollte eine bereits getroffene Entscheidung reproduzierbar ausführen.

Unveränderliche Artefakte statt latest

Damit eine Produktkomposition später rekonstruiert werden kann, müssen ihre Bestandteile eindeutig identifizierbar bleiben.

Ein einfaches Grundmodell sieht so aus:

/remote-a/1.0.0/remoteEntry.js
/remote-a/1.1.0/remoteEntry.js

Version 1.0.0 bleibt unter ihrer Adresse unverändert verfügbar, nachdem Version 1.1.0 veröffentlicht wurde. Eine Fehlerkorrektur überschreibt Version 1.1.0 nicht, sondern erzeugt ein neues Artefakt:

/remote-a/1.1.1/remoteEntry.js

Eine veröffentlichte Adresse darf später nicht auf andere Inhalte zeigen. Andernfalls lässt sich aus einer gespeicherten URL nicht mehr ableiten, welche konkreten Bytes zu einem früheren Zeitpunkt ausgeliefert wurden.

Ein Bezeichner wie latest ist deshalb keine reproduzierbare Produktionsreferenz. Er benennt keinen stabilen Artefaktzustand, sondern eine veränderliche Auswahlregel. Zwei Aufrufe derselben Adresse können unterschiedliche Inhalte liefern.

Semantische Versionen sind für Kommunikation und Kompatibilitätsaussagen hilfreich. Für einen belastbaren Artefaktnachweis reichen sie jedoch nicht immer aus. Zusätzlich können eine Build-ID, eine Commit-ID oder ein Artefakt-Digest gespeichert werden. Entscheidend ist, dass die ausgelieferten Inhalte eindeutig identifiziert werden können.

Veränderlich ist nicht das Artefakt. Veränderlich ist seine Zuordnung zu einem Nutzungskontext.

production-de
vorher   → Remote A 1.0.0
nachher  → Remote A 1.1.0
Rollback → Remote A 1.0.0

Promotet wird dabei dasselbe geprüfte Artefakt, nicht ein neu erzeugter Build.

Drei unterschiedliche Metadatenebenen

Ein robustes Aktivierungsmodell kann drei Arten von Metadaten unterscheiden: das Artefaktmanifest, das Kompositionsmanifest und die Aktivierungszuordnung. Diese Trennung ist kein vorgeschriebener technischer Standard. Sie ist ein Referenzmodell, das Verantwortlichkeiten sichtbar macht.

Das Artefaktmanifest

Das Artefaktmanifest beschreibt ein konkretes veröffentlichtes Remote-Artefakt.

{
  "name": "remote-a",
  "version": "1.1.0",
  "buildId": "184",
  "entry": "https://cdn.example.com/remote-a/1.1.0/remoteEntry.js",
  "integrity": "sha384-..."
}

Es kann weitere technische Angaben enthalten, etwa zu bereitgestellten Modulen, zusätzlichen Assets oder erwarteten Abhängigkeiten.

Das Artefaktmanifest beantwortet jedoch nicht, ob dieses Remote in Produktion verwendet werden darf. Es kennt weder die Freigabe für einen bestimmten Markt noch die Zuordnung zu einer Pilotgruppe.

Das Artefaktmanifest beschreibt ein Artefakt. Es trifft keine Produktfreigabe.

Das unveränderliche Kompositionsmanifest

Das Kompositionsmanifest beschreibt einen später reproduzierbaren Satz freigegebener Remote-Artefakte für eine definierte Host-Version.

{
  "schemaVersion": 1,
  "compositionId": "composition-2026-08-06-184",
  "expectedHostVersion": "5.4.2",
  "remotes": {
    "remoteA": {
      "version": "1.1.0",
      "buildId": "184",
      "entry": "https://cdn.example.com/remote-a/1.1.0/remoteEntry.js",
      "integrity": "sha384-..."
    },
    "remoteB": {
      "version": "2.3.1",
      "buildId": "92",
      "entry": "https://cdn.example.com/remote-b/2.3.1/remoteEntry.js",
      "integrity": "sha384-..."
    }
  }
}

Nach seiner Veröffentlichung wird dieses Manifest nicht mehr verändert. Eine andere Kombination aus erwarteter Host-Version, Remotes und relevanter Konfiguration erhält eine neue Composition ID.

Die Host-Angabe benötigt dabei eine Präzisierung: Lädt ein bereits ausgelieferter Host das Kompositionsmanifest, kann er sich dadurch nicht rückwirkend selbst austauschen. Die erwartete Host-Version ist in diesem Modell eine Kompatibilitätsbedingung und Diagnoseinformation. Soll auch das Host-Artefakt gemeinsam mit den Remotes aktiviert werden, muss bereits die äußere Bootstrap- oder Auslieferungsschicht an dieselbe Composition ID gebunden sein.

Eine Produktkomposition ist ein unveränderlicher Snapshot. Sie beschreibt nicht nur einzelne Remote-Versionen, sondern die konkret freigegebene Kombination und den Host-Kontext, für den sie bestimmt ist.

Die Aktivierungszuordnung

Die Aktivierungszuordnung verbindet einen Release-Channel oder Nutzungskontext mit einer Composition ID.

{
  "production-de": "composition-2026-08-06-171",
  "pilot-de": "composition-2026-08-06-184",
  "validation": "composition-2026-08-06-184"
}

Soll Version 1.1.0 für production-de wirksam werden, wird nicht das bestehende Kompositionsmanifest umgeschrieben. Stattdessen wird eine neue unveränderliche Produktkomposition veröffentlicht und der Channel-Pointer atomar auf deren Composition ID gesetzt.

Unveränderlich sind Artefakte und Kompositionssnapshots. Veränderlich ist nur die kontrollierte Zuordnung eines Nutzungskontexts zu einem freigegebenen Snapshot.

Warum ganze Produktkompositionen aktiviert werden

Es wäre technisch möglich, für jedes Remote einen separat veränderlichen Produktionszeiger zu führen:

remoteA-pointer wird geändert
remoteB-pointer bleibt vorübergehend alt
remoteC-pointer wird später geändert

Damit entstehen jedoch Übergangszustände. Nutzer können Kombinationen erhalten, die nie gemeinsam geprüft oder bewusst freigegeben wurden. Besonders problematisch wird das, wenn mehrere Pointer über unterschiedliche Systeme, Cache-Knoten oder Aktualisierungswege verteilt werden.

Ein unveränderlicher Kompositionssnapshot vermeidet diese Zwischenzustände:

Composition 171
├── erwarteter Host 5.4.2
├── Remote A 1.0.0
├── Remote B 2.3.1
└── Remote C 4.0.2

Composition 184
├── erwarteter Host 5.4.2
├── Remote A 1.1.0
├── Remote B 2.3.1
└── Remote C 4.0.2

Die Aktivierung verändert nur die Zuordnung:

production-de
von Composition 171
auf Composition 184

Die kleinste kontrolliert aktivierbare Einheit ist damit nicht zwingend ein einzelnes Remote. Für Reproduzierbarkeit und Auditierbarkeit ist häufig die vollständige Produktkomposition die wichtigere Einheit.

Das bedeutet nicht, dass bei jeder Remote-Veröffentlichung alle anderen Remotes erneut gebaut werden. Die bestehenden Artefakte werden lediglich in einem neuen Kompositionssnapshot referenziert.

Unterstützt werden dadurch nicht beliebige Kombinationen aller veröffentlichten Versionen. Unterstützt und freigegeben werden konkrete Produktkompositionen. Das begrenzt die kombinatorische Explosion.

Der Host löst auf, er entscheidet nicht

Eine externe Versionsauflösung ist nur dann eine echte Entkopplung, wenn die Freigabepolitik nicht anschließend als Anwendungscode in die Shell wandert.

Ein ungünstiges Modell wäre:

if (country === 'DE' && tenant === 'pilot') {
  loadRemoteA('1.1.0');
} else if (country === 'US') {
  loadRemoteA('1.0.0');
}

Damit wird der Host zum Besitzer der Länder-, Mandanten- und Freigabelogik. Neue Aktivierungsregeln können erneut einen Host-Release erfordern. Gleichzeitig wird schwieriger nachvollziehbar, wer welche Version wann und aus welchem Grund aktiviert hat.

Das Zielmodell trennt die Entscheidung von ihrer technischen Ausführung:

Nutzungskontext
        ↓
Aktivierungssteuerung
        ↓
Composition ID
        ↓
Host lädt exakt referenzierte Artefakte

Der Host kennt das technische Verfahren zur Auflösung und zum Laden. Die Freigabe- und Aktivierungsentscheidung liegt jedoch außerhalb seines Anwendungscodes.

Die konkrete Umsetzung kann ein externes Aktivierungsmanifest, ein Konfigurationsdienst, eine serverseitige Auflösung oder eine Edge-Konfiguration sein. In größeren Landschaften kann dafür eine eigene Aktivierungssteuerung entstehen, gelegentlich auch als Activation Control Plane bezeichnet. Diese muss jedoch nicht zwangsläufig ein komplexer zentraler Microservice sein.

Der Host sollte keine Freigabepolitik implementieren. Er sollte das Ergebnis dieser Politik reproduzierbar ausführen.

Release-Channels und Nutzungskontexte

Release-Channels sind nicht dasselbe wie technische Umgebungen.

Umgebungen können etwa development, test und production sein. Sie beschreiben häufig getrennte Infrastruktur- und Betriebsbereiche.

Release-Channels drücken dagegen den Freigabestatus oder den beabsichtigten Nutzungskontext aus:

validation
internal
pilot
production
restricted-production

Ein Channel benötigt nicht zwangsläufig eine eigene Infrastruktur.

validation
└── Composition 184

pilot-de
└── Composition 184

production-de
└── Composition 171

Dasselbe unveränderliche Artefakt kann schrittweise durch mehrere Channels promotet werden. Eine Promotion baut das Remote nicht erneut. Sie erweitert den Nutzungskontext, für den dasselbe geprüfte Artefakt freigegeben ist.

Der Aktivierungskontext kann neben Umgebung und Release-Channel weitere Dimensionen enthalten:

Aktivierungskontext
├── Umgebung
├── Release-Channel
├── Markt oder regulatorische Region
├── Mandant
├── Produktvariante
├── Benutzergruppe
└── stabile Rollout-Kohorte

Nicht jede Produktlandschaft benötigt alle diese Dimensionen. Jede zusätzliche Dimension erhöht die Zahl aktiver Produktzustände und damit Governance-, Support- und Beobachtungsaufwand.

Ein differenziertes Aktivierungsmodell ist kein Selbstzweck. Es sollte nur so viele Kontexte unterscheiden, wie für reale Freigabeentscheidungen erforderlich sind.

Deterministische Zuordnung und gepinnte Sitzungen

Eine dynamische Auflösung darf nicht mit zufälliger oder ständig wechselnder Komposition verwechselt werden.

Ein Nutzer oder Mandant sollte nicht bei jedem Seitenaufruf ohne nachvollziehbare Regel eine andere Produktkomposition erhalten. Bei prozentualen Rollouts sollte die Kohortenzuordnung stabil sein:

Nutzer oder Mandant
        ↓
stabile Kohorte
        ↓
Composition ID

Noch wichtiger ist die Stabilität innerhalb eines Seitenaufrufs oder einer Sitzung. Der Host sollte beim Bootstrap eine Composition ID auflösen und diesen Snapshot für alle später lazy geladenen Remotes verwenden.

Andernfalls kann folgender Zustand entstehen:

Remote A wird aus Composition 171 geladen
        ↓
Channel-Zuordnung ändert sich
        ↓
Remote B wird später aus Composition 184 geladen

Die laufende Anwendung bestünde dann aus einer Mischung zweier Produktstände, die möglicherweise nie gemeinsam geprüft wurden.

Dynamische Aktivierung bedeutet nicht, dass die Produktkomposition während einer laufenden Sitzung beliebig wechseln sollte. Eine neue Aktivierung kann bei einem kontrollierten Reload oder einer neuen Sitzung wirksam werden.

Das Pinnen der Composition ID verbessert zugleich die Diagnosefähigkeit. Ein Fehler lässt sich eindeutig dem Produktzustand zuordnen, der zu Beginn der Sitzung aufgelöst wurde.

Kontrollierte Freigabe und Auditierbarkeit

In stark kontrollierten oder regulierten Produktlandschaften reicht es nicht, nur die aktuell aktive URL zu kennen. Es muss nachvollziehbar sein, wie der wirksame Produktzustand zustande kam.

Typische Nachweisfragen lauten:

• Welches Remote-Artefakt wurde veröffentlicht?
• Welche konkrete Version, welche Build-ID und welcher Digest gehören dazu?
• Welche Produktkomposition wurde freigegeben?
• Für welchen Channel, Markt oder Mandanten galt die Freigabe?
• Welche Prüfungen waren abgeschlossen?
• Wer hat die Aktivierung genehmigt?
• Wer hat sie technisch ausgeführt?
• Wann wurde sie wirksam?
• Welche Composition ID war zuvor aktiv?
• Welche Produktkomposition war zu einem bestimmten Zeitpunkt aktiv?
• Wann und aus welchem Grund wurde ein Rollback durchgeführt?

Ein Aktivierungsnachweis kann beispielsweise folgende Informationen enthalten:

Aktivierungsnachweis
├── Composition ID
├── Host-Version
├── Remote-Versionen und Digests
├── Ziel-Channel
├── Nutzungskontext
├── Freigabeentscheidung
├── Zeitpunkt
├── ausführende Identität
└── vorherige Composition ID

Nicht alle Angaben müssen Bestandteil des öffentlich ausgelieferten Kompositionsmanifests sein.

Es ist sinnvoll, zwischen Data Plane und Control Plane zu unterscheiden:

Data Plane
└── liefert die für den Host notwendige Produktkomposition

Control Plane
└── verwaltet Freigaben, Aktivierungen, Rollen und Audit Trail

Der Host benötigt eine Produktkomposition. Die Organisation benötigt zusätzlich den Nachweis, wie diese Produktkomposition zustande kam.

Je nach Risikomodell können getrennte Rollen, Vier-Augen-Freigaben oder manipulationsgeschützte Audit-Logs angemessen sein. Sie sind jedoch keine universelle gesetzliche Pflicht für jedes System.

Autonome Veröffentlichung trotz kontrollierter Aktivierung

Kontrollierte Produktaktivierung hebt die unabhängige Entwicklung und Veröffentlichung eines Remotes nicht auf.

Remote-Team
├── entwickelt
├── testet
├── versioniert
└── veröffentlicht Remote A 1.1.0

Freigabeprozess
└── bestätigt Eignung für definierte Channels

Aktivierungssteuerung
└── ordnet Composition 184 dem Pilot-Channel zu

Host
└── lädt Composition 184

Unabhängiges Deployment bedeutet nicht unkontrollierte Aktivierung.

Das Remote-Team muss nicht auf einen Host-Build warten, damit eine kompatible Remote-Version technisch verfügbar wird. Die Organisation kann trotzdem kontrollieren, wann und für wen diese Version Bestandteil des Produkts wird.

Damit werden zwei Entscheidungen voneinander getrennt: Ist das Remote-Artefakt verfügbar? Und für welchen Produktkontext soll es wirksam werden?

Parallele Versionen und ihre Supportkosten

Eine Aktivierungssteuerung ermöglicht mehrere gleichzeitig aktive Versionen:

Remote A
├── 1.1.0 für validation
├── 1.1.0 für pilot-de
├── 1.0.0 für production-de
└── 0.9.4 für einen befristeten Bestandsmandanten

Das kann für Pilotgruppen, marktspezifische Freigaben, unterschiedliche Einführungszeitpunkte, kontrollierte Rollouts oder vorübergehende Kompatibilitätsfenster sinnvoll sein.

Parallele Versionen sind jedoch kein kostenloser Dauerzustand.

Mit jeder zusätzlich aktiven Version wachsen die Supportmatrix und die Zahl beobachtbarer Produktkombinationen. APIs müssen länger rückwärtskompatibel bleiben. Fehler können nur in bestimmten Nutzungskontexten auftreten. Diagnose, Monitoring und Ablösung werden aufwendiger.

Für jede ältere aktive Version müssen klare Fragen beantwortbar sein:

• Warum ist sie noch aktiv?
• Für wen ist sie aktiv?
• Wer verantwortet sie?
• Welche APIs müssen sie weiterhin unterstützen?
• Bis wann wird sie abgelöst?
• Welche Bedingungen verhindern aktuell die Promotion?

Parallele Versionen benötigen einen Besitzer und ein Ablaufdatum.

Sie sind ein kontrolliertes Freigabewerkzeug, keine Einladung, beliebig viele Versionen dauerhaft miteinander zu kombinieren.

Kompatibilität bei begrenztem Version Skew

Eine dynamische Aktivierung kann eine Version referenzieren. Sie macht die referenzierte Kombination nicht automatisch kompatibel.

Zu berücksichtigen sind unter anderem:

• der Mountvertrag zwischen Host und Remote,
• die aktive Host-Version,
• APIs und Datenmodelle,
• gemeinsam genutzte Laufzeitabhängigkeiten,
• benötigte Browser- oder Plattformfähigkeiten,
• andere Bestandteile der Produktkomposition.

Ein Manifest kann eine Version referenzieren. Es kann ihre fachliche und technische Kompatibilität nicht allein garantieren.

Die Freigabe einer Produktkomposition kann deshalb automatisierte und gegebenenfalls manuelle Prüfungen voraussetzen. Welche Prüfungen notwendig sind, hängt von den Integrationsverträgen und dem Risikomodell ab.

Der zentrale Punkt ist nicht, jede theoretisch mögliche Kombination zu unterstützen. Unterstützt und freigegeben werden konkrete Produktkompositionen.

Dadurch bleibt Version Skew bewusst begrenzt. Ein Remote kann gegenüber dem Host oder anderen Remotes in unterschiedlichen Versionen aktiv sein, aber nur innerhalb definierter Kompatibilitätsfenster.

Atomare Aktivierung

Die Umstellung auf eine neue Composition ID sollte als atomare Entscheidung behandelt werden.

Problematisch wären Zustände, in denen nur ein Teil einer Produktkomposition sichtbar wird oder einzelne Remote-Zuordnungen nacheinander aktualisiert werden. Bei verteilten Caches kann es dagegen legitim sein, dass einige Clients noch Composition 171 und andere bereits Composition 184 erhalten – solange beide Snapshots vollständig, freigegeben und in sich konsistent sind.

Ein möglicher Ablauf ist:

1. Eine neue unveränderliche Produktkomposition erstellen.
2. Schema, Artefaktquellen und Referenzen prüfen.
3. Die Freigabe abschließen.
4. Die Composition ID veröffentlichen.
5. Den Channel-Pointer atomar umstellen.
6. Die Aktivierung im Audit Trail protokollieren.

Die neue Komposition wird vollständig vorbereitet, bevor sie sichtbar wird.

Die Atomarität bezieht sich auf die wirksame Zuordnung. Sie bedeutet nicht, dass alle Caches weltweit im selben Moment umschalten. Jede einzelne Auflösung muss jedoch entweder auf die bisherige oder auf die neue vollständige Produktkomposition zeigen – niemals auf einen teilweise aktualisierten Zwischenzustand.

Caching, Ausfall und Last Known Good

Ein extern aufgelöstes Kompositionsmanifest führt eine neue Abhängigkeit in den Startpfad ein. Diese Abhängigkeit benötigt ein bewusstes Cache- und Ausfallmodell.

Die verschiedenen Datenarten haben unterschiedliche Eigenschaften:

Remote-Artefakte
→ langfristig und unveränderlich cachebar

Kompositionsmanifeste
→ langfristig cachebar, da unveränderlich

Channel- oder Aktivierungszeiger
→ kurzlebiger oder gezielt invalidierbarer Cache

Der Host muss nicht bei jedem späteren Remote-Aufruf synchron einen zentralen Dienst kontaktieren. Er kann beim Start den Channel-Pointer auflösen, das unveränderliche Kompositionsmanifest laden und die Composition ID für die Sitzung pinnen.

Ein mögliches Modell lautet:

Host-Start
├── aktiven Channel-Pointer laden
├── unveränderliches Kompositionsmanifest laden
├── Schema, Integrität und Referenzen prüfen
├── Composition ID für die Sitzung pinnen
├── nach erfolgreichem Start als Last Known Good markieren
└── bei Ausfall:
    └── letzte bekannte gültige Komposition verwenden

Eine Last Known Good kann den Start ermöglichen, wenn die Aktivierungssteuerung vorübergehend nicht erreichbar ist. Eine Komposition sollte allerdings nicht allein deshalb als gültiger Rückfall gelten, weil ihr Manifest syntaktisch korrekt ist. Dafür müssen zuvor definierte Start- oder Health-Kriterien erfüllt sein. Welche Artefakte dafür bereits geladen werden müssen, hängt davon ab, welche Remotes für den initialen Produktstart kritisch sind.

Last Known Good ist dennoch nur eine mögliche Strategie.

Je nach Risikomodell kann ein System stattdessen eine fest eingebaute sichere Basiskomposition verwenden, kontrolliert fehlschlagen oder den Zugriff auf bestimmte Produktbereiche verhindern.

Zu klären ist insbesondere:

• Wo wird die letzte bekannte gültige Komposition gespeichert?
• Was geschieht bei einem Erstaufruf ohne Cache?
• Wie wird ein syntaktisch gültiges, aber unvollständiges Manifest behandelt?
• Wie schnell wird eine Aktivierung sichtbar?
• Wie schnell wird ein Rollback sichtbar?
• Welche Cache-Laufzeiten begrenzen die Reaktionszeit?
• Bleiben ältere Artefakte weiterhin abrufbar?

Ein Activation Service im kritischen Startpfad benötigt ein bewusstes Ausfallmodell.

Integrität und Schutz der Aktivierungssteuerung

Ein dynamisches Manifest ist nicht automatisch sicherer als eine statische Zuordnung. Es verbessert die Steuerbarkeit, wird aber selbst zu einer Verfügbarkeits- und Sicherheitsgrenze.

Die Aktivierungssteuerung darf nicht zu einem Mechanismus werden, über den der Host beliebige Remote-Quellen lädt.

Mögliche Schutzmaßnahmen sind:

• ausschließlich erlaubte und vertrauenswürdige Artefaktquellen,
• verschlüsselte Übertragung,
• Schema-Validierung,
• eindeutige Artefakt-Digests,
• Integritätsinformationen,
• signierte Manifeste oder Produktkompositionen, falls das Risikomodell dies verlangt,
• eingeschränkte Schreibrechte für Aktivierungszuordnungen,
• nachvollziehbare Freigabe- und Aktivierungsidentitäten,
• Schutz vor dem Laden nicht freigegebener Quellen.

Ein Hash kann nachweisen, dass geladene Inhalte dem erwarteten Inhalt entsprechen. Er ersetzt nicht automatisch eine vertrauenswürdige Freigabe oder eine Prüfung der Herkunft.

Ob und wie konkrete Browsermechanismen zur Integritätsprüfung eingesetzt werden können, hängt vom tatsächlichen Ladevorgang und der verwendeten technischen Integration ab. Nicht jedes Setup stellt dafür dieselben Möglichkeiten bereit.

Rollback durch Rücknahme einer Zuordnung

Bei unveränderlichen Artefakten und Kompositionssnapshots muss ein Rollback keinen alten Build neu erzeugen.

Artefaktspeicher
├── Remote A 1.0.0
└── Remote A 1.1.0

Vor der Aktivierung:

production-de → Composition 171
               └── Remote A 1.0.0

Nach der Aktivierung:

production-de → Composition 184
               └── Remote A 1.1.0

Rollback:

production-de → Composition 171

Weder Remote A 1.0.0 noch der Host werden dafür erneut gebaut.

Der technische Rollback ist eine Änderung der Aktivierungszuordnung. Er nimmt die vorherige Aktivierungsentscheidung zurück und setzt den Channel auf einen früheren, weiterhin gültigen Kompositionssnapshot.

Warum ein Rollback trotzdem scheitern kann

Unveränderliche Artefakte ermöglichen einen schnellen Rollback. Sie garantieren noch keinen sicheren Rollback.

Ein Rücksprung auf eine ältere Produktkomposition ist nur möglich, wenn das ältere Remote-Artefakt weiterhin verfügbar ist. Darüber hinaus müssen seine Abhängigkeiten und Integrationsverträge noch funktionieren.

Ein Rollback kann scheitern, wenn:

• die älteren Artefakte oder abhängigen Assets gelöscht wurden,
• APIs nicht mehr rückwärtskompatibel sind,
• Datenmodelle oder serverseitige Zustände inkompatibel verändert wurden,
• der aktuelle Host das ältere Remote nicht mehr mounten kann,
• gemeinsam genutzte Laufzeitabhängigkeiten nicht mehr kompatibel sind,
• die Cache-Strategie die zurückgesetzte Aktivierungszuordnung nicht rechtzeitig sichtbar macht.

Ein Rollback kann technisch in Sekunden ausgelöst werden und fachlich trotzdem unmöglich sein.

Unveränderliche Artefakte sind eine Voraussetzung für schnelle Rollbacks, aber kein Ersatz für rückwärtskompatible Verträge.

Deshalb sollte auch eine frühere Composition ID nicht allein deshalb als sichere Rückfalloption gelten, weil sie noch gespeichert ist. Ihre technische und fachliche Gültigkeit muss innerhalb des vorgesehenen Rollback-Fensters erhalten bleiben.

Beobachtbare und rekonstruierbare Produktkompositionen

Eine dynamisch aufgelöste Produktkomposition muss diagnostizierbar sein.

Mindestens nachvollziehbar sein sollten:

Composition ID
Host-Version
Remote A 1.1.0 / Build 184
Remote B 2.3.1 / Build 92
Release-Channel
relevanter Nutzungskontext
Zeitpunkt der Auflösung

Diese Informationen können in technischen Logs, Fehlerberichten, Supportinformationen, Telemetrie, Incident-Daten oder einer Diagnoseansicht erscheinen.

Wer parallele Produktkompositionen betreibt, muss bei einem Fehler sagen können, welche konkrete Komposition betroffen war.

Eine reine Ausgabe von production oder latest reicht dafür nicht. Sie beschreibt einen veränderlichen Zeiger, aber nicht den tatsächlich geladenen Produktzustand.

Für eine spätere Rekonstruktion müssen sowohl die damals aktive Channel-Zuordnung als auch das referenzierte unveränderliche Kompositionsmanifest und die darin genannten Remote-Artefakte erhalten bleiben.

Feature Flags sind eine andere Steuerungsebene

Versionsaktivierung und Feature Flags lösen unterschiedliche Probleme.

Versionsaktivierung
→ Welche Implementierung des Remotes wird geladen?

Feature Flag
→ Welches Verhalten innerhalb der geladenen Implementierung ist aktiv?

Ein Nutzungskontext kann Remote A 1.1.0 laden, während eine neue Funktion innerhalb dieser Version noch deaktiviert ist:

production-de
└── lädt Remote A 1.1.0
    └── Feature Flag deaktiviert Funktion X

Das unterscheidet sich grundlegend davon, weiterhin Remote A 1.0.0 zu laden:

production-de
└── lädt Remote A 1.0.0 statt 1.1.0

Ein Feature Flag ersetzt keine kontrollierte Artefaktaktivierung. Ein Kompositionsmanifest ersetzt keine fachlichen Feature Flags.

Beide Mechanismen können gemeinsam verwendet werden. Sie sollten aber getrennt beobachtet, verantwortet und zurückgenommen werden können.

Welche Version lädt der Host also?

Ein Remote-Team kann Version 1.0.0 und Version 1.1.0 unabhängig veröffentlichen. Ob und wann der Host Version 1.1.0 lädt, hängt davon ab, wo die Zuordnung zwischen Produktkontext und Remote-Version verwaltet wird.

Ist die Remote-Adresse fest im Host-Bundle verdrahtet, benötigt der Wechsel einen Host-Release.

Löst der Host dagegen eine externe, freigegebene Produktkomposition auf, kann eine kompatible Remote-Version ohne neuen Host-Code-Release aktiviert werden. Die Aktivierung bleibt dennoch eine kontrollierte Produktfreigabe.

Für reproduzierbare und stark kontrollierte Produktlandschaften ist es robuster, unveränderliche Remote-Artefakte und unveränderliche Kompositionssnapshots zu veröffentlichen und lediglich die Zuordnung eines Release-Channels zu einer Composition ID kontrolliert zu verändern.

Der Host sollte für die Dauer einer Sitzung genau eine Composition ID verwenden. Dadurch stammen auch später lazy geladene Remotes aus demselben freigegebenen Produktstand.

Parallele Remote-Versionen bleiben möglich. Sie benötigen jedoch begrenzte Kompatibilitätsfenster, nachvollziehbare Ownership und einen geplanten Ablösezeitpunkt.

Ein schneller technischer Rollback ist nur dann fachlich sicher, wenn alte Artefakte weiterhin mit APIs, Datenmodellen, Host und Laufzeitverträgen kompatibel sind. Der Rollback ist eine neue Aktivierungsentscheidung auf einen früheren, weiterhin gültigen Kompositionssnapshot.

Veröffentlicht ist nicht aktiviert. Unabhängige Remote-Releases und kontrollierte Produktaktivierung widersprechen sich nicht. Der Host sollte keine Freigabepolitik in Form von Länder- und Mandantenverzweigungen implementieren. Aktiviert wird eine konkrete Produktkomposition, nicht eine abstrakte Version latest.

Eine dynamische Auflösung benötigt deshalb mehr als ein veränderliches Manifest: atomare Zuordnungen, eine klare Cache-Strategie, Integritätsprüfungen, Beobachtbarkeit, einen Audit Trail und ein bewusstes Ausfallmodell.

Der Host lädt nicht die neueste Remote-Version. Er lädt die Version, die für den aktuellen Nutzungskontext ausdrücklich freigegeben wurde.