캐싱 완벽 정리: 무엇을 캐싱하지 않을지부터 정한다
캐시가 왜 빠른가를 넘어, 왜 어렵고 무엇을 포기하는지까지. 지역성과 메모리 계층, Cache-Aside/Write-Through/Write-Back, eviction 정책, 관통·눈사태·스탬피드 같은 장애 패턴, 정합성 패턴, 그리고 '언제 캐싱하지 말아야 하는가'의 결정 감각까지 정리했다. 주니어와 함께 토론할 질문도 담았다.
캐시가 왜 빠른가를 넘어, 왜 어렵고 무엇을 포기하는지까지. 지역성과 메모리 계층, Cache-Aside/Write-Through/Write-Back, eviction 정책, 관통·눈사태·스탬피드 같은 장애 패턴, 정합성 패턴, 그리고 '언제 캐싱하지 말아야 하는가'의 결정 감각까지 정리했다. 주니어와 함께 토론할 질문도 담았다.
왜 JWT는 cookie vs localStorage 토론에서 의견이 갈리는가. Cookie의 자동 전송이라는 강점이 동시에 CSRF 취약점이 되는 메커니즘, SameSite·CSRF 토큰·Double Submit 방어법, 그리고 일렉트론 환경에서는 왜 cookie가 도리어 부적합한지까지 정리했다.
CQRS = '바꾸는 길과 보는 길을 갈라놓자'. read/write 분리의 본질부터 Stage 1(같은 DB) → Stage 2(Primary/Replica) → Stage 3(별도 DB + Kafka 동기화)까지 단계별 진화를 ticket-command/query 실제 구현으로 풀어 정리했다.
왜 메시지 큐가 필요한가부터 Topic/Partition/Offset, length-prefix framing, sparse mmap index, segment rolling, batch가 61배 빠른 이유, zero-copy, Outbox 패턴까지. Kotlin/Netty로 직접 짠 MyKafka MVP 코드를 reference로 풀어 정리했다.
선착순 티켓팅 시스템을 MSA로 설계하면서 내린 9개 결정을 '상황/옵션/선택/왜/트레이드오프' 5단으로 정리했다. MSA·CQRS·Bulkhead·Gateway·직접 인프라 구현·동시성 제어·진화 순서까지.
선착순 티켓팅 MSA 프로젝트를 주니어와 토론할 때 쓰는 질문 모음. MSA / CQRS / Kafka / 부하 테스트 / 메타 학습 / '만약 X면?' 시나리오 게임까지. 정답이 하나가 아닌, 트레이드오프 토론을 목적으로 한다.
콘서트 티켓팅을 MSA로 학습하기 위한 사이드 프로젝트 노트. 도착지 다이어그램, 핵심 패턴 7개, 1→5단계 진화 순서, 그리고 '동작하는 최소 → 측정 → 한계 → 진화' 메타 원칙까지 정리했다.
동기 호출의 한계, EDA의 세 조건, Spring @EventListener, Kafka·RabbitMQ 구분, 멱등성, 코레오그래피 vs 오케스트레이션, 결과적 일관성, 실전 함정까지 한 번에 정리했다.
C10K 문제부터 fd·epoll, libuv 스레드 풀, Node.js의 6페이즈, Redis·Nginx·가상 스레드 비교까지 — '이벤트 루프'라는 단어가 가리키는 게 뭔지 정리했다.
검사 카드 30+종을 EJS와 Svelte 양쪽에 따로 만들고 있었다. 한쪽 손보면 다른 쪽이 깨졌다. Puppeteer가 어드민 URL을 그대로 렌더링하게 만들어 단일 진실의 원천으로 통합한 과정.
QA 자동 테스트를 돌리다 발견한 권한 격상 취약점. 백엔드가 클라이언트에서 넘어온 isMaster 플래그를 JWT role과 교차검증 없이 그대로 신뢰하고 있었다. 발견부터 수정까지, 그리고 role 기반 권한을 다룰 때 챙겨야 할 것.
왜 풀이 필요한가부터 ThreadPoolExecutor 내부, BlockingQueue, HikariCP, 가상 쓰레드의 Continuation·Poller·ForkJoinPool, OS↔JVM 경계까지 동시성 처리의 전체 그림을 정리했다.
체감이 느린 API를 쿼리 탓이라 의심하고 EXPLAIN을 찍었는데 실행 시간이 0.5ms였다. 진짜 병목은 SQL 바깥, N+1과 직렬화와 중복 호출에 있었다. 밑단부터 보는 습관이 이번엔 DB가 범인이 아니라고 알려준 이야기.
비동기 처리에 큐가 왜 필요한지부터 SQS와 Kafka의 차이까지, 실무 관점에서 큐를 정리했다.
월 수백 건짜리 PR 처리 파이프라인에 두 개의 큐를 두려다, DB 한 테이블 + nullable 타임스탬프 + cron 폴링으로 대체한 결정 과정입니다.
환자+메타+결과를 한 API에서 다 주던 구조가 왜 무너졌는지. API 분리, No-Offset 페이징, 비동기 전환까지 실제 개선 과정.
가끔 회원권이 2개씩 생기는 버그, 왜 생겼고 왜 Redis Lock이었나. UNIQUE를 못 거는 공유 DB 환경에서 레이스 컨디션을 잡은 이야기.
인덱스를 바꾸면 된다는 건 알았는데, 어떻게 찾았고 왜 복합이어야 했는지. EXPLAIN 읽는 법부터 복합 인덱스 컬럼 순서, 그리고 인덱스로 한계가 와서 파티셔닝까지 간 과정.
단순 최적화가 아니라 구조 자체를 바꿔야 했던 이유. 왜 화면 캡처가 근본적으로 틀린 접근이었는지, 왜 SQS + 워커였는지.
팀원 2명이 개발도 QA도 해야 하는 상황에서 만든 자동화 시스템. 외주 QA가 대시보드에 YAML을 올리면 SQS를 거쳐 로컬 워커가 Maestro로 앱을 테스트한다. 왜 이 구조가 됐고, 아직 못 푼 문제는 뭔지.
10년 된 LMS의 히스토리 조회가 실서비스까지 느리게 만들고 있었다. 버퍼 풀 경합, 캐싱이 안 됐던 이유, 그리고 분석팀 등장까지 겹쳐서 DB를 분리한 과정.