Redis를 선택한 이유와 RDB 유니크 제약 비교 검증1. 배경카카오페이 단건 코인 결제 흐름을 리팩토링하면서 tid를 어디에 저장하고, 중복 결제 요청을 어떻게 막을지 고민했다.카카오페이 결제는 대략 다음 흐름으로 진행된다.1. 사용자가 코인 결제 요청2. 서버가 카카오페이 ready API 호출3. 카카오페이가 tid 발급4. 사용자가 카카오페이 결제 화면에서 결제 진행5. 서버가 success callback에서 pg_token과 tid로 approve API 호출여기서 tid는 카카오페이가 발급하는 결제 트랜잭션 식별자다. 서버는 approve 요청을 보내기 위해 이 값을 가지고 있어야 한다.처음에는 단순히 Redis에 다음 형태로 저장하는 방식을 검토했다.coin_tid:{memberId} =..

쿠팡은 어떻게 모든 페이지에 빠르고 최신인 데이터를 뿌리는가 — Core Serving Platform쿠팡 상품 페이지를 보면 상품명, 이미지, 가격, 재고, 배송 예정일, 리뷰, 할인 정보까지 온갖 정보가 한 화면에 떠 있다. 그런데 이 데이터들이 전부 한 서버에 저장되어 있는 게 아니다. 이미지·상품명은 Catalog팀이, 가격은 Pricing팀이, 배송 정보는 Fulfillment팀이, 리뷰는 Review팀이 각자 관리한다. 이번 글은 이렇게 흩어진 도메인 데이터를 모아서 쿠팡의 거의 모든 고객 페이지에 빠르고 안정적으로 제공하는 Core Serving Platform에 대한 발표를 정리한 것이다. 크게 두 부분으로 나눠서 정리했다. 앞부분은 이 시스템을 어떻게 설계했는지, 뒷부분은 실제로 운영하면..

유튜브 영상을 보며 메모한 내용을 블로그용으로 재정리한 글입니다. 이해가 안 되는 개념은 아래 "궁금한 점 / 더 찾아볼 부분"에 표시해두었습니다. https://www.youtube.com/watch?v=WKYE-QtzO6g 1. 배경 — 왜 실시간 시세가 필요했나주식 투자자들은 가장 정확하고 최신의 시세·호가 정보를 제공하는 MTS(Mobile Trading System)를 선호한다. 증권사는 거래소로부터 시세를 실시간으로 전달받아 사용자에게 제공하는데, 국내 종목은 모든 증권사가 무료로 제공하지만 해외 종목은 조건부 무료이거나 유료인 경우가 많다.토스증권은 실시간 시세 정보를 조건 없이 전부 무료로 제공한다는 점이 특징이다. 그런데 처음부터 이랬던 것은 아니다. 초기 구현: API 폴링 방식처음에는..

[대규모 시스템 설계 기초] 1장 정리: 사용자 수에 따른 규모 확장성이 글은 『가상 면접 사례로 배우는 대규모 시스템 설계 기초』 1장, “사용자 수에 따른 규모 확장성”을 공부하며 정리한 내용입니다.책의 흐름을 따라가면서, 추가로 멘토님께 질문했던 로드밸런서, 서버 대수 산정, DB 복제, 캐시, 무상태성 API에 대한 답변도 함께 정리했습니다.1. 처음은 단일 서버에서 시작한다가장 단순한 시스템은 하나의 서버에 모든 것을 올려두는 구조다.사용자가 api.mysite.com 같은 도메인으로 접속하면, 먼저 DNS 서버에 해당 도메인의 IP 주소를 질의한다. DNS가 IP 주소를 반환하면 사용자의 브라우저나 앱은 해당 IP 주소로 HTTP 요청을 보낸다. 서버는 요청을 처리한 뒤 HTML이나 JSON ..

8,000건 배치 INSERT, 왜 UNION ALL MERGE 대신 MyBatis Batch를 선택했나인턴 당시, 외부 금융기관에서 수신한 채권/주식 시장가 데이터를 매일 적재하는 배치를 개선한 경험을 정리한다. 단순히 "느리다"는 문제로 시작했지만, 파고들수록 SQL 파싱 비용, 옵티마이저 부담, JDBC 드라이버 내부 동작까지 이어지는 문제였다.문제 상황기존 배치는 파일을 한 행씩 읽으며 다음 순서로 동작했다.종목코드 컬럼을 확인해 보유 종목인지 SELECT로 조회보유 종목이면 필드 매핑 정보에 맞춰 파싱해 Map에 담음 (key는 필드 매핑에 정의된 실제 컬럼명, value는 파싱된 값)상품 하나당 즉시 단건 INSERT약 8,000건을 처리하는 데 매번 이 흐름을 반복하다 보니, 데이터가 늘어날..

1. 배경1차 리팩토링에서는 카카오페이 결제 승인과 내부 코인 지급 트랜잭션을 분리했다.READY -> PAY_SUCCESS -> AFTER_COMMIT 이벤트 -> Coin 지급 -> SUCCESS이 구조는 외부 결제 API 호출과 내부 DB 처리를 하나의 트랜잭션으로 묶지 않는다는 점에서 안전하다. 하지만 아직 한 가지 문제가 남아 있다.Spring Event는 기본적으로 인메모리 이벤트다. 따라서 다음 상황이 발생할 수 있다.1. 카카오페이 approve 성공2. 결제내역 PAY_SUCCESS 저장3. 트랜잭션 커밋4. AFTER_COMMIT 이벤트 발행5. 리스너 실행 전 서버 종료또는:1. PAY_SUCCESS 저장2. AFTER_COMMIT 리스너 실행3. Coin 생성 중 예외 발생이..