Skip to content

Conversation

kilhyeonjun
Copy link
Contributor

@kilhyeonjun kilhyeonjun commented Nov 7, 2024

요구사항

  • 콘서트 예약 시나리오(대기열 인원수 제한 없음)
    대기열 구현에 대한 설계를 진행하고, 설계한 내용과 부합하도록 적절하게 동작하는 대기열을 구현하여 제출
    • Redis, Queue, MQ 등 DB가 아닌 다른 수단을 활용해 대기열 개선 설계 및 구현 (”Nice to have”)

작업 내용

  • Waiting Queue 의 Repository 구현체를 JPA -> Redis로 변경
    • 해당 과정에서 토큰의 저장 부분 또한 Redis의 Hash 로 이관하였습니다. 이관함에 따라 기존의 도메인 모델의 속성값이 달라져서 비지니스 로직에도 추가 개선 작업을 하였습니다.
  • 설계 보고서 작성 CACHE_REDIS_QUEUE.md

리뷰포인트

  • 궁금한 사항은 코멘트 남겨놨습니다. 확인 부탁드립니다!
  • 리뷰어님들이 생각했을 때 더 좋은 패턴이 보일 경우 공유해주시면 좋을 것 같습니다.

Copy link
Contributor Author

@kilhyeonjun kilhyeonjun left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

간단하게 구현체만 바꾸면 될줄 알았으나 DB에 저장하는 방식을 제거하고 Hash를 사용함으로써 비지니스에도 영향도가 많이 가서 diff가 많은 점 참고 부탁드림다!

@Value("${queue.active-key}")
private String activeQueueKey;

public WaitingQueue save(WaitingQueue waitingQueue) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

기존 Repository 인터페이스 구조를 변경하지 않을려고 하다가 save 내부가 많이 지저분해졌습니다. 구현체가 바뀜에 따라 인터페이스도 바뀌었어야 했을까요?
애초에 첫 인터페이스가 유연하지 못하게 만든 것도 있는 것 같습니다.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

구현체가 바뀜에 따라 인터페이스는 변경되면 안됩니다. 그렇다면 인터페이스를 사용할 논리가 부족해집니다.

처음부터 인터페이스를 쓰지 않고, 구현체만 사용중에- 새로운 구현체가 필요해져서 인터페이스를 만드는 방식이 좀더 자연스럽다고 생각합니다.

@kilhyeonjun kilhyeonjun merged commit 402c5d9 into master Nov 10, 2024
@kilhyeonjun kilhyeonjun deleted the feature/step-14 branch November 10, 2024 05:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants