1. September 2025cases.boardcork.com

Casos Criminales - Echtzeit-Detektivspiel

Boardcorks digitales Produkt: bis zu 10 Geräte lösen denselben Kriminalfall auf einem gemeinsamen Board. Live in Produktion, mit Konten und Zahlungen.

Live-Ansicht

Casos Criminales

Dein Team bekommt einen Fall, ein gemeinsames Board und eine vollständige Fallakte. Ihr habt zwei bis drei Stunden, um ihn zu lösen. Bis zu 10 Geräte arbeiten gleichzeitig auf demselben Board. Es ist das digitale Produkt von Boardcork. Es ist live in Produktion, mit Nutzerkonten und Zahlungen, und ich habe es end-to-end entworfen und gebaut.

Das Problem, das das Produkt fast versenkt hätte

Die erste Version lief auf meiner Maschine perfekt. Mit zwei geöffneten Tabs: makellos. Mit einem echten Team aus sechs Personen nicht. Zwei Symptome tauchten auf - und beide waren dasselbe Problem in Verkleidung:

Verzögerungen. Du verschiebst einen Hinweis auf dem Board, und der Rest des Teams sieht es eine halbe Sekunde später. In einem kooperativen Spiel gegen die Uhr fühlt sich eine halbe Sekunde wie eine kaputte App an.
Konflikte. Zwei Spielende berührten fast gleichzeitig dasselbe Element, und der Zustand wurde zwischen den Geräten inkonsistent. Jede Person sah ein anderes Board. In einem Deduktionsspiel ist das kein UI-Bug - es zerstört die Partie.

Die Diagnose: der Flaschenhals war nicht Socket.IO

Die instinktive Reaktion war, den Transport zu beschuldigen und Events zu optimieren. Genau das habe ich anfangs falsch gemacht und Zeit verloren. Das eigentliche Problem lag eine Schicht tiefer: jedes Board-Event schrieb in die Datenbank. Der kritische Pfad einer einzelnen Spielaktion sah damit so aus:

Spieleraktion → Event → DB-Schreibvorgang → Bestätigung → Broadcast an alle anderen

Die Datenbank saß innerhalb der Echtzeitschleife. Mit sechs Spielenden, die parallel Events erzeugten, wurde dieser Schreibvorgang zum Serialisierungspunkt des gesamten Systems: er addierte Latenz zu jeder Aktion und erzeugte, sobald zwei Schreibvorgänge um denselben Datensatz konkurrierten, genau die Zustandskonflikte, die wir sahen. Den Socket zu optimieren hätte nichts gelöst. Der Transport war nicht das Problem. Die Persistenzarchitektur war es.

Die Entscheidung: die Datenbank aus dem kritischen Pfad nehmen

Ich habe die Persistenzstrategie vollständig geändert.

Der Spielzustand lebt im Speicher, solange die Sitzung aktiv ist. Er ist während des Spiels die einzige Quelle der Wahrheit und autoritativ: er löst die Reihenfolge der Aktionen an einer einzigen Stelle auf, sodass zwei Spielende, die dasselbe berühren, nicht mehr auseinanderlaufen können.
Events werden direkt aus diesem Zustand propagiert, ohne auf I/O zu warten.
Der Schreibvorgang in die Datenbank erfolgt am Ende der Sitzung, außerhalb der Spielschleife, wo einige hundert Millisekunden Latenz niemanden stören.

Die DB wurde vom Flaschenhals pro Aktion zu dem, was sie von Anfang an hätte sein sollen: Speicher für Ergebnisse, nicht für Live-Zustand.

Das Ergebnis

Die Verzögerungen verschwanden: ohne I/O im kritischen Pfad erfolgt der Broadcast sofort.
Die Zustandskonflikte verschwanden: mit einer einzigen autoritativen Quelle der Wahrheit pro Partie gibt es keine konkurrierenden Schreiber.
Das System trägt die 10 gleichzeitigen Geräte pro Sitzung, die das Produkt braucht.

Der Trade-off, und das ist der ehrliche Teil

Diese Entscheidung hat echte Kosten, und die gehören genannt: stürzt der Prozess mitten in der Partie ab, ist der Fortschritt dieser Sitzung verloren. Ich habe das bewusst akzeptiert, und die Begründung ist produktseitig, nicht technisch. Eine Sitzung dauert zwei bis drei Stunden und wird in einem Zug gespielt. Die Wahrscheinlichkeit eines Absturzes in diesem Fenster ist gering; die Wahrscheinlichkeit, dass eine Verzögerung oder ein Zustandskonflikt die Partie ruiniert, lag mit der alten Architektur bei 100 %. Ich habe ein seltenes, behebbares Risiko gegen ein konstantes, fatales getauscht. In einer anderen Domäne - einem kollaborativen Editor, in den Nutzende Wochen investieren - wäre die richtige Entscheidung die umgekehrte: periodische Snapshots oder ein CRDT. Genau das macht es zu einer Architekturentscheidung und nicht zu einer Optimierung: sie hängt von der Domäne ab, und man muss sie verteidigen können.

Das Erlebnis

Gemeinsames Board: das gesamte Team arbeitet in Echtzeit am selben Fall.
Vollständige Fallakte: Hinweise, Verdächtige und Dokumente zum Analysieren.
Antwortprüfung: das System prüft die Antworten des Teams, bevor es das Urteil fällt.

Status

Live in Produktion, mit Nutzerkonten und Zahlungen. Löse deinen ersten Fall unter cases.boardcork.com.