★ Bối cảnh câu chuyện

Có lần đang ngồi trong buổi họp với khách, mình nghĩ chỉ đơn giản là confirm rule nghiệp vụ như mọi khi. Ai ngờ khách lại hỏi:
💬 「このシステムのアーキテクチャはどのようになっていますか？」
(Kiến trúc hệ thống bên bạn hiện tại đang thiết kế thế nào?)

Trời ơi, mình đứng hình luôn. Trong đầu chỉ nghĩ “ơ thì… có FE, có BE, có DB… thế thôi chứ gì?”. Nhưng không dừng ở đó, khách đi sâu hơn:
💬 「API サーバーとバッチ処理は別プロセスですか？冗長構成はどうなっていますか？」
(API server và batch có chạy tách biệt không? Cấu hình redundancy thế nào?)

 

Bối cảnh cụ thể là: hệ thống lúc đó đang xử lý việc gửi mail reminder cho bệnh nhân đặt lịch khám.

  • Rule nghiệp vụ: Nếu booking nằm buổi sáng → gửi reminder lúc 7h sáng; nếu booking nằm buổi chiều → gửi reminder lúc 12h trưa.

  • Thực tế kỹ thuật: Dev setup batch chạy lúc 6:55 để gửi mail cho slot 7h, và 11:55 để gửi mail cho slot 12h.
    👉 Vấn đề: Nếu bệnh nhân book sau 6:55 (cho slot 7h sáng) thì batch đã chạy mất rồi → reminder không được gửi.

Khách mới hỏi:

  • “Batch này có tách riêng với API server không? Hay gom chung một process?”

  • “Có chạy dự phòng (redundancy) nếu batch fail không?”

Lúc đó mặt mình chắc y như dev junior mới bị hỏi “em biết design pattern gì chưa?” – cười gượng và trả lời vòng vo:
“Dạ phần này em confirm lại với team kỹ thuật rồi báo sau ạ…” 🙃

 

⁉️ Vì sao vấp?

  • Mình nghĩ BrSE/BA chỉ cần nắm rule nghiệp vụ, ai ngờ khách lại quan tâm cả kiến trúc.

  • Kiến trúc không chỉ là “chuyện của dev lead”, mà khách hàng đôi khi muốn hiểu để đánh giá:

    • Hệ thống có đủ ổn định không?

    • Có đảm bảo scalability khi user tăng lên không?

    • Nếu lỗi, có cơ chế failover hay backup không?

🌱 Bài học mình rút ra

1. Cần nắm khái niệm cơ bản về system architecture và định nghĩa về API server & Batch
Một hệ thống thông thường sẽ gồm:

  • FE (Frontend): nơi user thao tác (web/app).

  • BE (Backend): xử lý logic nghiệp vụ, giao tiếp DB.

  • DB (Database): lưu trữ dữ liệu booking, user, v.v.

  • Batch: job chạy định kỳ, ví dụ gửi mail reminder lúc 6:55 hoặc 11:55.

  • API Gateway: cổng điều phối request từ ngoài vào.

  • External Service: dịch vụ bên ngoài, như mail server hoặc payment gateway.

👉 Ở đây, bạn nên nhờ dev/ops chuẩn bị cho 1 diagram high-level (kiểu “sơ đồ khối”) để khi khách hỏi “batch và API có tách không?” thì còn biết vị trí các thành phần nằm ở đâu.

<< Giải thích định nghĩa >>

  • 🖥️ API Server là gì?

    • Vai trò: xử lý tương tác trực tiếp với người dùng hoặc ứng dụng khác theo thời gian thực.

    • Ví dụ:

      • Khi bệnh nhân mở app/web để đặt lịch → request đi vào API server.

      • API server kiểm tra thông tin, lưu dữ liệu booking vào Database, trả về kết quả ngay lập tức.

    • 👉 Có thể hình dung API server như lễ tân bệnh viện: tiếp nhận thông tin, ghi sổ, phản hồi tức thì.

     

  • ⚙️ Batch Job là gì?

    • Vai trò: xử lý tự động, theo lịch định sẵn (schedule), không cần người dùng thao tác.

    • Ví dụ:

      • Hệ thống có rule: gửi mail nhắc nhở 7h sáng và 12h trưa.

      • Batch job chạy đúng giờ (6:55, 11:55) để lấy danh sách booking từ Database và gửi mail cho bệnh nhân.

    • 👉 Có thể hình dung Batch job như nhân viên hậu cần: cứ đến giờ cố định là đi in danh sách, chuẩn bị thư nhắc và gửi đi.

✅ Tóm lại:

  • API server lo phần “mặt trước” – tiếp nhận và xử lý request của bệnh nhân.

  • Batch job lo phần “hậu trường” – đến giờ là tự chạy để gửi mail hoặc làm công việc định kỳ.

  • Khách hỏi “có tách riêng không?” để chắc chắn rằng nếu batch gặp sự cố, API vẫn hoạt động bình thường, không ảnh hưởng đến trải nghiệm người dùng.

  • Redundancy của API server

    • Thay vì chỉ có 1 server để chạy API, hệ thống dựng 2 hoặc nhiều server.

    • Đặt trước load balancer → nếu 1 server chết thì request sẽ được chuyển sang server khác.
      → Người dùng không bị ảnh hưởng.

  • Redundancy của batch job

    • Batch gửi mail reminder chạy lúc 6:55.

    • Nếu batch fail (ví dụ server batch down, hoặc script lỗi), hệ thống có job dự phòng hoặc cơ chế retry để chạy lại trên một server khác.

    • Nhờ đó, reminder vẫn được gửi, không bị mất.

2. Phân tích ví dụ về batch gửi mail reminder

  • Nghiệp vụ: Khách hàng đặt lịch khám buổi sáng → nhận mail reminder lúc 7h. Đặt lịch buổi chiều → nhận reminder lúc 12h.

  • Cách triển khai kỹ thuật: Dev setup batch chạy 6:55 và 11:55.

  • Issue phát sinh: Nếu bệnh nhân đặt lịch sau 6:55 (cho slot 7h sáng) → batch đã chạy mất rồi, reminder không được gửi.

👉 Tại sao khách hỏi “batch có tách process không?” và “có redundancy không?”

  • Nếu batch gom chung với API, lỡ batch chạy lâu → có thể ảnh hưởng API.

  • Nếu batch fail mà không có redundancy → bệnh nhân không nhận reminder → ảnh hưởng trải nghiệm.

Chính ví dụ này cho thấy: nắm kiến trúc hệ thống không phải để bạn giải thích chi tiết code, mà để hiểu phạm vi và rủi ro khi triển khai nghiệp vụ.

 

🟢 Ví dụ minh họa về Flow batch reminder CÓ redundancy

 

 

3. Cần nắm đến phạm vi nào thì đủ?

  • Không cần biết dev viết batch bằng Python hay Java.

  • Nhưng cần hiểu batch là 1 process tách biệt với API, chạy định kỳ theo lịch.

  • Biết được: nếu batch fail → hệ quả là reminder không được gửi, và nếu hệ thống không có failover thì user sẽ bị ảnh hưởng.

  • Hiểu được mức “high-level” này là đủ để bạn nói chuyện với khách hàng và biết khi nào nên kéo dev vào giải thích chi tiết.

 

4. Chuẩn bị sẵn “từ khóa” khi khách hỏi
Đây là những keyword “báo hiệu” khách đang quan tâm ở tầng kiến trúc:

  • Redundancy (冗長化) – chạy dự phòng.

  • Failover (フェイルオーバー) – tự động chuyển khi hệ thống chính fail.

  • Scalability (スケーラビリティ) – khả năng mở rộng khi user tăng.

  • Cloud Service (AWS, Azure…) – hạ tầng lưu trữ/vận hành.

  • Batch vs Real-time – xử lý định kỳ hay ngay lập tức.

👉 Khi nghe những từ này, bạn biết ngay đây không phải câu hỏi nghiệp vụ, mà là câu hỏi kiến trúc.

 

5. Dám nói “để em confirm lại” một cách chuyên nghiệp
Thay vì ấp úng, hãy trả lời rõ ràng:
「本件は技術的な詳細が関わるため、開発チームと確認してからご回答いたします。」
(Vì đây liên quan tới chi tiết kỹ thuật, em sẽ confirm với team dev rồi phản hồi sau ạ.)

 

6. Làm cầu nối, không cần thành chuyên gia kiến trúc
Vai trò BrSE/BA không phải là “kiến trúc sư hệ thống”. Quan trọng nhất là:

  • Biết phân biệt: đâu là business rule, đâu là system architecture.

  • Dẫn đúng người vào khi cần (dev lead, system architect).

  • Có khả năng “dịch lại” cho khách bằng ngôn ngữ dễ hiểu: batch chạy sai giờ → user không nhận mail reminder.

👉 Và thế là đủ để vừa giữ uy tín trước khách, vừa giúp team vận hành mượt.

 

📚 Checklist dành cho newbie khi gặp câu hỏi kiến trúc

  • Nắm high-level diagram: FE – BE – DB – Batch – External.

  • Hiểu từ khóa cơ bản: redundancy, failover, scalability.

  • Biết phân biệt: nghiệp vụ vs kiến trúc.

  • Có sẵn câu trả lời “xin confirm lại với team kỹ thuật” – ngắn gọn, chuyên nghiệp.

  • Sau họp, log lại câu hỏi + assign đúng người trong dev team.

 

✨ Đúc kết
Làm BrSE/BA không phải biết tất cả, mà phải biết mình “không biết cái gì” để dẫn đúng người vào cuộc.
Khách không chờ bạn trả lời ngay, nhưng họ cần thấy bạn nắm được bức tranh lớn và biết cách điều phối.

Nên đừng sợ khi bị hỏi kiến trúc – hãy xem đó là cơ hội để mình học thêm và trở thành một “bridge” đúng nghĩa 🌉