<aside> <img src="/icons/reorder_gray.svg" alt="/icons/reorder_gray.svg" width="40px" />

목차

</aside>

1. 배경

입찰 서비스는 신뢰할 만한 가격 제공과 요청에 대한 빠른 피드백을 제공해야 합니다. 그 이유는 사용자가 경매 현재가 를 보고 입찰 규모를 정하고, 자신의 요청 여부에 따라서 다음 액션을 결정할 수 있기 때문입니다.

서비스의 특성과 서버 아키텍처를 고려했을 때, 아래와 같은 요구사항이 도출되었습니다.

<aside> ✅

구현 요구사항

1. 사용자가 현재가를 신뢰할 수 있어야 한다
2. 입찰 요청 이후 평균 1초 이내에 사용자에게 피드백이 와야 한다.
   • 입찰 데이터 저장 외에도 경매 시간 연장등의 시스템 작업이 수행
   • 응답 속도는 빨라야 한다.
3. Monolith 서버이기 때문에, 다른 기능에 미치는 영향을 최소화해야 한다.
4. 서버 관리 인력이 충분하지 않은 상태이므로, 관리 비용은 낮을 수록 좋다. </aside>

우선, 1.현재가 신뢰와 2.빠른 피드백 을 위해 사용자 요청에 응답하는 방식과 구조를 결정했습니다. 그리고 결정된 구조에 따라 3.다른 기능 영향, 4.관리 비용를 위해 이벤트 교환 방식을 결정했습니다.

2. 선택지

🗣️ 사용자 요청 응답 방식

실시간 반영 방식과 요청 여부 선응답 + 후처리를 고려했습니다.

<aside> ⏳

WebSocket을 활용한 실시간 정보 변화 반영

➕ 사용자가 현재 보는 데이터가 실시간임을 인지함 → 현재 보이는 데이터의 신뢰도🔺

➖ 경매 서비스 특성상, 빈번한 데이터의 업데이트는 전체 시간의 극히 일부(마감 시간 근처)

➖ Monolith 구조에서 Open Connection을 유지하는 건 API 서버 전체에 영향을 줌

➖ 근본적으로 사용자가 보낸 응답에 대한 빠른 피드백을 보장하지는 않음(추가적인 구조 필요)

</aside>

<aside> 📬

사용자 요청 성공 여부만 응답하고 Event Driven 방식의 시스템 작업 처리 후 별도로 피드백

➕ 현재 가격은 Redis에서 관리하고, 로직 초반부에 배치해서 현재가에 미달한 요청은 빠른 피드백

➕ 현재가를 상회하는 요청도 응답 이후 데이터 갱신 이벤트로 별도 수행하여 빠른 피드백 가능

➖ WebSocket을 함께 활용하지 않는다면, 현재 가격 확인을 위해서는 새로 고침 필요

</aside>