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

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

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

블랙프라이데이, 선착순 이벤트, 한정 수량 판매와 같은 상황에서는 수천~수만 건의 주문 요청이 동시에 하나의 재고를 대상으로 몰리는데 이때 적절한 동시성 제어나 방파제 역할을 하는 대기열이 없다면 DB Lock 경합과 커넥션 풀 고갈이 발생하고, 서버 리소스 사용량이 급증한다. 이러한 구조는 응답 지연, 타임아웃과 재시도를 유발하고, 사용자 경험에서도 좋지 않으며 이는 다시 시스템 부하를 키우는 악순환으로 이어진다. 결국 수만건의 주문 요청을 완화하기 위해선 모든 요청을 한 번에 처리하려고 하는 것이 아니라, 서버가 감당할 수 있는 만큼만 순차적으로 처리해야 한다. 이를 위해 사용자 요청을 즉시 처리하는 것이 아닌 대기실에서 기다리게끔 하는 대기열이 필요하다.Redis 대기열 선택 대기열은 모든 요청이 ..