본문 바로가기

Study for./Architecture3

매주 한 편씩 쓰다 보니 10주가 지나 있었습니다 TL;DR — 10주 동안 매주 한 편씩 블로그를 썼습니다. 토요일 저녁마다 "정상이 어디에요?" 라고 스스로에게 물었고, 돌아오는 답은 언제나 "아 5분만 더 가면 돼" 였습니다. 그 5분이 열 번 쌓여 10주가 되었고, 저는 끝내 포기하지 않았습니다. 이 글은 그 열두 편의 흔적이 만든 열한 번째 저를 돌아보는 총괄 회고이자, 마지막 라운드(Spring Batch + Materialized View + 기간별 Ranking API) 에서 내린 결정을 기록한 인덱스입니다.프롤로그 — 글을 쓰기 시작한 2주차의 저처음부터 매주 블로그를 쓸 생각은 아니었습니다. 1주차에는 Ktlint·EditorConfig·Git Hook 같은 도구를 세팅하고, 팀 동료의 질문 ("Kotlin 에 ESLint 같은 거 있.. 2026. 4. 17.
주문 대기열 시스템 설계: Redis Sorted Set의 내부 구조가 실시간 순번 조회를 가능하게 하는 원리 TL;DR — 트래픽 폭증 시 하류 시스템을 보호하면서 유저에게 공정한 순서를 보장하기 위해 Redis Sorted Set 기반의 주문 대기열을 구현했다. 처음에는 "Redis가 빠르니까"라는 이유만으로 충분하다고 생각했지만, 순번 조회(ZRANK)가 왜 O(log N)인지를 제대로 설명하지 못하는 자신을 발견했다. 그래서 Sorted Set의 내부 구현체인 스킵 리스트(Skip List)와 스팬(Span) 메커니즘까지 파고들었고, 그 과정에서 얻은 이해를 이 글에 정리한다. 1. 트래픽 제어의 필요성: Back-pressure 평소 초당 100건이던 주문 요청이 블랙 프라이데이 시작 직후 초당 10,000건으로 폭증하는 상황을 가정해 보았다. 이 트래픽이 주문 API로 직접 유입되면 어떤 일이 벌어질.. 2026. 4. 3.
뽀빠이 식당으로 보는 트래픽 몰림, Retry, 그리고 Idempotency 한 줄 요약같은 순간에 요청이 몰리면 시스템은 생각보다 쉽게 흔들릴 수 있습니다. 그래서 Exponential Backoff + Jitter, Token Bucket 같은 장치로 몰림을 나누어 보고, 결제처럼 상태를 바꾸는 요청에서는 Retry만 붙이기보다 Idempotency와 State를 함께 설계해야 한다고 생각합니다. 먼저 뽀빠이 식당 장면으로 Thundering Herd, Exponential Backoff + Jitter, Token Bucket을 가볍게 풀어 보고요. 그다음 결제 처리 예시를 보면서 Retry, Idempotency, Timeout, State가 왜 같이 묶여야 하는지 천천히 이어서 보려고 합니다. 사실 뽀빠이를 본적이 없습니다, 그저 그림이 귀여워서 예시로 삼아봤습니다왜 .. 2026. 3. 20.