Was ist Präsenz (Online-Status)?

Präsenz ist ein Echtzeitsignal dafür, ob ein Nutzer gerade online, abwesend oder offline ist, aktuell gehalten durch Verbindungen und Heartbeats. Der grüne Punkt ist täuschend einfache Oberfläche über einem wirklich schweren verteilten Problem: Der Server muss Abwesenheit erschließen – Geräte kündigen ihr Ende selten an – und dann jede Schlussfolgerung an alle Zuschauenden senden, im Maßstab einer Kontaktliste. Standardisiert wurde das Muster lange vor dem modernen Chat, in den Presence-Stanzas von XMPP; seine Grundlagen haben sich seither nicht verändert.

Das Wichtigste in Kürze

Der Heartbeat-Vertrag

Das gesamte Muster passt in einen einzigen Austausch:

Client      alle 30 s:  save { status: "online", lastActiveAt: now }
Server      alle 60 s:  Sweep — lastActiveAt älter als 90 s?  → status: "offline"
                        (TTL = 2–3 × Heartbeat-Intervall)
Beobachter  status = "online"   → grüner Punkt
            status = "offline"  → "zuletzt gesehen 12:41"  ← lastActiveAt, der dauerhafte Teil

Derselbe Vertrag als SDK-Code – Heartbeat hinaus, Abonnement herein:

// JavaScript / Node.js — Back4app JS SDK
// Presence: heartbeat your own status, subscribe to your contacts'
const heartbeat = () =>
  myPresence.save({ status: 'online', lastActiveAt: new Date() });
await heartbeat();
setInterval(heartbeat, 30_000); // server sweeps offline at 2–3× this

const contacts = new Parse.Query('Presence');
contacts.containedIn('user', myContactIds);
const sub = await contacts.subscribe();
sub.on('update', (p) => setStatus(p.get('user'), p.get('status')));

// Flutter / Dart — Back4app Flutter SDK
// Presence: heartbeat your own status, subscribe to your contacts'
Future<void> heartbeat() async {
  myPresence
    ..set('status', 'online')
    ..set('lastActiveAt', DateTime.now());
  await myPresence.save();
}
Timer.periodic(const Duration(seconds: 30), (_) => heartbeat());

final contacts = QueryBuilder<ParseObject>(ParseObject('Presence'))
  ..whereContainedIn('user', myContactIds);
final sub = await LiveQuery().client.subscribe(contacts);
sub.on(LiveQueryEvent.update, (p) => setStatus(p.get('user'), p.get('status')));

// iOS / Swift — Back4app Swift SDK
// Presence: heartbeat your own status, subscribe to your contacts'
func heartbeat() async throws {
    myPresence.status = "online"
    myPresence.lastActiveAt = Date()
    _ = try await myPresence.save()
}
// Fire every 30 s — the server sweeps offline at 2–3× this

let contacts = Presence.query(containedIn(key: "user", array: myContactIds))
let sub = try await contacts.subscribe()
sub.handleEvent { _, e in
    if case .updated(let p) = e { setStatus(p.user, p.status) }
}

// Android / Kotlin — Back4app Android SDK
// Presence: heartbeat your own status, subscribe to your contacts'
fun heartbeat() {
    myPresence.put("status", "online")
    myPresence.put("lastActiveAt", Date())
    myPresence.saveInBackground()
}
timer.scheduleAtFixedRate(0, 30_000) { heartbeat() } // sweep at 2–3× this

val contacts = ParseQuery.getQuery<ParseObject>("Presence")
contacts.whereContainedIn("user", myContactIds)
val sub = ParseLiveQueryClient.Factory.getClient().subscribe(contacts)
sub.handleEvent(SubscriptionHandling.Event.UPDATE) { _, p ->
    setStatus(p.getString("user"), p.getString("status"))
}

Verbindungsereignisse vs. Heartbeat-TTL

Die beiden Erkennungsmodelle, ehrlich verglichen – keine Ranking-Seite tut das in einer einzigen Tabelle:

Das WebSocket-Protokoll selbst lehrt die Lektion: Es bringt Ping-/Pong-Steuerframes genau deshalb mit, weil TCP einen verschwundenen Gegenüber nicht offenbart, und seine Taxonomie der Close-Codes reserviert 1006 für “abnormales Schließen – kein Close-Frame empfangen”, den Zombie-Fall. Produktionsreife Präsenz schichtet daher beide Modelle übereinander: Verbindungsereignisse für sofortige Übergänge, den Heartbeat-Ablauf als die Wahrheit, die auffängt, was die Ereignisse verpassen.

Der Zustandsautomat

Zwei Verfeinerungen zeichnen ausgereifte Implementierungen aus. Abwesenheit wird auf dem Client erkannt: Der Server sieht einen in den Hintergrund geschobenen Tab nicht, der Browser schon – die Page Visibility API meldet verborgene Tabs, Eingabe-Listener melden Untätigkeit, und ein Offline-Signal nach bestem Bemühen beim Schließen des Tabs reitet auf der Beacon API. Offline wird entprellt: Der Kulanzzustand existiert, weil mobile Verbindungen flattern – veröffentlichen Sie “offline” bei jedem Tunnel und jedem Aufzug, und die Kontaktliste jedes Beobachters flackert mitfühlend mit. Verzögern Sie die Ankündigung, brechen Sie bei Wiederverbindung ab, und das Flattern fällt in sich zusammen. Eine weitere Unterscheidung lohnt sich, vom Protokoll übernommen, das Präsenz formalisiert hat: berechnete Präsenz (online, über die Verbindung) gegenüber vom Nutzer gesetztem Status (bitte nicht stören) – Letzterer gewinnt die Zusammenführung immer.

Flüchtig von Entwurf wegen

Präsenz ist ein Cache der Wirklichkeit, keine dauerhafte Aufzeichnung: Ein Status, der zu spät eintrifft, ist schlimmer als gar keiner – das “online” von gestern ist heute eine Lüge. Dieses Prinzip treibt die Umsetzungsentscheidungen: Status liegt in schnellen Speichern mit TTL statt in dauerhaften Tabellen, wird nie zur späteren Zustellung in die Warteschlange gestellt und fällt unter Backpressure als Erstes weg. Nur lastActiveAt verdient Persistenz. Tippanzeigen sind dieses Prinzip in seiner Extremform – Mikro-Präsenz auf eine einzige Unterhaltung begrenzt, in Sekunden verfallend, beim Sender entprellt und verworfen statt wiederholt; wenn “Ada tippt …” nicht jetzt ankommen kann, sollte es nie ankommen.

Das Fan-out-Problem

Die Skalierungsmauer der Präsenz ist Multiplikation, nicht Speicher. Ein durchgerechnetes Beispiel: 100.000 gleichzeitige Nutzer, jeder für 50 Kontakte sichtbar, jeder mit bescheidenen 20 Zustandswechseln pro Stunde – das sind 100.000 × 50 × 20 = 100 Millionen Präsenzereignisse pro Stunde, die zuzustellen sind, von einem Feature, das pro Nutzer eine kleine Zeile speichert. Die Hebel, in der Reihenfolge, in der man sie zieht: eng abonnieren – die Nutzer auf dem Bildschirm beobachten (die offene Liste der Unterhaltungen), nicht den gesamten Kontaktgraphen; den Long Tail abrufen statt pushen – “zuletzt gesehen” beim Öffnen eines Profils holen, statt es zu streamen; die Verteilung in Gruppen begrenzen – jenseits einiger hundert Mitglieder Präsenz bei Interaktion zeigen, nicht für die gesamte Liste; und Übergänge bündeln, sodass ein flatternder Nutzer ein entprelltes Ereignis kostet und nicht dreißig. Das Fan-out selbst reitet auf der üblichen Pub/Sub-Maschinerie – Präsenz ist der At-most-once-Sonderfall dieses Musters, in dem das Verwerfen eines veralteten Ereignisses ein Feature ist.

Mehrere Geräte und Datenschutz

Ein Nutzer, drei Geräte, ein Punkt – Präsenz pro Nutzer ist eine Zusammenführung von Präsenz pro Gerät. Verfolgen Sie den Heartbeat jedes Geräts getrennt; der Nutzer ist online, solange irgendein Gerät es ist, und die Merge-Regel lautet “verfügbarster Zustand gewinnt”: online auf dem Telefon schlägt untätig auf dem Desktop, und das “bitte nicht stören” irgendeines Geräts überstimmt den Rest. “Zuletzt gesehen” meldet das jüngste Gerät. Datenschutz ist die andere Hälfte des Entwurfs, und die Hälfte, die Engineering-Blogs überspringen, obwohl Nutzer genau danach am häufigsten fragen: Sichtbarkeitsregeln (alle / Kontakte / niemand), Gegenseitigkeit (wer sich verbirgt, verliert den Blick auf die anderen) und ein grobes “zuletzt gesehen” (“kürzlich” statt Zeitstempeln). Setzen Sie die Regeln in den Berechtigungen der Datenschicht durch – Präsenz ist Verhaltensdaten, und ein durchgesickertes “online um 3 Uhr nachts” ist eine echte Offenlegung.

Typische Anwendungsfälle

• Chat und Messaging – der kanonische grüne Punkt, “zuletzt gesehen” und Tippanzeigen.
• Kollaborationswerkzeuge – wer im Dokument ist, Cursor-Präsenz, Seitenleisten mit aktiven Personen.
• Support und Marktplätze – Routing nach Verfügbarkeit von Agenten, Vertrauenssignale wie “Verkäufer ist online”.
• Multiplayer und Soziales – Lobbys, Freundeslisten, Einstiegsmöglichkeiten zu Freunden.
• Werkzeuge für die Belegschaft – Verfügbarkeitszustände, die Routing und Status-Dashboards speisen.

Wie sollten Sie Präsenz bauen? Eine Entscheidungsmatrix

Grenzen und Trade-offs

• Präsenz ist probabilistisch. Zwischen zwei Heartbeats ist der Punkt eine Vermutung; ehrliche Systeme bekennen sich zu begrenzter Veralterung, statt sofortige Wahrheit vorzutäuschen.
• Aktualität kostet Schreibvorgänge. Das Heartbeat-Intervall zu halbieren verdoppelt die Schreiblast über alle Online-Nutzer hinweg – Erkennungstempo wird in Durchsatz bezahlt.
• Fan-out skaliert mit dem Erfolg. Das Feature ist bei 1.000 Nutzern günstig und bei 10 Millionen ein Architekturprojekt; entwerfen Sie den Umfang der Abonnements, bevor das Wachstum Sie dazu zwingt.
• Flattern ist systemimmanent. Mobilfunknetze garantieren ständige Wiederverbindungen; ohne Entprellen verstärkt Präsenz Netzrauschen zu Rauschen in der Oberfläche.
• Es hat die Form einer Überwachung. Online-Muster verraten Schlaf, Arbeit und Gewohnheiten; Sichtbarkeitsregeln und ihre Durchsetzung in der Berechtigungsschicht sind Anforderungen, keine Verbesserungen.

Präsenz mit Back4app

Back4app ist eine Open-Source-Plattform für Backend as a Service (BaaS), die eine verwaltete Datenbank, automatisch generierte REST- und GraphQL-APIs, Authentifizierung, Dateispeicher und Serverless-Funktionen mit Cloud Code kombiniert. Die Bausteine von oben bilden sich eins zu eins ab: Eine Presence-Klasse hält status und lastActiveAt; der Heartbeat ist eine periodische Speicherung (die Code-Tabs); Beobachter halten ein Live-Query-Abonnement auf die gerade sichtbaren Kontakte und empfangen gepushte Aktualisierungen über die verwaltete WebSocket-Flotte der Plattform; ein geplanter Cloud-Code-Job ist der TTL-Durchlauf, der veraltete Zeilen auf offline setzt und das Entprellen auslöst; und Klassenberechtigungen plus ACLs setzen die Sichtbarkeitsregeln in der Datenschicht um, wo sie hingehören. Nichts Maßgeschneidertes zu betreiben – Präsenz wird zur Übung in Datenmodellierung über Infrastruktur, die das Backend ohnehin betreibt.