결과 조회 API 방식

[sim-mer]

개요

현재 API 구조상 Guest 결과 조회 API만 QuestionController에 존재하는데 후에 추가할 리포트, 통계 기능을 생각하면 채점 결과 관련해서는 CQRS를 적용해보는게 어떨까요? 개인적으로는 ResultController와 같은 새로운 Controller와 Service로 채점 결과를 따로 처리하는 Controller를 분리하는게 좋을 것 같습니다.

참고사항

[bayy1216]

생각하고 있는 방향이

1. 단일데이터베이스
2. DB이중화
3. 이벤트소싱 중 어떤 것인가요?

[sim-mer]

• 먼저 제출api와 결과 조회 api는 분리합니다.
• 다음으로, 최초 채점이나 문제 수정으로 인한 재채점 상황에서 분명 어느 정도는 delay가 발생할 것 같은데, 이때 결과 조회하는 요청이 들어왔을 경우 제출된 답변의 현재 상태를 알 수 없는 문제가 발생합니다.
• 3-tier 아키텍쳐라면 단일 DB나 DB이중화를 사용해서 현재 답변의 상태를 저장할 경우 AI 채점 delay와 비교해서 엄청난 이점을 얻진 못할 것같습니다.
• 따라서 Redis 같은 인메모리 DB로 AI 채점 Delay 동안 결과조회 API 요청이 들어왔을 때 답변의 상태를 확인한 후 응답하는 과정이 필요할 것 같습니다.

[bayy1216]

• 먼저 제출api와 결과 조회 api는 분리합니다.
• 다음으로, 최초 채점이나 문제 수정으로 인한 재채점 상황에서 분명 어느 정도는 delay가 발생할 것 같은데, 이때 결과 조회하는 요청이 들어왔을 경우 제출된 답변의 현재 상태를 알 수 없는 문제가 발생합니다.

해당내용은 CQRS랑은 관계가 없지않나요?

• 3-tier 아키텍쳐라면 단일 DB나 DB이중화를 사용해서 현재 답변의 상태를 저장할 경우 AI 채점 delay와 비교해서 엄청난 이점을 얻진 못할 것같습니다.
• 따라서 Redis 같은 인메모리 DB로 AI 채점 Delay 동안 결과조회 API 요청이 들어왔을 때 답변의 상태를 확인한 후 응답하는 과정이 필요할 것 같습니다.

AI채점과 CQRS는 관계가 없는것같습니다

[sim-mer]

아 CQRS 설명은 빼먹었네요.

• CQRS를 고려해 볼 필요가 있다고 생각한건 재채점시의 결과 데이터에 관해서 입니다.

  • "Redis 같은 인메모리 DB로 AI 채점 Delay 동안 결과 조회 API 요청이 들어왔을 때 답변의 상태를 확인한 후 응답하는 과정이 필요할 것 같습니다."

• 위의 과정을 적용하지 않는다면 재채점 = Command, 결과 및 통계 조회 = Query라고 생각했을 때, AI가 재채점을 수행하고 있는 Command 과정 중에도 기존의 Data로 Query가 가능하고 수정이 끝난 후에는 결과 Data의 변경이 이루어져 변경된 Data를 조회할 수 있도록 하자는 말이었습니다.
• 또한 가장 양이 많은 data는 테이블 스키마 구조상 question과 question_criteria 일텐데 이 부분을 변경하게 하는 채점 or 수정 command와 가장 요청이 많을 것으로 예상되는 결과 조회 query를 같은 모듈로 둔다면 복잡성이 올라갈 것 같습니다.
• 아키텍쳐는 아직 생각해보진 않았지만 데이터의 양이 적으면 단일 DB로도 가능할 것 같습니다.