트래픽 급증 시 DB 병목 해소
광고 시스템 유사 환경에서 DB 병목을 진단하고 캐싱으로 해결
사이드 프로젝트에서 이벤트성 트래픽이 몰릴 때 응답 지연이 심해지는 문제를 겪었습니다. 분석해보니 광고 노출 로그를 `DB`에 실시간으로 쓰는 구조가 병목이었습니다. 초당 수백 건의 쓰기가 동시에 들어오면 DB 락이 걸려서 읽기 요청도 함께 느려졌습니다.
Redis를 앞에 두고 로그를 버퍼링한 뒤 배치로 DB에 쓰는 방식으로 바꿨더니, 응답 시간이 3배 이상 개선됐습니다. 트래픽이 많은 시스템에서 쓰기와 읽기 경로를 분리하는 게 왜 중요한지를 직접 수치로 확인한 경험이었습니다. 아키텍처 결정 하나가 체감 성능에 바로 영향을 준다는 걸 그때 처음으로 실감했습니다.
이 결의 특징
사이드 프로젝트 이벤트 트래픽 병목(광고 로그 DB 실시간 쓰기→DB 락→읽기 지연)을 Redis 버퍼링으로 개선(응답 3배 향상) 측면을 수치로 명시했습니다. 아키텍처 결정의 체감 영향을 직접 관찰한 흔적이 있습니다.
이 결이 통하는 자리
DB 직렬화 지연을 비동기 처리로 전환할 수 있는 시니어 수준 설계를 초기 단계에서 구현한 지원자가 살아 있을 때 통합니다.