전체 글677 락을 걸었더니 서른 명이 쿠폰을 못 받았습니다: 유니크 제약과 조건부 쓰기가 안에서 하는 일 1. 1인 1매를 지키려는 세 가지 코드쿠폰 이벤트를 만들었습니다. 조건은 두 개입니다. 한 사람이 한 장만 받을 수 있고, 전체 100장까지만 나갑니다. 처음 짠 코드는 이랬습니다. if (couponRepository.existsBy(eventId, userId)) { throw new AlreadyIssuedException();}couponRepository.save(new Coupon(eventId, userId)); 이 코드는 요구사항을 만족시키지 못하죠. 확인과 저장 사이가 벌어져 있어서, 두 요청이 동시에 들어오면 둘 다 통과합니다. 한 사람이 32번 누르게 하고 재봤습니다. 조회 후 삽입 (락 없음) 발급 32장 / 29장 / 7장 (회차마다 다름) 한 장만 나가야 .. 2026. 8. 8. [시스템 설계 - 보상] Ep.7 취소했는데 쿠폰이 돌아오지 않습니다 0장. 주문을 취소했더니 손님이 쿠폰까지 잃었습니다손님이 주문을 취소합니다. 결제가 취소되고, 재고가 돌아오고, 적립 예정이던 포인트가 회수됩니다. 마지막으로 쓴 쿠폰을 돌려줄 차례입니다. 그런데 그 쿠폰은 어제 만료됐습니다. 주문할 때는 살아 있었습니다. 돌려줄 방법이 없습니다. 손님은 주문도 잃고 쿠폰도 잃었습니다. 에러 로그는 없습니다. 코드는 시킨 대로 했습니다. 넷은 돌아갔고 하나만 안 됐습니다. 쿠폰이 유별난 놈이었던 걸까요. 그러면 되돌린다는 건 대체 무슨 뜻이었을까요?1장. 되돌리기는 원래 일의 반대가 아닙니다결제를 취소해 보신 적 있으실 겁니다. 카드사에 매출이 넘어가기 전에 누르면 취소로 끝나고, 넘어간 뒤에 누르면 환불이 됩니다. 그 차이는 날짜가 아니라 매출이 넘어갔는지입니다. .. 2026. 8. 6. [시스템 설계 - 경계] Ep.6 주문 상태 값을 하나 추가했더니 매장에 돈이 더 나갔습니다 0장. 주문 상태 값을 하나 추가했더니 매장에 돈이 더 나갔습니다주문팀이 환불 대기 상태를 하나 추가합니다. 주문 상태 컬럼에 값 하나가 늘었습니다. 새벽 3시에 도는 정산 배치의 조건은 이랬습니다. WHERE status != 'CANCELED' 취소된 것만 빼고 전부 정산한다, 지금까지는 맞는 조건이었습니다. 그날 밤, 아직 환불이 끝나지 않은 주문들의 대금이 매장 계좌로 나갑니다. 다음 달 정산에서 회수해야 합니다. 매장 사장님들에게 연락을 돌려야 합니다. 주문팀은 자기 도메인에 값을 하나 늘렸을 뿐입니다. 정산팀은 조건문을 그대로 두었던 것이구요. 둘 다 맞게 일했는데 돈이 틀어졌습니다.그러면 저 값의 뜻은 누가 정하고 있었을까요?1장. 그 테이블은 처음엔 옳았습니다사고의 출발점은 테이블 하나입니.. 2026. 8. 5. [시스템 설계 - 격리] Ep.5 하나가 느려지면 전부 멈춥니다 0장. 결제사 한 곳이 느려졌는데 회원가입 메일이 안 나갑니다외부 결제사 한 곳의 응답이 느려집니다. 장애가 발생해 아예 다운된 것은 아닙니다. 30초쯤 뒤에 응답이 오긴 옵니다. 에러가 쏟아지는 상황도 아니므로 겉보기에는 시스템이 평온하게 돌아가는 듯합니다. 그런데 몇 분 뒤 모니터링 대시보드에 뜨는 현상은 결제 실패가 아닙니다. 갑자기 신규 회원가입 처리가 멈춥니다. 메인 화면의 상품 목록이 뜨지 않습니다. 곧이어 서버의 헬스 체크가 실패하기 시작하고, 로드 밸런서는 살아있는 서버를 타겟 그룹에서 하나씩 빼버립니다. 결제와 아무 상관 없는 기능이 전부 죽어버립니다. 여기서 이런 의문이 듭니다. 결제사가 느려졌는데 왜 회원가입이 안 되지? 무슨 상관이 있었던 걸까요?1장. 왜 무관한 것까지 멈추나결제사.. 2026. 8. 1. [시스템 설계 - 고유 ID] Ep.4 시계가 거꾸로 갑니다: 고유 ID 만들기가 어려운 진짜 이유 분산 환경으로 시스템을 확장할 때, 예상치 못한 곳에서 발목을 잡혔다면 무엇 때문일까요? 트래픽을 견디려 서버를 늘립니다. 병목을 줄이려 데이터베이스를 쪼갭니다. 그러자 단일 서버 시절 공기처럼 당연하게 쓰던 기초적인 기능들이 시스템의 발목을 잡기 시작합니다. 그중 하나가 바로 식별자 발급입니다. 단일 데이터베이스 환경에서는 너무나 당연하고 쉬웠던 일이, 서버가 늘어나고 데이터베이스가 쪼개지는 순간 거대한 아키텍처적 고민거리로 둔갑합니다. 이 글에서는 분산 환경에서 고유한 ID를 생성하기 위해 업계가 어떤 대가를 치르며 발전해 왔는지, 그리고 우리가 마주한 시스템에는 어떤 방식이 가장 적합할지 트레이드오프의 관점에서 살펴보겠습니다.0. 겹치거나 멈추거나: 분산 환경의 딜레마그런데 이것은 왜 필요한 걸까요.. 2026. 7. 31. 이전 1 2 3 4 ··· 136 다음
