개발.. 한놈만 팬다

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 를 보장하니깐 동시성도 트랜잭션이 잘 막아줄 것이라고 막연히 믿었다.혼자 주문할 땐 이 믿음이 안깨진다.읽고 -> 확인하고 -> 줄이고 -> 커밋 읽기와 쓰기가 딱 붙어 있어서 문제가 생길 틈이 안보인다. 검증할 상황 자체..

강의 목록 API 하나를 "추측 대신 측정"으로 파고들어캐싱 → 구조 개선 → 메모리까지 잡은 기록.Stack: Node.js · TypeScript · TypeORM(MySQL) · Redis · Vitest 한눈에 보기지표BeforeAfter변화응답 시간(대형 케이스)9.5 s0.27 s🟢 −97%외부 인기도 API7,000 ms20 ms (캐시 히트)🟢 −99.7%요청당 객체 메모리3,560 KB53 KB🟢 −98.5%조립 객체 수1,652개20개🟢 −98.8%응답 20건을 주는 API가 매번 1,652건을 다 만들고 있었다. → 20건만 만들도록 바꾼 이야기. 개선 여정 (요약) 1. 측정부터 — 구간별 타이밍const mark = (label) => { marks[label] = now..

멈춘 코드브랜드 도메인을 만들고 있었다. 요구사항은 단순했다"어드민이 브랜드를 등록할 때, 동일한 이름의 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..

언젠가 만들고 싶다고 생각만 하던 도구가 있었다.회사에서 반복적으로 마주치는 불편함을 해결할 화면이 있으면 좋겠다고 자주 생각했지만, 막상 시작하려고 하면 데이터, 기준, 화면 구성이 한꺼번에 떠올라 쉽게 손이 가지 않았다. 이번에는 달랐다.AI가 있어서 시작할 수 있었다. 문제의식과 업무 맥락을 설명하면 AI가 기능을 나누고 구현 순서를 잡는 데 도움을 줬다.그렇게 머릿속에만 있던 내부 도구를 움직이는 웹앱으로 만들 수 있었다.그 결과물이 Observatory다. 아래 앱 화면 캡처는 외부 공개를 위해 실제 수치, 개인 식별 정보, 랭킹/테이블 데이터 영역을 블러 처리했다.왜 만들었나우리 회사는 교육 콘텐츠를 다루고 있고, 수강생의 시청 기록은 여러 시스템에 쌓인다.운영성 데이터는 RDB에, 날짜별..

좋아요 등록·취소는 단순한 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 모킹으로 테스트를 더 편..