DB는 옵션이 아니라 단일 진실 소스다

DB는 옵션이 아니라 단일 진실 소스(SSOT)다.

다만 실무에서는 이 문장을 이렇게 확장해서 이해하면 더 정확합니다.

---

1) 왜 DB가 SSOT인가

• 영속성: 프로세스/서버 죽어도 남는 건 DB뿐
• 정합성/감사: “누가 언제 뭘 바꿨나” 최종 증거는 DB
• 복구/정산: 장애 후 재처리, 정산, 민원 대응은 DB로 함
• 조직 책임: 계약 이행/검수도 결국 데이터로 판정

결론: 캐시/검색/세션/큐 다 날아가도 DB만 살아있으면 재구성 가능해야 합니다.

---

2) SSOT 원칙이 깨지는 흔한 패턴

❌ 캐시가 진실이 되는 순간

• “DB보다 캐시가 최신” 같은 상태
• TTL, 무효화 누락으로 운영이 꼬임

❌ 이벤트/큐가 진실이 되는 순간

• 메시지 유실/중복 시 데이터가 뒤틀림
• DB가 아니라 로그/큐를 기준으로 재처리해야 하는 상황

❌ 화면/엑셀/운영자 메모가 진실이 되는 순간

• 데이터 수정 기준이 시스템 밖으로 나가버림
• 민원/감사에서 터짐

3) SSOT를 유지하면서도 성능/확장을 챙기는 방법

핵심은 이겁니다.

DB를 진실로 두되, 읽기는 사본을 허용한다.
(단, 사본은 언제든 폐기 가능해야 함)

실무 패턴:

• Write는 DB만 (트랜잭션으로 확정)
• Read는 캐시/서치/리드 레플리카 가능
• 사본은 항상 “DB 기준으로 재생성 가능” 해야 함

---

4) 운영에서 바로 쓰는 체크리스트

• 데이터 수정은 항상 DB 트랜잭션으로 끝나는가
• 캐시/서치/인덱스는 DB로부터 재빌드 가능한가
• 장애 시 “정답은 DB”라고 말할 수 있는가
• 운영자 수동 수정이 있으면 로그/이력이 남는가
• 정합성 이슈 발생 시 재처리 플로우가 있는가

---

5) 한 줄 더 날카롭게

캐시는 빠르게 보여줄 수는 있어도,
책임을 져주진 못한다.
책임은 DB가 진다.

이게 SI에서 “DB가 진실”인 이유입니다.