개발.. 한놈만 팬다

TL;DR — 트래픽 폭증은 한 층으로 못 막는다. 누구를 들일지(Rate Limit) → 얼마나 빨리 들일지(대기열) → 기다리는 사람을 어떻게 붙잡을지(폴링 피드백), 세 질문에 각각 한 층씩. DB 커넥션 40개라는 바닥에서 거꾸로 설계했고, 부하 테스트로 검증했다.1. 블랙 프라이데이의 산수 - 서버를 늘려도 안 되는 이유시나리오는 이렇다. 평소 초당 100건이던 주문이 행사 시작 직후 초당 10,000건으로 폭증한다. 우리 서버가 가진 것자원크기출처Tomcat 워커 스레드200(설정값) application.ymlDB 커넥션 풀40(설정값) jpa.ymlPG 호출 read-timeout2초 (재시도 포함 최대 약 7.5초)(설정값) openfeign read-timeout · resilienc..

TL;DR — 선착순 쿠폰의 동시성은 "락으로 막는" 문제라고 생각했는데, Kafka로 요청을 한 줄로 세우면 경쟁 자체를 없앨 수 있었다. 다만 큐로 직렬화해도 그걸로 끝이 아니었다. 직렬화는 "전역 수량(100장)"만 지키고, "1인 1장"은 다른 장치(UK)가 필요했다. 결국 직렬화 + UK + 원자적 수량 감소라는 세 방어선을 조합했고, 그 대가로 발급은 비동기가 되었다.순진하게 짜보면선착순 100장 쿠폰. 제일 먼저 떠오른 코드는 이랬다.1. 남은 수량 조회 (remaining = 100)2. if remaining > 0 → 발급3. remaining -= 1 혼자 요청하면 잘 된다.문제는 1만 명이 동시에 1번을 실행할 때다.다 같이 remaining = 100을 읽는다.다 같이 ..

발단 — "인기순으로 보여주세요"상품 목록에 정렬 옵션을 추가했다. 최신순, 가격순, 그리고 좋아요순.enum class ProductSort(val sort: Sort) { LATEST(Sort.by(Sort.Direction.DESC, "createdAt")), PRICE_ASC(Sort.by(Sort.Direction.ASC, "price")), LIKES_DESC(Sort.by(Sort.Direction.DESC, "likeCount")),} 최신순·가격순은 멀쩡했는데, 좋아요순만 유독 느렸다. 데이터가 적을 땐 몰랐다가, 상품을 10만 건으로 늘리고 나서야 체감이 됐다.여기서 "처음엔 데이터가 적어서 못 느꼈다"는 점이 핵심이다. 성능 문제는 모수가 커져야 드러난다. 왜 느릴까 ..

`@Transactional`로 묶었다고 동시성이 해결되는 건 아니다. 그건 원자성(A) 얘기지 격리성(I) 얘기가 아니다. 재고 5개짜리 상품에 10명이 동시에 주문을 넣는 상황을 따라가며 비관적 락, 낙관적 락, 그리고 "사실 읽을 필요도 없는" 원자적 UPDATE까지 저울질한 기록. 시작은 단순한 착각이었다주문 로직을 짜면서 처음엔 이렇게 생각했다."재고 차감이랑 주문 생성을 @Transacional 로 묶었으니, 동시에 주문이 들어와도 알아서 잘 처리하겠지 트랜잭션이 ACID 를 보장하니깐 동시성도 트랜잭션이 잘 막아줄 것이라고 막연히 믿었다.혼자 주문할 땐 이 믿음이 안깨진다.읽고 -> 확인하고 -> 줄이고 -> 커밋 읽기와 쓰기가 딱 붙어 있어서 문제가 생길 틈이 안보인다. 검증할 상황 자체..

멈춘 코드브랜드 도메인을 만들고 있었다. 요구사항은 단순했다"어드민이 브랜드를 등록할 때, 동일한 이름의 soft-deleted 행이 있으면 새 INSERT 대신 그 행을 복구(restore)하라."설계 문서는 이 로직을 BrandAdminFacade.create 에 두라고 했다. 그대로 옮기다가 손이 멈췄다. // BrandAdminFacade.create()fun create(name: String): BrandInfo { val existing = brandRepository.findByName(name) // ← 왜 Facade 가 이걸 알지? return when { existing == null -> save(BrandModel(name)) ex..

좋아요 등록·취소는 단순한 INSERT/DELETE 같지만, 멱등성을 제대로 보장하려면 다섯 개의 결정을 거친다. DB unique 제약과 hard delete 같은 결정들이 한 트랜잭션 안에서 도메인 정합성을 어떻게 만드는지 정리한다. 1. POST /products/{id}/likes 한 줄에서 시작좋아요는 처음 봤을 때 단순한 기능이었다. 명세상 엔드포인트는 세 개뿐이다. (user_id, product_id) 한 행을 INSERT 하거나 DELETE 하는 일이다.그런데도 설계 문서를 쓰는 동안 결정해야 했던 것이 다섯이었다.멱등성, 좋아요 수의 위치, soft delete 와 unique 의 충돌, BaseEntity 상속 여부, 그리고 그 모두를 묶는 hard delete 결단.이 글은 그 다..

루프팩 첫 주, 회원 도메인 세 가지를 TDD로 구현했다. 잘한 것보다 어색했던 게 더 많아서, 일단 기록부터 남긴다. TDD를 막 시작한 사람, 도메인 검증을 어디 둘지 고민하는 사람에게 참고가 될지도.(Red 실패하는 테스트 Green 최소 구현 Refactor 코드 정리 다음 사이클)이번 주에 한 일3개의 유스케이스를 TDD 사이클 한 바퀴씩 돌렸다.회원가입 POST /api/v1/users내 정보 조회 GET /api/v1/users/me (이름 마지막 글자 * 마스킹)비밀번호 수정 PATCH /api/v1/users/me/password각 기능은 test → feat → refactor 세 커밋으로 끊어서, 한 사이클이 어디서 끝나는지 git 그래프만 봐도 보이도록 했다. 가장 곱씹었던 결정 ..

Mock API를 우선 제공해야 하는 필요성에 대한 이해Mock API는 데이터베이스 연결이나 백엔드 처리 없이 정적 응답만 제공합니다. 테스트 및 개발용: 실제 API가 준비되지 않았거나 불완전하거나 불안정한 경우 사용 https://velog.io/@khy226/msw로-모의-서버-만들기 MSW(Mock Service Worker)로 더욱 생산적인 FE 개발하기MSW(Mock Service Worker)는 Service Worker를 이용해 서버를 향한 실제 네트워크 요청을 가로채서(intercept) 모의 응답 (Mocked response)를 보내주는 API Mocking 라이브러리이다.velog.iohttps://techblog.woowahan.com/20154/ API 모킹으로 테스트를 더 편..

10주간 항해를 마치고 부족한 부분을 다시 공부하고자 항해 그 후 스터디에 참여를 하여 스터디를 진행을 하였습니다.스터디를 진행을 하면서 개인적으로 공부를 했던것을 기록하려고 합니다. 해당 내용은 항해에서 배웠던 10주간 챕터들 중에서 항해하면서 부족하고 추가로 공부할 필요가 있는 것을 키워드 별로 공부를 진행 했습니다. 런던파와 고전파에 대한 이해와 본인의 견해 수립런턴파와 고전파의 가장 큰 차이는 테스트에서의 격리(isolation)를 어떻게 정의하고 구현하느냐이다.런던파런던파는 테스트 대상 코드가 다른 객체/클래스에 의존할 경우, 이 의존성을 모두 테스트 대역(test double) 으로 대체해야 한다고 본다.테스트 대역은 실제 객체 대신 사용하는 ‘단순화된 대체’ 객체로, 복잡성을 줄이고 테스트를..

프로그래머스에서 문제를 풀다가 다른 사람들의 풀이를 보면서 새롭게 알게 되어 알게 된 내용을 기록 해보려고 합니다. 우선 관련된 프로그래머스 문제는 짝수의 합 입니다. 이 문제는 반복문을 이용하면 간단하게 풀리는 문제였지만, IntStream.rangeClosed 을 이용하면 더 간단하게 작성 할수 있다는 것을 알게 되었습니다. IntStream.range vs rangeClosed ?IntStream.range 와 rangeClosed 은 둘다 주어진 범위 내에서 순차적으로 정수 스트림을 반환 합니다.차이점은 range 는 마지막 정수를 포함하지 않고, rangeClosed 는 마지막 정수를 포함합니다. import java.util.stream.IntStream;IntStream.range(0, 5)..