후니-devStory

TL;DR: 기능보다 근거. 실패·복구까지 설계하고, 지표로 말하는 습관을 얻었다. 이제부터는 그 습관을 매일 쌓아 팀이 믿는 개발자로 간다.시작한 이유입사 1년. 회사 일이 바쁘다는 이유로 공부를 미뤘다. 학부 시절엔 설계와 아키텍처 얘기를 좋아했는데, 어느새 출퇴근 루틴에 익숙해진 내 모습이 보였다. 변화가 필요했다. 내 돈과 시간을 들여 선택한 과정이라 솔직히 무서웠다. 후회할까 봐. 결론은 후회 없음이다. 팀원들과 부딪히며 매일 “왜 이렇게 설계해야 하는가”를 다시 묻게 됐다. 의지가 돌아왔고, 재미도 돌아왔다.10주 동안 얻은 것기능보다 근거. 책임 경계와 실패·복구 시나리오를 먼저 적는다.운영을 버티는 기본기. 멱등성, 락 전략, 읽기·쓰기 분리, 재시도·서킷 브레이커를 실제 코드로 체득.체감..

WIL (2025-09-08 ~ 2025-09-14)Redis 자료구조 집중 요약 (Data Structures Only)이번 주는 자료구조 자체만 정리했다. 각 구조의 한 줄 설명, 언제 쓰는지, 핵심 명령과 복잡도, 주의점만 남겼다.0) TL;DRString / List / Set / Sorted Set(ZSET) / Hash / Stream / Bitmap·Bitfield / HyperLogLog / Geo기본 패턴만 알면 80%는 끝: 캐시(String), 큐(List), 중복 제거(Set), 랭킹(ZSET), 작은 객체(Hash), 이벤트 로그(Stream), 출석·플래그(Bitmap), 고유 수 추정(HLL), 반경 검색(Geo).1) 한눈 비교표 타입특징대표 시나리오핵심 명령삽입갱신/조회/범..

🔥 "랭킹 좀 만들어달라는데 Redis 메모리가..." - ZSET 랭킹 시스템 구축기TL;DR: "간단한 랭킹 좀 만들어주세요"라는 요청이 어떻게 다중 ZSET vs 단일 ZSET 설계 고민 → 가중치 실시간 변경 지옥 → 콜드 스타트 딜레마까지 이어졌는지. 실제 커밋 로그와 함께 보는 7일간의 현실.🚀 Day 1: 기존 구조에 한 줄만 추가하면 되겠네기획팀: "오늘의 인기상품 랭킹 보여주실 수 있나요?"나: "MetricsHandler에 랭킹 서비스 한 줄만 추가하면 될 것 같은데요?"프로젝트를 살펴보니 이미 완성된 이벤트 처리 구조가 있었다:// apps/commerce-streamer/src/main/java/com/loopers/handler/impl/MetricsHandler.java@Co..

TL;DR :주문 이벤트가 다인스턴스에서 동시에 전송되며 중복 결제가 발생했다. 설정(acks=all, idempotence=true)만으로는 애플리케이션 레벨 경합을 막을 수 없었다.나는 Outbox + DB 원자적 선점 + 동기 전송(.get())으로 "처음부터 안전"을 선택했다.토픽은 max.in.flight=5, Consumer는 별도 테이블 기반 멱등성, DLT는 Table 우선으로 운영했다.결과적으로 유실/중복/순서 문제를 "설계로 산" 뒤, 성능 최적화를 진행할 수 있었다. 그날, 같은 주문이 두 번 결제되었다 😨[ERROR] Duplicate payment detectedpaymentId: 92134, orderId: 55120, amount: 39000Original: 2024-03-0..