# ADR-001: マルチテナント認証にAuth0を採用する

## ステータス
承認済み（2025-04-15）

## コンテキスト
新規SaaSプロダクトの認証基盤を決定する必要がある。
以下の要件がある:
- マルチテナント対応（テナントごとにユーザーを分離）
- Web + モバイルアプリからのアクセス
- SSO（シングルサインオン）対応が将来的に必要
- チーム内に認証の深い実装経験を持つメンバーがいない

検討した候補:
1. **Firebase Auth**: Google提供。手軽だがマルチテナント対応が限定的
2. **Auth0**: 認証特化SaaS。マルチテナント対応が充実
3. **自前実装**: 完全な制御が可能だが、工数とセキュリティリスクが大

## 決定
Auth0を認証基盤として採用する。
- Auth0 Organizationsでマルチテナントを管理
- JWT + RS256で認証トークンを発行
- 将来のSSO対応はAuth0 Enterprise Connectionで実現

## 結果

### ポジティブ
- マルチテナント機能が標準搭載（Organizations）
- セキュリティのベストプラクティスが適用済み
- 実装工数を約2ヶ月削減できる見込み

### ネガティブ
- 月額コスト発生（MAU 1,000までは無料、以降従量課金）
- ベンダーロックインのリスク（認証アダプタで抽象化して軽減）
- カスタマイズの自由度に制限がある

### ニュートラル
- チームのAuth0学習に1週間程度必要
- 既存のユーザーデータの移行ツールが提供されている

# ADR-002: IoTセンサーデータの保存にTimescaleDBを採用する

## ステータス
承認済み（2025-04-20）

## コンテキスト
IoTデバイスからのセンサーデータを蓄積・分析する基盤が必要。
要件:
- 書き込み: 1日あたり1億レコード（約1,150 writes/sec）
- クエリ: 直近7日間のリアルタイム集計
- 保持: 90日以上のデータをアーカイブ
- チームスキル: PostgreSQLの経験が豊富

候補の比較:
| 候補 | Pros | Cons |
|------|------|------|
| PostgreSQL | チームに経験あり | 時系列クエリに最適化されていない |
| TimescaleDB | PostgreSQL互換。時系列最適化 | 運用の追加知識が必要 |
| InfluxDB | 時系列DB特化 | 独自クエリ言語。学習コスト高 |
| ClickHouse | 高速な分析クエリ | 書き込みパターンが特殊 |

## 決定
TimescaleDBを採用する。
- ハイパーテーブルで時系列データを自動パーティション
- 継続的集計（Continuous Aggregates）でリアルタイム分析
- 圧縮ポリシーで90日超のデータを効率的にアーカイブ

## 結果

### ポジティブ
- PostgreSQL互換のため、既存のスキルとツールが流用可能
- 自動パーティションとデータ圧縮で運用負荷を軽減
- ORM（Prisma）がそのまま使える

### ネガティブ
- ハイパーテーブル固有の制約（一部のALTER TABLEが不可）
- TimescaleDB特有の運用知識が必要（チャンク管理等）

### ニュートラル
- マネージドサービス（Timescale Cloud）を利用する選択肢もある
- PostgreSQLからの移行はスキーマ変更のみで可能

# RFC-2025-005: 統合通知基盤の設計

## メタデータ
- **著者**: あなたの名前
- **ステータス**: Draft
- **作成日**: 2025-04-25

## 1. サマリー
メール、プッシュ通知、アプリ内通知を統合管理する
通知基盤を構築する提案。

## 2. 背景と動機
現在、通知はメール送信のみで、各機能から直接送信APIを呼んでいる。
これにより以下の問題がある:
- 通知ロジックが各所に散在し、保守が困難
- プッシュ通知やアプリ内通知への対応が困難
- ユーザーの通知設定が管理できない

## 3. 提案

### アーキテクチャ
各サービスは通知イベントを発行するだけ。
通知基盤がチャネルの振り分けと配信を担当。

- **Notification API**: 通知リクエストの受付
- **Channel Router**: ユーザー設定に基づくチャネル振り分け
- **Channel Adapters**: 各チャネル（Email/Push/In-App）への配信
- **Template Engine**: テンプレートベースの通知内容生成
- **Message Queue**: SQSによる非同期配信

### テンプレート例
テンプレートはHandlebars形式で管理:
「{{userName}}さん、ご注文 #{{orderId}} が発送されました。」

## 4. 代替案

### 4.1 既存の直接送信を拡張
- Cons: 各サービスにチャネル分岐ロジックが必要
- 却下理由: 保守性が低い

### 4.2 外部SaaS（SendGrid + OneSignal）
- Cons: 複数SaaSの統合管理が複雑
- 却下理由: 統合的なユーザー設定管理が困難

## 5. リスク
| リスク | 軽減策 |
|--------|--------|
| メッセージの重複送信 | 冪等性キーで重複排除 |
| 配信遅延 | Dead Letter Queueとリトライ |

## 6. 実装計画
Phase 1（3週間）: メール通知の移行
Phase 2（2週間）: プッシュ通知の追加
Phase 3（2週間）: アプリ内通知の追加

## レビューコメント

### 1. [CONCERN] キャッシュ対象のスコープが広すぎないか
全ユーザーデータ（購入履歴を含む）をキャッシュすると、
Redisのメモリ使用量が膨大になります。
アクセス頻度の高いデータ（プロフィール、設定）のみに
限定することを推奨します。

### 2. [BLOCKER] TTL 24時間では古いデータが表示される期間が長すぎる
ユーザーが設定を変更してもキャッシュ削除が
「プロフィール更新時のみ」だと、
管理者による設定変更が24時間反映されません。
キャッシュ無効化の対象イベントを網羅的に定義してください。

### 3. [QUESTION] Redisの障害時のフォールバック戦略は？
Redis障害時にPostgreSQLへ直接アクセスするフォールバックは
検討されていますか？Circuit Breakerの導入を推奨します。

### 4. [SUGGESTION] 購入履歴は別のキャッシュ戦略が適切では
購入履歴は頻繁に更新されるため、Cache-Asideより
Read-Through + 短いTTL（5分）が適しているかもしれません。