API-Keys
ADITUS-Queue

Der Enterprise Virtual Waiting Room

ADITUS-Queue ist ein eigenständiger Virtual Waiting Room, der jede Website, API oder jeden Online-Dienst vor Lastspitzen schützt. Er integriert sich nahtlos in die ADITUS-Ticketing-Plattform — und lässt sich genauso unabhängig vor jede Web-Anwendung setzen. Besucher werden in einem gehosteten Warteraum gehalten und strikt in Ankunftsreihenfolge mit einer konfigurierten Rate pro Minute weitergeleitet. Die Einbindung reicht vom einzelnen Gateway-Link oder Script-Tag ganz ohne Infrastruktur auf Betreiberseite über die Durchsetzung im Reverse-Proxy oder CDN bis zur reinen REST-API.

Neu: die selbstregelnde Weiterleitungsrate. Die Queue liest einen Healthcheck deines Shops und regelt die Rate selbst — mehr Besucher, wenn der Shop Reserven hat, sofortige Entlastung, wenn er unter Druck gerät.

Trotz des Funktionsumfangs: Die Einrichtung dauert Minuten, nicht Tage. Ein veröffentlichter Link oder ein Script-Tag — keine Infrastruktur, kein Deployment, keine Code-Änderungen auf deiner Seite.

Zur EinbindungSprich mit uns

Quick Start: in unter 2 Minuten live

Schütze deine Anwendung in unter 2 Minuten: Kopiere das Script-Tag in deinen Head oder nutze den Gateway-Link. Keine Änderungen an deiner Server-Infrastruktur notwendig. Erst wenn du maximale Kontrolle willst, schaltest du die optionalen Profi-Features frei — alles Weitere auf dieser Seite ist genau das: optionale Tiefe für später.

503
Klassischstarr & überlastet — alle Besucher treffen gleichzeitig auf den Shop
WarteraumHealthcheck regelt die Weiterleitungsrate
ADITUS-Queuedynamisch & geschützt — Weiterleitung genau im Tempo, das der Shop verkraftet
  1. 1

    Warteraum anlegen

    In der ADITUS-Verwaltung: Name, Shop-Adresse, Weiterleitungsrate pro Minute. Alles Weitere ist mit sinnvollen Standardwerten vorbelegt.

  2. 2

    Eine Zeile kopieren

    Entweder den fertigen Gateway-Link statt des Shop-Links veröffentlichen — oder das vorbereitete Script-Tag in die Shop-Seite einfügen, genau wie ein Analytics-Snippet.

  3. 3

    Fertig — die Queue ist scharf

    Unterhalb der Weiterleitungsrate sehen Besucher den Warteraum nie. Erst wenn eine Lastspitze kommt, greift die Queue — gehostet, skaliert und betrieben von uns.

Wächst mit: drei Schutzstufen

Die Mächtigkeit der Queue ist ein Upgrade-Pfad, keine Voraussetzung. Stufe 1 deckt die große Mehrheit aller Anwendungsfälle allein ab.

Stufe 1: Standard-SchutzGateway-Link oder Script-Tag. Sofort einsatzbereit, null Infrastruktur — reicht für die meisten Standardfälle aus.Sofort einsatzbereit
Stufe 2: Advanced-SchutzDie selbstregelnde Weiterleitungsrate per Shop-Healthcheck — die Queue bedient den Regler für dich.Optional
Stufe 3: Bulletproof-SchutzEdge-Härtung per Offline-JWT-Prüfung in Nginx, Caddy oder dem CDN — für DevOps-Teams.Optional — für DevOps-Teams

Einbindung: zwei Varianten

Welche Variante passt, entscheidet eine Frage: Lässt sich der veröffentlichte Shop-Link ändern? Wenn ja, ist der Gateway-Link die bessere Wahl — der Traffic erreicht den Shop erst nach der Weiterleitung. Ist die veröffentlichte Shop-URL fest, schützt das Script-Tag den Shop ohne Änderung an dessen Veröffentlichung. Darüber hinaus lässt sich die Prüfung im Reverse-Proxy oder CDN durchsetzen (unten), direkt über die REST-API ansteuern oder in jeder Backend-Sprache mit JWT-Bibliothek verifizieren — Node.js, PHP, Java, .NET, Python, Go.

Gateway-LinkScript-TagReverse-Proxy / CDNREST-APIBackend-Prüfung (JWT, jede Sprache)

Variante A: der Gateway-Link (empfohlen)

Jeder Warteraum stellt eine eigene Eingangs-URL bereit. Sie wird überall dort veröffentlicht, wo sonst der Shop-Link stünde — Newsletter, Website, Social Media. Die Queue nimmt die Anfrage entgegen und entscheidet serverseitig in einem Schritt: Unterhalb der Weiterleitungsrate wird der Besucher direkt an die konfigurierte Shop-Adresse weitergeleitet und bemerkt die Queue überhaupt nicht; ist die Rate überschritten, landet er im Warteraum und wird automatisch weitergeleitet, sobald er an der Reihe ist. Der Shop selbst erhält vor der Weiterleitung keinen Traffic — die Anfragen werden abgefangen, bevor sie die Shop-Infrastruktur erreichen.

newsletter.html
<!-- Der veröffentlichte Shop-Link zeigt auf die Queue statt auf den Shop: -->
<a href="https://aditus.dev/queue/<slug>/enter">Tickets kaufen</a>

Für diese Variante muss die Zieladresse des Shops (Ziel-URL) an der Queue konfiguriert sein — an sie werden weitergeleitete Besucher weitergeleitet. Eingelassene Besucher erreichen den Shop mit einem signierten Zugriffs-Token in der URL — einem Standard-HS256-JWT, den der Shop optional offline im eigenen Backend mit dem gemeinsamen Secret prüfen kann. Aufbau, Claims und ein Backend-Beispiel sind unten dokumentiert. Hinweis: Der Gateway schützt den veröffentlichten Einstiegspunkt; wer die Shop-URL direkt kennt, kann daran vorbei. Wenn das relevant ist, kombinierst du den Gateway-Link mit dem Script-Tag oder prüfst den Token im Shop-Backend.

Variante B: das Script-Tag

Lässt sich der veröffentlichte Shop-Link nicht ändern, besteht die Integration aus einem einzelnen Script-Tag. Es wird zusammen mit den Shop-Seiten ausgeliefert — auf demselben Weg wie ein Analytics-Snippet — und muss auf jeder Seite vorhanden sein, die der Warteraum schützen soll. Empfohlen ist die Platzierung im <head> mit dem Attribut defer; die genaue Position ist nicht kritisch.

shop.html
<!-- Auf jeder zu schützenden Shop-Seite im <head>: -->
<script src="https://aditus.dev/queue/<slug>/embed.js" defer></script>

Das exakte Tag für einen konkreten Warteraum — mit bereits eingesetztem Slug — steht in der ADITUS-Verwaltung pro Queue zum Kopieren bereit. Das Script führt bei jedem Seitenaufruf drei Prüfungen aus:

  1. 1

    Besucher hat einen gültigen Pass

    Es passiert nichts. Der Pass gilt pro Browser-Sitzung; der Besucher nutzt den Shop ohne Unterbrechung.

  2. 2

    Besucher kehrt aus dem Warteraum zurück

    Der Zugriffs-Token in der URL wird serverseitig geprüft (Signatur, Queue-Zuordnung, Ablauf). Ist er gültig, wird ein Sitzungs-Pass gespeichert und der Token aus der Adresszeile entfernt. Ungültige oder abgelaufene Tokens führen zurück in den Warteraum.

  3. 3

    Besucher hat keinen Pass

    Wartet aktuell niemand, wird der Besucher im Hintergrund still zugelassen und bleibt auf der Seite — der Warteraum erscheint gar nicht. Erst wenn die konfigurierte Weiterleitungsrate überschritten ist und sich eine Schlange gebildet hat, wird der Besucher in den Warteraum umgeleitet; die aktuelle Seite wird als validierte Rücksprung-URL mitgegeben — nach der Weiterleitung landet er exakt auf der ursprünglich aufgerufenen Seite.

Fällt offen aus

Ist der Queue-Service nicht erreichbar oder der Warteraum unbekannt, tut das Script nichts und der Shop bleibt voll nutzbar. Ein Ausfall des Warteraums blockiert den Shop nie.

Kein offener Redirect

Rücksprung-URLs werden serverseitig gegen die für die Queue konfigurierten Domains geprüft. Der Warteraum leitet ausschließlich auf Seiten des registrierten Shops weiter.

Härtung: Erzwingen des Zugriffsschutzes am Edge-Proxy

Optionales Upgrade — für DevOps-TeamsFür die Einrichtung oben nicht erforderlich

Beide Varianten oben schützen den veröffentlichten Einstiegspunkt. Soll der Shop auch für Besucher, die seine URL direkt kennen, ohne Freigabe unerreichbar sein, wandert die Prüfung vor den Shop — in den Reverse-Proxy oder das CDN, das seinen Traffic terminiert. Die Logik ist immer dieselbe in drei Schritten: den Token beim Rücksprung aus dem URL-Parameter aditus_queue_token übernehmen und als Cookie speichern; bei jedem Request den Token aus dem Cookie als Standard-HS256-JWT mit dem gemeinsamen Secret prüfen (Issuer aditus-queue, Audience der Queue-Slug, Ablauf); ohne gültigen Token auf den Warteraum unter https://aditus.dev/queue/<slug> umleiten. Die Prüfung erfolgt offline — der Proxy ruft die Queue nie auf und fügt keine Latenz hinzu. Die folgenden Skizzen zeigen das Muster für vier verbreitete Umgebungen; sie werden an die eigene Umgebung angepasst.

Nginxnjs-Modul — Prüfung direkt im Proxy, kein Zusatzdienst.Snippet enthalten
Caddyjwtauth-Plugin — reine Konfiguration, keine Zeile Code.Snippet enthalten
CloudflareWorker am Edge — weltweit erzwungen, bevor Traffic den Shop erreicht.Snippet enthalten
AWS CloudFrontLambda@Edge — die Prüfung läuft im globalen AWS-Netz.Snippet enthalten
Standard-HS256-JWTOffline-Prüfung — kein RückrufNull ZusatzlatenzMit jedem Reverse-Proxy nutzbar
Nginx (njs)
# Skizze: Nginx mit njs (js_import) — prüft den Zugriffs-Token als HS256-JWT
# direkt am Proxy, ohne Rückruf an die Queue. An die eigene Umgebung anpassen.

# nginx.conf:
#   env ADITUS_QUEUE_SECRET;
#   js_import queue from /etc/nginx/queue.js;
#   server {
#     location /       { js_content queue.gate; }
#     location @shop   { proxy_pass http://shop_backend; }
#   }

// /etc/nginx/queue.js:
const crypto = require('crypto');
const SLUG = '<slug>';
const SECRET = process.env.ADITUS_QUEUE_SECRET; // Shared Secret der Queue

function claims(token) {
  const p = token.split('.');
  if (p.length !== 3) return null;
  const sig = crypto.createHmac('sha256', SECRET)
    .update(p[0] + '.' + p[1]).digest('base64url');
  if (sig !== p[2]) return null;
  const c = JSON.parse(Buffer.from(p[1], 'base64url'));
  const ok = c.iss === 'aditus-queue' && c.aud === SLUG && c.exp > Date.now() / 1000;
  return ok ? c : null;
}

function gate(r) {
  const fromUrl = r.args.aditus_queue_token;
  const m = (r.headersIn.Cookie || '').match(/(?:^|;\s*)aditus_queue=([^;]+)/);
  const token = fromUrl || (m && m[1]);
  if (!token || !claims(token)) {
    // Kein gültiger Token -> zurück in den Warteraum
    r.return(302, 'https://aditus.dev/queue/' + SLUG);
    return;
  }
  if (fromUrl) {
    // Token aus der Rücksprung-URL in ein Sitzungs-Cookie übernehmen
    r.headersOut['Set-Cookie'] =
      'aditus_queue=' + fromUrl + '; Path=/; Secure; HttpOnly; Max-Age=600';
  }
  r.internalRedirect('@shop');
}

export default { gate };
Caddyfile
# Skizze: Caddy mit dem jwtauth-Plugin (github.com/ggicci/caddy-jwt).
# Token kommt beim Rücksprung als ?aditus_queue_token=… oder danach als Cookie;
# jwtauth prüft beide Quellen. An die eigene Umgebung anpassen.
shop.example.com {
  route {
    jwtauth {
      sign_key {env.ADITUS_QUEUE_SECRET}
      sign_alg HS256
      from_query aditus_queue_token
      from_cookies aditus_queue
      issuer_whitelist aditus-queue
      audience_whitelist <slug>
      user_claims qnr
    }
    # Token aus der URL einmalig in ein Cookie übernehmen
    @rueckkehr query aditus_queue_token=*
    header @rueckkehr Set-Cookie "aditus_queue={http.request.uri.query.aditus_queue_token}; Path=/; Secure; HttpOnly; Max-Age=600"
    reverse_proxy shop_backend:8080
  }
  # Ohne gültigen Token: zurück in den Warteraum
  handle_errors {
    @unauth expression {http.error.status_code} == 401
    redir @unauth https://aditus.dev/queue/<slug> 302
  }
}
Cloudflare Worker
// Skizze: Cloudflare Worker vor dem Shop — prüft den HS256-JWT offline per
// WebCrypto. Secret als Worker-Secret ADITUS_QUEUE_SECRET hinterlegen.
const SLUG = "<slug>";
const ROOM = "https://aditus.dev/queue/" + SLUG;

export default {
  async fetch(req, env) {
    const url = new URL(req.url);
    const fromUrl = url.searchParams.get("aditus_queue_token");
    const m = (req.headers.get("Cookie") || "").match(/(?:^|;\s*)aditus_queue=([^;]+)/);
    const token = fromUrl || (m && m[1]);
    if (!token || !(await valid(token, env.ADITUS_QUEUE_SECRET))) {
      return Response.redirect(ROOM, 302); // zurück in den Warteraum
    }
    if (fromUrl) {
      // Token in ein Cookie übernehmen und die URL bereinigen
      url.searchParams.delete("aditus_queue_token");
      return new Response(null, {
        status: 302,
        headers: {
          Location: url.toString(),
          "Set-Cookie": "aditus_queue=" + token +
            "; Path=/; Secure; HttpOnly; Max-Age=600",
        },
      });
    }
    return fetch(req); // gültiger Pass -> durch zum Shop
  },
};

async function valid(token, secret) {
  const p = token.split(".");
  if (p.length !== 3) return false;
  const key = await crypto.subtle.importKey(
    "raw", new TextEncoder().encode(secret),
    { name: "HMAC", hash: "SHA-256" }, false, ["verify"],
  );
  const ok = await crypto.subtle.verify(
    "HMAC", key, b64url(p[2]),
    new TextEncoder().encode(p[0] + "." + p[1]),
  );
  if (!ok) return false;
  const c = JSON.parse(new TextDecoder().decode(b64url(p[1])));
  return c.iss === "aditus-queue" && c.aud === SLUG && c.exp > Date.now() / 1000;
}

function b64url(v) {
  return Uint8Array.from(
    atob(v.replace(/-/g, "+").replace(/_/g, "/")),
    (ch) => ch.charCodeAt(0),
  );
}
AWS CloudFront (Lambda@Edge)
// Skizze: AWS CloudFront mit Lambda@Edge (Viewer-Request, Node.js).
// Gleiches Muster: Token aus ?aditus_queue_token oder Cookie, HS256 offline
// prüfen, ohne gültigen Token in den Warteraum umleiten.
// Hinweis: Lambda@Edge hat keine Umgebungsvariablen — das Secret z. B. beim
// Deployment einbetten oder aus SSM/Secrets Manager cachen.
'use strict';
const crypto = require('crypto');
const SLUG = '<slug>';
const ROOM = 'https://aditus.dev/queue/' + SLUG;
const SECRET = '<ADITUS_QUEUE_SECRET>';

exports.handler = async (event) => {
  const req = event.Records[0].cf.request;
  const qs = new URLSearchParams(req.querystring || '');
  const fromUrl = qs.get('aditus_queue_token');
  const cookie = (req.headers.cookie || []).map((h) => h.value).join('; ');
  const m = cookie.match(/(?:^|;\s*)aditus_queue=([^;]+)/);
  const token = fromUrl || (m && m[1]);

  if (!token || !valid(token)) {
    return redirect(ROOM); // zurück in den Warteraum
  }
  if (fromUrl) {
    // Token in ein Cookie übernehmen und die URL bereinigen
    qs.delete('aditus_queue_token');
    const clean = req.uri + (qs.toString() ? '?' + qs.toString() : '');
    return redirect(clean, {
      'set-cookie': [{ key: 'Set-Cookie', value:
        'aditus_queue=' + token + '; Path=/; Secure; HttpOnly; Max-Age=600' }],
    });
  }
  return req; // gültiger Pass -> durch zum Shop (Origin)
};

function valid(token) {
  const p = token.split('.');
  if (p.length !== 3) return false;
  const sig = crypto.createHmac('sha256', SECRET)
    .update(p[0] + '.' + p[1]).digest();
  const got = Buffer.from(p[2], 'base64url');
  if (got.length !== sig.length || !crypto.timingSafeEqual(sig, got)) {
    return false;
  }
  const c = JSON.parse(Buffer.from(p[1], 'base64url'));
  return c.iss === 'aditus-queue' && c.aud === SLUG && c.exp > Date.now() / 1000;
}

function redirect(location, extraHeaders) {
  return {
    status: '302',
    headers: Object.assign(
      { location: [{ key: 'Location', value: location }] },
      extraHeaders || {},
    ),
  };
}

Hinweis: Mit aktiver Prüfung am Edge benötigt jeder Besucher einen Token — auch diejenigen, die unterhalb der Weiterleitungsrate sonst still passieren würden. Veröffentliche dazu den Gateway-Link (Variante A), oder lass den Proxy Besucher ohne Token in den Warteraum umleiten; dieser stellt bei leerer Schlange sofort einen Token aus.

Einrichtung: Was ADITUS von dir benötigt

Der Warteraum wird von ADITUS konfiguriert. Für die Einrichtung stellst du folgende Angaben bereit:

Grafik (optional)

Eine Titelgrafik für die Warteraum-Seite, z. B. das Key-Visual der Veranstaltung. Querformat, mindestens 920 × 380 Pixel (dargestellt mit bis zu 460 px Breite, beschnitten auf maximal 190 px Höhe), JPG oder PNG, als öffentlich erreichbare HTTPS-URL oder als Datei an ADITUS.

Text (optional)

Eine kurze Nachricht unterhalb des Warteraum-Titels, z. B. ein Hinweis zum Vorverkaufsstart oder zur erwarteten Wartezeit. Reiner Text, Zeilenumbrüche bleiben erhalten; empfohlene Länge bis etwa 300 Zeichen. Der Text wird unverändert angezeigt — bei internationalem Publikum stellst du ihn in der passenden Sprache oder zweisprachig bereit.

Shop-Domains

Die Domains der Seiten, auf denen das Script läuft (z. B. shop.example.com). Sie legen fest, welche Rücksprung-URLs der Warteraum akzeptiert.

Anzeigename, Ziel-URL, Rate

Der Titel des Warteraums (z. B. der Veranstaltungsname), die Ziel-URL für weitergeleitete Besucher (für den Gateway-Link erforderlich — sie ist die Shop-Adresse, an die der Gateway weiterleitet) und die Weiterleitungsrate in Besuchern pro Minute. Die Rate ist der Grenzwert: Solange weniger Besucher eintreffen, als die Rate zulässt, passieren alle ohne Warteraum. Sie ist jederzeit im laufenden Betrieb anpassbar.

Aktualisiert sich automatisch (alle paar Sekunden)
1

Wartenummer — wird beim Öffnen der Seite einmal vergeben und bleibt für die gesamte Wartezeit erhalten, auch über ein Neuladen hinweg.

2

Position und freigegebene Nummer — wie viele Nummern noch vor der eigenen liegen und bis zu welcher Nummer gerade weitergeleitet wird. Die freigegebene Nummer wächst kontinuierlich mit der Weiterleitungsrate.

3

Fortschrittsbalken — zeigt, wie weit die Weiterleitung bereits an die eigene Nummer herangerückt ist.

4

Voraussichtliche Wartezeit — berechnet aus aktueller Position und Weiterleitungsrate; sie verkürzt sich, während die Weiterleitung voranschreitet. Sobald die eigene Nummer freigegeben ist, leitet die Seite automatisch zum Shop weiter — ganz ohne Zutun.

Einmalig konfiguriert (statisch)
A

Titelgrafik — optional, z. B. das Key-Visual der Veranstaltung.

B

Anzeigename — der Titel des Warteraums, z. B. der Veranstaltungsname.

C

Nachricht — optionaler Text unterhalb des Titels, unverändert angezeigt.

Schema der Warteraum-Seite: Coral markierte Elemente sind Live-Werte und aktualisieren sich automatisch, grau markierte werden einmalig konfiguriert.
Der gehostete Warteraum mit Titelgrafik und Nachricht: Wartenummer, Position, freigegebene Nummer und voraussichtliche Wartezeit aktualisieren sich automatisch.

Die Warteraum-Seite selbst ist zweisprachig (Deutsch/Englisch). Die Sprache wird automatisch anhand der Browser-Einstellung des Besuchers gewählt; eine Konfiguration ist nicht erforderlich.

Betrieb: das Live-Dashboard

Während des Vorverkaufs überwacht ADITUS jeden Warteraum in einem Live-Dashboard: Anzeigen zeigen die aktuellen Wartenden, den Zulauf neuer Besucher im Verhältnis zur Weiterleitungsrate, die Weiterleitungsrate selbst (bei aktiver selbstregelnder Rate samt konfiguriertem Maximum) und die voraussichtliche Wartezeit für Neuankömmlinge. Ein Verlauf stellt Wartende und Zulauf über die Zeit gegenüber, und die Queue-Instanzen, die den Traffic bedienen, melden ihre eigene Auslastung — CPU, Speicher und Request-Rate. Die Weiterleitungsrate lässt sich jederzeit im laufenden Betrieb anpassen — etwa wenn der Shop Reserven zeigt.

Das Live-Dashboard in der ADITUS-Verwaltung, während des Vorverkaufs alle 3 Sekunden aktualisiert.

Betrieb: Lasttests und Healthcheck

Die Belastbarkeit der Queue wird nicht nur behauptet, sondern regelmäßig nachgewiesen. Aus der ADITUS-Verwaltung heraus feuern Lasttests echte Requests auf einen dedizierten Test-Warteraum des Produktionssystems (produktive Warteräume werden nie berührt). Ein Test simuliert den Besucherpfad — Beitritt und Status-Polling — mit konfigurierbarer Rate und Dauer. Live-Anzeigen zeigen die erreichte Request-Rate, Median- und p95-Latenz sowie die Fehlerquote; ein Sekundenverlauf stellt Durchsatz und Latenz gegenüber, und jeder Lauf wandert in eine Historie, damit Ergebnisse über die Zeit vergleichbar bleiben. Tests laufen zusätzlich nach Zeitplan, und ein geplanter Lauf, der deutlich schlechter abschneidet als die letzten vergleichbaren Läufe, wird automatisch markiert.

Ein Lasttest gegen die Produktions-Queue: Live-Kennzahlen, Sekundenverlauf, die während des Tests aktiven Queue-Instanzen und die Historie vergangener Läufe.

Für die externe Überwachung stellt der Queue-Service einen öffentlichen Healthcheck unter /queue/healthz bereit. Er antwortet ohne Authentifizierung und ohne Datenbankzugriff — ein einfaches Verfügbarkeitssignal für das Uptime-Monitoring. Während eines Lasttests zeigt die Verwaltung zusätzlich die selbst gemeldeten Queue-Instanzen mit CPU, Speicher, Event-Loop-Verzögerung und Request-Rate; unter Last startet die Plattform automatisch weitere Instanzen, und der Test macht das sichtbar.

Betrieb: die selbstregelnde Weiterleitungsrate

Optionales Upgrade — eine feste Rate genügt

Die Weiterleitungsrate ist der eine Regler, der während eines Vorverkaufs über alles entscheidet — und bisher musste ihn jemand im Blick behalten. Das ist vorbei: Die Queue kann die Rate selbst regeln, gesteuert vom tatsächlichen Zustand des geschützten Shops. Das Ergebnis ist ein Warteraum, der in jedem Moment so schnell verkauft, wie es der Shop sicher verkraftet — ohne dass jemand am Regler steht.

Volle Auslastung, null Risiko

Solange der Shop gesund ist, steigt die Rate in kleinen Schritten und ungenutzte Reserven werden zu Verkäufen. Zeigt der Shop Belastung, fällt die Rate deutlich — bewusst asymmetrisch: Entlastung sofort, Last kehrt vorsichtig zurück.

Fail-safe von Grund auf

Ein nicht erreichbarer Healthcheck öffnet die Tore nie weiter: Die Rate friert zunächst ein und fällt dann auf das konfigurierte Minimum. Der Shop ist genau dann geschützt, wenn gerade niemand hinschaut.

Deine Regeln, volle Transparenz

Du definierst, was gesund heißt — Antwortzeit, CPU-Last, jeder Messwert, den dein Shop meldet. Jede automatische Anpassung wird protokolliert und ist im Live-Dashboard sichtbar, samt der Regel, die sie ausgelöst hat.

Statt die Weiterleitungsrate von Hand nachzuführen, kann ein Warteraum sie automatisch aus einem Healthcheck des geschützten Shops regeln. ADITUS fragt in einem konfigurierbaren Intervall eine Health-URL des Shops ab und bewertet die Antwortzeit sowie optional numerische Felder aus der JSON-Antwort anhand vom Betreiber definierter Regeln (zum Beispiel: Antwortzeit unter 500 ms, CPU-Last unter 0,8). Solange der Shop gesund ist, steigt die Rate langsam in kleinen Schritten; sobald eine Regel verletzt wird, sinkt sie schnell um einen Prozentsatz — bewusst asymmetrisch, damit der Shop sofort entlastet wird, die Last aber vorsichtig zurückkehrt. Die Rate bleibt dabei immer innerhalb eines konfigurierten Minimums und Maximums.

Antwortet der Health-Endpoint nicht, verhält sich das System fail-safe: Die Rate wird zunächst eingefroren, nach mehreren Fehlversuchen in Folge sinkt sie auf das konfigurierte Minimum — ein nicht erreichbarer Healthcheck öffnet die Tore nie weiter. Jede automatische Anpassung wird protokolliert und ist im Live-Dashboard sichtbar; bevor die Automatik aktiviert werden kann, muss der Endpoint einmalig aus der Verwaltung heraus erfolgreich getestet werden.

Der Health-Endpoint auf Shop-Seite bleibt trivial: eine HTTPS-URL, ohne Authentifizierung erreichbar, Antwort mit 2xx. Ein JSON-Body ist optional — alle numerischen Felder (verschachtelte Objekte werden zu Punktpfaden abgeflacht) stehen als Messwerte für Regeln zur Verfügung:

Beispiel-Health-Antwort des Shops
{
  "status": "ok",
  "responseBudgetMs": 500,
  "metrics": {
    "cpuLoad": 0.42,
    "dbPoolWaiting": 0,
    "openCheckouts": 118
  }
}

// Nutzbare Messwerte (Punktpfade):
//   responseBudgetMs, metrics.cpuLoad, metrics.dbPoolWaiting, metrics.openCheckouts
// Dazu immer verfügbar: die gemessene Antwortzeit (ms).

Betrieb: Bot-Schutz per Proof-of-Work

Für stark nachgefragte Vorverkäufe kann ein Warteraum zusätzlich einen Arbeitsnachweis verlangen, bevor eine Wartenummer vergeben wird. Der Browser löst dann im Hintergrund ein kleines kryptographisches Rätsel — für den Besucher unsichtbar und bei der Standard-Schwierigkeit auf gewöhnlichen Geräten deutlich unter einer Sekunde. Für eine Bot-Farm ändert sich das Bild: Jeder einzelne Beitritt kostet dieselbe Rechenarbeit, das Ziehen tausender Nummern wird damit proportional teuer statt kostenlos. Der Schutz ist standardmäßig aus und wird pro Warteraum in der ADITUS-Verwaltung aktiviert; die Schwierigkeit ist einstellbar (8 bis 24 Bit, Standard 15 — jedes zusätzliche Bit verdoppelt die Arbeit). Die gehostete Warteraum-Seite löst das Rätsel automatisch; an der Shop-Einbindung ändert sich nichts.

Eine bewusste Konsequenz: Solange der Schutz aktiv ist, entfällt die stille Direktfreigabe unterhalb der Weiterleitungsrate — jeder Besucher durchläuft den Warteraum, denn nur dort wird der Arbeitsnachweis erbracht. Und eine Einordnung: Der Arbeitsnachweis schützt die Nummernvergabe gegen massenhaftes Ziehen. Er ist ein Baustein gegen automatisierte Aufkäufer, kein vollständiger Bot-Schutz — bei Bedarf wird er mit Maßnahmen im Shop selbst kombiniert (etwa Kauflimits).

Nur Eigenbau-Integrationen, die die Queue-API direkt ansteuern, lösen das Rätsel selbst. Der Ablauf: Challenge abholen, eine Nonce finden, deren SHA-256-Hash aus Challenge plus Nonce mit der geforderten Anzahl Null-Bits beginnt, und beides mit dem Beitritt einreichen. Challenges sind signiert und fünf Minuten gültig; Wiederverwendung wird zusätzlich pro Instanz unterbunden:

Proof-of-Work-Ablauf für Eigenbau-Integrationen
// 1. Challenge holen (nur relevant, wenn PoW für die Queue aktiv ist)
GET https://aditus.dev/queue/<slug>/pow
// -> { queue, enabled: true, challenge, bits, expiresInSeconds: 300,
//      algorithm: "sha256" }

// 2. Nonce suchen: SHA-256(challenge + "." + nonce) muss mit <bits>
//    Null-Bits beginnen. Im Browser per WebCrypto — bei der
//    Standard-Schwierigkeit deutlich unter einer Sekunde.

// 3. Beitritt mit Lösung
POST https://aditus.dev/queue/<slug>/join
{ "pow": { "challenge": "…", "nonce": "…" } }

// Ohne oder mit ungültiger Lösung antwortet /join mit
// 428 Precondition Required — und liefert im Fehlerkörper direkt eine
// frische Challenge mit, sodass kein zweiter Abruf nötig ist.

Betrieb: geplante Öffnungen mit fairer Auslosung

Für angekündigte Vorverkäufe kann ein Warteraum einen festen Öffnungszeitpunkt bekommen. Wer früher kommt, landet in einer Pre-Queue: Die Warteraum-Seite zeigt einen Countdown bis zur Öffnung, weitergeleitet wird noch niemand. Zur Öffnung passiert der entscheidende Schritt — die Weiterleitungsreihenfolge unter allen bis dahin Wartenden wird fair ausgelost. Drei Stunden früher da zu sein bringt damit keinen Vorteil gegenüber drei Minuten; Reload-Marathons und geparkte Browser-Tabs verlieren ihren Sinn. Wer nach der Öffnung dazukommt, reiht sich hinter der ausgelosten Gruppe in normaler Reihenfolge ein.

Die Auslosung ist eine mathematische Permutation über die vor der Öffnung vergebenen Wartenummern — jede Nummer erhält genau eine Position, keine geht verloren, keine kommt doppelt vor, und die Zuordnung ist aus der Beitrittsreihenfolge nicht vorhersagbar. Wird der Öffnungszeitpunkt in der Verwaltung geändert, setzt sich die Auslosung neu auf; an der Shop-Einbindung und der API ändert sich nichts.

Betrieb: Abandon-Erkennung

Nicht jeder, der eine Wartenummer zieht, bleibt auch. Geschlossene Tabs und verlassene Browser reißen sonst Lücken: Das Weiterleitungsfenster wandert über Nummern, die niemandem mehr gehören, und der reale Durchsatz fällt unter die konfigurierte Rate. Mit aktivierter Abandon-Erkennung meldet die gehostete Warteraum-Seite ihre Anwesenheit in einem regelmäßigen Heartbeat. Bleibt eine Nummer länger als die konfigurierte Frist still (60 bis 3600 Sekunden, Standard 180), gilt sie als abgesprungen — und das Weiterleitungsfenster rückt um genau diesen Betrag schneller vor, freie Plätze kommen also den Besuchern zugute, die tatsächlich noch warten.

Die Erkennung ist bewusst nachsichtig: Ein zurückkehrender Besucher, dessen Nummer als abgesprungen gezählt wurde, aber bereits im Weiterleitungsfenster liegt, wird normal weitergeleitet — der Heartbeat beschleunigt nur, er entzieht nie eine Weiterleitung. Eigenbau-Integrationen mit eigener Warteseite senden dasselbe Signal über POST /queue/<slug>/heartbeat (JSON-Body mit der Wartenummer, empfohlen alle 60 Sekunden).

Betrieb: VIP-Bypass-Codes

Presse, Partner, Fanclub-Kontingente: Manche Besucher sollen nie einen Warteraum sehen. Für sie lassen sich pro Warteraum in der ADITUS-Verwaltung Bypass-Codes anlegen — jeder mit Bezeichnung, optionalem Nutzungslimit und optionalem Ablaufdatum, jederzeit deaktivierbar oder löschbar. Geteilt wird ein Code als einfacher Link: /queue/<slug>/enter?code=… leitet mit gültigem Zugriffs-Token direkt in den Shop, an der gesamten Warteschlange vorbei. Eigenbau-Integrationen lösen Codes stattdessen über POST /queue/<slug>/bypass ein und erhalten das Token als JSON.

Zwei bewusste Sicherheitseigenschaften: Ein ungültiger Code am Gateway-Link fällt still auf den normalen Weg zurück — von außen ist nicht erkennbar, ob ein Code je existiert hat. Und die JSON-Route antwortet für ungültige, abgelaufene, aufgebrauchte und deaktivierte Codes identisch, es gibt also kein Orakel zum Code-Raten. Bypass-Weiterleitungen sind im Token als solche markiert und verbrauchen keine regulären Weiterleitungsplätze.

Technische Details

Die folgenden Abschnitte sind für die Einbindung nicht erforderlich — das Script-Tag oben ist vollständig. Sie dokumentieren die Funktionsweise für die technische Bewertung und für Shops, die die Freigabe zusätzlich im eigenen Backend prüfen wollen.

Funktionsweise der Weiterleitung

Jeder Besucher erhält per atomarem Datenbank-Inkrement eine fortlaufende Wartenummer. Die Weiterleitung schreitet kontinuierlich voran: Die aktuell freigegebene Nummer berechnet sich als Basis + Rate × vergangene Minuten. Die Statusabfrage ist rein lesend und belastet die Datenbank nicht pro Anfrage. Es gibt keinen Zustand pro Besucher auf dem Server, keinen Cronjob und keinen Timer — der Queue-Service kann unter Last selbst nicht zum Engpass werden. Das Pausieren einer Queue stoppt Weiterleitung und Nummernvergabe; Ratenänderungen wirken kontinuierlich, die freigegebene Nummer springt nie zurück.

Fairness: strikt in Ankunftsreihenfolge

Die Weiterleitung erfolgt strikt in Ankunftsreihenfolge (First come, first served): Das atomare Inkrement fixiert die Position jedes Besuchers im Moment des Beitritts, danach ändert sie sich nie. Es gibt bewusst keine Lotterie, keine Zufallsauswahl und keine Priority-Lane — bei Knappheit ist die Ankunftsreihenfolge die einzige Ordnung, die Besucher als fair akzeptieren, und die einzige, die sich nicht manipulieren lässt. Vordrängeln ist auf zwei Ebenen technisch ausgeschlossen: Wartenummern wachsen nur, und die Freigabeprüfung vergleicht die Nummer des Besuchers serverseitig mit der aktuell freigegebenen Nummer — erst wenn diese Prüfung besteht, wird der Zugriffs-Token ausgestellt, signiert mit dem Secret der Queue. Ein Besucher kann keine bessere Position behaupten, und ein gefälschter Token scheitert an der Signaturprüfung. Wer getrennte Ströme braucht — etwa einen Warteraum pro Event oder pro Verkauf —, betreibt mehrere unabhängige Warteräume, jeder mit eigenem Slug, Secret, eigener Rate und Konfiguration.

Architektur unter Last: Messwerte

Das Designziel folgt direkt aus der oben beschriebenen Weiterleitungslogik: Weil sich die freigegebene Nummer aus der verstrichenen Zeit ableitet und die Statusabfrage keinen Zustand pro Besucher liest, ist fast der gesamte Besucher-Traffic zustandslose Berechnung. Jede Instanz kann jede Anfrage beantworten, Instanzen teilen sich nichts außer der Datenbank, und die Plattform startet unter Last automatisch weitere Instanzen. Der eine Datenbank-Schreibzugriff pro Besucher — das atomare Inkrement beim Beitritt — ist der einzige Serialisierungspunkt und fällt genau einmal pro Besucher an, nicht pro Abfrage. Die folgenden Zahlen stammen aus dem oben beschriebenen eingebauten Lasttest-Runner, gemessen über den öffentlichen HTTPS-Endpunkt gegen eine einzelne Instanz des Queue-Service; das Profil mix kombiniert Beitritt und Status-Polling im Verhältnis des realen Besucherpfads:

LaufErgebnis
mix · 10 req/s · 30 sLatenz p50 7,6 ms · p95 12,0 ms · Fehlerquote 0 %
mix · 25 req/s · 60 sLatenz p50 7,3 ms · p95 11,4 ms · Fehlerquote 0 %
mix · 50 req/s · 45 sLatenz p50 6,7 ms · p95 11,0 ms · Fehlerquote 0 %
status · 50 req/s · 45 sLatenz p50 6,4 ms · p95 8,9 ms · Fehlerquote 0 %

Gemessen im Juli 2026 mit dem produktiven Code-Pfad; jeder Lauf schloss ohne Fehler und mit einstelliger Median-Latenz ab. Eine einzelne Instanz verarbeitet fünfzig Requests pro Sekunde — mehrere tausend wartende Besucher, die im empfohlenen Intervall abfragen — ohne erkennbare Anstrengung; darüber hinaus übernehmen zusätzliche Instanzen. Diese Skalierung ist keine Blackbox: Jede laufende Instanz meldet sich fortlaufend selbst mit Live-Metriken — CPU, Speicher, Request-Durchsatz —, jederzeit einsehbar in der ADITUS-Verwaltung. So ist transparent, wie viele Instanzen einen On-Sale gerade tragen und wie viel Reserve bleibt. Geplante Lasttests weisen diese Zahlen fortlaufend gegen das Produktionssystem nach, und ein Lauf, der deutlich hinter seine Vorgänger zurückfällt, wird automatisch markiert.

Endpoints

Zehn Endpoints, keine Authentifizierung für Besucher, CORS beschränkt auf die pro Queue konfigurierten Domains. Die gehostete Warteraum-Seite nutzt genau diese API — sie lässt sich auch direkt ansteuern, wenn ein komplett eigener Warteraum gewünscht ist.

EndpointWas er tut
GET /queue/<slug>Gehostete Warteraum-Seite: fordert eine Nummer an, pollt den Status und leitet nach Freigabe automatisch weiter.
POST /queue/<slug>/joinWartenummer vergeben (der einzige Schreibzugriff im Besucherpfad). 423, solange der Warteraum pausiert ist.
GET /queue/<slug>/status?number=NWeiterleitungs-Status einer Nummer abfragen — rein lesend, inklusive Retry-After-Header. 404 für nie ausgegebene Nummern.
POST /queue/<slug>/tokenEine freigegebene Nummer gegen einen signierten HS256-JWT eintauschen. 425, solange die Nummer noch nicht freigegeben ist; 404 für nie ausgegebene Nummern.
GET /queue/<slug>/enterGateway-Eingang: wird anstelle der Shop-URL veröffentlicht. Leitet bei freier Kapazität direkt an die konfigurierte Ziel-URL weiter (mit Zugriffs-Token); andernfalls in den Warteraum. Erfordert eine konfigurierte Ziel-URL. Akzeptiert ?code=… für VIP-Bypass-Codes: Ein gültiger Code überspringt die Warteschlange komplett, ein ungültiger fällt ohne Hinweis auf den normalen Weg zurück.
GET /queue/<slug>/embed.jsEinbindungs-Script für den Shop: lässt Besucher still ein, solange niemand wartet; erst bei gebildeter Schlange leitet es Besucher ohne gültigen Pass in den Warteraum und bringt sie exakt auf die Ausgangsseite zurück.
GET /queue/<slug>/verify?token=…Serverseitige Token-Prüfung, die das Einbindungs-Script nutzt: validiert Signatur, Audience und Ablauf eines Zugriffs-Tokens.
GET /queue/<slug>/infoÖffentliche Queue-Info: Aktiv-Status, aktuell freigegebene Nummer und Anzahl Wartender.
POST /queue/<slug>/heartbeatAnwesenheitssignal für die optionale Abandon-Erkennung: Die Warteraum-Seite meldet eine Nummer als weiterhin anwesend. Ohne aktivierte Erkennung wird der Aufruf still angenommen.
POST /queue/<slug>/bypassVIP-Bypass-Code per JSON einlösen: liefert Zugriffs-Token samt Ziel-URL. Ungültige, abgelaufene, aufgebrauchte und deaktivierte Codes ergeben identisch 404 — kein Orakel zum Code-Raten.
GET /queue/<slug>/powProof-of-Work-Challenge für den optionalen Bot-Schutz: liefert enabled: false, solange der Schutz aus ist; andernfalls eine signierte Challenge, deren Lösung /join erwartet.
GET /queue/healthzÖffentlicher Healthcheck für das Uptime-Monitoring: antwortet ohne Authentifizierung und ohne Datenbankzugriff. Bewusst von den Instanz-Metriken ausgenommen, damit Monitoring-Pings das Traffic-Bild nicht verfälschen.

1. Wartenummer anfordern

join.ts
// Wartenummer anfordern (einziger Schreibzugriff im Besucherpfad).
const res = await fetch("https://aditus.dev/queue/<slug>/join", {
  method: "POST",
});
const ticket: {
  queue: string;              // Queue-Slug
  name: string;               // Anzeigename des Warteraums
  number: number;             // vergebene Wartenummer
  serving: number;            // bis zu dieser Nummer wird weitergeleitet
  ahead: number;              // Anzahl Nummern vor dieser
  admitted: boolean;          // true -> sofort weiter zu /token
  estimatedWaitSeconds: number;
  retryAfterSeconds: number;  // empfohlenes Polling-Intervall
} = await res.json();
// 423 Locked -> der Warteraum ist pausiert (keine Weiterleitung, keine neuen Nummern).

2. Status abfragen

status.ts
// Statusabfrage — rein lesend, beliebig oft wiederholbar.
// Der Server sendet zusätzlich einen Retry-After-Header.
const res = await fetch(
  "https://aditus.dev/queue/<slug>/status?number=" + ticket.number,
);
const status: {
  queue: string;
  name: string;
  active: boolean;            // false -> Weiterleitung pausiert
  number: number;
  serving: number;
  ahead: number;
  admitted: boolean;
  estimatedWaitSeconds: number;
  retryAfterSeconds: number;
} = await res.json();

if (status.admitted) {
  // -> Token abholen und zum Shop weiterleiten
}

3. Zugriffs-Token abholen

token.ts
// Sobald admitted=true: Zugriffs-Token abholen.
const res = await fetch("https://aditus.dev/queue/<slug>/token", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ number: ticket.number }),
});
// 425 Too Early -> die Nummer ist noch nicht zur Weiterleitung freigegeben.
const grant: {
  queue: string;
  number: number;
  token: string;              // signierter HS256-JWT
  tokenType: "JWT";
  expiresInSeconds: number;   // Standard: 600 s
  targetUrl: string | null;   // konfiguriertes Weiterleitungsziel
} = await res.json();

// Weiterleitung übernimmt die gehostete Warteraum-Seite automatisch:
// targetUrl + "?aditus_queue_token=" + grant.token

Optional: Token-Prüfung im eigenen Backend

Die Script-Tag-Einbindung ist für sich vollständig. Shops mit eigenem Backend können den Zugriffs-Token dort zusätzlich prüfen: Es ist ein Standard-HS256-JWT, offline mit dem gemeinsamen Secret verifizierbar — kein Rückruf an die Queue, keine zusätzliche Latenz. Das Secret wird beim Anlegen der Queue erzeugt, genau einmal angezeigt und lässt sich jederzeit rotieren. Claims: iss ist immer aditus-queue, aud der Queue-Slug, qnr die weitergeleitete Wartenummer, exp begrenzt die Gültigkeit (Standard 10 Minuten). Hinweis: Bei der stillen Direktfreigabe unterhalb der Weiterleitungsrate entsteht kein Token — ein Backend, das zwingend einen Token verlangt, schickt Besucher ohne Token in den Warteraum; dieser stellt bei leerer Schlange sofort einen Token aus.

verify.ts
// ZIELSYSTEM (dein Shop / deine Seite): Token prüfen — Standard-JWT (HS256).
// Das Secret erhältst du einmalig von ADITUS beim Einrichten des Warteraums.
import jwt from "jsonwebtoken";

const payload = jwt.verify(token, process.env.ADITUS_QUEUE_SECRET!, {
  algorithms: ["HS256"],
  issuer: "aditus-queue",     // iss ist immer aditus-queue
  audience: "<slug>",         // aud ist der Queue-Slug deines Warteraums
}) as { qnr: number; iat: number; exp: number };

// payload.qnr = die weitergeleitete Wartenummer.
// Gültiger Token -> Besucher passieren lassen (z. B. Cookie setzen).
// Fehlender/ungültiger Token -> zurück in den Warteraum:
//   https://aditus.dev/queue/<slug>

Sicherheit im Überblick

Die Sicherheitsmechanismen sind oben dort beschrieben, wo sie im Ablauf hingehören; dieser Abschnitt sammelt sie. Signierte Tokens: Zugriffs-Tokens sind HS256-JWTs, signiert mit einem Secret pro Queue, das genau einmal angezeigt wird und sich jederzeit rotieren lässt; die Audience-Bindung (Queue-Slug) und eine kurze Gültigkeit (Standard 10 Minuten) begrenzen den Wert eines abgefangenen Tokens. Bot-Schutz: Die optionale Proof-of-Work-Prüfung macht massenhaftes Beitreten aus Bot-Farmen proportional teuer; Challenges sind HMAC-signiert und verfallen nach fünf Minuten; ein Best-Effort-Schutz pro Instanz unterbindet zusätzlich die Wiederverwendung einer bereits eingelösten Challenge — der eigentliche Kostentreiber ist die Hash-Arbeit selbst. Redirects: Rücksprung-URLs werden serverseitig gegen die pro Queue konfigurierten Domains geprüft — der Warteraum wird nie zum offenen Redirect. API-Fläche: Besucher-Endpoints tragen keinerlei Zugangsdaten, CORS ist pro Queue beschränkt, der Admin-Zugriff nutzt API-Keys, die nur als Hash gespeichert sind, keine anderen Keys verwalten können und eine Audit-Spur hinterlassen. Lastspitzen: Die zustandslose Architektur absorbiert Last per Design — jede Instanz beantwortet jede Anfrage, die Plattform skaliert Instanzen automatisch; die DDoS-Filterung auf Netzwerkebene übernimmt die Hosting-Plattform vor dem Dienst.

Fehlerfälle: Was passiert, wenn etwas ausfällt

Ein Warteraum steht vor dem Umsatz — sein Verhalten im Fehlerfall zählt genauso wie der Normalbetrieb.

  • Queue-Service nicht erreichbar (Script-Tag-Variante): Das Script fällt offen aus — der Shop bleibt voll nutzbar. Ein Ausfall des Warteraums blockiert den Shop nie.
  • Queue-Service nicht erreichbar (Gateway-Variante): Neue Einstiege pausieren; bereits weitergeleitete Besucher sind auf dem Shop und arbeiten unbeeinträchtigt weiter.
  • Ausfall einer einzelnen Instanz: Kein Besucher merkt es. Auf keiner Instanz liegt Zustand pro Besucher — jede Instanz beantwortet jede Anfrage, die gemeinsame Datenbank ist die einzige zustandsbehaftete Komponente.
  • Browser-Refresh: Die Wartenummer bleibt in der Browser-Sitzung erhalten — ein Neuladen kehrt auf dieselbe Position zurück, der Platz in der Schlange geht nie verloren.
  • Besucher löscht Cookies oder Browser-Speicher: Die Position ist bewusst nicht wiederherstellbar — der Besucher zieht eine neue Nummer am Ende der Schlange. Alles andere wäre ein Einfallstor für Positionsbetrug.
  • Warteraum pausiert: Beitritt und Weiterleitung stoppen mit klarem Signal (HTTP 423) und erklärender Meldung im Warteraum — keine stillen Fehler.
  • Shop-Healthcheck fällt aus (automatische Rate): Die Rate wird erst eingefroren, dann auf das konfigurierte Minimum gesenkt — ein nicht erreichbarer Healthcheck öffnet die Tore nie weiter.

Einordnung gegenüber spezialisierten Warteraum-Lösungen

ADITUS-Queue adressiert dieselben technischen Problemstellungen wie spezialisierte Enterprise-Virtual-Waiting-Room-Produkte. Die Tabelle ordnet die Fähigkeiten, an denen solche Produkte gemessen werden, der Umsetzung in ADITUS-Queue zu — inklusive einer bewussten Auslassung.

FähigkeitIn ADITUS-Queue
FairnessStrikt FCFS per atomarem Inkrement; Vordrängeln technisch ausgeschlossen.
Fail-openBei der Script-Tag-Einbindung blockiert ein Warteraum-Ausfall die geschützte Anwendung nie; bereits weitergeleitete Besucher sind in jeder Variante unbeeinträchtigt.
Edge-DurchsetzungOffline-Token-Prüfung in Nginx, Caddy, Cloudflare, CloudFront — null Zusatzlatenz.
Bot-SchutzOptionales Proof-of-Work pro Queue, für echte Browser unsichtbar.
Nachgewiesene LeistungVeröffentlichte Messwerte, fortlaufend per geplanten Lasttests auf Produktion nachgewiesen.
Adaptive WeiterleitungsrateSelbstregelnde Rate, gesteuert vom Healthcheck der geschützten Anwendung.
API-firstJede Besucher- und Admin-Funktion ist ein dokumentierter REST-Endpoint.
Priority-/VIP-LanesBewusst nicht angeboten — strikte Ankunftsreihenfolge ist das Fairness-Versprechen. Getrennte Zielgruppen laufen als getrennte Warteräume.

Administration per API-Key

Alles, was die ADITUS-Verwaltung für einen Warteraum kann — Weiterleitungsrate anpassen, pausieren, Konfiguration ändern —, steht auch Maschinen offen. Der Zugriff erfolgt über einen API-Key mit dem Präfix qak_, gesendet als Bearer-Token; Keys werden in der Verwaltung erstellt und widerrufen, genau einmal angezeigt und nur als Hash gespeichert. Der typische Einsatz ist ein On-Sale-Runbook: Ein geplanter Job hebt die Weiterleitungsrate kurz vor dem Start an, ein Skript pausiert die Queue im Notfall, das Monitoring liest die aktuelle Konfiguration. Zwei Leitplanken gelten: Die Key-Verwaltung selbst ist mit einem Key bewusst nicht möglich — ein geleakter Key kann nie weitere Keys erstellen oder auflisten —, und jede Änderung per Key wird im Audit-Log unter dem Namen des Keys protokolliert.

Beispiele mit curl
# Alle Warteräume auflisten
curl -H "Authorization: Bearer qak_…" \
  https://aditus.dev/api/admin/queue/sites

# Weiterleitungsrate im laufenden Betrieb anheben: Lesen -> Feld ändern -> Schreiben.
# PATCH erwartet die vollständige Konfiguration (ohne slug); unbekannte
# Felder wie id oder Zeitstempel werden serverseitig ignoriert.
KEY="qak_…"; BASE="https://aditus.dev/api/admin/queue"
SITE=$(curl -s -H "Authorization: Bearer $KEY" "$BASE/sites" \
  | jq '.sites[] | select(.slug == "<slug>")')
echo "$SITE" | jq '.ratePerMinute = 300' | curl -s -X PATCH \
  -H "Authorization: Bearer $KEY" -H "Content-Type: application/json" \
  -d @- "$BASE/sites/$(echo "$SITE" | jq -r .id)"

# Warteraum pausieren (keine Weiterleitung, keine neuen Nummern): active = false
echo "$SITE" | jq '.active = false' | curl -s -X PATCH \
  -H "Authorization: Bearer $KEY" -H "Content-Type: application/json" \
  -d @- "$BASE/sites/$(echo "$SITE" | jq -r .id)"
Zeitgesteuert per GitHub Actions
# .github/workflows/onsale.yml — Weiterleitungsrate zum Vorverkaufsstart anheben.
# Den API-Key als Repository-Secret ADITUS_QUEUE_API_KEY hinterlegen.
name: Weiterleitungsrate zum On-Sale anheben
on:
  schedule:
    - cron: "55 8 14 3 *"   # 14. März, 08:55 UTC — kurz vor dem On-Sale
  workflow_dispatch: {}

jobs:
  raise-rate:
    runs-on: ubuntu-latest
    steps:
      - name: Rate auf 300/min anheben
        env:
          KEY: ${{ secrets.ADITUS_QUEUE_API_KEY }}
        run: |
          BASE="https://aditus.dev/api/admin/queue"
          SITE=$(curl -sf -H "Authorization: Bearer $KEY" "$BASE/sites" \
            | jq '.sites[] | select(.slug == "<slug>")')
          echo "$SITE" | jq '.ratePerMinute = 300' \
            | curl -sf -X PATCH \
              -H "Authorization: Bearer $KEY" \
              -H "Content-Type: application/json" \
              -d @- "$BASE/sites/$(echo "$SITE" | jq -r .id)"