고민보단 실천을

배포 전략 비교: Rolling vs Blue-Green vs Canary, 언제 무엇을 선택할까배포 전략은 예쁜 그림이 아니라 장애 반경과 롤백 속도를 결정한다.한 줄 요약Rolling: 기본값. 혼종 상태가 생겨 검증이 어렵다.Blue-Green: 스위치 기반. 롤백이 빠르지만 비용이 든다.Canary: 일부 트래픽만 새 버전. 관측/판단 체계가 필요하다.Kubernetes Deployment(rollingUpdate) 예시spec: strategy: type: RollingUpdate rollingUpdate: maxSurge: 25% maxUnavailable: 0배포 판단 지표 예시에러율: 5xx 비율, 핵심 API 실패율지연: p95/p99, 타임아웃 비율비즈니스..

DB 데드락 실전: 원인(락 순서) 분석과 재시도/쿼리/인덱스로 줄이는 법데드락은 대부분 락 획득 순서가 서로 다르기 때문에 생긴다. 원인 분석과 예방/완화(재시도) 전략을 정리한다.전형적인 예시-- Tx ABEGIN;UPDATE accounts SET balance = balance - 100 WHERE id = 1;UPDATE accounts SET balance = balance + 100 WHERE id = 2;COMMIT;-- Tx B (순서 반대)BEGIN;UPDATE accounts SET balance = balance - 50 WHERE id = 2;UPDATE accounts SET balance = balance + 50 WHERE id = 1;COMMIT;데드락을 줄이는 3가지 큰 ..

CORS 프리플라이트 최적화: 왜 OPTIONS가 폭주하고 어떻게 줄이나CORS는 허용/차단만의 문제가 아니다. 운영에서는 OPTIONS 프리플라이트가 트래픽을 잡아먹는 경우가 있다. 발생 조건과 줄이는 방법을 정리한다.프리플라이트 발생 조건(요약)simple request가 아니다(커스텀 헤더, 특정 Content-Type 등).Authorization 헤더 사용.PUT/DELETE 같은 메서드.Access-Control-Max-Age로 캐시Access-Control-Allow-Origin: https://app.example.comAccess-Control-Allow-Methods: GET,POST,PUT,DELETE,OPTIONSAccess-Control-Allow-Headers: Content-T..

API Pagination 실전: Offset vs Cursor, 정렬 안정성으로 중복/누락 방지하기페이지네이션은 구현이 쉬워 보여도, 데이터가 계속 변하는 서비스에서는 중복/누락과 성능 문제로 바로 운영 이슈가 된다.Offset과 Cursor(Seek) 방식의 차이를 비교하고, 정렬 안정성과 커서 설계까지 포함해 바로 적용 가능한 형태로 정리한다.Offset이 쉬운 만큼 위험한 이유OFFSET이 커질수록 앞쪽 행을 더 많이 스캔/버린다.데이터 삽입/삭제가 동시에 일어나면 페이지 사이에 중복/누락이 생긴다.정렬 키가 유일하지 않으면 결과가 흔들린다(createdAt만 정렬 등).Cursor(Seek) 페이지네이션 기본 쿼리실무에서는 (createdAt, id)처럼 유일해지는 조합을 정렬 키로 만든다.--..