Bỏ qua

ADR-010: Python/FastAPI cho Matching Microservice

Trạng thái

Accepted

Ngày

2026-04-08

Người quyết định

Tech Lead

Architecture Drivers

D3 (Developer Experience), D7 (Khả năng mở rộng)

Bối cảnh

Matching Service cần implement rule-based scoring trong GĐ1 và phát triển thêm ML models trong GĐ2. Backend chính là Java/Spring Boot. Câu hỏi là matching nên nhúng trong Java hay chạy như Python service riêng.

Các Phương Án Xem Xét

Phương án A: Python/FastAPI service riêng biệt

  • Ưu điểm: Hệ sinh thái Python AI/ML (scikit-learn, transformers, spaCy); FastAPI tự sinh OpenAPI docs; phát triển độc lập; con đường tự nhiên đến ML ở GĐ2
  • Nhược điểm: Thêm một service cần vận hành; overhead giao tiếp inter-service

Phương án B: Nhúng trong Java backend (PostgreSQL native scoring)

  • Ưu điểm: Deploy đơn giản hơn (single service); truy cập DB trực tiếp để scoring
  • Nhược điểm: Java không lý tưởng cho NLP/ML; khó thêm ML models ở GĐ2; PostgreSQL-only scoring giới hạn linh hoạt

Quyết Định

Sử dụng Phương án A: Python/FastAPI service riêng. GĐ1 implement rule-based scoring (có thể dùng PostgreSQL functions qua psycopg3 hoặc implement bằng Python thuần). GĐ2 thêm ML models và AI feedback loop tự nhiên trong hệ sinh thái Python.

Giao tiếp: Backend → Matching Service qua REST API nội bộ. Matching Service có quyền read-only vào PostgreSQL để tra cứu Anchored Data.

Hệ Quả

Tích cực

  • Con đường phát triển tự nhiên đến ML/AI ở GĐ2
  • Scaling và deployment độc lập
  • Thư viện NLP Python sẵn có cho xử lý văn bản tiếng Việt

Tiêu cực

  • Thêm một service cần vận hành (Docker container)
  • Latency inter-service cho matching calls

Liên Quan