Ihr Regionalleiter schreibt um 16 Uhr: die neue Boutique-Akquisition in Charleston geht in acht Wochen online, Markenstandards sind Pflicht, Booking Engine integriert, keine Ausnahmen. Sie öffnen Ihr aktuelles Multi-Site-Setup – siebzehn WordPress-Instanzen, jede mit eigenem Plugin-Wirrwarr, jede bricht nach Updates unterschiedlich zusammen, jede braucht eine separate Staging-Umgebung. Ihr Dev-Team schätzt mindestens zwölf Wochen. Ich habe dieses exakte Szenario bei Hotelgruppen mit 8, 25, sogar 47 Properties die Launch-Timelines zerstören sehen. Die Architektur-Entscheidung, die Sie heute treffen, bestimmt, ob Ihre nächste Property drei Tage oder drei Monate dauert. Die meisten Gruppen wählen den Weg, der sich sicher anfühlt – und verbringen dann zwei Jahre damit, ihn zu entwirren. Hier ist der Next.js-Ansatz, der jede Property einer Gruppe von einer Plattform aus bedienen lässt, ohne das Chaos.

Es gibt einen besseren Weg. Eine einzelne Next.js-Anwendung – richtig architektiert – kann jede Property einer Hotelgruppe aus einer Codebase, einer Deployment-Pipeline und einer Content-Management-Schicht bedienen. Jede Property bekommt ihr eigenes Branding, ihren eigenen Content, ihre eigene Domain. Das Engineering-Team bekommt wieder Verstand zurück.

Dieser Artikel zerlegt exakt, wie man dieses System baut. Nicht Theorie – echte Architektur-Patterns, die wir bei echten Hotelgruppen-Projekten verwendet haben.

Inhaltsverzeichnis

Hotel Group Websites: Multi-Property Architecture mit Next.js

Warum Hotelgruppen eine einheitliche Plattform brauchen

Die typische Hotelgruppen-Website-Situation sieht so aus: Property A läuft auf WordPress mit einem Theme von 2019. Property B ist auf Squarespace, weil der GM seinen Neffen hat einrichten lassen. Property C hat eine benutzerdefinierte PHP-Site, die niemand anfassen will. Die Corporate-Website läuft auf einer ganz anderen Plattform.

Jedes Property-Update erfordert einen anderen Workflow. Brand-Konsistenz ist ein Hirngespinst. SEO-Strategie ist fragmentiert über Dutzende Domains ohne gemeinsame Autorität. Wenn Corporate beschließt, einen neuen Amenity-Badge hinzuzufügen oder das Booking-Widget zu aktualisieren, muss jemand diese Änderung an 15 verschiedenen Stellen vornehmen.

Die Kosten verdoppeln sich:

  • Wartungsaufwand: Jede Plattform braucht ihr eigenes Hosting, Security-Patches, Plugin-Updates
  • Brand-Drift: Properties weichen langsam von Brand-Guidelines ab
  • Developer Context Switching: Ihr Team (oder Agentur) braucht Expertise über mehrere Plattformen hinweg
  • Langsame Property-Launches: Neue Akquisitionen brauchen Monate, um online zu gehen
  • Analytics-Fragmentierung: Keine einheitliche Sicht auf Performance über das Portfolio

Eine zentralisierte Multi-Property-Plattform löst all das. Eine Codebase. Ein Deployment. Ein CMS. Per-Property-Content und Branding, bereitgestellt durch Konfiguration, nicht separate Codebases.

Architektur-Übersicht: Eine Codebase, viele Properties

Hier ist die High-Level-Architektur, die funktioniert:

┌─────────────────────────────────────────────┐
│              CDN / Edge Network               │
│         (Vercel, Cloudflare, Fastly)          │
├─────────────────────────────────────────────┤
│           Next.js Application                 │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐     │
│  │ Property  │ │ Property  │ │ Property  │     │
│  │ Resolver  │ │ Theming   │ │ Content   │     │
│  │ Middleware│ │ Engine    │ │ Fetcher   │     │
│  └──────────┘ └──────────┘ └──────────┘     │
├─────────────────────────────────────────────┤
│              API Layer                        │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐     │
│  │ Headless  │ │ Booking   │ │ Media     │     │
│  │ CMS       │ │ Engine    │ │ CDN       │     │
│  └──────────┘ └──────────┘ └──────────┘     │
└─────────────────────────────────────────────┘

Die Next.js-App dient als Rendering-Layer. Middleware bestimmt, welche Property angefordert wird (via Domain, Subdomain oder Pfad). Die Theming-Engine wendet property-spezifische Stile an. Der Content-Fetcher zieht property-bezogene Inhalte vom Headless CMS.

Alles Nachgelagerte – das CMS, die Booking-Engine, der Media-Speicher – wird mit einer Property-ID abgefragt. Diese ID ist der Faden, der das gesamte System zusammenhält.

Multi-Tenancy-Patterns in Next.js

Es gibt drei primäre Ansätze zu Multi-Tenancy in Next.js. Jeder hat Tradeoffs.

Pattern 1: Subdomain-basiertes Routing

Jede Property bekommt eine Subdomain: grandplaza.hotelgroup.com, seasideresort.hotelgroup.com.

Next.js Middleware fängt die Anfrage ab, extrahiert die Subdomain und löst die Property-Konfiguration auf:

// middleware.ts
import { NextRequest, NextResponse } from 'next/server';
import { getPropertyByDomain } from '@/lib/properties';

export function middleware(request: NextRequest) {
  const hostname = request.headers.get('host') || '';
  const subdomain = hostname.split('.')[0];
  
  const property = getPropertyByDomain(subdomain);
  
  if (!property) {
    return NextResponse.redirect(new URL('/not-found', request.url));
  }
  
  // Inject property context into headers for downstream use
  const response = NextResponse.next();
  response.headers.set('x-property-id', property.id);
  response.headers.set('x-property-slug', property.slug);
  
  return response;
}

Vorteile: Saubere URLs, leichte Property-Isolation, gut für SEO, wenn Properties keine separaten TLDs brauchen.
Nachteile: SSL-Zertifikatsverwaltung für Wildcards, weniger Brand-Unabhängigkeit pro Property.

Pattern 2: Custom Domain Mapping

Jede Property hat ihre eigene Domain: grandplazahotel.com, seasideresort.com.

Das ist, was die meisten Hotelgruppen eigentlich wollen. Die Middleware-Logik ist ähnlich, aber Sie matchen gegen eine Domain-Lookup-Tabelle:

const DOMAIN_MAP: Record<string, string> = {
  'grandplazahotel.com': 'grand-plaza',
  'www.grandplazahotel.com': 'grand-plaza',
  'seasideresort.com': 'seaside-resort',
  'www.seasideresort.com': 'seaside-resort',
};

Vercel unterstützt Custom Domains pro Projekt nativ, und Sie können bis zu 50 Domains auf ihrem Pro-Plan ($20/Monat ab 2026) mappen. Für größere Portfolios entfernt ihr Enterprise-Plan diese Grenze.

Vorteile: Volle Brand-Unabhängigkeit, vorhandenes Domain-Kapital erhalten.
Nachteile: DNS-Verwaltungs-Overhead, komplexere SSL-Bereitstellung.

Pattern 3: Pfad-basiertes Routing

Alle Properties unter einer Domain: hotelgroup.com/properties/grand-plaza, hotelgroup.com/properties/seaside-resort.

Vorteile: Einfachste Implementierung, konsolidierte Domain-Autorität für SEO.
Nachteile: Weniger Brand-Identität pro Property, URL-Struktur fühlt sich unternehmensartig an.

Pattern Brand-Unabhängigkeit SEO-Flexibilität Implementierungs-Komplexität Am besten für
Subdomain Mittel Mittel Niedrig Budget-bewusste Gruppen
Custom Domain Hoch Hoch Mittel Etablierte Marken
Pfad-basiert Niedrig Hoch (konsolidiert) Niedrig Neue Portfolio-Seiten

Die meisten Hotelgruppen, mit denen wir bei Social Animal arbeiten, wählen am Ende Custom Domain Mapping. Properties haben Brand-Kapital in ihren Domains, und Marketing-Teams wollen die Unabhängigkeit.

Hotel Group Websites: Multi-Property Architecture mit Next.js - Architektur

Headless-CMS-Strategie für Hotelgruppen

Die CMS-Wahl macht oder bricht diese Architektur. Sie brauchen ein System, das Multi-Tenancy auf Content-Ebene unterstützt – wo Editoren von Property A nicht versehentlich Property B's Content ändern können, aber Corporate-Admins alles verwalten können.

CMS-Optionen, die gut funktionieren

Sanity ist meine Top-Wahl für Hotelgruppen. Seine Dokumentebenen-Berechtigungen, benutzerdefinierte Studio-Konfiguration und GROQ-Abfragesprache machen property-bezogene Content-Abfrage trivial. Sie können ein einzelnes Sanity Studio mit Workspace-pro-Property-Ansichten erstellen. Die Preisgestaltung beginnt bei $99/Monat für den Team-Plan (2026-Preisgestaltung) und skaliert gut zu großen Content-Volumen.

Contentful funktioniert, wenn Sie bereits in ihrem Ökosystem sind. Ihre Space-Level-Isolation mappt gut zu Properties, kann aber teuer werden – jeder Space im Premium-Plan fügt Kosten hinzu, und Sie schauen auf $2.500+/Monat für Enterprise-Scale Hotel-Gruppen-Anforderungen.

Strapi (selbst gehostet) ist die Budget-Option. Sie müssen die Multi-Tenancy-Schicht selbst bauen, indem Sie benutzerdefinierte Middleware und rollenbasierte Zugriffskontrolle verwenden, aber es gibt keine Pro-Sitz-Lizenzkosten.

Wir decken den vollständigen CMS-Auswahlprozess in unserem Headless-CMS-Entwicklungsleitfaden ab.

Content-Modellierung für Hotels

Hier ist ein Content-Modell, das über Properties hinweg funktioniert:

// Sanity-Schema-Beispiel
export const property = defineType({
  name: 'property',
  title: 'Property',
  type: 'document',
  fields: [
    defineField({ name: 'name', type: 'string' }),
    defineField({ name: 'slug', type: 'slug' }),
    defineField({ name: 'domain', type: 'string' }),
    defineField({ name: 'brand', type: 'reference', to: [{ type: 'brand' }] }),
    defineField({ name: 'location', type: 'geopoint' }),
    defineField({ name: 'theme', type: 'propertyTheme' }),
    defineField({ name: 'bookingEngineId', type: 'string' }),
  ],
});

export const room = defineType({
  name: 'room',
  title: 'Room Type',
  type: 'document',
  fields: [
    defineField({ name: 'property', type: 'reference', to: [{ type: 'property' }] }),
    defineField({ name: 'name', type: 'string' }),
    defineField({ name: 'description', type: 'blockContent' }),
    defineField({ name: 'maxOccupancy', type: 'number' }),
    defineField({ name: 'amenities', type: 'array', of: [{ type: 'reference', to: [{ type: 'amenity' }] }] }),
    defineField({ name: 'gallery', type: 'array', of: [{ type: 'image' }] }),
  ],
});

Das Schlüsselmuster: Jedes Content-Dokument referenziert eine property. Abfragen filtern immer nach Property. Editoren sehen nur den Content ihrer Property. Corporate-Admins sehen alles.

Shared Components vs. Property-Level-Anpassung

Hier wird die Architektur interessant. Sie wollen 80% der Components über Properties hinweg geteilt, mit 20%, die per-Property-Anpassung erlauben.

Die Theming-Schicht

Erstellen Sie eine Theme-Konfiguration pro Property, die in Ihr Component-System einfließt:

// types/theme.ts
export interface PropertyTheme {
  colors: {
    primary: string;
    secondary: string;
    accent: string;
    background: string;
    text: string;
  };
  typography: {
    headingFont: string;
    bodyFont: string;
  };
  logo: {
    light: string;
    dark: string;
  };
  borderRadius: 'none' | 'sm' | 'md' | 'lg';
  heroStyle: 'fullbleed' | 'contained' | 'split';
}

Tailwind CSS v4 (released 2025) macht das erheblich einfacher mit seiner CSS-first-Konfiguration und nativer Theme-Funktionsunterstützung. Sie können CSS Custom Properties auf Layout-Ebene setzen und sie durch jede Component kaskadieren lassen:

// app/layout.tsx
export default async function PropertyLayout({ children }: { children: React.ReactNode }) {
  const property = await getCurrentProperty();
  const theme = property.theme;
  
  return (
    <html
      style={{
        '--color-primary': theme.colors.primary,
        '--color-secondary': theme.colors.secondary,
        '--font-heading': theme.typography.headingFont,
        '--font-body': theme.typography.bodyFont,
      } as React.CSSProperties}
    >
      <body className="font-body text-text bg-background">
        {children}
      </body>
    </html>
  );
}

Component-Komposition

Shared Components akzeptieren Theme-Token und rendern unterschiedlich pro Property, ohne Branching-Logik:

// components/HeroSection.tsx
export function HeroSection({ property }: { property: Property }) {
  const heroConfig = property.theme.heroStyle;
  
  const variants = {
    fullbleed: 'h-screen w-full',
    contained: 'h-[70vh] max-w-7xl mx-auto rounded-2xl overflow-hidden',
    split: 'grid grid-cols-2 h-[80vh]',
  };
  
  return (
    <section className={variants[heroConfig]}>
      {/* Shared hero content structure */}
    </section>
  );
}

Booking-Engine-Integration

Hotel-Websites existieren aus einem Grund: um Buchungen zu treiben. Die Booking-Engine-Integration muss rock solid sein.

Die meisten Hotelgruppen verwenden eine dieser Booking-Engines: SynXis (Sabre), Pegasus, Bookassist, SiteMinder, oder ein proprietäres zentrales Reservierungssystem. Das Integrationsmuster ist fast immer das gleiche: Übergeben Sie eine Property-ID, Datumbereich und Gastzahl, um Verfügbarkeit zu bekommen.

// lib/booking.ts
export async function checkAvailability({
  propertyCode,
  checkIn,
  checkOut,
  adults,
  children,
}: BookingQuery) {
  const response = await fetch(`${BOOKING_ENGINE_URL}/availability`, {
    method: 'POST',
    headers: {
      'Authorization': `Bearer ${BOOKING_API_KEY}`,
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({
      hotel_code: propertyCode,
      arrival: checkIn,
      departure: checkOut,
      guests: { adults, children },
    }),
  });
  
  return response.json();
}

Für das Booking-Widget selbst haben Sie zwei Optionen:

  1. Eingebetteter iframe: Die Booking-Engine bietet ein Widget, das Sie einbetten. Minimale Arbeit, minimale Kontrolle.
  2. API-gesteuerte benutzerdefinierte UI: Sie bauen die Such- und Ergebnis-UI, rufen die Booking-API direkt auf, und geben nur für die Zahlung zur Booking-Engine ab. Mehr Arbeit, viel bessere UX.

Option 2 ist, wo eine Next.js-Architektur wirklich glänzt. Sie können eine wunderschöne, schnelle, on-brand Booking-Erfahrung bauen, die sich native zu jeder Property anfühlt. Server Components können Verfügbarkeitsdaten vorab abrufen. Der Booking-Flow bleibt auf Ihrer Domain, was besser für Conversion Tracking und SEO ist.

Domain-Routing und Property-Auflösung

Der Property-Auflösungs-Flow muss schnell sein. Wirklich schnell. Er läuft auf jedem einzelnen Request.

Hier ist das Pattern, das in der Produktion funktioniert:

  1. Edge Middleware löst Domain → Property Slug auf (In-Memory-Lookup, Sub-Millisekunde)
  2. Property-Konfiguration wird am Edge mit Vercel Edge Config oder Cloudflare KV gecacht
  3. Vollständige Property-Daten (Theme, Navigation, Footer-Content) werden einmal pro Build über ISR oder beim Request mit Caching abgerufen
// lib/property-resolver.ts
import { get } from '@vercel/edge-config';

export async function resolveProperty(hostname: string): Promise<PropertyConfig | null> {
  // First: check edge config (sub-5ms)
  const domainMap = await get<Record<string, string>>('domain-map');
  const propertySlug = domainMap?.[hostname];
  
  if (!propertySlug) return null;
  
  // Second: get full property config (cached)
  const propertyConfig = await get<PropertyConfig>(`property:${propertySlug}`);
  return propertyConfig;
}

Vercel Edge Config ist perfekt dafür – es ist ein global verteilter Key-Value-Store mit Read-Latenz unter 1ms. Es kostet $0 auf Pro-Plänen für bis zu 512KB Daten, was mehr als genug für eine Property-Lookup-Tabelle ist.

Leistung im großen Maßstab

Hotel-Websites haben spezifische Performance-Charakteristiken, die wichtig sind:

  • Bildreiche Seiten: Room Galleries, Property-Fotos, Destination-Bildvorgänge
  • Saisonale Verkehrsspitzen: Feiertage, Convention-Saison, lokale Events
  • Globale Zielgruppe: Internationale Reisende, die von überall aus browsern
  • Konversions-kritisch: Jede 100ms Ladezeit kostet Buchungen

Statische Generierungsstrategie

Verwendung von Inkrementeller Statischer Regeneration (ISR) für Property-Seiten. Hotel-Content ändert sich nicht jede Minute – eine 60-Sekunden-Revalidierungsperiode ist normalerweise in Ordnung:

// app/[propertySlug]/page.tsx
export async function generateStaticParams() {
  const properties = await getAllProperties();
  return properties.map((p) => ({ propertySlug: p.slug }));
}

export const revalidate = 60;

Für eine 30-Property-Gruppe mit ~20 Seiten pro Property generieren Sie ~600 Seiten vor. Next.js handhabt das ohne zu schwitzen. Build-Zeiten bleiben unter 5 Minuten.

Image-Optimierung

Next.js Image-Component mit einem Remote-Loader handhabt per-Property-Image-Optimierung. Wenn Sie Sanity verwenden, ist ihr Image-CDN mit automatischer Format-Konvertierung und Größenänderung ausgezeichnet. Cloudinary ist eine andere solide Option bei $89/Monat für den Plus-Plan.

Eine typische Hotel-Property-Seite sollte anstreben:

  • LCP unter 2,5s auf 4G-Verbindungen
  • CLS von 0 (kein Layout Shift durch Loading Images)
  • Gesamtes Page-Gewicht unter 1,5MB beim ersten Load

Zentralisiertes Management-Dashboard

Beyond dem CMS brauchen Hotelgruppen Operational Dashboards. Das ist, wo Sie benutzerdefinierte Tools bauen:

  • Property-Übersicht: Status jeder Property-Website (live, staging, Wartung)
  • Content-Frische: Welche Properties haben ihren saisonalen Content nicht aktualisiert
  • Performance-Monitoring: Core Web Vitals pro Property
  • Analytics Rollup: Booking-Funnel-Metriken über alle Properties

Wir bauen das typischerweise als separate Next.js-App (oft mit App Router's Server-seitigen Fähigkeiten), die sich mit denselben Datenquellen verbindet. Das Management-Dashboard ist ein internes Tool – es muss nicht flashy sein, aber es muss funktional sein.

Deployment und DevOps

Eine Codebase bedeutet eine CI/CD-Pipeline. Hier ist der Deployment-Flow:

  1. Code-Änderungen: PR → Review → Merge zu main
  2. Build: Next.js baut alle statischen Seiten über alle Properties
  3. Deploy: Vercel (oder ähnlich) deployed zum Edge-Netzwerk
  4. DNS: Jede Property-Domain zeigt auf das Deployment

Content-Änderungen erfordern kein Deployment. Das Headless CMS triggert ISR Revalidation via Webhook:

// app/api/revalidate/route.ts
export async function POST(request: Request) {
  const body = await request.json();
  const { propertySlug, contentType } = body;
  
  // Revalidate specific paths for the changed property
  revalidatePath(`/${propertySlug}`);
  
  if (contentType === 'room') {
    revalidatePath(`/${propertySlug}/rooms`);
  }
  
  return Response.json({ revalidated: true });
}

Echter Kostenvergleich

Lassen Sie uns die tatsächlichen Kosten für eine 20-Property-Hotelgruppe vergleichen:

Kostenategorie Separate Seiten (WordPress) Einheitliche Next.js-Plattform
Hosting (monatlich) $2.000-4.000 (20 × verwalteter WP) $150-400 (Vercel Pro/Team)
CMS-Lizenzierung $0-600 (Plugins pro Seite) $99-300 (Sanity/Contentful)
SSL-Zertifikate $0-400 (wenn nicht Let's Encrypt) $0 (auto-bereitgestellt)
Wartung (jährlich) $40.000-80.000 (Updates, Sicherheit) $10.000-20.000
Neue Property Launch $5.000-15.000 pro Seite $500-2.000 (Content + Konfiguration)
Jährliche Gesamtsumme (geschätzt) $75.000-150.000 $15.000-35.000

Die Zahlen sind nicht einmal nah beieinander. Und das berücksichtigt nicht die Developer Experience Verbesserungen – eine Codebase zu haben bedeutet, Ihr Team versteht eigentlich das System. Keine "welche WordPress-Version läuft auf dieser Property"-Momente mehr.

Für Hotelgruppen, die diesen Ansatz erwägen, haben wir unsere Next.js-Entwicklungsfähigkeiten dargelegt, und Sie können unsere Preisstruktur für eine detaillierte Schätzung sehen.

FAQ

Wie lange dauert es, eine Hotelgruppe auf eine einheitliche Next.js-Plattform zu migrieren?

Für eine 10-20 Property-Gruppe erwarten Sie 3-5 Monate vom Kickoff bis zum vollständigen Launch. Die erste Property dauert am längsten (8-10 Wochen), weil Sie die Plattform bauen. Jede nachfolgende Property ist primär Content-Migration und Theme-Konfiguration, was 1-2 Wochen dauert. Wir launchen typischerweise in Wellen – 3-4 Properties gleichzeitig.

Können einzelne Properties immer noch einzigartige Seiten haben, die andere Properties nicht haben?

Absolutely. Das Content-Modell unterstützt property-spezifische Seitentypen. Wenn Ihre Resort-Property einen "Wedding Venues"-Abschnitt braucht, aber Ihr Business-Hotel nicht, das ist eine Content-Level-Entscheidung. Das CMS-Schema unterstützt optionale Seitentypen, und das Next.js dynamische Routing handhabt das Rendering jeder Seite, die in CMS für eine bestimmte Property existiert.

Was passiert, wenn Sie ein neues Hotel erwerben und es zur Plattform hinzufügen müssen?

Das ist einer der größten Siege. Eine neue Property hinzuzufügen bedeutet: ein Property-Entry im CMS erstellen, das Theme konfigurieren (Farben, Schriftarten, Logo), das Domain-Mapping hinzufügen und Content einfüllen. Ein kompetentes Content-Team kann eine neue Property in 1-2 Wochen live haben. Vergleichen Sie das mit 2-3 Monaten, um eine eigenständige Website zu bauen.

Wie handhaben Sie Multi-Language-Unterstützung über Properties in verschiedenen Ländern hinweg?

Next.js hat eingebaute i18n-Routing-Unterstützung. Kombiniert mit einem Headless CMS, der lokalisierte Content unterstützt (Sanity und Contentful tun das beide gut), können Sie jede Property in seinen relevanten Sprachen bedienen. Eine Property in Barcelona könnte Spanisch, Katalanisch, Englisch und Französisch brauchen. Eine Property in Miami könnte nur Englisch und Spanisch brauchen. Jede Property's Sprachkonfiguration ist unabhängig.

Funktioniert diese Architektur mit Astro statt Next.js?

Ja, und für einige Hotelgruppen ist das eigentlich die bessere Wahl. Wenn Ihre Properties primär Content-angetrieben mit minimaler Interaktivität sind (keine komplexe Booking-Flow zum Beispiel), kann Astro's Multi-Page-Architektur noch bessere Leistung mit weniger JavaScript bereitstellen. Die Multi-Tenancy-Patterns sind ähnlich – Middleware-basierte Property-Auflösung, Headless CMS mit Property-Scoping, Theme-Token pro Property.

Wie handhaben Sie SEO, wenn Properties auf separaten Domains sind, aber von einer Anwendung aus bereitgestellt werden?

Jede Property-Domain bekommt ihre eigene Sitemap, ihre eigene robots.txt, ihre eigenen strukturierten Daten (Hotel Schema Markup), und ihre eigenen Meta-Tags. Aus Googles Perspektive sind das völlig separate Websites. Die Canonical URLs zeigen auf jede Property's eigene Domain. Sie bekommen auch den Vorteil zentralisierter Schema-Markup-Generierung – jede Property bekommt automatisch richtiges JSON-LD für Hotels, Zimmer, Bewertungen und lokale Geschäftsinformationen.

Was ist mit Property-spezifischen Integrationen wie lokale Activity-Buchung oder Spa-Reservierungssysteme?

Die Component-Architektur unterstützt property-level Integrations-Konfiguration. Jede Property-Konfiguration im CMS kann angeben, welche Third-Party-Integrationen es verwendet. Die Rendering-Schicht bezieht bedingt diese Integrations-Components ein. Eine Spa-Property bekommt das Spa-Booking-Widget. Ein Downtown Business Hotel bekommt den Meeting Room Configurator. Diese werden als Dynamic Imports geladen, so dass sie Bundle-Größe für Properties, die sie nicht verwenden, nicht beeinflussen.

Gibt es ein Risiko, dass eine Property's Traffic-Spike andere Properties beeinflusst?

Auf einer Plattform wie Vercel oder Cloudflare Pages, nicht wirklich. Diese Edge-Plattformen sind für Traffic-Spikes konzipiert. Statische Seiten werden aus CDN-Cache bereitgestellt, also eine Spike auf einer Property verbraucht keine Server-Ressourcen, die eine andere beeinflussten würden. Für dynamische Routes (wie Verfügbarkeitsprüfungen in Echtzeit) wollen Sie Rate Limiting pro Property, um zu verhindern, dass eines Property's viraler Moment Ihre Booking-Engine API-Quoten erschöpft. Aber das ist eine API-Level-Bedenken, keine Hosting-Bedenken.