Echtzeit auf Plattformen: Live-Auktionen, Live-Feeds und Live-Status

Das Wichtigste in Kürze

• Echtzeit lohnt sich, wenn viele Menschen gleichzeitig auf dieselbe Sache reagieren oder auf einen Statuswechsel warten, etwa bei Auktionen, Live-Feeds oder Gerätezuständen. Auf eine Eingabe sollte eine Anwendung innerhalb von 100 Millisekunden reagieren, dann empfinden Nutzer das Ergebnis laut Google als unmittelbar.
• Für den Weg vom Server auf den Bildschirm gibt es drei gängige Verfahren: regelmäßiges Nachfragen (Polling), Server-Sent Events für Nachrichten in eine Richtung und WebSockets für den Austausch in beide Richtungen.
• Bei Geboten entscheidet der Server über die Reihenfolge. Er prüft und speichert jedes Gebot in einem unteilbaren Schritt, damit zwei gleichzeitige Gebote nicht beide gewinnen.
• Verbindungen brechen ab, und Smartphones schränken Apps im Hintergrund ein. Eine gute Echtzeit-Plattform stellt Verbindungen selbst wieder her, lädt den aktuellen Stand nach und erreicht Nutzer außerhalb der App per Push-Benachrichtigung.

Stand: September 2026

Auf Ihrem Marktplatz läuft die Auktion für einen Sportwagen, noch 30 Sekunden. Zwei Interessenten bieten fast im selben Moment, ein dritter verfolgt das Geschehen in der App im Zug. Alle drei sollen sofort sehen, wer vorn liegt, und am Ende gibt es genau einen Gewinner. Dieser Ratgeber erklärt, wann eine Plattform Echtzeit braucht, wie die Technik dahinter funktioniert und worauf es bei Geboten, Verbindungsabbrüchen und mobilen Apps ankommt.

Wann braucht eine Plattform Echtzeit?

Eine normale Webseite zeigt den Stand vom Moment des Aufrufs, Neues erscheint erst nach dem Neuladen. Für Produktbeschreibungen, Preislisten oder Ratgeber ist das genau richtig. Echtzeit lohnt sich, wenn eine Information schnell an Wert verliert oder viele Menschen gleichzeitig auf dieselbe Sache reagieren: bei Live-Auktionen, Feeds mit laufenden Aktivitäten, dem Status einer Bestellung oder eines Geräts, Chats und Dashboards im Backoffice.

Wie schnell „sofort“ sein muss, beschreibt Google in seinem älteren Leistungsmodell RAIL. Reagiert eine Anwendung innerhalb von 100 Millisekunden auf eine Eingabe, empfinden Nutzer das Ergebnis als unmittelbar. Dauert es länger, geht laut Google das Gefühl verloren, dass Aktion und Reaktion zusammengehören.

Drei Wege, wie Neuigkeiten auf den Bildschirm kommen

Im Web fragt normalerweise der Browser, und der Server antwortet. Für Echtzeit muss der Server von sich aus melden können, dass sich etwas geändert hat. Dafür gibt es drei Wege.

Regelmäßiges Nachfragen (Polling): Der Browser fragt in festen Abständen, ob es Neues gibt. Das ist einfach umzusetzen. Die Internet-Standardisierungsorganisation IETF beschreibt in ihrem Fachdokument RFC 6202 die Kehrseite: Je kürzer die gewünschte Verzögerung, desto häufiger die Anfragen, und bei Abständen im Sekundenbereich kann das Server und Netz stark belasten. Beim langen Nachfragen (Long Polling) hält der Server die Anfrage deshalb offen, bis es etwas Neues gibt.

Server-Sent Events (SSE): Der Browser öffnet eine Verbindung, über die der Server jederzeit Nachrichten schicken kann. Laut MDN, der Entwicklerdokumentation von Mozilla, fließen die Daten dabei nur in eine Richtung, vom Server zum Browser. Für Live-Feeds, Statusanzeigen und Dashboards reicht das oft, denn Aktionen der Nutzer laufen über normale Anfragen.

WebSockets: Laut MDN öffnen WebSockets eine Verbindung in beide Richtungen zwischen Browser und Server, über die Nachrichten ohne ständiges Nachfragen fließen. Das Protokoll ist seit Dezember 2011 als RFC 6455 standardisiert. Es passt, wenn viel in beide Richtungen fließt, etwa bei Geboten, Chats oder gemeinsamer Bearbeitung.

Warum bei Geboten die Reihenfolge zählt

Bei einer Auktion kommt es neben Tempo vor allem auf Eindeutigkeit an. Angenommen, das Höchstgebot steht bei 80.000 €, und zwei Personen bieten im selben Augenblick 81.000 €. Prüft der Server beide Gebote gleichzeitig gegen den alten Stand, halten sich beide für den Höchstbietenden. Fachleute nennen das eine Wettlaufsituation (Race Condition).

Die Lösung: Prüfen und Speichern geschehen in einem unteilbaren Schritt, in der Fachsprache atomar. Der Datenspeicher Redis führt dafür zum Beispiel kleine Programme (Skripte) aus, die laut seiner Dokumentation atomar ablaufen: Solange ein Skript läuft, ruhen alle anderen Vorgänge auf dem Server, und seine Wirkung ist entweder noch gar nicht oder schon vollständig eingetreten. So bekommt jedes Gebot einen eindeutigen Platz in der Reihenfolge, und das zweite Gebot über denselben Betrag gilt als zu niedrig.

Wie viel Echtzeit eine Auktion braucht, hängt auch vom Format ab. Die Erläuterungen zum Wirtschaftsnobelpreis 2020 beschreiben die bekanntesten Formate:

• Englische Auktion: Der Preis steigt, alle sehen die Gebote. Jedes neue Gebot muss sofort bei allen ankommen.
• Niederländische Auktion: Der Preis startet hoch und sinkt schrittweise, bis jemand kauft. Hier entscheidet, wer zuerst zugreift.
• Verdeckte Gebote (Sealed Bid): Niemand sieht die Gebote der anderen. Live sind hier Restzeit und eigener Status.

In allen drei Fällen entscheidet die Uhr des Servers, ob ein Gebot vor oder nach dem Ende kam, nicht die Uhr auf dem Smartphone.

Wie Echtzeit mit vielen Nutzern wächst

Läuft eine Plattform auf einem einzigen Server, verteilt dieser ein neues Gebot direkt an alle verbundenen Nutzer. Bei mehreren Servern hängen die Zuschauer einer Auktion an verschiedenen Rechnern, und ein Gebot muss trotzdem alle erreichen.

Dafür gibt es das Muster Veröffentlichen und Abonnieren (Publish/Subscribe, kurz Pub/Sub). Ein Server veröffentlicht die Nachricht in einem Kanal, etwa für eine bestimmte Auktion, und alle Server, die diesen Kanal abonniert haben, reichen sie an ihre Nutzer weiter. Laut Redis-Dokumentation kennen sich Absender und Empfänger dabei nicht, was eine bessere Skalierbarkeit ermöglicht. Abonnenten erhalten die Nachrichten in der Reihenfolge, in der sie veröffentlicht wurden.

Für die Planung ist ein Detail wichtig: Redis Pub/Sub stellt jede Nachricht höchstens einmal zu. Ist ein Empfänger in diesem Moment nicht verbunden, ist die Nachricht laut Dokumentation verloren. Wer verpasste Ereignisse nachliefern möchte, nutzt gespeicherte Datenströme (bei Redis heißen sie Streams), in denen Nachrichten aufbewahrt bleiben, oder lädt den aktuellen Stand aus der Datenbank nach.

Was passiert, wenn die Verbindung abbricht?

Verbindungen brechen ab: im Funkloch, beim Wechsel vom WLAN ins Mobilfunknetz oder wenn ein Server neu startet. Um zu prüfen, ob eine Verbindung noch steht, kennt das WebSocket-Protokoll kleine Kontrollnachrichten namens Ping und Pong: Eine Seite fragt, die andere antwortet.

Bei Server-Sent Events verbindet sich der Browser laut MDN von selbst neu. Versieht der Server seine Nachrichten mit einer Kennung, schickt der Browser laut HTML-Standard beim Wiederverbinden die Kennung der zuletzt empfangenen Nachricht mit (Last-Event-ID). So kann der Server genau das nachliefern, was in der Zwischenzeit passiert ist.

Bei WebSockets übernimmt die Anwendung das Wiederverbinden selbst. Der Standard RFC 6455 empfiehlt, den ersten Versuch um eine zufällige Zeit zu verzögern und die Abstände danach schrittweise zu verlängern. Sonst könnten nach einer Störung sehr viele Geräte gleichzeitig zurückkehren und den Server zusätzlich belasten.

Nach dem Wiederverbinden zählt der aktuelle Stand: Höchstgebot, Restzeit, Status. Sinnvoll ist, diesen Stand zuerst vollständig vom Server zu laden und erst danach wieder einzelne Änderungen anzuzeigen.

Echtzeit in mobilen Apps

Solange eine App geöffnet ist, funktioniert Echtzeit wie im Browser. Im Hintergrund dagegen sparen Smartphones Akku. Laut Apple bleiben einer iOS-App nach dem Wechsel in den Hintergrund zunächst fünf Sekunden für wichtige Aufgaben, kurz darauf pausiert das System sie. Android unterbricht im Ruhemodus Doze den Netzzugriff von Apps, wenn das Gerät eine Weile unbewegt, ohne Ladekabel und mit ausgeschaltetem Bildschirm liegt.

Nutzer außerhalb der App erreichen Sie deshalb mit Push-Benachrichtigungen über die Dienste der Hersteller: den Apple Push Notification service (APNs) und Firebase Cloud Messaging (FCM) bei Android. Google empfiehlt, FCM statt einer eigenen dauerhaften Verbindung zu nutzen, weil sich alle Apps eine Verbindung teilen und das den Akku schont. Für zeitkritische, sichtbare Benachrichtigungen sieht Google Nachrichten mit hoher Priorität vor, die auch im Ruhemodus ankommen.

Eine Benachrichtigung ersetzt allerdings keinen Live-Feed. Apple beschreibt Push-Nachrichten als Weg, kleine Datenmengen an Geräte zu schicken, auch wenn die App nicht läuft. Stille Hintergrund-Benachrichtigungen behandelt iOS mit niedriger Priorität und ohne garantierte Zustellung, Apple rät zu höchstens zwei oder drei pro Stunde. Sinnvoll ist deshalb eine Arbeitsteilung: Die Benachrichtigung meldet „Sie wurden überboten“, ein Tipp öffnet die App, und die lädt den aktuellen Stand live nach.

Aus der Praxis

Drei Plattformen aus unserer Arbeit zeigen, wie unterschiedlich Echtzeit aussehen kann. Für CooleKarren, einen internationalen Marktplatz für Luxusautos, haben wir eine Echtzeit-Gebotsmaschine auf Basis von Redis und WebSockets entwickelt. Der Marktplatz bietet drei Auktionsformate (englisch, niederländisch und mit verdeckten Geboten) sowie den Direktkauf, die Gebots-Latenz liegt unter 100 Millisekunden. Geboten wird im Web und in nativen Apps für iOS und Android.

byclaw.io ist unser eigenes Produkt, ein KI-Shopping-Agent für WhatsApp, Claude, ChatGPT und das Web. Ein Live-Feed zeigt dort, was die Agents gerade tun. Wer ein Produkt auf die Watchlist setzt, bekommt Bescheid, sobald der Preis fällt.

Bei der Buchungsplattform, die wir für Wasserplasma Experience entwickelt haben, liegt die Echtzeit nicht im Browser, sondern am Standort: Die Anlage schaltet sich genau für die gebuchte Session frei, und das Backoffice sieht laufend, ob eine bezahlte Stunde auch wirklich an der Anlage lief.

Häufige Fragen

Braucht jede Plattform Echtzeit?
Nein. Echtzeit lohnt sich dort, wo viele Nutzer gleichzeitig handeln oder auf einen Status warten, etwa bei Auktionen oder Chats. Oft genügt es, einzelne Bereiche einer Plattform live zu machen und den Rest ganz normal mit der Seite zu laden.

Was passiert, wenn zwei Personen genau gleichzeitig bieten?
Der Server prüft und speichert jedes Gebot in einem unteilbaren Schritt und bringt die Gebote so in eine eindeutige Reihenfolge. Das zuerst verarbeitete Gebot zählt. Das zweite liegt danach nicht mehr über dem Höchstgebot, und die bietende Person erfährt das sofort.

Funktioniert Echtzeit auch, wenn die App geschlossen ist?
Im Hintergrund schränken iOS und Android Apps ein, um Akku zu sparen. Wichtige Ereignisse erreichen Nutzer dann per Push-Benachrichtigung über die Dienste von Apple und Google. Öffnet jemand die App, lädt sie den aktuellen Stand und zeigt Änderungen wieder live.

Fazit

Echtzeit macht eine Plattform lebendig: Gebote, Feeds und Statusanzeigen erscheinen, ohne dass jemand neu laden muss. Für das Vertrauen der Nutzer zählen eine eindeutige Reihenfolge bei Geboten, ein sauberes Wiederverbinden und Benachrichtigungen, die auch außerhalb der App ankommen. Wer das von Anfang an einplant, bekommt Live-Funktionen, die mit der Plattform wachsen.

Planen Sie eine Plattform mit Live-Funktionen?

Beschreiben Sie Ihre Idee in unserem KI-Projekt-Kalkulator. Sie erhalten eine kostenlose Schätzung per E-Mail, und wir melden uns innerhalb von 24 Stunden.

Mehr zu unseren Leistungen für Plattformen und Marktplätze und SaaS-Produkte. Oder schreiben Sie uns direkt an unsere E-Mail-Adresse.

Quellen

1. Google, web.dev: „Measure performance with the RAIL model“, zuletzt aktualisiert am 10.06.2020. https://web.dev/articles/rail
2. IETF: RFC 6202 „Known Issues and Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTP“, April 2011. https://www.rfc-editor.org/rfc/rfc6202
3. MDN Web Docs: „Using server-sent events“, zuletzt geändert am 03.09.2026. https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events
4. MDN Web Docs: „The WebSocket API (WebSockets)“. https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API
5. IETF: RFC 6455 „The WebSocket Protocol“, Dezember 2011. https://www.rfc-editor.org/rfc/rfc6455
6. Redis: „Scripting with Lua“. https://redis.io/docs/latest/develop/programmability/eval-intro/
7. NobelPrize.org: „The quest for the perfect auction“, populärwissenschaftliche Hintergrundinformation (Popular information) zum Preis für Wirtschaftswissenschaften 2020. https://www.nobelprize.org/prizes/economic-sciences/2020/popular-information/
8. Redis: „Redis Pub/sub“. https://redis.io/docs/latest/develop/pubsub/
9. WHATWG: HTML Living Standard, Abschnitt 9.2 „Server-sent events“. https://html.spec.whatwg.org/multipage/server-sent-events.html
10. Apple Developer: „Extending your app’s background execution time“. https://developer.apple.com/documentation/uikit/extending-your-app-s-background-execution-time
11. Android Developers: „Optimize for Doze and App Standby“, zuletzt aktualisiert am 18.08.2026. https://developer.android.com/training/monitoring-device-state/doze-standby
12. Apple Developer: „Setting up a remote notification server“. https://developer.apple.com/documentation/usernotifications/setting-up-a-remote-notification-server
13. Apple Developer: „Pushing background updates to your App“. https://developer.apple.com/documentation/usernotifications/pushing-background-updates-to-your-app