SOOBIN LIM
→ 전체 프로젝트
01

D-ORDER

52,000명이 사용한 대학 축제 QR 주문 플랫폼

역할
Backend / Infrastructure / Production Operation / Incident Response
주요 기술
Django, Django REST Framework, Redis, PostgreSQL, AWS EC2, Linux, Nginx, Gunicorn, Daphne, WebSocket
저장소
Backend ↗
52K+
Real Users
~20K
동시접속 경험
3 min
Pending TTL
~30 min
Incident Recovery
D-ORDER 서비스 화면

Soobin's scope

직접 구현한 부분

Backend / Infrastructure / Production Operation / Incident Response

  1. 01주문 API와 상태 전이 로직, 테이블 단위 장바구니 및 쿠폰 정책을 구현
  2. 02AWS EC2 / Linux / Nginx / Gunicorn / Daphne 배포 환경과 WebSocket 운영 구성
  3. 03Cart API 구현 — 장바구니 상품 추가, 조회, 수량 변경, 상품 삭제
  4. 04결제 직전 Pending 주문 생성 및 TTL 적용, 주문 취소와 주문 확정 처리
  5. 05Coupon 처리 및 FEE 처리

01 — 프로젝트 개요

어떤 서비스인가

축제 부스 테이블에 부착된 QR로 손님이 직접 메뉴를 주문하고, 부스 운영자는 실시간으로 주문을 확인하고 정산하는 서비스입니다.

행사 기간 5만 명 이상이 이용한 주문 트래픽을 운영했고, 최대 동시 접속 약 2만 규모를 처리했습니다.

축제 기간 동안 실제 사용자 트래픽을 받았고, 개발뿐 아니라 운영 환경 구성과 장애 대응까지 담당했습니다.

02 — 제품 흐름

직접 살펴보는 제품 사용 흐름

FIXTURE DEMO / 운영 API 미연결 · 세 화면이 하나의 상태를 공유합니다
D-ORDER
멋쟁이 사자처럼테이블 : 1

테이블 이용료

세트

메뉴

음료

사용자 흐름

  1. 01메뉴를 고르고 수량을 정해 장바구니에 담습니다
  2. 02쿠폰을 적용하고 주문하기를 누르면 입금 계좌가 안내됩니다
  3. 03송금 확인 요청을 보내면 서빙 스태프에게 결제확인요청이 전달됩니다
  4. 04결제가 확인되면 주문이 확정되고 주문내역에서 상태를 봅니다

Soobin's backend scope

  • 테이블 단위 장바구니 API와 첫 주문 테이블 이용료(FEE) 검증
  • 쿠폰 유효성 · 잔여 수량 검증과 결제 금액 반영
  • 장바구니 스냅샷을 table_usage 채널로 실시간 동기화

지금 해볼 것

서빙 스태프 화면 → 서빙 요청 탭에서 '수락' 후 '눌러서 서비스 완료'를 누르면 운영진과 손님 화면이 서빙완료로 바뀝니다.

03 — 기술 구조

구조와 데이터 흐름

Request Path

  1. ClientQR Web
  2. Nginx
  3. Gunicorn / Django REST API
  4. Redis재고 예약 / Pending TTL
  5. PostgreSQL

Realtime Path

  1. Client
  2. Daphne / WebSocket
  3. 주문 상태 동기화테이블 / 부스

SOOBIN'S SCOPE / 직접 구현하고 구성한 구간

테이블 이용료가 PERSON / TABLE / NONE 조건에 따라 달라지는 구조를 처리하고, 첫 주문 시 필수 FEE가 포함되어야 하는 비즈니스 로직을 검증했습니다.

결제 단계에서 장시간 재고가 묶이지 않도록 Pending 주문에 3분 TTL을 적용했습니다.

재고 예약 과정에서 충돌 상황이 발생했을 때 HTTP 409를 이용해 충돌 상태를 명확하게 처리했습니다.

WebSocket을 이용해 테이블별 장바구니와 부스 주문 상태를 실시간으로 동기화했습니다.

04 — 문제 해결

무엇이 어려웠나

Resolution

테이블 이용료가 PERSON / TABLE / NONE 조건에 따라 달라지는 구조를 처리하고, 첫 주문 시 필수 FEE가 포함되어야 하는 비즈니스 로직을 검증했습니다.

05 — 장애 대응

Incident Response

실제 축제 운영 중 대규모 트래픽과 봇 요청이 겹치며 서버 CPU 사용률이 80% 이상으로 상승했습니다.

  1. Normal OperationDetect

    축제 기간 정상 운영

  2. Traffic Spike & Abnormal RequestsDetect

    대규모 트래픽과 봇 요청으로 CPU 사용률 80% 이상 상승

  3. Server Log / Request Pattern AnalysisAnalyze

    서버 로그와 요청 패턴 분석

  4. Abnormal Requests IdentifiedAnalyze
  5. Request BlockingRespond

    특정 요청 차단

  6. Rate Limit 적용Respond
  7. Query OptimizationHarden
  8. Server MonitoringHarden

    서버 상태 모니터링

약 30분 안에 서비스를 안정화했습니다.

06 — 결과

결과와 성과

  • 축제 기간 동안 52,000명 이상의 실제 사용자가 사용
  • 약 20K 규모의 동시접속 경험
  • Cart & Coupon 영역과 테이블 단위 주문 로직 구현
  • 3분 TTL과 409 Conflict로 재고 예약 충돌 제어
  • 운영 중 문제 발생 후 약 30분 내 안정화

52,000명의 실제 사용자가 있는 환경에서 운영 중 문제를 직접 해결한 프로젝트입니다.