Final Project: Ticket Booking Platform

Làm Ticket Booking Platform: hệ thống đặt vé sự kiện, Java/Spring Boot, microservices. Đây không phải tutorial CRUD. Đây là bài thi cuối: bạn tự code, AI chỉ ra đề, review và phỏng vấn.

1. Vì sao chọn đặt vé?

Vì bài toán này chạm gần như mọi chương đã học:

• Hai người cùng giữ một ghế → concurrency, lock, transaction.
• Giữ ghế 10 phút rồi hết hạn → state machine, scheduled job.
• Thanh toán có thể timeout, trả UNKNOWN → idempotency, reconciliation.
• Booking → Payment → Notification qua nhiều service → Saga, Outbox, Kafka, RabbitMQ.
• Flash sale 100k người vào cùng lúc → rate limit, Redis, queue.

Nó chính là bài Ticket booking và Flash sale của chương System Design, ghép với chương Distributed. Lần này bạn code thật, làm hỏng thật, đo thật.

2. Nguyên tắc

• Không frontend. Kiểm tra bằng REST, Postman collection, integration test, load test.
• Không lặp lý thuyết. Mỗi milestone chỉ link về bài đã học. Quên thì quay lại đọc.
• Mỗi milestone đi đủ 7 bước:

problem → design → implementation → failure simulation
        → benchmark → trade-offs → interview review

Mỗi milestone sẽ có: đề bài, acceptance criteria, test cases, failure scenarios, checklist.

3. Kiến trúc

                 Postman / k6 / integration test
                              │
                    ┌─────────▼─────────┐      ┌──────────┐
                    │  gateway          │─────▶│ Keycloak │ (JWT)
                    │  SC Gateway       │      └──────────┘
                    │  JWT + rate limit │── Redis
                    └──┬──────────┬─────┘
                       │          │
              ┌────────▼───┐  ┌───▼────────┐   REST    ┌──────────────┐
              │ catalog    │  │ booking    │──────────▶│ payment      │
              │ events,    │  │ hold seat, │◀─ webhook │ mock PSP +   │
              │ seats,cache│  │ confirm,   │           │ fault inject │
              └──┬─────┬───┘  │ saga       │           └──────┬───────┘
                 │     │      └──┬─────┬───┘                  │
             Postgres Redis   Postgres │ outbox ─▶ Kafka ◀─────┘
                                       │
                                  ┌────▼──────────┐
                                  │ notification  │◀── RabbitMQ
                                  │ consumer, DLQ │   (quorum queue)
                                  └───────────────┘

  Toxiproxy chen giữa các kết nối để giả lập lỗi mạng.
  Prometheus + Grafana + OTel quan sát toàn bộ.

Hạ tầng (docker-compose): Postgres, Redis, Kafka, RabbitMQ, Keycloak, Toxiproxy, Prometheus, Grafana. Test: JUnit 5, Testcontainers, k6.

4. 12 milestone

5. Cấu trúc repo gợi ý

ticket-booking/
├── docker-compose.yml          # Postgres, Redis, Kafka, RabbitMQ, Keycloak,
│                               # Toxiproxy, Prometheus, Grafana
├── .env.example                # biến môi trường, không commit secret
├── gateway/
├── catalog-service/
├── booking-service/
├── payment-service/            # mock PSP + fault injection API
├── notification-service/
├── common/                     # event schema, error model (giữ nhỏ)
├── tests/
│   ├── postman/                # collection theo milestone
│   └── k6/                     # load test script
├── infra/
│   ├── keycloak/realm.json
│   ├── grafana/dashboards/
│   └── helm/
└── docs/
    ├── requirements.md         # M0
    ├── adr/                    # mỗi quyết định = 1 ADR
    ├── benchmarks/             # số liệu M1, M7, M9
    └── postmortems/            # M12

6. Thang chấm (3 mức)

7. Definition of Done (mỗi milestone)

• Acceptance criteria đều có test tự động và xanh.
• Mọi failure scenario đã chạy thật (Toxiproxy, kill container), có ghi kết quả.
• Benchmark (nếu có) lưu trong docs/benchmarks/.
• Có ít nhất 1 ADR cho quyết định quan trọng.
• Không hardcode password, config qua ${ENV}.
• Đã qua lượt review và lượt phỏng vấn của AI.

Mỗi milestone có trang chi tiết riêng: bắt đầu từ M0, hoặc chọn trong mục lục bên trái.

Đúng là nhiều. Nhưng không cần làm theo số thứ tự cứng. Có một trục bắt buộc, phần còn lại là nhánh.

M0 ─▶ M1 ─▶ M2 ─▶ M3 ─▶ M4 ─▶ M5        (trục lõi: dữ liệu đúng)
                              │
            ┌─────────────────┼──────────────┐
            ▼                 ▼              ▼
           M6                M7             M10
       (notification)   (flash sale)   (security/obs)
                              │
                         M8 ─▶ M9            (hiệu năng)
                              │
                             M11 ─▶ M12      (HA + thi cuối)

• M0–M5 phải theo thứ tự. Ghế chưa đúng (M1) thì saga (M5) vô nghĩa.
• M10 làm sớm nếu được: có trace và dashboard thì debug M5–M7 dễ hơn nhiều.
• M8, M9 là bài đo đạc: làm khi hệ thống đã chạy ổn.
• M11, M12 luôn ở cuối.

Mẹo: mỗi milestone là một branch + một PR. Học buổi tối thì ước lượng 1–2 tuần/milestone.

Bạn nắm đúng điểm quan trọng: nếu AI viết code thì project không còn kiểm tra được bạn. AI chỉ đóng 3 vai:

Vòng lặp mỗi milestone:

AI ra đề ─▶ bạn design (ADR) ─▶ AI review design
   ─▶ bạn code + test ─▶ AI review PR ─▶ bạn chạy failure + benchmark
   ─▶ AI phỏng vấn ─▶ chưa đạt? quay lại bước cần sửa

Cách làm việc với agent xem lại bài Làm việc với AI agent. Quy tắc đơn giản: kẹt quá 2 giờ thì xin gợi ý, không xin lời giải.

Gần đủ, chỉ cần chỉnh một điểm: nhà tuyển dụng không chấm project chạy được, họ chấm bạn kể lại được quyết định. Hãy chuẩn bị:

• Một sơ đồ kiến trúc vẽ lại được trong 3 phút.
• Ba câu chuyện sự cố: oversell ở M1, UNKNOWN ở M3, mất event ở M5. Mỗi câu: triệu chứng → nguyên nhân → cách sửa → số liệu.
• Một bảng benchmark mà bạn hiểu từng con số.

Sau đó luyện thêm với Top 100 câu hỏi.