이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
대규모 트래픽 주문 처리 설계에서 가장 먼저 고려하는 것은 병목 지점이 어디인지를 파악하는 것입니다. 주문 프로세스는 API 게이트웨이→재고 확인→결제→주문 확정 단계로 나뉘는데, 재고 확인과 결제 단계가 동기 처리로 묶이면 트래픽 집중 시 대기열이 폭발합니다. 백엔드 수업에서 재고 확인을 캐시 레이어에서 먼저 처리하고, 결제는 비동기 큐로 분리하는 구조를 실습했습니다. 또한 DB 쓰기 충돌을 막기 위해 낙관적 락 전략을 쓰면 처리량을 유지하면서 정합성을 보장할 수 있다는 것도 배웠습니다. 앞으로도 주문 시스템 설계에서 동기 병목 식별 → 캐시·큐 분리 → 락 전략 설계 순서를 유지하겠습니다. 앞으로도 주문 시스템 설계에서 동기 병목 식별 → 캐시·큐 분리 → 락 전략 설계 순서를 유지하겠습니다.
트래픽 집중 시 동기 처리 구간이 병목이 됩니다. 낙관적 락은 충돌이 드문 환경에서 처리량을 크게 높이는 전략입니다.
분산 시스템 수업에서 주문 처리 흐름 중 하나의 서비스가 느려질 때 전체가 마비되는 케이스를 분석했습니다. 결제 API가 응답 지연을 일으키면 연결을 기다리는 스레드가 쌓이면서 API 게이트웨이까지 멈추는 cascade failure 패턴이었습니다. 이를 방지하기 위해 Circuit Breaker 패턴을 학습하고 간이 구현해봤는데, 호출 실패율이 임계치를 넘으면 서킷을 열어 즉시 fallback 응답을 반환하는 방식입니다. 핵심은 격리된 장애가 전파되지 않도록 서비스 경계마다 보호 장치를 두는 것이었습니다. 또한 주문 수신과 실제 처리를 큐로 분리해, 처리가 느려도 주문 접수는 계속 받을 수 있는 구조가 UX와 안정성을 동시에 챙기는 방법이었습니다.
단일 장애 지점을 없애는 것이 스케일링보다 먼저라는 것을 이 사례에서 확인했습니다.
백엔드 심화 스터디에서 주문 시스템의 성능 병목을 찾고 개선하는 실습을 진행했습니다. 처음에는 DB 인덱스를 추가하면 된다고 생각했는데, 모니터링 지표를 붙여보니 병목이 인덱스가 아니라 외부 API 호출 대기 시간이었습니다. 성능 최적화는 측정 먼저, 추측은 나중이라는 원칙을 이 경험에서 체득했습니다. 또한 개선 사항을 한 번에 전체 트래픽에 적용하지 않고, 작은 비율부터 올려가며 지표를 관찰하는 방식을 배웠습니다. 특정 케이스에서만 나타나는 오류가 전체 배포 후에야 발견되는 것을 막기 위해서입니다.
응답 시간 p95·p99 분위수를 함께 보는 것이 평균값만으로는 보이지 않는 꼬리 지연을 잡아냈습니다. 대규모 트래픽 환경에서 설계 단계의 구조만큼 운영 단계의 관측 가능성이 중요하다는 것을 이 스터디에서 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 CJ올리브영 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.