프로필 저장은 성공했는데 새로고침하면 옛값이 보입니다. 읽기 복제본의 지연을 어떻게 확인하고 방지하나요?

쓰기 원본이 커밋 성공을 반환한 것과 읽기 복제본이 그 변경을 적용한 것은 서로 다른 시점입니다. 프로필 저장 직후 새로고침이 복제본으로 라우팅되면 복제 로그가 아직 도착·재생되지 않아 이전 값이 보일 수 있습니다. 이는 저장 실패가 아니라 기능이 최종적 일관성(eventual consistency)을 허용하는지와 사용자에게 필요한 최신성 계약을 분리하지 않은 문제입니다.

본인 쓰기와 일반 읽기를 다르게 라우팅합니다

저장 응답에 변경 버전이나 원본 로그 위치를 포함하고, 그 버전 이상을 적용한 복제본으로만 이후 읽기를 보내면 read-your-writes를 구현할 수 있습니다. 복제본이 기준 위치에 도달하지 않았으면 잠시 원본으로 보내거나, 해당 화면에서 저장 응답의 최신 값을 낙관적으로 보여 주고 백그라운드에서 확인할 수 있습니다. ‘저장 후 5초 동안 원본’ 같은 시간 고정은 단순하지만 복제 지연이 그보다 길어질 수 있어 엄격한 보장이 아닙니다.

PostgreSQL의 WAL LSN, MySQL의 binlog/GTID, SQL Server의 로그·가용성 그룹 위치처럼 복제 진행을 나타내는 값과 API에서 노출할 버전의 연결은 엔진·복제 방식마다 다릅니다. 동기 복제인지 비동기 복제인지, 읽기 라우터가 어느 노드를 선택하는지, 장애 승격 시 미반영 쓰기가 어떻게 되는지 확인해야 합니다. 애플리케이션이 단순히 ‘replica=true’만 전달한다고 최신성 계약이 생기지는 않습니다.

지연이 커졌을 때의 우회 비용을 정합니다

대량 보고서나 검색성 조회처럼 잠깐 옛값이 허용되면 복제본으로 보내 원본 부하를 줄일 수 있습니다. 하지만 지연이 허용 상한을 넘으면 원본 우회, 기능 축소, 오래된 데이터 표시, 요청 거절 중 하나를 선택해야 합니다. 모든 읽기를 원본으로 보내면 최신성은 좋아질 수 있어도 원본 CPU·연결·스토리지 용량을 초과할 수 있습니다. 사용자 쓰기 직후 조회, 결제 잔액, 관리자 보고서는 서로 다른 계약을 갖게 하겠습니다.

관찰 지표는 복제 지연 시간만으로 충분하지 않습니다. 복제본의 적용 위치, 재생 대기, 오류, 원본 우회 요청 수, 오래된 버전을 본 사용자 요청, 승격 시 유실 가능한 로그 범위를 기록합니다. 긴 복제본 조회가 로그 적용이나 vacuum·undo 정리를 방해하는지도 DBMS별로 확인합니다. 테스트는 저장 직후 반복 조회, 지연 증가, 복제본 장애·승격, 커넥션 풀의 오래된 주소를 재현해 read-your-writes와 허용된 stale read가 각각 지켜지는지 검증하겠습니다.

읽기 라우터가 사용자 요청마다 다른 replica를 고르면 같은 세션에서도 값이 뒤로 갈 수 있습니다. 세션에 최소 읽기 버전을 보존하거나, 본인 쓰기 직후에는 같은 원본을 사용해 이런 역행을 줄이겠습니다. 다만 replica가 장애로 재생 위치를 잃거나 승격되면 기존 버전이 영원히 존재한다는 보장은 없으므로, 중요한 상태는 권위 원본에서 확인하고 사용자에게 재시도 가능한 불확정 결과를 전달해야 합니다.