M0 · Requirements, capacity, dựng hạ tầng

Đúng thứ tự. M0 không có logic đặt vé, nhưng mọi milestone sau đều đứng trên nó. Mình giao bài nhé.

1. Bối cảnh & bài toán

Ticket Booking bán vé concert. Bình thường vài chục request/giây. Lúc mở bán, hàng chục nghìn người vào cùng lúc. Nếu bỏ qua M0:

• Không có NFR → không biết "đủ nhanh" là bao nhiêu, benchmark M1/M7/M9 không có mốc so sánh.
• Không ước lượng QPS → chọn sai công cụ (ví dụ dùng DB lock cho 50k QPS ghi).
• Hạ tầng dựng tay, mỗi lần một kiểu → test không lặp lại được, failure scenario không chạy được.
• Secret nằm trong application.yml → lộ khi push GitHub.

M0 cần ra 3 thứ:
  docs/requirements.md   ─ FR, NFR, SLO, capacity
  docker-compose.yml     ─ 8 thành phần hạ tầng, có healthcheck
  5 service skeleton     ─ /actuator/health = UP

2. Ôn lại trước khi code

• Interview framework — đi từ requirements → estimate → design, không nhảy vào vẽ box.
• Requirements, SLO & capacity — cách tính QPS trung bình/đỉnh, storage, bandwidth.
• Ticket booking — các luồng chính: xem ghế, giữ ghế, thanh toán.
• Docker Compose — depends_on với condition: service_healthy, network, volume.
• Actuator — health group liveness/readiness, expose endpoint an toàn.
• Profile & config — đọc config từ ${ENV}, profile local/test.
• Keycloak docker setup — import realm khi khởi động.
• Prometheus & Grafana — scrape /actuator/prometheus.

3. Đề bài

3.1. Tài liệu docs/requirements.md phải có các mục:

Giả định để tính (bạn có thể đổi, nhưng phải ghi rõ):

1M user hoạt động/ngày, mỗi user xem 20 trang ghế, 10% giữ ghế
Flash sale: 100k người trong 5 phút đầu, sự kiện 20k ghế

Tự tính và điền:
  QPS đọc trung bình  = ? (20M / 86 400)
  QPS đọc đỉnh        = ? (hệ số peak bạn chọn, giải thích)
  QPS ghi giữ ghế đỉnh = ?
  Storage bookings/năm = ? (bytes/row × số booking)
  Số instance booking cần = ? (QPS đỉnh / QPS 1 instance đo ở M8)

3.2. docker-compose.yml — 8 thành phần, tất cả có healthcheck:

Skeleton (bạn tự điền phần còn lại):

services:
  postgres:
    image: postgres:16
    environment:
      POSTGRES_USER: ${POSTGRES_USER}
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
    volumes:
      - pgdata:/var/lib/postgresql/data
      - ./infra/postgres/init.sql:/docker-entrypoint-initdb.d/init.sql
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER}"]
      interval: 5s
      retries: 10
  # redis, kafka, rabbitmq, keycloak, toxiproxy, prometheus, grafana: TODO
  booking-service:
    build: ./booking-service
    env_file: .env
    depends_on:
      postgres: { condition: service_healthy }
      # TODO: kafka, redis
volumes:
  pgdata:

Mỗi service một database riêng (catalog, booking, payment, notification) tạo trong init.sql. Toxiproxy đứng giữa booking → postgres và booking → payment (dùng ở M4).

3.3. .env.example (commit file này, không commit .env):

POSTGRES_USER=ticket
POSTGRES_PASSWORD=change-me
REDIS_PASSWORD=change-me
RABBITMQ_DEFAULT_USER=ticket
RABBITMQ_DEFAULT_PASS=change-me
KEYCLOAK_ADMIN=admin
KEYCLOAK_ADMIN_PASSWORD=change-me
GRAFANA_ADMIN_PASSWORD=change-me
PSP_WEBHOOK_SECRET=change-me
BOOKING_DB_URL=jdbc:postgresql://postgres:5432/booking

3.4. Skeleton 5 service

# application.yml (mỗi service)
spring:
  application.name: booking-service
  datasource:
    url: ${BOOKING_DB_URL}
    username: ${POSTGRES_USER}
    password: ${POSTGRES_PASSWORD}
management:
  endpoints.web.exposure.include: health,info,prometheus
  endpoint.health.probes.enabled: true
  # TODO: health group readiness gồm db, redis

API của M0 chỉ có:

Flyway migration đầu tiên của catalog (schema dùng xuyên suốt):

CREATE TABLE events (
  id BIGSERIAL PRIMARY KEY,
  name TEXT NOT NULL,
  starts_at TIMESTAMPTZ NOT NULL,
  venue TEXT NOT NULL
);
-- seats nằm ở booking DB (M1): seats(id, event_id, code, status, version, held_by, hold_expires_at)

4. Acceptance criteria

1. docs/requirements.md có đủ FR, NFR (có số), ngoài phạm vi, capacity có phép tính, rủi ro.
2. docker compose up -d trên máy sạch: cả 8 container hạ tầng healthy trong ≤ 3 phút.
3. 5 service trả /actuator/health = UP; readiness = DOWN khi tắt Postgres.
4. Prometheus target page: 5 service đều UP.
5. Keycloak tự import realm ticket từ infra/keycloak/realm.json.
6. grep -r "password:" */src/main/resources chỉ thấy ${...}.
7. GET /api/events qua gateway trả 200.

5. Test cases

@SpringBootTest(webEnvironment = RANDOM_PORT)
@Testcontainers
class BookingHealthIT {
  @Container @ServiceConnection
  static PostgreSQLContainer<?> pg = new PostgreSQLContainer<>("postgres:16");

  @Autowired TestRestTemplate rest;

  @Test
  void healthIsUp() {
    // TODO: gọi /actuator/health, assert status UP
  }

  @Test
  void readinessDownWhenDbStopped() {
    // TODO: pg.stop()? hay dùng Toxiproxy? Chọn cách và giải thích
  }
}

6. Failure scenarios

7. Số liệu cần thu

• Thời gian docker compose up đến khi mọi thứ healthy.
• Thời gian start mỗi service, RAM mỗi container (docker stats).
• Lưu ở docs/benchmarks/m0-baseline.md. Đây là mốc để biết hạ tầng có vừa máy bạn không.

8. Checklist hoàn thành

• ☐ Acceptance criteria có test tự động và xanh
• ☐ Failure scenario đã chạy thật, có ghi kết quả
• ☐ docs/benchmarks/m0-baseline.md
• ☐ ADR-001: chọn database-per-service; ADR-002: Kafka cho domain event, RabbitMQ cho notification
• ☐ Không hardcode secret, có .env.example, .env trong .gitignore
• ☐ docs/requirements.md có phép tính capacity
• ☐ Prometheus scrape được 5 service
• ☐ Đã qua review + phỏng vấn của AI

Lo đúng chỗ. Gợi ý hướng, bạn tự đo:

• Dùng compose profiles: core (postgres, redis), messaging (kafka, rabbitmq), auth, obs. M1–M3 chỉ cần core + kafka.
• Kafka KRaft một node, không cần ZooKeeper. Đặt heap nhỏ qua biến env của image.
• Keycloak chạy start-dev ở local là đủ.
• Service Java: giới hạn -XX:MaxRAMPercentage và mem_limit trong compose. Xem lại bài cgroups để hiểu JVM thấy bao nhiêu RAM.

Câu hỏi để bạn tự trả lời: chạy service Java trong IDE hay trong compose thì tiện debug hơn? Ghi lựa chọn vào README.

Gần đúng, nhưng flash sale khác traffic thường. Đừng lấy một hệ số chung. Gợi ý:

• Tách 2 kịch bản: ngày thường (peak ≈ 2–3× trung bình) và flash sale (tính trực tiếp: 100k người, mỗi người refresh bao nhiêu lần trong 5 phút?).
• Tách đọc và ghi. Đọc có thể cache, ghi giữ ghế thì không.
• Quan trọng nhất: số ghế chỉ 20k. Số giữ ghế thành công bị giới hạn bởi số ghế, còn số thử thì không. Con số nào quyết định thiết kế?

Trả lời được câu cuối là bạn đã có lý do cho M7.

Đúng, nhiều image tối giản không có curl. Hướng đi: dùng chính script CLI có sẵn trong image (tìm trong /opt/kafka/bin), gọi một lệnh nhẹ tới localhost:9092. Lệnh trả exit code 0 là healthy. Đặt start_period đủ dài vì Kafka khởi động chậm. Tương tự cho Keycloak: bật health endpoint bằng biến KC_HEALTH_ENABLED rồi tìm cách gọi nó không cần curl.

OK. Mình soi theo checklist này trước:

Checklist review

• Có password/secret nào trong YAML, compose, Dockerfile, git history không?
• depends_on có dùng service_healthy hay chỉ thứ tự start?
• Liveness có phụ thuộc DB không? (Không được — DB chết sẽ làm restart loop.)
• Actuator có expose env, heapdump ra ngoài không?
• Capacity có phép tính và giả định rõ, hay chỉ có con số?
• Port, tên DB, tên topic có khớp quy ước chung không?

Câu hỏi phỏng vấn

1. Bạn ước lượng tải hệ thống thế nào?

🇻🇳 Tiếng Việt:

Em tách đọc và ghi, ngày thường và flash sale. Ngày thường khoảng 230 QPS đọc trung bình, peak 3 lần. Flash sale tính theo số người và số lần refresh. Ghi giữ ghế bị chặn bởi số ghế nên em tập trung vào chống tranh chấp, còn đọc thì cache.

🇬🇧 English:

I split reads from writes and normal days from flash sales. Normal reads are about 230 QPS with a 3x peak. For flash sales I estimate from users and refresh rate. Successful holds are bounded by seat count, so the hard part is contention, while reads are cached.

2. Liveness và readiness khác gì?

🇻🇳 Tiếng Việt:

Liveness hỏi "process còn sống không", fail thì restart. Readiness hỏi "nhận traffic được chưa", fail thì bỏ khỏi load balancer. DB chết chỉ làm readiness fail, không restart.

🇬🇧 English:

Liveness asks whether the process is alive; failing it triggers a restart. Readiness asks whether it can serve traffic; failing it removes the instance from the load balancer. A database outage should only fail readiness.

3. Vì sao mỗi service một database?

🇻🇳 Tiếng Việt:

Để service độc lập về schema và deploy. Đổi lại không join chéo được và phải dùng event, saga để giữ nhất quán.

🇬🇧 English:

It keeps schemas and deployments independent. The trade-off is no cross-service joins, so consistency needs events and sagas.

4. Secret được quản lý thế nào?

🇻🇳 Tiếng Việt:

Local dùng file .env không commit, có .env.example. Lên K8s dùng Secret hoặc vault. Code chỉ đọc biến môi trường.

🇬🇧 English:

Locally I use an uncommitted .env with a committed .env.example. In Kubernetes I use Secrets or a vault. The code only reads environment variables.

Cách nhớ ngắn gọn

• Requirements có số, capacity có phép tính.
• Healthcheck cho mọi container, service_healthy cho mọi phụ thuộc.
• Liveness không phụ thuộc DB.
• Secret chỉ qua ${ENV}.