Tag: Backend
이 태그가 달린 글들 "Backend"
-
브라우저 worker는 CPU worker도 I/O worker도 아니었다 — 작업 시간의 꼬리가 만든 용량 경계
browser worker의 병목은 CPU나 네트워크 하나로 설명되지 않았습니다. 계정별 session lock의 force-release가 60일 동안 1,129회 기록된 운영 신호를 출발점으로, browser process·page·proxy·외부 응답의 긴 꼬리가 queue 적체로 이어지는 경로와 용량 판단 기준을 정리합니다.
-
세션을 잃지 않으려면 요청을 어디로 보내야 하는가 — affinity와 계정 단위 직렬화
브라우저 세션은 인스턴스의 메모리에 있고, 같은 계정의 로그인·조회·댓글 등록은 서로 영향을 줍니다. Redis affinity로 기존 세션이 있는 인스턴스로 요청을 보내고, REST·메시징·관리 경로를 계정 단위 lock으로 직렬화하며, 소유 인스턴스 장애 때 health check 기반으로 새 세션을 수립하도록 바꾼 과정을 정리합니다.
-
큐가 가득 찼을 때 작업을 잃지 않으려면 — 6,397건 거절에서 배운 backpressure
브라우저 작업이 포화된 실제 운영 구간에서 3일간 6,397건의 publish가 queue-full로 거절됐습니다. bounded queue·publisher confirm·재예약·stale recovery로 수용 불가를 유실이 아닌 추적 가능한 상태 전이로 바꾼 과정을 정리합니다.
-
[JPA + Spring Mastery 09] 어디서 무엇을 쓸까 — JPA / JPQL / Native SQL 결정 트리, 측정값 4종으로 갈리는 컷
8 편을 거치며 PersistenceContext / Dirty Checking / Optimistic Lock / N+1 / IDENTITY / self-invocation / Saga·Outbox 를 측정값으로 풀었습니다. 이 마무리편은 그 모든 evidence 를 한 결정 트리 위에 올려놓습니다 — 도메인 단위인지 데이터 단위인지의 첫 갈림길로 시작해, JPA Dirty Checking 이 빛나는 곳 5 가지와 적자인 곳 5 가지, JPQL 의 중간 자리, Native / JdbcTemplate / MyBatis 의 자리를 4 측정값 (Dirty Checking 132× / saveAll IDENTITY ~1000× / OFFSET 1M 570× / bulk JPQL vs Dirty Checking 84×) 으로 컷하고, Eric Evans Aggregate (DDD 2003), Fowler PoEAA Identity Map / Unit of Work (2002), Greg Young CQRS Documents (2010), Vlad Mihalcea High-Performance Java Persistence (2016) 의 학술 anchor 와 카카오페이 readOnly QPS 58% 회고로 묶었습니다. 면접에서 'JPA 어떻게 다뤄봤어요?' 에 URL 한 줄로 답하기 위한 entry point 입니다.