블로그 지도: 어디부터 읽으면 좋은가
글이 열여덟 편이라 낱개로 읽으면 흐름이 안 잡힌다. 실무에서 겪은 문제와 학습으로 판 주제를 시리즈로 묶고, 시간이 없을 때 볼 대표 글 세 편을 추린 안내.
글이 열여덟 편이라 낱개로 읽으면 흐름이 안 잡힌다. 실무에서 겪은 문제와 학습으로 판 주제를 시리즈로 묶고, 시간이 없을 때 볼 대표 글 세 편을 추린 안내.
티켓팅 대기열을 다중화하자 slot 5짜리 입장에 15명이 들어왔다. 원인은 3대가 각자 admit을 돌린 것. SET NX 리더 선출로 한 주기에 한 대만 입장시키게 만들고, activeCount ≤ slot 불변식으로 검증한 과정.
직접 만든 Redis(MyRedis)에 대기열을 얹었더니 순번 조회가 느려졌다. 원인은 heap의 ZRANK가 O(N)이라는 것. Redis가 왜 skip list와 span을 쓰는지, 그리고 도구는 워크로드가 정한다는 이야기.
격리 수준을 4개 이름으로 외우는 대신 무슨 이상 현상을 막느냐로 이해한다. 표준 표가 실제 MySQL·PostgreSQL과 어떻게 다른지, 그리고 격리 수준이 못 막는 Lost Update를 앱에서 어떻게 잡는지.
캐시는 붙이면 빨라지는 옵션이 아니라 정합성을 내주고 속도를 사는 거래다. 동작 원리부터 읽기/쓰기 전략, 눈사태·스탬피드 같은 장애 패턴, 캐시가 독이 되는 데이터까지 정리했다.
토이 프로젝트로 대규모 트래픽을 시뮬레이션하는 걸 공부 중인데, 거기서 CQRS를 한번 구현해봤다.
메시지 큐가 필요한 이유, 카프카의 Topic/Partition/Offset, length-prefix framing, sparse mmap index, zero-copy, Outbox 패턴들을 Kotlin/Netty로 직접 짠 MyKafka MVP 코드를 reference로 풀어 정리했다.
동기 호출의 한계, EDA의 세 조건, Spring @EventListener, Kafka·RabbitMQ 구분, 멱등성, 코레오그래피 vs 오케스트레이션, 결과적 일관성, 실전 함정까지 한 번에 정리했다.
이벤트 루프라는 게 뭔지 막연하게 알고 있었지만 설명하기는 어려워 정리해보았다.
TESTER 계정으로 ?isMaster=true 한 줄만 바꿔 전체 의료 데이터가 쏟아졌다. 백엔드가 클라이언트가 보낸 권한 플래그를 JWT 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가 대시보드에 테스트 케이스를 올리면 로컬 워커가 앱은 Maestro, 웹은 Playwright로 돌린다. 잡 큐 없이 DB 폴링으로 워커를 물린 설계 이유까지.
100억 건 히스토리 조회가 20초씩 걸리더니 로그인·수강신청까지 같이 멈췄다. 원인은 Full Scan이 DB 버퍼 풀을 통째로 밀어낸 것. 캐싱이 안 먹힌 이유와 생성시간 Range 파티셔닝으로 20초를 1초로 만든 과정.