Decide — boring vs novel

주문이 들어오면 재고 차감, 알림 발송, 정산 기록까지 해야 한다. 이걸 API 한 번의 동기 호출 체인으로 다 처리할지, 일부를 큐에 던져 비동기로 뺄지 정해야 한다.

주문, 결제, 알림이 전부 들어있는 서버 하나로 서비스를 운영 중인데, 코드가 커지면서 작은 수정 하나에도 전체를 다시 배포해야 한다. 팀에서 "이제 마이크로서비스로 쪼개야 하지 않나"는 얘기가 나오기 시작했다.

신규 주문 서비스의 DB를 정하는 회의에서 동료가 "나중에 트래픽 커질 테니 처음부터 MongoDB로 가자"고 한다. 지금 트래픽은 하루 주문 몇천 건 수준이다.

상품 상세 API가 느려져서 p95가 1초를 넘기 시작했다. 회의에서 "레디스 캐시 붙이면 되지 않아요?"라는 말이 제일 먼저 나오는 상황.

주문 목록 화면이 점점 느려진다. 주문·고객·결제 테이블을 조인하고 건수까지 세서 보여주는 쿼리인데, 데이터가 수백만 건을 넘으면서 응답이 눈에 띄게 늘어졌다.

주문이 완료되면 알림 서비스를 호출해서 푸시/이메일을 보내야 합니다. 알림 API를 바로 부를지, 중간에 큐를 둘지 정해야 하는 상황이에요.

주문이 들어오면 이메일 발송이나 이미지 처리 같은 작업을 비동기로 빼야 해서 큐가 필요해졌다. AWS SQS 같은 관리형 서비스를 쓸지, DB 테이블 기반 큐를 직접 만들지 정해야 하는 상황.

결제가 완료되면 주문 상태, 재고, 포인트, 알림을 전부 바꿔야 합니다. 이걸 다 한 트랜잭션으로 묶을지, 돈과 상태만 묶고 나머지는 이벤트로 몇 초 뒤에 맞출지 정해야 하는 상황입니다.

주문 결제가 끝나면 알림 발송, 포인트 적립, 재고 차감 같은 후속 작업을 해야 한다. 후속 서비스들을 그냥 REST로 직접 호출할지, 이벤트 하나 발행하고 각자 알아서 구독하게 할지 정해야 한다.

상품 상세 페이지 트래픽이 늘면서 DB CPU가 80%를 넘기 시작했어요. 읽기 부하를 빼야 하는데, 복제본을 붙일지 캐시를 둘지 정해야 하는 상황입니다.

주문 서버가 결제사 API를 부르는데 가끔 타임아웃이 난다. 자동으로 몇 번 더 시도할지, 아니면 바로 실패를 돌려주고 사용자에게 알릴지 정해야 한다.

정산 로직을 새 버전으로 갈아끼우는 데 3주가 걸리는데, 그동안 팀원들은 매일 main에 기능을 머지하고 있다. 미완성 코드를 어디에 두고 작업할지 정해야 하는 상황.

공장 설비에서 올라오는 측정 이벤트를 받아 DB에 적재하는 수집 서버가 있다. 지금은 이벤트 하나당 INSERT 한 번인데, 라인이 늘면서 유입이 초당 수천 건으로 올라갔다. 한 건씩 바로 쓸지, 모아서 배치로 쓸지(배치 크기·flush 간격) 정해야 한다. 같은 고민이 오퍼 서비스에도 있다 — 사용자가 보는 오퍼 조회 API와 밤마다 도는 시세 재산정 파이프라인은 최적화할 숫자가 다르다.

주문 API 서버 한 대(8코어)로 운영 중인데, 프로모션 때마다 CPU가 90%를 치고 응답이 늘어진다. 회의에서 "인스턴스 사양을 올리자"는 쪽과 "서버를 여러 대로 늘리자"는 쪽이 맞붙었다. 어느 쪽부터 갈지 정해야 한다.

서버 한 대로 잘 돌던 주문 서비스가 트래픽이 늘어 인스턴스를 2대로 늘렸다. 그런데 새로고침할 때마다 로그인이 풀린다는 문의가 들어온다. 세션과 장바구니를 서버 메모리에 들고 있었기 때문이다. 로드밸런서에 sticky session을 걸어 같은 사용자를 같은 인스턴스로 보낼지, 세션을 Redis로 빼서 어느 인스턴스든 같은 요청을 받게 할지 정해야 한다.

매물 오퍼 가격 조회 API에 읽기가 몰려서 Redis 캐시를 붙이기로 했다. 그런데 회의에서 "쓸 때마다 캐시도 같이 갱신하면 항상 최신 아니냐"(write-through), "아예 캐시로 쓰기를 받고 DB엔 모아서 내리자"(write-behind)는 말까지 나왔다. 읽기 경로, 쓰기 경로, 그리고 무효화를 TTL로 할지 이벤트로 할지 정해야 하는 상황.

오퍼(주문) 이벤트 테이블이 수억 행을 넘어 DB 한 대로는 더 못 버티게 됐다. 샤드를 나눠야 하는데, 키가 시간순으로 증가하는 ID라는 게 함정이다. 해시로 고르게 흩뿌릴지, 시간/ID 범위로 자를지 정해야 한다. 공장 센서 로그든 부동산 오퍼 이벤트든 "시간순 키 + 최근 N시간 조회"가 같이 오는 전형적인 상황.

결제가 완료되면 '결제 완료' 이벤트를 큐에 발행하고, 정산 서비스가 받아서 장부에 기록한다. 네트워크가 흔들리거나 컨슈머가 재시작되면 메시지는 사라질 수도(유실), 두 번 도착할 수도(중복) 있다. 유실을 감수할지, 중복을 받아들이고 내가 막을지, 브로커가 약속하는 'exactly-once'를 믿을지 정해야 한다.

오퍼 상태 변경 이벤트(생성 → 가격 산정 → 승인 → 만료)를 Kafka로 흘려서 다운스트림(알림, 정산)이 받아 처리한다. 트래픽이 늘어 컨슈머를 늘리고 싶은데, 파티션을 늘리면 같은 오퍼의 '만료' 이벤트가 '승인'보다 먼저 처리될까 봐 손을 못 대고 있다.

세일 시작 10분 만에 주문 이벤트가 평소의 10배로 들어온다. 뒤에서 알림·정산·집계를 처리하는 워커는 초당 200건이 한계라 큐가 계속 깊어진다. 들어오는 쪽을 늦춰서 다 받아낼지(backpressure), 덜 중요한 작업을 버려서 핵심만 지킬지(shedding) 정해야 한다.