먼저 데이터가 어떻게 바뀌는지, 잠깐의 불일치를 허용할 수 있는지, 그리고 주된 조회가 키 기반인지 조인 중심인지 확인합니다. 신호가 섞이면 저장소를 역할별로 나누는 편이 더 현실적입니다.
먼저 묻는 세 가지
문서, 로그, 이벤트처럼 모양이 자주 바뀌고 한 번에 한 묶음으로 읽는 데이터에 유리합니다.
주문-결제-회원처럼 여러 엔터티가 이어져 관계와 참조 무결성이 핵심이면 RDB가 더 자연스럽습니다.
복제 지연으로 생기는 짧은 차이를 허용하고 최종적 일관성이면 충분한 서비스에 맞습니다.
재고, 송금, 예약처럼 한 번의 실패도 비용이 큰 작업은 ACID와 즉시 정확성이 우선입니다.
키 기반 읽기·쓰기 비중이 높고, 노드를 늘려 수평 확장해야 할 때 강합니다.
여러 테이블을 묶는 조인·집계·보고가 많다면 관계형 모델이 더 단순하고 안정적입니다.
하나의 서비스 안에서도 데이터의 역할은 다릅니다. 정확성이 필요한 영역과 빠른 확장이 필요한 영역을 분리하면 각 저장소의 장점을 그대로 살릴 수 있습니다.