배경기존에 채점 시스템에서 SNS와 SQS를 활용한 팬아웃(Fan-out) 패턴을 통해 채점 요청을 처리하고 있었다. 초기 아키텍처는 효율적인 비용과 처리량에 중심을 둔 Standard 타입의 SNS와 SQS로 구성했다. Standard는 순서를 보장하지 않는 대신, 높은 처리량을 제공하여 만약 채점 요청이 대량으로 들어올 경우 분산 처리하는데 유리했다. 그러나 먼저 제출한 사람의 채점이 먼저 처리되어야 한다는 요구사항이 있었다. 그래서 SNS와 SQS를 모두 FIFO, 선입 선출 구조로 변경했다. 그러나 이렇게 둘 다 FIFO로 구성할 경우 전체 채점 요청이 단 하나의 파이프라인을 통해 직렬로 처리될 수밖에 없었다. 만약 트래픽이 몰린다면 전체 시스템 처리 속도가 급격히 저하되는 성능 병목 지점이 될..

배경기능 요구사항:제출(Submission) 하나를 대표 코드로 지정(isDefault = true)기존에 대표 코드로 지정되어 있던 것은 자동 해제(isDefault = false) 방법 1가장 나이브한 구현 방식을 생각해보자면, Submission들을 전부 로딩해서 순회하며 isDefault가 true인 것을 false로 업데이트 한 뒤, 대표로 지정하고자하는 제출을 isDefault = true로 설정하는 것이다.`List findByUserAndProblem(...)` 같은 것으로 n건을 SELECT → READ 1서비스에서 순회하며 isDefault가 true인 것만 false로 set대표로 지정할 대상 엔티티도 set(isDefault=true)커밋 시점 플러시에서 변경된 엔티티 수만큼 UPD..

문제 상황문제 목록을 조회할 때 각 문제의 Top 유저를 함께 가져와야 했다. QueryDSL로 구현하려면, 기본적으로 문제를 조회하는 메인 쿼리와, 각 문제에 대한 Top 유저를 구하는 서브쿼리가 필요했다. Top 유저를 조회하는 기준 컬럼을 내림차순 정렬한 뒤 상위 1명만 선택한다는 아이디어로 설계했다. 즉, 정렬 후 limit 1을 적용해 한 행만 가져오는 방식을 떠올렸다. 실행을 돌려보니, Scalar subquery contains more than one row; SQL statement: 에러가 떴다. 문제 코드public List findPopularProblem(int limit) { QProblem problem = QProblem.problem; QProble..