당신의 체크아웃 엔드포인트는 400ms의 P95를 가지고 있습니다. 프로파일링 결과, 그 중 70%가 DB 읽기에 해당합니다.
읽기 리플리카를 추가하고 모든 SELECT 쿼리를 그것을 가리키도록 합니다. P95는 90ms로 낮아집니다. 팀은 축하합니다.
두 시간 후, 지원 티켓이 속수무책으로 쏟아집니다. 고객들은 배송 주소를 업데이트하지만 확인 화면에서 오래된 주소를 본다. 한 고객은 두 번 청구되었는데, "주문이 이미 존재한다"는 확인을 읽은 시간이 지나서 데이터가 상태가 아니어서 중복을 놓쳤기 때문입니다.
설치는 다음과 같습니다:
• Primary → 모든 쓰기 처리, 복제 지연 ~200ms
• Replica → 읽기 100% 처리
• 영향을 받는 흐름 → 프로필 업데이트, 주문 중복 제거, 결제 단일성
복제본은 정확히 설계된 대로 작동하고 있습니다. 그게 문제입니다.
무엇을 해야 합니까?
A) 읽기-쓰기 일관성: 사용자가 쓰기 후 짧은 시간 동안 읽기를 주 서버로 라우팅합니다.
B) 동기 복제: 쓰기를 확인하기 전에 복제 서버가 확인할 때까지 주 서버를 기다립니다.
C) 복제 서버 지연 모니터링 + 재시도: 지연이 임계값을 초과할 때를 감지하고 주 서버로 되돌아갑니다.
D) 중요 읽기를 주 서버로 라우팅: 복제 서버는 분석과 같은 비중요 읽기만 처리합니다.
네 네 네 네 모두 실제로 운영 중인 패턴입니다. 하나만 최근에 출시한 성능 우위를 파괴하지 않고 stale-read 문제를 해결할 수 있습니다.
하나를 선택하시오 (A, B, C, 또는 D) 그리고 왜 그런지 알려주세요. 댓글에 전면적인 분석이 포함되어 있으며, 어떤 답변이 주니어 엔지니어 함정인지도 포함합니다.
팀이 읽기 리플리카를 추가하고 stale 데이터를 디버깅하는 데 한 주를 보냈었다면 이를 공유해주세요.
답변을 남기세요 👇