feat: improve data flow

[cjw9506]

🚀 목적 및 필요성

실시간 경매에서 가장 중요한 기능은 실시간 입찰 기능입니다. 처음 생각한대로 흐름을 구현하는 과정에서 보다 좋은 구조가 있어서 issue 남깁니다.

초기 데이터 흐름

  @MessageMapping("/chat/{roomId}")
  public void chat(@DestinationVariable String roomId,
                   MessageDTO message) {

      template.convertAndSend("/sub/" + message.getRoomId(), message);

      if (chatService.isHighestPrice(message)) {
          template.convertAndSend("/sub/" + message.getRoomId(), message);
      }

  }

1. 메시지 발행(입찰) 후 바로 구독주소로 보내준다.
2. 이후 해당 메시지의 입찰가격이 최고가인지 확인한다.
3. 최고가라면 동일한 메시지를 한번 더 발행한다.
4. 클라이언트에서 동일한 메시지를 확인 후 최고가를 모든 클라이언트에 알려준다.

위와 흐름은 여러 단점이 존재한다.

• 메시지가 먼저 전송되고 이후에 최고가 여부를 확인하기 때문에, 사용자는 최고가가 아닌 입찰에 대해서도 초기에는 성공적으로 입찰된 것처럼 보일 수 있다.
• 최고가가 아닌 경우에도 두번의 통신이 발생하므로 네트워크 부하가 증가할 수 있다.

개선된 데이트 흐름

  @MessageMapping("/chat/{roomId}")
  public void chat(@DestinationVariable String roomId,
                   MessageDTO message) {

      boolean isHighest = chatService.isHighestPrice(message);
      message.updateStatus(isHighest);
      template.convertAndSend("/sub/" + message.getRoomId(), message);
  }

1. 클라이언트는 입찰을 한다.
2. 해당 메시지의 입찰가격이 최고가인지 확인한다.
3. 확인 후 최고가 여부에 따라 다른 메시지를 발행한다.
4. 클라이언트는 이를 확인 후 모든 클라이언트에 알려준다.

위 개선된 흐름은 초기 흐름의 단점을 개선할 수 있었다.

• 항상 최고가를 먼저 확인하므로, 사용자는 항상 최신 정보를 받게 된다.
• 두번의 통신을 한번의 통신으로 줄여 네트워크 부하를 감소시켰다.

위 흐름에서는 필수적으로 Redis를 먼저 거치기 때문에, 초기 구조보다 상대적으로 느린 응답 시간을 가질 수 있다. 하지만 Redis의 해시 데이터 하나만 갱신하는 과정을 거치기 때문에 큰 지연이 발생하진 않을 것이다. 사용자 경험 측면에서 생각했고, 자신의 입찰이 성공했는가에 대한 정확한 응답이 더 중요하다고 생각했다.

📋 작업 상세 내용

• [x] data flow 개선

[O0oO0Oo]

잘 읽었습니다! 확실히 레디스는 간단한 연산이여서 유저가 기다리는 시간이 적을것 같아요. 두번의 통신보다는 약간의 지연이 생겨도 한번의 확실한 응답이 적합한것 같습니다.