# Panit 데이터 read/write 패턴 문서

Panit 야구앱의 Firebase(Firestore + RTDB) 데이터 접근 패턴 전수 조사 결과. 백엔드(`mmday-firebase`)와 Flutter 클라이언트(`Panit`)를 함께 추적했다.

## 문서 구성
| 문서 | 내용 |
|---|---|
| [data-lifecycle.md](./data-lifecycle.md) | **각 데이터가 어떻게 생성되고 누가 읽는지** — 생성 주체·트리거·소비자 맵 (종합) |
| [backend-writes.md](./backend-writes.md) | 백엔드 모든 write 경로 (repository/trigger/scheduled/handler), 빈도·배치·핫문서·비용 |
| [backend-reads.md](./backend-reads.md) | 백엔드 모든 read + 캐싱 3계층(MemCache/kboCache/scoreboardCache), N+1·인덱스 |
| [optimization-plan.md](./optimization-plan.md) | **read/write 최적화 로드맵** — 영향도×리스크 우선순위, 권장 변경·검증 포인트 |
| client-patterns.md | 클라 접근 패턴(직접 Firestore/RTDB vs CF, 실시간 vs 단발, SWR). 위치: `Panit/docs/data-patterns/client-patterns.md` |

## 핵심 결론 (3줄)
1. **클라는 Firestore/RTDB를 직접 읽지 않는다** — `fcmTokens` write 1곳 외 전부 Cloud Functions HTTP 경유.
2. **최대 비용**: write=`games` 매일 월 전량 재기록 / read=`dailyArchive` 유저별 게임쿼리 중복 + `getStats` 무효화 후 voteHistory 풀스캔 / 클라=`voteSummary` 10초 폴링.
3. **인덱스 누락 없음** — 복합 인덱스 3종 모두 쿼리와 일치.