이건 부하 테스트 정리글 에서 측정했었던 테스트 결괏값이고, RPS 60부터 평균 응답시간과 p95 지연이 눈에 띄게 증가하기 시작하며 시스템이 포화 지점에 근접하고 있음을 보여준다. 이 구간은 단순한 트래픽 증가가 아니라, 내부 자원(DB, 커넥션 풀, 스레드 등)의 병목이 드러나기 시작하는 경계 구간으로 볼 수 있다.

레플리케이션 환경에서는 트랜잭션의 속성(ReadOnly 여부 등)에 따라 Master / Replica(DataSource)를 동적으로 선택해야 한다. 이를 위해 스프링에서는 동적 라우팅을 위한 AbstractRoutingDataSource를 제공한다. AbstractRoutingDataSource는 DataSource 인터페이스의 구현체로, 여러 DataSource를 하나로 묶고, 런타임에 실제 사용할 DataSource를 결정하는 역할을 한다.

말 그대로 하나의 큰 애플리케이션을 여러 개의 독립적인 모듈로 나눠 관리하는 구조로, 각 모듈은 도메인이나 계층 단위로 역할을 명확히 나누고, 필요한 부분만 서로 의존하도록 구성된다. 멀티모듈의 핵심은 모듈 간 의존성은 단방향을 유지하며, 상위 계층이 하위 계층을 의존하는 구조로, 하위 모듈은 상위 모듈의 구현이나 내부를 알지 못해야 한다.

Nginx 내부의 프로세스 동작 과정은 ‘페이지’로 첨부하였고, 여기에선 무중단 배포 전체 플로우와 Graceful Shutdown 도입 이유, 고트래픽 상황에서의 대응 방안들을 정리하였다.

서비스 내에서 채팅 발송, 브로드캐스트용, 특정 유저에게 아이템을 보낼 경우, 프로필 조회 등 다양한 이벤트 상황에서

Hibernate는 “이 user_id에 매핑된 FcmToken은 정확히 1개여야 한다”고 기대하지만, DB에서

이 경우 사용자에게는 즉시 “결제가 완료되었습니다” 또는 “실패했습니다”라고 안내할 수 없고,

이런 상태가 모호해지는 순간 중복 승인, 미확인 결제, 환불 불가 같은 치명적 사고로 이어진다.

특히 결제 승인과 같이 단일 트랜잭션이 외부 결제 서버와 DB 업데이트를 함께 수행하는 구간에서는, 멱등성만으로는

하지만, 데이터가 변경되는 POST과 PATCH의 경우 호출할 때마다 응답이 달라지기 때문에 멱등성을 보장하기 위해선 서버 단에서 구현이 필요하다.