초당 수만 건의 트래픽이 몰리는 API 서버를 설계한다면, 어떤 아키텍처와 기술 요소를 고려하시겠습니까?

고트래픽 시스템에서 아키텍처 설계만큼 중요한 건 문제가 생겼을 때 빠르게 발견하고 원인을 찾을 수 있는 관측 가능성 구조를 함께 설계하는 것이라고 생각합니다. 요청별 응답 시간 분포, 에러율, 포화도 세 가지가 기본 모니터링 지표 세트입니다. 설계 측면에서는 서비스 간 호출에 고유한 트레이스 ID를 전파해, 요청이 어디서 지연되거나 실패했는지를 추적할 수 있는 구조를 초반부터 넣겠습니다. 나중에 붙이려면 코드 전반을 수정해야 하기 때문입니다.

리트라이 로직은 지수 백오프와 지터를 함께 적용합니다. 단순 즉시 재시도는 서버가 회복되는 순간 트래픽이 한꺼번에 쏟아져 다시 다운시키는 '재시도 폭풍'을 일으킬 수 있습니다. 성능 최적화는 프로파일링 없이 짐작으로 접근하면 실제 병목과 어긋나는 경우가 많아, 측정 → 병목 확인 → 수정 → 재측정 순서를 원칙으로 합니다. 소규모 서비스에서 DB 인덱스 추가 하나로 응답 시간이 크게 줄어든 경험이 있어, 가장 단순한 개선이 가장 큰 효과를 내는 지점을 먼저 찾는 습관이 생겼습니다.