0 Fork 0

Files

T

ZeasyAlexandClaude Opus 5 d09e2b945a Struktur, Doku und S0-Toolchain fuer das abdulive-Toolkit

Monorepo-Geruest fuer neun Streamer-Tools plus den Ingest-Daemon, der
unter sechs davon liegt. Enthaelt:

- docs/: Ueberblick, Architektur, Twitch-Integration, Datenmodell,
  Roadmap, Setup, Hebel-Analyse und den MVP-Plan "Clip-Knopf"
- docs/projects/: je eine Spezifikation pro Tool
- docs/decisions/: vier ADRs (TS-Monorepo, SQLite, EventSub/IRC, Docker)
- docker/: Image mit ffmpeg und whisper.cpp, abhaengigkeitsfreier
  Entrypoint mit check-env, fetch-model und calibrate
- config/layout.yaml: aus einem VOD-Screenshot eingemessener
  Facecam-Ausschnitt (440x330 oben links, Chat-Overlay ab x=1270)

Noch kein Anwendungscode - Scheibe S0 aus docs/07-mvp-plan.md.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013VTGjd92LsDDWF3frd9FTB

2026-09-09 08:56:09 +02:00

1.4 KiB

Raw Blame History

ADR-0002: SQLite statt Postgres

Status: akzeptiert · Datum: 2026-09-09

Kontext

Mehrere Prozesse schreiben und lesen dieselben Daten. Datenvolumen: bei ~10 Zuschauern und 4 Streams pro Woche etwa 20.000 Chat-Nachrichten und 15.000 Viewer-Samples pro Monat — wenige MB.

Entscheidung

SQLite (better-sqlite3) im WAL-Modus, eine Datei unter data/db/.

Begründung

Kein Server, kein Docker, kein Zustand außerhalb einer Datei. Backup ist ein Dateikopie-Vorgang (VACUUM INTO).
WAL erlaubt beliebig viele gleichzeitige Leser neben einem Schreiber. Genau unsere Topologie: Der Ingest schreibt, alle anderen lesen.
better-sqlite3 ist synchron, was den Code im Ingest erheblich vereinfacht — keine Race Conditions zwischen Event-Verarbeitung und Schreibvorgang.
Die Datenmenge ist um Größenordnungen von SQLites Grenzen entfernt.

Konsequenzen

Nur ein schreibender Prozess. Der Ingest ist der einzige Schreiber für events, chat_messages, viewer_samples, streams, user_streams. Andere Apps schreiben ausschließlich in ihre eigenen Tabellen (clips, posts, redemptions, raids). Diese Aufteilung ist verbindlich.
Schreibende Zugriffe immer in Transaktionen bündeln, busy_timeout auf 5000 ms.
Migration auf Postgres wäre nötig, wenn das Dashboard je remote laufen soll. Steht nicht an; die Repository-Schicht in packages/db kapselt SQL genug, dass es machbar bliebe.

1.4 KiB Raw Blame History