To Be Continued

배경antcamp은 가상 주식 대회 플랫폼이다. 대회가 종료되면 모든 참가자의 최종 총자산을 계산해 순위를 확정해야 한다.총자산은 아래 공식으로 계산된다.총자산 = 현금 잔액 + (보유 종목별 확정가 × 보유 수량)이때 확정가는 대회 종료 시점의 실제 주가여야 하므로, 한투(한국투자증권) API를 호출해 가격을 가져와야 한다.문제캐싱 전 이미지 삽입단순하게 구현하면 참가자 수 × 보유 종목 수만큼 한투 API를 호출하게 된다.예를 들어 참가자 100명이 각자 5개 종목을 보유하고 있다면 최대 500번 API를 호출해야 한다.이 방식에는 두 가지 문제가 있다.한투 API에는 **호출 횟수 제한(Rate Limit)**이 있어 초과 시 오류가 발생한다.외부 API 호출이 많을수록 정산 처리 시간이 길어진다...

문제 상황asset-service에서 Kafka Consumer를 실행하던 중 다음과 같은 에러가 발생했다Error deserializing VALUE for partition competition.ticked-0그리고 핵심 원인은 아래 코드였다No type information in headers and no default type provided처음에는 Kafka 연결 문제나 Producer 설정 문제라고 생각했지만, 로그를 확인해보니 실제 원인은 Consumer가 Kafka 메시지를 객체로 변환하지 못하는 문제였다. 문제가 발생한 코드asset-service에는 competition.ticked 토픽을 구독하는 Consumer가 있었다.@Slf4j@Component@RequiredArgsConstr..

Kafka를 사용한 이유이번 프로젝트는 competition-service와 asset-service가 나누어진 구조였다.competition-service는 대회 관련 기능을 담당하고, asset-service는 계좌와 보유 주식 관련 기능을 담당한다.문제는 대회에서 사용자가 참가했을 때 asset-service에서도 그 사실을 알아야 한다는 점이었다.사용자가 대회에 참가하면 해당 사용자에게 대회용 계좌를 만들어줘야 하기 때문이다.이때 competition-service가 asset-service를 직접 호출할 수도 있지만, 그렇게 하면 두 서비스가 강하게 연결된다.그래서 Kafka를 사용해 이벤트를 주고받는 방식으로 처리했다. Kafka 이벤트 방식전체 흐름은 다음과 같다.competition-ser..

테이블 구조모의 주식 대회 서비스의 자산은 현재 아래 두 테이블을 기준으로 구성되어 있다.Account (계좌)- account_id- user_id- is_endedHoldings (보유 주식)- holding_id- account_id- stock_code- quantity- final_price하나의 Account 아래에 여러 Holdings가 존재하는 구조문제 상황초기 설계에서는 대회 종료 여부(is_ended)를 나타내는 컬럼이 존재하지 않았다.그래서 Holdings의 값을 기준으로 대회 종료 여부를 판단하려고 했다.holdings.final_price != 0 → 대회 종료문제 인식이 구조의 흐름은 다음과 같다대회 종료 → final_price 저장 → 조회 시 final_price로 종료 판..

프로젝트 배경모의 투자 서비스에서 주식 대회 기능을 구현하고 있다.사용자는 가상의 돈으로 주식을 매수/매도대회 종료 시점에 보유 주식의 최종 가격 + 잔고 기준으로 수익률을 계산이를 기반으로 순위를 산정즉, 대회 종료 시점에는 모든 참가자의 보유 주식에 대해 종목별 최종 가격을 조회하는 과정이 필요하다.문제 상황여러 사용자가 동일한 종목을 보유할 수 있기 때문에 가격 조회 과정에서 중복 호출이 발생할 수 있다.사용자1: A, B, C 보유사용자2: B, C 보유→ B, C는 여러 번 조회될 수 있음같은 시점의 가격인데도 반복 조회가 발생하는 구조다.고민최종 가격은 DB에 저장해야한다.하지만 DB에 저장하기 전에 가격을 조회하는 과정에서 중복 API호출이 발생하는 문제가 있었다.그래서 캐싱을 고민하게 되었..

문제 상황모의 주식 투자 대회 서비스를 설계하던 중 다음과 같은 고민이 발생했다.대회 종료 시 유저에게 거래내역, 최종 수익률, 최종 자산을 보여주기 위해 포트폴리오 테이블을 따로 만들어야하는가? 나의 초기 의견나는 처음에 포트폴리오 테이블이 필요하다고 생각했고 이유는 다음과 같았다.대회 종료 시점의 결과를 별도로 저장해야 한다이후 조회 시 매번 계산하지 않아도 된다랭킹이나 결과 페이지에서 빠르게 조회할 수 있다즉, 종료 시점 결과를 스냅샷으로 저장해야 한다는 관점이었다. 팀원의 의견팀원은 포트폴리오 테이브 없이도 충분하다는 입장이었고 이유는 다음과 같았다.대회마다 계좌를 새로 생성한다대회 종료 후에는 계좌, 보유 주식 데이터가 변경되지 않는다.따라서보유 수량평균 매수가남은 현금을 이용하면 언제든지 최종..

보호되어 있는 글입니다.

상황프로젝트 진행 중 일부 구간에서 소통이 원활하지 않은 구간이 있었고 이 문제는 중간에 언급되지 않고 진행되었다.그 결과 프로젝트 후반에 의사소통 충돌이 여러번 발생했다.원인초기 도메인 설계 및 역할 정의 부족협업 방식(회의, 공유 기준)에 대한 명확한 합의 부족결과도메인 간 책임 경계가 모호해짐서로 기대하는 역할이 달라 충돌 발생후반으로 갈수록 의사소통 비용 증가느낀점소통이 원활하지 않은 상태에서 개발이 진행되면 작은 불일치가 누적되어 큰 충돌이 된다는것을 경험했다.개선 방향초기 역할, 책임, 소통 방식 명확히 정의정기적인 소통으로 문제 조기 공유작은 이슈라도 바로 공유