Files
abdulive/docs/decisions/ADR-0002-sqlite.md
T
ZeasyAlexandClaude Opus 5 d07c18441b S1: Einrichtungs-Assistent, Twitch-Auth, Datenbank und Chat-Aufnahme
Zugangsdaten kommen jetzt aus der App statt aus einer .env: ein
Einrichtungs-Assistent auf http://localhost:4792/setup nimmt Client-ID,
Secret und OBS-Passwort entgegen, der OAuth-Rueckruf laeuft auf denselben
Server. Gespeichert wird verschlueselt (AES-256-GCM) in einem Volume,
bewusst nicht in der Datenbank - die wird auf die Windows-Seite gesichert.
Siehe ADR-0005.

Technikbasis vereinfacht: Node 24 bringt node:sqlite, WebSocket, fetch und
die Ausfuehrung von TypeScript mit. Das Projekt hat damit null
Laufzeitabhaengigkeiten und keinen Build-Schritt; pnpm-Workspaces und die
Paketmanifeste sind entfallen, Importe laufen ueber die imports-Map der
Wurzel-package.json. erasableSyntaxOnly verhindert Syntax, die das Type
Stripping stillschweigend entfernen wuerde. Siehe Nachtrag 2 in ADR-0001.

Enthalten:
- packages/core: Config, Layout, Logger mit Secret-Maskierung, Retry, YAML
- packages/db: Migrationen, Repositories, alle SQL-Anweisungen an einem Ort
- packages/twitch: Secret-Speicher, OAuth, Helix mit Token-Bucket, IRC
- apps/ingest: Daemon, Einrichtungsseite, Spike-Erkennung
- 20 Tests (IRC-Parser, Spike-Detektor, Datenbankschicht)

Der Chat verbindet sich anonym, solange nichts hinterlegt ist - damit laesst
sich die Datenaufnahme pruefen, bevor die Twitch-Apps existieren.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013VTGjd92LsDDWF3frd9FTB
2026-09-09 09:56:55 +02:00

1.6 KiB

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 über das eingebaute node:sqlite im WAL-Modus, eine Datei im Docker-Volume abdulive-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.
  • node:sqlite ist synchron (DatabaseSync), was den Code im Ingest erheblich vereinfacht - keine Race Conditions zwischen Ereignisverarbeitung und Schreibvorgang.
  • Es ist in Node 24 enthalten: keine native Abhaengigkeit, kein node-gyp, keine Prebuild-Suche im Docker-Build. Siehe Nachtrag 2 in ADR-0001.
  • 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.