アーキテクチャ

リクエストとメディアの流れ

ブラウザ (React)
  ├─ REST API ────────> Express API
  │                       ├─ SQLite: 曲・プレイリスト・関連情報
  │                       └─ ダウンロードキュー ─> yt-dlp / FFmpeg ─> 永続ストレージ
  └─ GET /api/stream ─> Express の Range 対応ストリーミング ────> 保存済みファイル

バックエンド

Express サーバーはアルバム、曲、プレイリスト、ダウンロードキュー、ストリーミングの API を提供します。SQLite は曲とプレイリストのメタデータを保持し、実ファイルはダウンロード先ディレクトリに置かれます。

ダウンロードキューはメモリ上で処理されます。各項目は原則として音声を先に、次に動画を取得します。プロセス再起動時に未完了キューは復元されないため、運用時はこの特性を考慮してください。

再生

フロントエンドは共有の HTML5 メディア要素を利用します。曲に動画ファイルがある場合は音声／動画モードを選択でき、動画がない曲は音声モードに戻ります。ストリーミング API は HTTP Range を扱うため、対応ブラウザでシーク再生できます。

永続化とスケールの制約

項目	設計上の制約
SQLite	同時書き込みの特性上、バックエンドは単一レプリカを前提とします。
ダウンロードキュー	プロセス内メモリのため、複数レプリカ間で共有できません。
メディア	DB とファイルを同じライフサイクルでバックアップする必要があります。
Kubernetes 更新	ReadWriteOnce の永続ボリュームを使う場合は Recreate 戦略が安全です。

複数バックエンドへスケールする場合は、SQLite・キュー・メディア保存先を共有可能なサービスへ置き換える設計が必要です。