이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
졸업 프로젝트로 한정판 상품 선착순 구매 기능을 만들 때, 오픈 1분 만에 3,000명이 몰리는 시나리오를 시뮬레이션했습니다. 처음엔 요청을 바로 DB에 써서 재고를 차감했는데, 동시성 문제로 재고가 음수가 되거나 중복 구매가 발생했습니다.
이후 메시지 큐를 앞에 두고 처리 순서를 직렬화하는 방식으로 바꿨습니다. 요청은 큐에 쌓이고, 소비자가 순서대로 재고를 확인·차감하니 중복 구매가 사라졌습니다. 큐의 처리 속도가 병목이 되어 소비자 인스턴스를 수평으로 늘리는 방법도 실험했습니다.
실패했던 부분은 큐가 가득 찰 때의 폴백 전략을 미리 짜지 않아 큐 오버플로 시 요청이 그냥 버려진 것입니다. 덕분에 선착순 이벤트에서는 수용 가능한 최대치를 미리 정하고 초과 요청엔 즉시 거절 응답을 주는 설계가 더 나을 수 있다는 걸 배웠습니다.
인턴 때 이벤트 쿠폰 선착순 발급 API가 오픈 순간 응답 시간이 5초를 넘겼습니다. 원인은 재고 조회와 차감이 모두 DB 트랜잭션으로만 처리돼 커넥션 풀이 10초 안에 고갈됐기 때문입니다.
Redis `DECR` 명령어로 재고를 관리하는 방식으로 변경했습니다. 원자적 감소를 보장하면서 DB 요청 수가 확연히 줄었고, 응답 시간이 400ms 수준으로 내려왔습니다. 다만 Redis 장애 시 재고 불일치가 생기는 문제가 있어 주기적인 DB와의 동기화 로직을 별도로 넣어야 했습니다.
그 경험을 통해 선착순 시스템에서 가장 중요한 요소는 정합성과 속도 사이의 균형이라는 걸 배웠습니다. 완벽한 정합성을 위해 속도를 포기하면 사용자가 몰리는 순간 서비스가 멈추고, 너무 느슨한 설계는 재고 오류로 이어집니다. 그 트레이드오프를 의식하며 설계하는 습관을 그때부터 갖게 됐습니다.
사이드 프로젝트에서 팬 미팅 티켓 선착순 예매 기능을 출시하기 전, 실제 오픈과 비슷한 부하를 미리 걸어봤습니다. 당시 동시 200요청 기준으로 테스트했는데, 응답 시간이 7초를 넘기고 일부 요청은 타임아웃이 났습니다.
프로파일링을 해보니 결제 검증 단계에서 외부 API 호출이 동기로 묶여 전체 흐름을 막고 있었습니다. 해당 호출을 비동기로 분리하고 타임아웃을 명시적으로 설정하니, 같은 200요청 기준 응답 시간이 1.2초로 줄었습니다.
실패했던 부분은 부하 테스트 시나리오가 실제 사용 패턴과 달랐던 것입니다. 실제 오픈에선 예상보다 더 짧은 시간에 트래픽이 몰려 큐 지연이 발생했습니다. 부하 테스트는 최악의 시나리오를 더 극단적으로 잡아야 한다는 걸 이때 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.