[기타] 임시 저장 서비스 경험기

임시 저장 서비스

사내에서 임시 저장 서비스를 구현하면서, 어떻게 할 것인가.. 어떤 방법이 좋은가에 대해 고민했던 부분을 공유해보려고 한다. 

결과적으로, 설계 당시에 선택한 방법이 가져올 문제점 등에 대해 충분히 고려하지 못해 나중에 수고스러워 지는 부분도 있었던 것도 같고, 다음에 구현하게 될 때 좀더 빠르고 정확하게 할 수 있도록 기록을 남겨 보려 한다.

 

임시 저장 서비스 기능 요구 사항

• 상태 : 임시 저장, 생성 완료 (발행)
• 임시 저장 데이터 : 생성, 수정, 삭제, 조회 가능
• 완성 데이터 : 생성, 수정, 삭제, 조회 가능
• 데이터 목록 : 임시 저장, 완성 데이터는 같이 조회가능 해야 함
• 중요 : 완성 데이터가 있어도 임시 저장 데이터가 유효 해야 함
• 중요 : 사용자는 하나의 객체에 대해서만 생서/수정 한다는 가정

 

임시 저장 테이블 설계 

구현에 있어 가장 큰 차이는 아마 DB 설계에 있지 않을 까 생각 한다. 

결론적으로는 3안이 가장 심플 한 것 같지만, 티스토리 처럼 완성 데이터가 있어도 임시 저장 데이터도 따로 관리 되어야 한다면, 1안-2안이 선택 될 것 같고 그 중에서는 1안이 나은 것 같다.

 

1안. 테이블 2개로 관리 (A, TempA)

임시 저장 테이블(TempA)와, 완성 테이블(A)를 분리하는 방법 (A : TempA는 1:1 or 1:N)

 

 

2안. 테이블 1개와 내부 필드로 관리 (A, Temp 필드)

완성 테이블 A의 필드(JSON 필드 등)로 임시 저장 데이터를 관리

임시 저장 데이터는 payload 형태 채 저장 -> response 로 나가기 쉬울테니

하나의 필드로 포함시키는 이유는 좀더 심플하게 구현해보기 위함

 

3안. 테이블 1개 및 상태값으로 관리 (A)

하나의 테이블로 관리

완성 테이블과 임시 저장 테이블 간 상태 값이 다름

완성 테이블이 된다면, 임시 저장 데이터는 사라진다는 가정

 

임시 저장 API 설계 - 테이블 1안

1. TempA 및 A 테이블 각각에 생성/수정/삭제/조회 구현 

 

2. 테이블이 2배지만 API (CRUD) 단위가 매우 심플해짐

• TempA 생성, 수정, 삭제, 조회 -> 이슈 없음 (TempA 객체를 대상으로 CRUD)
• A 수정, 조회 -> 이슈 없음 (A 객체를 대상으로)

 

3. 비즈니스 로직 수행 간, 서로의 테이블에 영향을 주어야 할 수 있음 (요구조건에 따라 상이함)

• A 생성 -> TempA 유지 or 삭제 (유지한다는 건 임시 저장 데이터 보존 or 삭제 한다는 건 임시 저장 데이터 초기화)
• A 삭제 -> TempA 삭제

 

4. A와 TempA를 같이 목록 조회시 불편할 수 있음 (요구 조건에 따라 상이함)

• 각 테이블을 query 해서 merge 해야 함 (쿼리 2배)

 

5. 만약 임시 글이 티스토리 처럼 여러개(N) 저장이 가능하다면? (버전 관리가 필요하다면?)

• Temp는 Temp 대로 N개를 쭉 쌓으면 됨

 

임시 저장 API 설계 - 테이블 2안

1. A 테이블에 대해서만 바라보고 진행

 

2. 테이블이 적고, 다른 테이블에 영향을 주지 않아도 됨

• 임시 저장 생성/수정 -> A테이블 다른 필드에는 빈 값, A테이블 Temp필드(json)에 임시 저장 데이터(json) payload 채 생성/수정
• 임시 저장 삭제 -> A테이블 Temp필드(json) 삭제
• A 생성, 수정 -> 이슈 없음
• A 삭제 -> 자동으로 Temp 필드 같이 삭제 됨 

 

3. 비즈니스 로직에서 Schema에 맞춰 저장된 payload 데이터를 한 번 더 파싱 해야 함 

• 임시 저장 조회 -> A테이블 Temp필드를 Schema 형식으로 파싱해서 줌
• 완성 데이터 조회 -> A테이블 데이터를 Schema 형식으로 파싱해서 줌
• 임시 저장, 완성 데이터 합친 목록 조회-> 임시 저장의 경우 Temp 필드를 Schema 형식으로 파싱해서 줌

 

4. 만약 임시 글이 티스토리 처럼 여러개(N) 저장이 가능하다면?

• 필드만으로 관리하기엔 힘들 수 있음.

 

임시 저장 API 설계 - 테이블 3안

임시 저장 데이터는 따로 관리 될 필요 없다는 가정

 

1. A 테이블만 바라보고 진행

 

2. 테이블이 적고, 다른 테이블에 영향을 주지 않아도 됨

• 임시 저장 생성/수정/삭제 -> A 테이블(상태-임시 저장) 생성/수정/삭제
• 완료 데이터 생성/수정/삭제 -> A 테이블(상태-생성 완료) 생성/수정/삭제
• 임시 저장 후 완료 데이터 생성 -> A테이블 (상태-임시 저장 -> 상태-생성 완료) 수정

 

3. 비즈니스 로직에서 Schema에 맞춰 저장된 payload 데이터를 한 번 더 파싱 할 필요 없음

• 임시 저장 조회 -> A 테이블(상태-임시 저장) 값 조회
• 완료 데이터 조회 -> A 테이블(상태-생성 완료) 값 조회
• 임시 저장, 완성 데이터 합친 목록 조회-> A 테이블(상태-임시 저장, 생성 완료) 값 조회

 

4. 만약 임시 글이 티스토리 처럼 여러개(N) 저장이 가능하다면?

• 필드만으로 관리하기엔 힘들 수 있음.

 

후기

프로젝트를 진행하면서 2안으로 진행

 

배경

- 임시 저장 값을 심플하게 필드 하나로 관리하면 좋을 것 같아서

- 임시 저장 데이터가 따로 관리가 필요해서 3안 x

 

후기

1. 생각보다 JSONField를 쓰는게 불편했다.

- schema 로 다시 변환하는 과정 (payload와 response는 항상 같지 않으니까)이 번거로웠던 것 같다.

 

2. 요구사항을 잘 생각해 보아야 한다.

- 해당 글에서는 1개의 객체에 대해서만 임시 저장, 저장 등을 진행했지만, 만약 한번에 N개의 데이터가 임시 저장/수정 되어야 한다면? -> 개발 복잡도 상승

 

3. 임시 저장 데이터가 관리 되어야 하는지 여부도 중요하다. (위 1안, 2안 따라 테이블이나 필드가 무조건 생성 되어야 함)

 

4. 3안이 가장 심플하다.. 이상적

 

(추가) 5. 만약 임시 저장이 여러 버전으로 관리되어야 한다면?

- 2안, 3안으로는 구현이 힘듬