객체 저장소 업로드가 성공했는데 CDN과 메타데이터 DB는 다른 버전을 봅니다. 어떤 일관성 경계를 구분하나요?
잠깐, 답변을 보기 전에
먼저 내 말로 설명해 볼까요?
답변과 점검 포인트 펼치기답변 접기
구두 답변
정의를 외우기보다, 원리와 조건을 연결해 설명해 보세요.
객체 저장소 자체의 읽기·목록 일관성과 CDN 캐시·앱 메타데이터·외부 transaction은 별도입니다. 특정 제품이 강한 일관성을 제공해도 두 저장소와 캐시가 한 원자 상태가 되는 것은 아닙니다.
동작 원리와 전제
객체를 저장한 뒤 DB의 파일 상태를 바꾸다 죽으면 고아 객체가 생길 수 있고 DB부터 공개하면 아직 없는 객체를 가리킬 수 있습니다. 준비·업로드·검증·공개 상태를 나누고 안정적인 객체 ID·버전을 사용합니다.
선택과 실패 처리
불변 버전 키로 새 객체를 쓰고 메타데이터 포인터를 조건부 전환하면 캐시 혼동을 줄일 수 있습니다. 같은 키 덮어쓰기라면 validator와 CDN 무효화·TTL을 관리합니다. 업로드 성공과 checksum 검증·외부 공개는 다릅니다.
구체적인 사례와 검증
파일 버전 v1을 CDN이 보관한 상태에서 같은 키를 v2로 덮으면 origin은 v2를 반환해도 edge는 TTL 동안 v1을 줄 수 있습니다. 불변 키와 메타데이터 포인터는 이 혼동을 줄이지만 old URL 접근을 언제 종료할지도 정해야 합니다. 업로드한 객체와 DB의 파일 행을 정리할 때 참조가 없다는 판단이 현재인지 확인합니다. 업로드 중인 객체를 고아로 오인해 지우지 않게 작업 상태·시간·소유자를 함께 봅니다. 버전별 접근권한·presigned URL 만료와 보관 정책도 연결합니다. 강한 객체 저장소의 읽기 보장과 앱 전체의 원자 공개는 다른 설계 문제입니다.
각 단계 중단·동일 키 쓰기 경쟁·CDN hit·삭제 후 조회를 시험합니다. 고아 객체 정리는 참조 상태와 보존 기간을 확인한 뒤 수행합니다. 저장소의 공식 버전 계약을 확인하고 오래된 '항상 eventual' 또는 '모든 계층 즉시 최신' 설명을 피합니다.
득점 포인트
이해가 드러나는 지점을 확인해 보세요.
- 핵심 구분: 객체 저장소 자체의 읽기·목록 일관성과 CDN 캐시·앱 메타데이터·외부 transaction은 별도입니다.
- 선택 조건: 불변 버전 키로 새 객체를 쓰고 메타데이터 포인터를 조건부 전환하면 캐시 혼동을 줄일 수 있습니다.
- 검증 기준: 각 단계 중단·동일 키 쓰기 경쟁·CDN hit·삭제 후 조회를 시험합니다.
감점 포인트
놓치기 쉬운 조건과 오해를 짚어 보세요.
- 객체 저장소가 강한 일관성이면 CDN·DB 포인터도 즉시 같은 상태가 된다고 한다.
더 파고들 거리
하나 더 질문하며 이해의 범위를 넓혀 보세요.
- 조각 전송과 최종 객체 확정 사이에 실패하면 upload ID와 checksum으로 어떻게 재개하나요?
- 캐시가 가진 표현의 최신성과 개인정보 저장 정책을 어떤 validator·Cache-Control로 나누나요?
- 조회한 버전이 저장 전에 바뀌었다면 자동 덮어쓰기 대신 어떤 충돌 결과를 반환하나요?
득점·감점 포인트는 학습용 자기 점검 기준이며, 특정 회사의 실제 채점표가 아닙니다.
원리부터 공부하고 싶다면
답변을 보충하는 개념·예제·슈도코드를 읽어 보세요.