예약·취소 API 설계
약 75초
멱등성·트랜잭션·롤백 축으로 가른 뒤 실제 겪은 중복 요청 사례로 설명
인턴 때 숙박 플랫폼 백엔드 팀에서 예약·취소 API를 처음 만져봤습니다. 처음에는 단순히 INSERT·DELETE로 구현했는데, 테스트 중 네트워크 단절로 같은 요청이 두 번 들어오는 상황이 재현됐습니다. 그때야 멱등성이 단순한 개념이 아니라는 걸 실감했습니다. 이후 idempotency_key를 헤더로 받아 중복 처리를 막고, 예약과 포인트 차감을 단일 트랜잭션으로 묶어 부분 성공 상태가 남지 않게 했습니다. 취소 흐름에서는 부분 환불이 있어서 롤백 기준을 명확히 정의해 팀 위키에 남겼습니다.
B2B 계약 조건마다 취소 수수료 계산 로직이 달라서, 분기 하드코딩 대신 설정 테이블로 뽑아내 파트너사가 늘어도 코드를 건드리지 않아도 되는 구조를 만들었습니다. 여러 파트너사에서 동시에 호출되는 상황을 상상하면서 정합성을 먼저 그리는 습관이 그때 생겼습니다.
이 결의 특징
멱등성키와 트랜잭션 조합, 파트너사별 설정 테이블로 수수료를 분기하는 B2B API의 정교한 구조가 명확합니다. 계약사양 기준을 알람과 직결한 운영 설계 흔적이 선명합니다.
이 결이 통하는 자리
API는 구축보다 운영이 더 길다는 통찰이 살아있고, SLA 임계값을 계약기준과 자동 연동한 구체성이 두드러집니다. 알람이 없으면 사용자가 장애를 먼저 발견하게 된다는 실제 경험이 느껴질 때 통합니다.