이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
인턴 때 숙박 플랫폼 백엔드 팀에서 예약·취소 API를 처음 만져봤습니다. 처음에는 단순히 INSERT·DELETE로 구현했는데, 테스트 중 네트워크 단절로 같은 요청이 두 번 들어오는 상황이 재현됐습니다. 그때야 멱등성이 단순한 개념이 아니라는 걸 실감했습니다. 이후 idempotency_key를 헤더로 받아 중복 처리를 막고, 예약과 포인트 차감을 단일 트랜잭션으로 묶어 부분 성공 상태가 남지 않게 했습니다. 취소 흐름에서는 부분 환불이 있어서 롤백 기준을 명확히 정의해 팀 위키에 남겼습니다.
B2B 계약 조건마다 취소 수수료 계산 로직이 달라서, 분기 하드코딩 대신 설정 테이블로 뽑아내 파트너사가 늘어도 코드를 건드리지 않아도 되는 구조를 만들었습니다. 여러 파트너사에서 동시에 호출되는 상황을 상상하면서 정합성을 먼저 그리는 습관이 그때 생겼습니다.
예약 API를 배포한 뒤 운영 관점에서 의식하지 못했던 문제를 여러 번 마주쳤습니다. 처음에는 에러 로그만 쌓았는데, 특정 파트너사에서 취소 요청이 갑자기 증가하는 패턴을 뒤늦게 발견했습니다. 이후 파트너사별 API 호출량·에러율·응답 시간을 대시보드로 분리해서 모니터링하도록 구성했습니다.
SLA는 파트너사 계약마다 달라서, 계약 기준(99.5% 가용성·응답 2초 이내)을 알람 임계값과 직접 연동했습니다. 알람이 울리면 어느 파트너사·어느 엔드포인트인지 즉시 알 수 있어서 대응 시간이 크게 줄었습니다. 예약·취소 API는 구축보다 운영이 더 오래 걸리는 작업이라는 것을 실감했습니다.
알람 없는 운영은 장애를 사용자가 먼저 발견하게 만드는 구조라는 걸 이 경험에서 배웠습니다.
예약 API에서 동시에 같은 타임슬롯을 두 명이 요청하는 시나리오를 처음 마주쳤을 때, 단순 SELECT 후 INSERT로 구현하면 두 건 모두 성공으로 응답하는 이중 예약이 발생할 수 있다는 걸 테스트에서 확인했습니다. 낙관적 락(Optimistic Lock)을 적용해 타임슬롯 버전 번호를 비교하도록 바꾸니 충돌 시 한 건이 실패로 처리됐습니다. 취소와 환불이 분리된 서비스에 걸쳐 있어 부분 실패 처리가 필요했는데, SAGA 패턴으로 예약 취소 → 환불 요청 → 상태 갱신을 단계별로 나누고 실패 시 보상 트랜잭션이 자동 실행되도록 설계했습니다.
접근 순서를 먼저 그리고, 각 단계의 실패 시나리오를 정의한 뒤 구현하는 흐름이 이때 생겼습니다. 정상 흐름보다 실패 흐름을 먼저 설계하는 습관이 B2B API의 신뢰성을 만든다는 것을 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 트립비토즈 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.