1. 입찰 시 보증금 예치 호출 문제

• 직면한 문제: 입찰 시 사용자의 보증금을 즉시 예치(Hold)해야 하며, 결제 서버의 응답 결과(잔액 부족, 계정 상태 등)에 따라 입찰 프로세스를 중단하고 사용자에게 정확한 실패 사유를 전달해야 함.
• 해결 방안: Fail-Fast 전략: 경매 도메인의 유효성 검증 직후에 보증금 hold API를 호출하여, hold 실패 시 입찰 DB 반영이 일어나지 않도록 트랜잭션을 차단함.
  • 에러 전파(Error Propagation): 결제 서버(PaymentApiClient)에서 수신한 에러 응답을 분석하여 DEPOSIT_INSUFFICIENT_BALANCE 등의 구체적인 메시지로 변환해 사용자에게 전달.

2. 실시간 이벤트(SSE)와 조회 API 간 데이터 스펙 불일치 해결

• 직면한 문제: 실시간 입찰 알림(SSE)은 사용자 친화적인 Nickname을 전달하는 반면, 입찰 기록 조회 API는 시스템 식별자인 PublicId 위주로 반환하여 프론트엔드에서 데이터 매핑 및 "내 입찰" 식별 로직이 복잡해지는 문제가 발생함.

• 해결 방안:

  1. 식별자 표준화: 입찰 알림(SSE)에 PublicId를 필수 포함하여 클라이언트 측 식별 로직을 일원화. ← 현재 상황에서는 이게 편리
  2. DTO Aggregation: 입찰 서비스가 회원 서비스와 연동(RestClient)하여 닉네임 정보를 결합해 반환하도록 조회 로직 고도화.

• 선택 이유: 클라이언트가 닉네임을 표시하기 위해 추가 API를 호출하는 비효율을 제거하고, 시스템 전체의 일관성을 확보하여 프론트엔드 개발 생산성을 높이기 위함.