Skip to content

VideoDemoScript.md

Latest commit

 

History

History
99 lines (81 loc) · 6.79 KB

VideoDemoScript.md

File metadata and controls

99 lines (81 loc) · 6.79 KB
Raw

Kịch bản Demo Video: Hệ thống TicketBox (Kèm hướng dẫn chạy chi tiết)

Tài liệu này là kịch bản demo môn học, bao gồm các Functional Requirements (FR) và đặc biệt là hướng dẫn cấu hình/chạy lệnh chi tiết cho các Non-Functional Requirements (NFR). Đã được tối ưu để tận dụng thư mục k6-testing có sẵn của nhóm.

Phần 1: Giới thiệu chung (1 phút)

  • Mục tiêu: Giới thiệu ngắn gọn TicketBox là hệ thống bán vé sự kiện chịu tải cao.
  • Điểm nhấn: Giải quyết bài toán tải đột biến (Rate Limiting), tranh chấp vé (Concurrency), an toàn thanh toán (Circuit Breaker & Idempotency).
  • Các Actor chính (RBAC): Khán giả, Ban tổ chức, Nhân viên soát vé.

Phần 2: Demo Chức năng Nghiệp vụ - Functional Requirements (FR) (3-4 phút)

2.1. Phân hệ Khán giả (Trải nghiệm mua vé)

  • Hành động:
    1. Mở trình duyệt, vào trang chủ, chọn 1 sự kiện.
    2. Bấm xem sơ đồ ghế (hiển thị sơ đồ SVG trực quan).
    3. Đặt vé: Cố tình chọn số lượng vé lớn hơn mức giới hạn cho phép (VD: 5 vé).
    4. Hệ thống báo lỗi: "Vượt quá giới hạn vé cho phép".
    5. Sửa lại số lượng đúng và nhấn Mua vé.

2.2. Thanh toán & E-ticket

  • Hành động:
    1. Redirect sang trang VNPAY (môi trường Sandbox).
    2. Nhập thẻ test VNPAY (9704198526191432198 / NGUYEN VAN A / 07/15 / OTP: 123456).
    3. Thanh toán thành công -> Chuyển về trang kết quả TicketBox.
    4. Mở tab Thông báo / Vé của tôi để show mã QR E-ticket vừa sinh ra.

2.3. Phân hệ Quản trị (Admin)

  • Hành động:
    1. Đăng nhập tài khoản Organizer.
    2. Mở Dashboard xem biểu đồ doanh thu theo thời gian thực (nhấn mạnh số liệu vừa nhảy do đơn hàng trên).
    3. Chuyển sang tính năng AI Artist Bio: Upload 1 file PDF giới thiệu nghệ sĩ và show kết quả text AI đã tóm tắt tự động.

2.4. Phân hệ Soát vé (Mobile Offline Sync)

  • Hành động:
    1. Mở ứng dụng Mobile (Flutter hoặc máy ảo giả lập).
    2. Quét QR code vé vừa mua -> Màn hình xanh báo Hợp lệ.
    3. Tắt kết nối mạng (Wifi/Data) trên thiết bị di động.
    4. Quét mã QR của 1 vé thứ 2 -> Báo Hợp lệ (Chế độ Offline).
    5. Bật lại mạng -> Ứng dụng tự động đẩy data lên server (show log "Sync completed" hoặc check DB trên server).

Phần 3: Demo Điểm nhấn Kỹ thuật - NFR (Cực kỳ quan trọng) (3-4 phút)

Ghi chú quay video: Nhóm hãy mở sẵn Terminal / VSCode và bật HTML Report của k6 để video nhìn chuyên nghiệp nhất.

3.1. Concurrency Control & Rate Limiting (Chống tải đột biến 80k User & Không Oversell)

  • Mục tiêu: Chứng minh khi 80,000 người dùng đâm vào hệ thống cùng lúc (Spike load), hệ thống không sập, chặn chính xác các request dư thừa (Rate Limit), xếp hàng bằng Queue, và đảm bảo tuyệt đối không bán lố vé (0 oversell).
  • Thực thi:
    1. Đảm bảo API, Worker, Redis, Postgres đang chạy. Seed data trước bằng npx nx run worker:seed.
    2. Mở Terminal, di chuyển vào folder K6: 
      cd src/ticketbox/k6-testing
# Chạy bài test mô phỏng 80k VUs (spike)
k6 run stress-test-80k.js --summary-export=stress-results.json
    3. Mở file HTML Report để show biểu đồ.
    4. Giải thích trên Video (vừa nói vừa chỉ vào biểu đồ):
      • "Báo cáo cho thấy ở kịch bản 80,000 người dùng truy cập, chỉ những người vào sớm được đẩy vào BullMQ Queue xử lý, hệ thống đã chặn thành công hàng nghìn request rác bằng Redis Throttler (báo lỗi 429 Rate Limited)."
    5. Tiếp tục chạy script kiểm tra tính toàn vẹn (Zero-Oversell): 
      k6 run anti-oversell-verify.js
      • Show kết quả in ra: "Số lượng vé bán ra chính xác bằng số vé tổng cộng, oversell_detected = 0. Database được bảo vệ bằng Optimistic Locking."

3.2. Idempotency (Chống trừ tiền hai lần)

  • Mục tiêu: Mô phỏng tình huống mạng rớt, client gửi lại (retry) request thanh toán liên tục 10 lần. Hệ thống chỉ xử lý giao dịch 1 lần và trả về kết quả đã lưu cache cho 9 lần retry sau.
  • Thực thi:
    1. Cùng ở trong folder src/ticketbox/k6-testing.
    2. Chạy k6 test tự động hoàn toàn (không cần nhập token): 
      k6 run idempotency-test.js
    3. Kết quả: K6 sẽ tự động mua 1 vé, lấy token, sau đó bắn 10 request thanh toán liên tục bằng cùng 1 Idempotency-Key.
    4. Giải thích (chỉ vào log in ra): "Nhìn vào log, Request đầu tiên tạo Payment mới (Success). 9 Request tiếp theo bị hệ thống nhận diện là trùng Idempotency-Key, nên thay vì xử lý lại, hệ thống trả về đúng kết quả thanh toán của lần 1 (Idempotency Replay). Nhờ vậy, khách hàng có bấm đúp bao nhiêu lần cũng không bao giờ bị charge tiền hai lần."

3.3. Circuit Breaker & Graceful Degradation (Kháng lỗi Thanh toán)

  • Mục tiêu: Chứng minh khi cổng VNPAY lỗi liên tục, hệ thống sẽ ngắt mạch (Circuit Open) để tự bảo vệ.
  • Thực thi:
    1. Vào file .env ở backend api, cố tình đổi sai URL của VNPAY: VNP_URL=http://localhost:9999/timeout
    2. Mở Postman, gửi request POST /payments liên tục 4 lần:
      • Lần 1: API chạy lâu rồi báo lỗi.
      • Lần 2: Tương tự.
      • Lần 3: Tương tự.
      • Lần 4: Bấm gửi, API trả về ngay lập tức với status 503 Service Unavailable và message PAYMENT_GATEWAY_UNAVAILABLE.
    3. Giải thích: "Sau 3 lần gọi VNPAY thất bại, Circuit Breaker đã MỞ. Hệ thống từ chối các request tiếp theo ngay lập tức để tiết kiệm tài nguyên (CPU/RAM). Các chức năng khác như xem sự kiện, quét vé vẫn hoạt động bình thường (Graceful Degradation)."

Phần 4: Tổng kết (30 giây)

  • Hệ thống đã cover toàn bộ workflow vòng đời sự kiện (Tạo sự kiện -> Mua vé -> Thanh toán -> Soát vé ngoại tuyến).
  • Kiến trúc đủ vững vàng để đối mặt với môi trường thực tế: Rớt mạng ở sân vận động (Offline Sync), VNPAY sập (Circuit Breaker), Tranh mua vé lượt truy cập cao (BullMQ Queue + Rate Limiting).

Chúc nhóm trình bày tự tin và đạt điểm tối đa!