설계 판단
백엔드 의사결정 기준, 아키텍처 트레이드오프, 기술 선택 근거
-
[백엔드 운영] 풀을 키우기 전에 — 느린 SQL이 커넥션을 잡고 있을 때
active가 max에 붙었다고 풀이 작은 건 아니다. 각 커넥션이 어떤 SQL을 몇 ms째 잡고 있는지(held)부터 봐야 한다. items.order_id 인덱스 하나로 hold time을 줄여, 풀을 키우지…
-
[백엔드 운영] 긴 작업이 짧은 요청을 잡아먹을 때 — 풀 격리와 읽기/쓰기 분리
풀은 FIFO 큐다. 긴 작업 하나가 슬롯을 오래 잡으면 빠른 SELECT까지 줄 뒤에서 대기한다. short/long 풀 격리와 읽기/쓰기 분리를 Spring의 AbstractRoutingDataSource(마법)와 Go의 명시 호출로 비교한다.
-
[백엔드 운영] Hikari가 공짜로 해주던 것 — 커넥션 누수 추적을 직접 만들어 보다
커넥션을 빌리고 반납을 안 하면 풀은 조용히 고갈된다. HikariCP는 leakDetectionThreshold 한 줄로 누수를 stacktrace까지 잡아주지만, Go pgxpool엔 그 기능이 없어 직접 만들어야 한다. 같은 UX를…
-
[백엔드 운영] 커넥션을 얼마나 기다리고 얼마나 오래 살릴까 — timeout과 lifetime을 Hikari·pgxpool로 비교
풀이 비었을 때 얼마나 기다릴지(connectionTimeout vs ctx deadline)와 커넥션을 얼마나 오래 살릴지(maxLifetime). ‘실패를 빨리 만들수록 건강하다’는 fast-fail 원리와, DB가 먼저 끊은 죽은 커넥션을 풀이 빌려주는…
-
[백엔드 운영] 커넥션 풀이 막히는 순간을 숫자로 읽는 법 — Hikari와 pgxpool은 같은 고갈을 다르게 보여준다
active·idle·awaiting·total·max 다섯 숫자와 p50·p99로 풀의 상태를 읽는 법. 그리고 같은 풀 고갈을 HikariCP는 awaiting 게이지로, Go pgxpool은 누적 카운터로 보여주는 관측 패러다임 차이까지 — 두…
-
[설계 판단] 커넥션 풀 크기는 무엇으로 정하는가 — HikariCP·PostgreSQL 표준 공식과 Little’s Law
커넥션 풀은 클수록 좋다는 직관은 틀렸다. (코어×2)+디스크라는 PostgreSQL·HikariCP 표준 공식과 Little’s Law로 풀 크기를 정하는 기준, 왜 작은 풀이 더 빠른지, 그리고 Go의 database/sql로 Spring처럼…
-
JWT의 Fire and Forget 원칙 — 판단 기준과 설계 트레이드오프
JWT는 발급(Fire) 후 서버가 저장하지 않는다(Forget). 서명 검증만으로 신뢰를 판단하므로 DB 조회 없이 수평 확장이 가능하다. 단 무효화 불가라는 대가가 따른다. 언제 쓰고 언제 쓰지…
-
[WebRTC] 외부 TURN 서비스 vs self-host — 4축 의사결정
결론 먼저 — 4축 비교 축 외부 TURN 서비스 self-host (Coturn / Pion TURN) 시작 비용 0 (가입 즉시) VM/리전 설정 필요 변동 비용 분당…
-
[설계 판단] 미디어 평면과 비즈니스 평면을 두 서비스로 쪼갠 이유
결론 먼저 — 한 서비스 vs 두 서비스, 4축 비교 축 한 서비스 두 서비스 분리 장애 격리 한쪽이 죽으면 둘 다 격리됨 배포 주기…
-
[설계 판단] 1:1 AI 음성 상담을 위해 SFU를 ‘Dumb Pipe’로 둔 이유
결론 먼저 — 1:1 음성 상담의 미디어 토폴로지 비교 토폴로지 서버 CPU 대역폭 지연 구현 복잡도 1:1 상담 적합성 P2P (Mesh) 0 매우 낮음 최저…