1편에서는 비관적 락 대신 유니크 제약조건으로 재설계해서, 락 없이도 예약 중복 체크를 할 수 있었다. 그런데 다른 개발자분들과 리뷰하는 과정에서, 예약 기능에 아직 개선할 여지가 남아있다는 걸 알게 됐다. 이 글은 1편에서 다룬 테이블과 코드를 그대로 이어서 다루기 때문에, 먼저 1편을 읽고 오시면 이해가 훨씬 쉬울 것이다.예약 시스템에서 비관적락은 정말 필요했을까? — lty's Blog 예약 시스템에서 비관적락은 정말 필요했을까?최근 한 기업의 채용 과제전형에서 숙소 예약 시스템을 구현하면서, 동시성 제어 방식을 비관적 락에서 유니크 제약조건으로 바꾼 판단 과정을 정리한다. 결과와 무관하게, 이 판단이 어떤 근거sunhistory.tistory.comBLOCKED_DATE 테이블은 관리자가 데이터를..

최근 한 기업의 채용 과제전형에서 숙소 예약 시스템을 구현하면서, 동시성 제어 방식을 비관적 락에서 유니크 제약조건으로 바꾼 판단 과정을 정리한다. 결과와 무관하게, 이 판단이 어떤 근거로 이뤄졌고 어디서 놓쳤는지는 다시 짚어볼 가치가 있었다. 같은 자리를 두 사람이 동시에 예약하면 두 사용자가 동시에 같은 집, 같은 기간을 예약하려고 할 때 어떻게 막을 것인가가 가장 까다로운 지점이었다. 서버 입장에서는 "이 기간, 지금 비어있나?"를 확인하고 "예약 완료"로 바꾸는 그 찰나에, 다른 요청도 같은 질문을 던지고 있을 수 있다. 이를 제대로 처리하지 못하면 같은 기간에 두 건의 예약이 동시에 성립하는 정합성 문제가 발생한다. 이런 상황을 동시성(concurrency) 문제라고 부른다. RESERV..

직장 동료로부터 "루퍼스"라는 현업자 대상 백엔드 부트캠프를 알게 됐습니다. 5월 9일부터 7월 25일까지, 10주 동안 진행되는 코스였고 저는 이번 4기 코스를 수료했습니다. 교육비가 할인해서 약 140만원 정도로 절대 가볍지 않은 금액이라 신청 전에 꽤 고민했습니다. 그래서 저처럼 신청할지 말지 고민하는 분들을 위해 제가 직접 겪은 경험과 후기를 최대한 솔직하게 남겨보려 합니다.지원과정지원 과정은 생각보다 간단했습니다. 구글 폼으로 몇 가지 설문 문항을 작성하고, 교육비를 결제하면 지원이 마무리되는 방식이었습니다. 다만 별도의 코딩테스트나 면접 없이 진행되다 보니, 오히려 "내가 정말 들어도 되는 교육인가"에 대한 감이 잘 잡히지 않았습니다. 신청 전에 후기를 찾아봤지만 자세하게 적힌 후기가 많지 않..

랭킹 시스템을 구현하기 전에는 단순히 주문 수나 좋아요 수를 합산해서 점수를 계산하면 되는 기능이라고 생각했는데 실제로 설계를 시작해 보니 고려해야 할 요소가 많았다. 어떤 데이터를 랭킹의 기준으로 사용할지, 이벤트는 어떻게 전달할지, Redis 장애가 발생하면 어떻게 복구할지, 신규 상품은 어떻게 랭킹에 진입시킬지까지 고민해야 했다. 이번 글에서는 랭킹 시스템을 구현하면서 고민했던 설계 과정과, 그 과정에서 선택한 방법 그리고 그 이유를 정리해보려고 한다.랭킹 데이터 지표 선정랭킹 시스템에서 가장 먼저 고민한 것은 어떤 데이터를 랭킹의 신호(Signal)로 사용할 것인가​였다.후보는 크게 세 가지였다.조회수(View)좋아요(Like)주문(Order)최종적으로는 주문 횟수와 좋아요 수만 랭킹 점수에 반..