Leistung und Skalierung

Skrum ist die All-in-one-KI-Projektsteuerung — Team-Chat, Aufgaben und Sprints, native Videomeetings und eingehende Code-Aktivität in einem Arbeitsbereich, wobei jede KI-Aktion auf eine menschliche Freigabe wartet.

Skrum ist so konstruiert, dass es reaktionsfähig bleibt, wenn ein Arbeitsbereich wächst und wenn die Infrastruktur einen schlechten Tag hat. Diese Seite dokumentiert die konkreten Zahlen, das Caching-Modell und die Ausfallmodi.

Lastschwellen

Opt-in k6-Szenarien unter load/ halten Skrum an diese Ziele gegenüber dem komponierten Stack mit deterministischen Fake-Anbietern:

• Realtime-Fan-out — 500 gleichzeitige Socket-Clients in einem Kanal, p95-Latenz von Nachricht bis Fan-out ≤ 250 ms, Fehlerrate < 0.1%.
• POST-Nachricht — p95 ≤ 200 ms bei 50 rps, Fehlerrate < 0.5%.
• Board-Lesevorgang (GET /api/tasks?projectId=…) — p95 ≤ 150 ms bei 100 rps, Fehlerrate < 0.5%.
• Suche (GET /api/search) — p95 ≤ 300 ms bei 50 rps, Fehlerrate < 1%.
• Startseiten-Zusammenfassung (GET /api/home/summary) — p95 ≤ 200 ms bei 100 rps, Fehlerrate < 0.5%.

Read-Through-Caching

Ein kleiner Redis-basierter Read-Through-Cache deckt drei heiße Pfade ab: die Kanalliste pro Arbeitsbereich, Projekt-Board-Projektionen und die Dashboard-/Startseiten-Zusammenfassung. Jeder Schlüssel ist mit der accountId des Arbeitsbereichs präfixiert — ein Arbeitsbereich kann nur seine eigenen zwischengespeicherten Daten lesen. Die Invalidierung ist ereignisgesteuert über das Realtime-Rückgrat (message.posted, channel.*, task.*), mit einer kurzen TTL als Absicherung. Der Cache speichert ausschließlich bereits autorisierte, nicht geheime Projektionen.

Chaos-Resilienz

Wenn eine Abhängigkeit ausfällt, schlägt Skrum sicher fehl, anstatt teilweise zu schreiben oder Daten leaken zu lassen.

• Redis ausgefallen. Realtime und Cache degradieren; REST liefert weiterhin die Quelle der Wahrheit aus Mongo und Postgres. Rate-Limiter versagen sicher (verweigern, öffnen das Tor nie).
• Mongo oder Postgres nicht erreichbar. Routen liefern einen lokalisierten Fehler der Klasse 503 — kein unbehandelter Absturz, kein Teilschreibvorgang.
• MinIO oder LiveKit ausgefallen. Datei-Uploads und Meetings schlagen sicher mit einem lokalisierten Fehler fehl; der Rest der App läuft weiter. Siehe Sicherung und Wiederherstellung.

Sobald eine Abhängigkeit zurückkehrt, wird der Dienst automatisch wieder aufgenommen — kein manueller Neustart erforderlich.

FAQ

• Führe ich die k6-Suite in CI aus? Ja, hinter einem Opt-in-Job. Lastszenarien blockieren nie einen normalen Pull-Request.
• Kann ich die Cache-TTL erhöhen? Die TTL ist bewusst kurz. Ereignisgesteuerte Invalidierung ist der primäre Korrektheitspfad; die TTL ist nur eine Absicherung gegen Redis-Ausfälle.
• Leakt der Cache jemals über Arbeitsbereiche hinweg? Nein — jeder Schlüssel ist mit der accountId präfixiert, und ein dedizierter Test beweist die Cross-Tenant-Isolation.

Siehe auch: Skrum-Dokumentation