Node.js SaaS 백엔드가 분당 10,000 요청 규모에서 실패하는 3가지 패턴과 각각을 해결하는 구체적 기술 스택

Context

Node.js 백엔드는 1,000명 활성 사용자까지는 안정적이지만 3,000~5,000명 구간에서 Stripe 웹훅 재시도, 배경 작업 누적, 중복 청금 티켓이 발생한다. 8,000~10,000 분당 요청(RPM) 규모에서는 배포 시 작업 손실, 웹훅 중복으로 인한 이중 청금, MFA 상태 불일치로 인한 사용자 잠금 같은 심각한 장애가 발생한다.

Technical Solution

• 배경 작업 손실 방지: setTimeout이나 메모리 배열 대신 Redis, RabbitMQ, 또는 PostgreSQL SKIP LOCKED를 사용하는 지속성 큐(Persistent Queue) 도입. 작업 실행 전 데이터베이스에 저장하고 원자적 락(Atomic Lock)으로 첫 번째 워커만 작업을 획득하게 구현
• Stripe 웹훅 중복 제거: 웹훅 핸들러를 멱등성(Idempotency) 가드로 감싸기. (stripe_event_id, event_type) 조합에 유니크 제약을 추가하거나 처리 완료 플래그를 원자적으로 확인
• MFA 상태 드리프트 방지: JWT 토큰을 상태 저장소 없이 사용하되, 민감한 작업(예: POST /api/billing/change-email)마다 API 레벨에서 MFA를 강제 검증. UI 플래그만으로는 불충분
• 크래시 복구 메커니즘: 작업이 실행 시작 전에 데이터베이스에 저장되고 성공 후 완료 표시. 워커 크래시 시 다른 워커가 지수 백오프로 재획득
• 스트레스 테스트 자동화: autocannon 또는 hey로 HTTP 부하 생성, Stripe CLI로 동일한 웹훅 50개 동시 발생, 프로세스 강제 종료(kill -9)로 복구 검증

Impact

KeelStack 스트레스 테스트에서 초당 100개의 동일한 Stripe 웹훅 발생 시 1% 미만의 에러율과 0건의 중복 거래 달성. 오류율, 작업 손실 수, 중복 거래 수가 모두 0으로 측정.

Key Takeaway

SaaS 백엔드는 높은 트래픽보다 동시성으로 인한 경합 조건(Race Condition)과 장애 시나리오(Crash)에서 실패한다. 지속성 큐, 멱등성 검증, 상태 비저장 인증, 원자적 작업 청구 같은 패턴을 사전에 구현하면 3배 트래픽 피크까지 예측 가능한 장애 없이 운영 가능하다.