🛒 Backend Engineering · 8/9 · 약 8분

Backend Engineering 시리즈 전체 보기

객체 저장소와 업무 데이터 저장소는 하나의 원자적 거래로 묶기 어렵다. 파일은 저장됐지만 연결 기록이 실패하거나, 기록은 만들어졌지만 파일 업로드가 끝나지 않는 공백이 생길 수 있다.

가상의 첨부 파일 흐름을 준비, 확정, 보상, 조정 단계로 나눠 검토했다. 어느 저장소를 먼저 쓰는가보다 부분 성공을 표현하고 다시 안전한 상태로 수렴시키는 규칙이 중요했다.

#Backend · #ObjectStorage · #Consistency · #Compensation

이 글에서 다룰 것

• 두 저장소 사이에 일관성 공백이 생기는 이유
• 준비 기록과 최종 확정을 분리하는 방법
• 보상 처리와 정기 조정이 맡아야 할 역할

저장 순서를 바꿔도 왜 실패 창이 남을까

파일을 먼저 저장하면 이후 업무 기록 생성 실패에서 연결되지 않은 객체가 남는다. 업무 기록을 먼저 만들면 업로드 실패에서 존재하지 않는 파일을 가리키는 기록이 남는다. 순서를 바꾸면 불일치의 모양만 달라질 뿐 가능성은 사라지지 않는다.

따라서 지켜야 할 불변식은 확정된 업무 기록은 검증된 객체만 가리킨다는 것이다. 준비 중인 첨부와 사용 가능한 첨부를 같은 상태로 보이면 다른 기능이 미완성 데이터를 정상 데이터로 소비할 수 있다. 부분 성공을 명시적인 중간 상태로 표현해야 한다.

준비 후 확정 방식도 실패를 없애지는 않는다. 대신 실패를 찾고 복구할 기준을 제공한다는 점이 다르다.

준비와 확정 사이에 무엇을 검증해야 할까

먼저 업로드 의도를 식별하는 준비 기록을 만들고 제한된 위치에 객체를 저장한다. 업로드가 끝나면 객체 존재 여부와 허용된 크기 범주, 형식 같은 조건을 확인한 뒤 업무 기록을 사용 가능 상태로 확정한다. 준비 단계에는 만료 시각을 두어 끝나지 않은 작업이 무기한 남지 않게 한다.

사용자가 같은 업로드를 다시 요청하면 새 객체를 계속 만들기보다 기존 준비 작업을 찾는다. 의도 식별자가 같고 준비 작업이 아직 유효하면 남은 단계부터 이어 간다. 이미 확정됐다면 기존 결과를 반환해 반복 요청을 같은 결과로 수렴시킨다.

업로드 의도 등록
      ↓
준비 기록 생성 ── 중단 → 만료 대상
      ↓
객체 업로드
      ↓
존재와 조건 확인 ── 실패 → 보상 대상
      ↓
업무 기록 확정

객체 접근 권한도 상태와 맞춰야 한다. 준비 중인 객체는 최종 공개 경로에서 보이지 않게 하고, 확정된 기록을 통해서만 접근하도록 경계를 둔다.