Báo cáo dễ hiểu về kiến trúc hệ thống sàn giáo dục

Ngày viết lại: 31/05/2026 Nguồn gốc: viết lại từ bản báo cáo domain-book/bao-cao-kien-truc-he-thong-san-giao-duc.md theo phong cách dễ hiểu hơn. Mục tiêu: giải thích kiến trúc sàn giáo dục bằng tiếng Việt dễ hiểu, hạn chế tiếng Anh và từ học thuật khó. Phạm vi: sàn giáo dục nhiều bên, nơi người học hoặc phụ huynh mua dịch vụ học từ giáo viên, trung tâm hoặc bên dạy; nền tảng đứng giữa để hỗ trợ tìm kiếm, đặt lịch, học, thanh toán, giữ tiền, mở tiền, chuyển tiền, hoàn tiền, xử lý tranh chấp, đánh giá, an toàn, bằng chứng học tập và trí tuệ nhân tạo.

Ghi chú ngắn:

• Bản gốc dùng nhiều thuật ngữ tiếng Anh về sàn, đặt lịch, thanh toán, sổ tiền, quy trình dài, tìm kiếm, xếp hạng, trí tuệ nhân tạo, kết nối ngoài và vận hành.
• Trong bản viết lại này, tôi dùng cách nói tiếng Việt trước: "sàn giáo dục", "bên dạy", "người học", "đặt lịch", "sổ tiền", "quy trình dài", "tìm kiếm và xếp hạng", "niềm tin và an toàn", "bằng chứng học tập".
• Một số tên chuẩn hoặc tên sản phẩm vẫn được giữ ở phần nguồn tham khảo để đối chiếu.

1. Nói ngắn gọn trước

Sàn giáo dục không phải là:

một hệ bán khóa học + thêm người bán.

Nó cũng không chỉ là:

một hệ học trực tuyến + thêm thanh toán.

Sàn giáo dục khó vì nó nằm giữa nhiều bên:

• người học,
• phụ huynh,
• giáo viên,
• trung tâm,
• bên cung cấp nội dung,
• nền tảng,
• bên thanh toán,
• đội hỗ trợ,
• đôi khi có trường học hoặc doanh nghiệp.

Sàn phải xử lý cùng lúc:

• người học tìm đúng lớp,
• phụ huynh tin được bên dạy,
• bên dạy đăng dịch vụ đúng cam kết,
• lịch học không bị trùng,
• buổi học diễn ra thật,
• có bằng chứng học tập,
• tiền được thu đúng,
• tiền được giữ đúng,
• tiền được trả đúng,
• hoàn tiền và tranh chấp xử lý công bằng,
• đánh giá không bị gian lận,
• trẻ em và dữ liệu học viên được bảo vệ,
• trí tuệ nhân tạo không tự quyết định chuyện nhạy cảm.

Một hệ bán hàng thông thường có thể dừng ở:

người mua trả tiền -> người bán giao hàng.

Nhưng sàn giáo dục phải hỏi thêm:

• lớp học có diễn ra không?
• giáo viên có đến không?
• học viên có tham gia không?
• kết quả học tập có bằng chứng không?
• phụ huynh có hài lòng không?
• nếu buổi học lỗi thì lỗi của ai?
• nếu hoàn tiền thì hoàn bao nhiêu?
• nếu đã chuyển tiền cho giáo viên rồi mới có tranh chấp thì xử lý thế nào?

Điểm cần nhớ:

Sàn giáo dục chỉ lớn được khi nối được:

niềm tin + tiền + lịch học + lớp học + bằng chứng học tập + hỗ trợ tranh chấp

thành một hệ thống nhất quán.

2. Quyết định kiến trúc ngắn

Nếu xây thực tế, nên bắt đầu bằng một hệ lõi gọn nhưng chia ranh giới rõ.

Không nên bắt đầu bằng quá nhiều dịch vụ nhỏ.

Cũng không nên viết một khối rối, mọi thứ gọi thẳng vào nhau.

Cách hợp lý hơn:

Giai đoạn đầu:

một ứng dụng chính

nhưng chia module rõ

+ dùng bên thanh toán cho sàn

+ có sổ tiền nội bộ

+ có hộp sự kiện để phát sự kiện chắc chắn

+ có dữ liệu đọc riêng cho tìm kiếm

+ có trạng thái rõ cho quy trình dài

+ có màn hình hỗ trợ vận hành mạnh.

Khi lớn:

tách riêng các phần rủi ro hoặc tải lớn:

thanh toán và sổ tiền,

tìm kiếm và xếp hạng,

trí tuệ nhân tạo,

thông báo,

dữ liệu học tập,

báo cáo.

Lý do:

• Sàn giáo dục còn phải thay đổi nhanh để tìm đúng mô hình kinh doanh.
• Thanh toán và sổ tiền cần đúng tuyệt đối hơn phần khác.
• Tìm kiếm và xếp hạng cần dữ liệu đọc riêng.
• Trí tuệ nhân tạo có chi phí, độ trễ và rủi ro riêng.
• Lớp học, điểm danh, bằng chứng học tập cần nhất quán với đặt lịch và tiền.

Đánh đổi:

• Một ứng dụng chính chia module giúp ra sản phẩm nhanh hơn.
• Nhưng phải giữ kỷ luật ranh giới module.
• Tách dịch vụ sớm có thể giúp một số phần mở rộng tốt hơn.
• Nhưng tách sớm sẽ làm tăng lỗi do dữ liệu phân tán, khó theo dõi và khó xử lý sự cố.

Khuyến nghị:

Đội nhỏ hoặc vừa:

bắt đầu bằng một ứng dụng chính có ranh giới module rõ.

Chỉ tách dịch vụ khi:

ranh giới nghiệp vụ rõ,

tải đủ lớn,

rủi ro đủ cao,

và có đội chịu trách nhiệm riêng.

3. Kiến trúc tổng thể dễ hiểu

Một sàn giáo dục nên có các lớp sau:

Ứng dụng người dùng

- ứng dụng người học hoặc phụ huynh

- màn hình cho bên dạy

- không gian làm việc của giáo viên

- cổng cho phụ huynh

- màn hình vận hành của nền tảng

Lớp đường gọi hệ thống

- nhận yêu cầu từ ứng dụng

- đăng nhập và phiên dùng

- xác định người đang dùng theo vai trò nào

- giới hạn tần suất

- chống lạm dụng

Các vùng nghiệp vụ lõi

- danh tính và khách thuê

- hồ sơ bên dạy và dịch vụ đăng bán

- tìm kiếm và khám phá

- đặt lịch và xếp lịch

- tổ chức học

- bài tập, đánh giá và bằng chứng

- điều phối thanh toán

- sổ tiền của sàn

- chuyển tiền cho bên dạy

- hoàn tiền và tranh chấp

- niềm tin, an toàn và rủi ro

- đánh giá và uy tín

- thông báo

- trí tuệ nhân tạo

- dữ liệu học tập và báo cáo

- kết nối với hệ ngoài

Nền dữ liệu và vận hành

- cơ sở dữ liệu giao dịch

- sổ tiền

- hộp sự kiện

- nơi tìm kiếm

- nơi lưu tệp

- kho dữ liệu phân tích

- hệ theo dõi vận hành

Điểm quan trọng:

Mỗi vùng nghiệp vụ phải có nguồn dữ liệu đúng của riêng nó.

Nhưng không bắt buộc mỗi vùng là một dịch vụ riêng ngay từ đầu.

Ví dụ:

• đặt lịch là nguồn đúng cho trạng thái buổi học,
• sổ tiền là nguồn đúng cho dòng tiền,
• hồ sơ bên dạy là nguồn đúng cho thông tin công khai của giáo viên hoặc trung tâm,
• bằng chứng học tập là nguồn đúng để xử lý hoàn tiền, tranh chấp và chất lượng.

4. Các vùng nghiệp vụ bắt buộc

4.1. Danh tính, tổ chức và vai trò

Cần mô hình được:

• người dùng,
• cách đăng nhập,
• tổ chức,
• thành viên tổ chức,
• vai trò,
• liên kết phụ huynh và học viên,
• tài khoản bên dạy,
• tổ chức bên dạy,
• nhân viên vận hành của nền tảng.

Vì một người có thể có nhiều vai trò.

Ví dụ:

• một người vừa là phụ huynh của học viên A,
• vừa là giáo viên ở trung tâm B,
• vừa mua khóa học cho chính mình,
• vừa là người quản lý của một nhóm giáo viên.

Nếu chỉ có:

user.role = teacher

thì hệ sẽ rất nhanh bị rối.

Cần phân biệt:

• người này là ai,
• đang hành động trong tổ chức nào,
• đang hành động với vai trò nào,
• đang xử lý học viên hoặc lớp nào,
• có quyền xem dữ liệu nào.

Khuyến nghị:

• giai đoạn đầu dùng chung một cơ sở dữ liệu cũng được,
• nhưng mọi dữ liệu phải có phạm vi người tham gia hoặc tổ chức rõ,
• không được để giáo viên xem dữ liệu học viên ngoài lớp hoặc lịch của mình,
• không nhầm khách thuê phần mềm với người bán trên sàn.

Ví dụ quan trọng:

Một trung tâm dạy học trên sàn là "bên dạy".

Nó không nhất thiết là một khách thuê phần mềm hoàn toàn tách biệt.

4.2. Hồ sơ bên dạy và dịch vụ đăng bán

Cần mô hình được:

• hồ sơ giáo viên hoặc trung tâm,
• dịch vụ đăng bán,
• khóa học,
• buổi học thử,
• lớp học trực tiếp,
• gói học,
• chính sách giá,
• chính sách hủy,
• quy trình duyệt nội dung,
• phiên bản nội dung đăng bán.

Vì sao cần phiên bản?

Vì người mua có thể mua theo một cam kết cũ.

Ví dụ:

• lúc mua ghi "hoàn tiền 100% nếu không hài lòng sau buổi đầu",
• sau đó bên dạy sửa thành "không hoàn tiền".

Khi có tranh chấp, hệ phải biết người mua đã mua theo phiên bản nào.

Không nên để bên dạy sửa thẳng nội dung công khai mà không có lịch sử.

Khuyến nghị:

• các trường quan trọng phải có cấu trúc rõ,
• phần mô tả có thể linh hoạt,
• dịch vụ đăng bán nên qua duyệt trước khi công khai,
• thay đổi chính sách quan trọng phải tạo phiên bản mới.

4.3. Đặt lịch và xếp lịch

Cần mô hình được:

• yêu cầu đặt lịch,
• đơn đặt lịch,
• người tham gia,
• khung giờ rảnh,
• chính sách rảnh bận,
• yêu cầu đổi lịch,
• yêu cầu hủy,
• trường hợp vắng mặt,
• buổi học,
• bằng chứng hoàn thành.

Đặt lịch trên sàn giáo dục không giống đơn hàng bán đồ.

Nó là một quy trình dài:

người mua chọn dịch vụ

-> chọn lịch

-> bên dạy xác nhận

-> thanh toán

-> học

-> điểm danh

-> có bằng chứng hoàn thành

-> mở tiền cho bên dạy

-> đánh giá

-> có thể tranh chấp.

Nếu chỉ lưu:

status = paid

thì không đủ.

Cần có trạng thái rõ như:

• nháp,
• đang chờ xác nhận,
• đã xác nhận,
• đã thanh toán,
• đã lên lịch,
• đã diễn ra,
• vắng học viên,
• vắng giáo viên,
• hoàn thành,
• đang yêu cầu hoàn tiền,
• đang tranh chấp,
• đã đóng.

Khuyến nghị:

• giai đoạn đầu dùng trạng thái rõ trong cơ sở dữ liệu,
• có việc chạy nền để xử lý hạn chờ,
• mọi thay đổi trạng thái phải ghi vết,
• khi lớn hơn mới dùng máy điều phối quy trình chuyên dụng.

4.4. Tổ chức học

Cần mô hình được:

• sản phẩm học,
• chương trình học,
• lớp hoặc nhóm học,
• ghi danh,
• buổi học,
• điểm danh,
• nội dung bài học tại thời điểm học,
• hoạt động học,
• tài liệu.

Một dịch vụ trên sàn có thể là:

• buổi học thử,
• lớp học trực tuyến trực tiếp,
• khóa học theo nhóm,
• khóa tự học,
• gói kèm riêng,
• chương trình dài hạn.

Do đó, phần "đăng bán" và phần "dạy học thật" không nên trộn lẫn.

Ví dụ:

Listing là lời hứa bán ra ngoài.

Session là buổi học thật đã diễn ra.

Evidence là bằng chứng buổi học hoặc kết quả học.

Khuyến nghị:

• không cần hỗ trợ mọi chuẩn giáo dục ngay,
• nhưng mô hình dữ liệu nên ánh xạ được sang người dùng, tổ chức, khóa học, lớp, ghi danh, kết quả,
• nếu sau này kết nối với hệ học ngoài, ranh giới kết nối phải sẵn sàng.

4.5. Bài tập, đánh giá và bằng chứng học tập

Cần mô hình được:

• mẫu bài tập,
• câu hỏi hoặc mục đánh giá,
• thang chấm,
• bản chụp hoạt động,
• lần làm bài,
• bài nộp,
• bằng chứng,
• phản hồi,
• sửa bài,
• giáo viên xem lại,
• kết quả học tập.

Sàn giáo dục cần chứng minh chất lượng học, không chỉ chứng minh "đã có buổi học".

Bằng chứng học tập giúp:

• phụ huynh hiểu con học gì,
• nền tảng xử lý tranh chấp,
• bên dạy chứng minh đã dạy,
• xếp hạng bên dạy tốt hơn,
• phát hiện chất lượng thấp,
• đánh giá hiệu quả học tập.

Ví dụ bằng chứng:

• điểm danh,
• bài nộp,
• phản hồi của giáo viên,
• bản ghi tóm tắt buổi học nếu được phép,
• kết quả bài kiểm tra,
• ghi chú tiến bộ,
• xác nhận hoàn thành.

Khuyến nghị:

• có cấu trúc tối thiểu và có phiên bản,
• không lưu mọi thứ trong một khối dữ liệu tự do không phiên bản,
• thiết kế để sau này có thể chuyển sang chuẩn giáo dục nếu cần.

5. Thanh toán

5.1. Vì sao thanh toán của sàn giáo dục khó?

Thanh toán trong sàn giáo dục không chỉ là thu tiền.

Cần xử lý:

• người mua trả tiền,
• nền tảng thu phí,
• bên dạy được nhận phần của mình,
• tiền có thể bị giữ cho đến khi học xong,
• hoàn tiền một phần hoặc toàn phần,
• tranh chấp,
• bên thanh toán báo giao dịch thành công hoặc thất bại,
• chuyển tiền cho nhiều bên dạy,
• đối soát với số dư thực tế.

Các khái niệm cần có:

• ý định thanh toán,
• giao dịch thu tiền,
• đơn hàng trên sàn,
• tài khoản thanh toán của bên dạy,
• sổ tiền,
• khoản bên dạy được nhận,
• phí nền tảng,
• khoản giữ lại,
• điều kiện mở tiền,
• lô chuyển tiền,
• hoàn tiền,
• tranh chấp,
• đối soát,
• hộp nhận thông báo từ bên thanh toán.

5.2. Không nên tự làm hệ giữ tiền quá sớm

Với sàn nhiều bên, nên dùng bên thanh toán có hỗ trợ sàn.

Lý do:

• xác minh người bán và tổ chức là bài toán tài chính riêng,
• chuyển tiền cho nhiều bên ở nhiều nơi rất phức tạp,
• xử lý thẻ thanh toán kéo theo yêu cầu bảo mật nặng,
• hoàn tiền và tranh chấp cần hạ tầng chuyên dụng,
• tự giữ tiền hộ có thể có rủi ro pháp lý.

Nhưng dùng bên thanh toán không có nghĩa là bỏ qua sổ tiền nội bộ.

Cần nhớ:

Số dư ở bên thanh toán không phải nguồn đúng duy nhất của nền tảng.

Hóa đơn không phải sổ tiền.

Đơn hàng không phải khoản chuyển tiền.

Thông báo từ bên thanh toán chưa phải sự thật cuối cùng nếu chưa đối soát.

5.3. Luồng thanh toán đề xuất

Luồng dễ hiểu:

Người mua thanh toán

-> hệ điều phối thanh toán tạo yêu cầu thu tiền

-> bên thanh toán xử lý

-> hệ nhận thông báo

-> trạng thái đơn được cập nhật

-> sổ tiền ghi bút toán

-> quy trình chờ bằng chứng học xong

-> khoản của bên dạy đủ điều kiện nhận

-> tạo lô chuyển tiền

-> đối soát với bên thanh toán và ngân hàng.

Khuyến nghị:

• giai đoạn đầu có thể chưa giữ tiền phức tạp,
• nếu đã có giữ tiền, mở tiền, chuyển tiền, hoàn tiền, tranh chấp thì sổ tiền là bắt buộc,
• không tự xây ví hoặc ký quỹ nếu chưa có pháp lý và giấy phép phù hợp.

6. Sổ tiền

6.1. Vì sao bắt buộc?

Sàn giáo dục sẽ gặp các câu hỏi như:

• Bên dạy A còn bao nhiêu tiền được nhận?
• Đơn B hoàn một phần thì phí nền tảng đảo thế nào?
• Người mua khiếu nại sau khi đã chuyển tiền thì xử lý thế nào?
• Phí nền tảng đã được ghi nhận hay còn chờ?
• Lô chuyển tiền C gồm những khoản nào?
• Bên thanh toán báo chuyển tiền thất bại thì đảo bút toán ra sao?

Bảng thanh toán đơn giản không trả lời được các câu này một cách chắc chắn.

6.2. Cách nghĩ về sổ tiền

Sổ tiền nên ghi theo bút toán hai bên.

Nói dễ hiểu:

Mỗi dòng tiền đi từ một tài khoản này sang tài khoản khác.

Tổng ghi tăng và ghi giảm phải cân nhau.

Không sửa tay lịch sử.

Nếu sai thì ghi bút toán đảo hoặc điều chỉnh.

Các tài khoản có thể gồm:

• tiền đang nằm ở bên thanh toán,
• tiền phải trả cho bên dạy,
• doanh thu phí nền tảng,
• nghĩa vụ hoàn tiền,
• khoản dự phòng tranh chấp,
• số dư âm của bên dạy,
• chi phí khuyến mãi,
• thuế phải nộp.

6.3. Nguyên tắc sổ tiền

Cần:

• không sửa bút toán đã ghi,
• có mã chống ghi trùng,
• có tham chiếu ra giao dịch ngoài,
• có tham chiếu nghiệp vụ như đơn hàng hoặc tranh chấp,
• có loại giao dịch rõ,
• có trạng thái đã ghi, đã đảo hoặc đã hủy,
• có tiền tệ rõ.

Đánh đổi:

• tự xây sổ tiền cần hiểu cả kỹ thuật và kế toán,
• dùng nhà cung cấp sổ tiền nhanh hơn nhưng tốn phí và phụ thuộc,
• sổ tiền không cho sửa tay nên sửa lỗi phải bằng bút toán đảo,
• nhiều loại tiền tệ làm phức tạp hơn nhiều.

Khuyến nghị:

Nếu chỉ làm sàn giới thiệu và chưa giữ/chia/chuyển tiền:

chưa cần sổ tiền đầy đủ.

Nếu đã giữ tiền, chia tiền, chuyển tiền, hoàn tiền hoặc tranh chấp:

sổ tiền là phần ưu tiên cao nhất.

7. Quy trình dài

Nhiều việc trong sàn giáo dục không kết thúc trong một yêu cầu.

Ví dụ:

Bên dạy đăng ký

-> xác minh

-> được bật khả năng nhận tiền.

Đặt lịch

-> thanh toán

-> học

-> có bằng chứng

-> mở tiền

-> đánh giá.

Yêu cầu hoàn tiền

-> thu thập bằng chứng

-> ra quyết định

-> đảo sổ tiền

-> gửi lệnh hoàn tiền.

Tranh chấp

-> gom bằng chứng

-> gửi bên thanh toán nếu cần

-> nhận kết quả

-> điều chỉnh sổ tiền.

Trí tuệ nhân tạo chấm nháp

-> lấy bối cảnh

-> tạo nhận xét

-> kiểm tra

-> giáo viên duyệt

-> công bố.

7.1. Không nên dùng việc chạy nền rời rạc tùy tiện

Nếu chỉ dùng nhiều việc chạy theo lịch mà không có trạng thái rõ, hệ sẽ khó biết:

• bước nào đã làm,
• bước nào đang chờ,
• bước nào thất bại,
• có chạy lại an toàn không,
• có gửi trùng tiền hoặc trùng thông báo không.

7.2. Cách làm thực dụng

Giai đoạn đầu:

• mỗi quy trình có trạng thái rõ trong cơ sở dữ liệu,
• ghi sự kiện vào hộp sự kiện cùng lúc với thay đổi dữ liệu,
• việc nền đọc sự kiện và xử lý,
• mọi bước có mã chống chạy trùng,
• có màn hình xem dòng thời gian cho đội hỗ trợ.

Khi lớn:

• dùng máy điều phối quy trình cho thanh toán, tranh chấp, chuyển tiền, hoàn tiền,
• không dùng các việc chạy theo lịch rời rạc cho dòng tiền quan trọng.

Khuyến nghị:

Quy trình liên quan tiền phải nhìn lại được từng bước.

Không được là một chuỗi việc nền mù.

8. Tìm kiếm và xếp hạng

Người học hoặc phụ huynh cần tìm được bên dạy phù hợp.

Tìm kiếm trong sàn giáo dục không chỉ là tìm theo chữ.

Cần xét:

• môn học,
• cấp độ,
• độ tuổi,
• ngôn ngữ,
• lịch rảnh,
• giá,
• địa điểm hoặc học trực tuyến,
• đánh giá,
• tỷ lệ hoàn thành,
• tỷ lệ hoàn tiền,
• số tranh chấp,
• tốc độ phản hồi,
• độ tin cậy của bên dạy,
• cờ an toàn trẻ em,
• sự công bằng cho bên dạy mới.

8.1. Các phần cần có

Cần:

• dữ liệu tìm kiếm của dịch vụ đăng bán,
• dữ liệu tìm kiếm của bên dạy,
• dữ liệu lịch rảnh,
• dữ liệu kết quả học tập,
• tín hiệu chất lượng và rủi ro,
• ý định của người mua,
• hiểu câu tìm kiếm,
• lấy ứng viên phù hợp,
• xếp hạng,
• chặn theo chính sách,
• thử nghiệm,
• ghi lại ai đã được hiển thị.

8.2. Vì sao không dùng trí tuệ nhân tạo lớn để thay toàn bộ tìm kiếm?

Trí tuệ nhân tạo có thể giúp hiểu câu hỏi, tóm tắt và giải thích gợi ý.

Nhưng tìm kiếm trên sàn cần:

• phản hồi nhanh,
• lọc chắc chắn theo lịch, giá, tuổi, môn học,
• xếp hạng giải thích được,
• chống bên dạy lách hệ,
• thử nghiệm so sánh,
• tuân thủ chính sách,
• công bằng khi hiển thị.

Vì vậy, trí tuệ nhân tạo chỉ nên là lớp hỗ trợ.

Nó không thay thế toàn bộ hệ tìm kiếm và xếp hạng.

8.3. Lộ trình tìm kiếm

Khuyến nghị:

Giai đoạn đầu:

tìm theo chữ + bộ lọc rõ + điểm đơn giản.

Giai đoạn 1:

thêm tín hiệu chất lượng,

ghi lại lượt hiển thị,

thử nghiệm cách xếp hạng.

Giai đoạn 2:

thêm tìm theo nghĩa,

thêm mô hình xếp hạng,

thêm cơ chế công bằng và khám phá bên dạy mới.

Không nên làm xếp hạng máy học phức tạp khi chưa có dữ liệu về lượt xem, đặt lịch, hoàn thành và kết quả học.

9. Ghép người học với bên dạy

Tìm kiếm là để người mua tự chọn.

Ghép là khi nền tảng đề xuất hoặc phân công bên dạy phù hợp.

Cần mô hình được:

• nhu cầu của người học,
• hồ sơ học viên,
• năng lực bên dạy,
• lịch rảnh,
• ràng buộc,
• ứng viên ghép,
• điểm phù hợp,
• người vận hành xem lại,
• quyết định phân công.

Với sàn giáo dục, ghép phải tính:

• môn học,
• cấp độ,
• độ tuổi,
• múi giờ và lịch rảnh,
• học một kèm một hay học nhóm,
• ngân sách,
• ngôn ngữ,
• chất lượng giáo viên,
• mong muốn của phụ huynh,
• tải làm việc của giáo viên,
• công bằng cho bên dạy,
• rủi ro và chính sách.

Đánh đổi:

• ghép thủ công có chất lượng cao nhưng khó mở rộng,
• ghép theo luật dễ giải thích nhưng cần mô hình luật tốt,
• ghép bằng máy học có thể tăng tỷ lệ đặt lịch nhưng dễ thiên lệch và khó giải thích.

Khuyến nghị:

Giai đoạn đầu:

hỗ trợ người vận hành ghép bằng điểm theo ràng buộc.

Khi có đủ dữ liệu:

dùng máy học để tối ưu,

nhưng vẫn phải giải thích được và có kiểm soát công bằng.

10. Niềm tin và an toàn

Sàn giáo dục phải xây niềm tin từ đầu.

Không thể đợi đến khi có sự cố mới thêm kiểm duyệt.

Cần mô hình được:

• xác minh danh tính,
• xác minh bằng cấp hoặc chứng chỉ,
• hồ sơ rủi ro của bên dạy,
• duyệt dịch vụ đăng bán,
• kiểm duyệt tin nhắn,
• kiểm duyệt đánh giá,
• tín hiệu gian lận,
• điểm rủi ro,
• vi phạm chính sách,
• hành động xử lý,
• khiếu nại,
• ghi vết.

Các rủi ro thường gặp:

• bên dạy giả,
• bằng cấp giả,
• dịch vụ đăng bán cam kết quá mức,
• kéo giao dịch ra ngoài sàn,
• đánh giá giả,
• nội dung không phù hợp trẻ em,
• tài khoản bị chiếm,
• lạm dụng hoàn tiền hoặc khiếu nại thanh toán.

10.1. Ma sát theo rủi ro

Không nên bắt mọi bên dạy chịu cùng một mức kiểm tra.

Cách thực dụng:

Bên dạy mới hoặc rủi ro cao:

kiểm tra kỹ hơn,

giữ tiền lâu hơn,

giới hạn một số khả năng.

Bên dạy có lịch sử tốt:

ít ma sát hơn,

mở tiền nhanh hơn,

được hiển thị tốt hơn nếu chất lượng thật tốt.

Đánh đổi:

• kiểm duyệt thủ công chính xác hơn nhưng chậm,
• trí tuệ nhân tạo kiểm duyệt nhanh nhưng có thể sai,
• xác minh quá chặt giảm gian lận nhưng làm bên dạy tốt nản,
• chính sách quá công khai có thể giúp người xấu học cách lách.

Khuyến nghị:

• các quyết định khóa tài khoản, giữ tiền, từ chối hoàn tiền lớn phải có ghi vết,
• người bị ảnh hưởng nên có đường khiếu nại,
• không để trí tuệ nhân tạo tự ra quyết định cuối cùng ở việc nhạy cảm.

11. Chính sách và quyết định quyền

Sàn có rất nhiều chính sách:

• ai được truy cập dữ liệu nào,
• bên dạy nào được bán loại dịch vụ nào,
• dịch vụ đăng bán có được duyệt không,
• hủy lịch được hoàn bao nhiêu,
• khi nào được chuyển tiền,
• khi nào phải giữ tiền,
• đánh giá nào bị ẩn,
• nội dung nào vi phạm an toàn trẻ em,
• khi nào cần người xem lại kết quả trí tuệ nhân tạo.

Không nên viết tất cả thành các câu điều kiện rải rác trong nhiều màn hình.

11.1. Cách làm tốt hơn

Cần có một nơi quyết định chính sách cho các việc nhạy cảm.

Đầu vào:

• ai đang làm,
• muốn làm gì,
• với tài nguyên nào,
• trong bối cảnh nào.

Đầu ra:

• cho phép,
• từ chối,
• cần xem lại,
• lý do,
• phiên bản chính sách.

Ví dụ:

Phụ huynh A muốn xem bài nộp của học viên B.

Hệ phải kiểm:

A có phải phụ huynh hợp lệ của B không?

B có thuộc lớp hoặc đơn mua liên quan không?

dữ liệu này có bị hạn chế không?

11.2. Không đưa mọi thứ vào máy chính sách

Không phải mọi phép tính đều cần đưa vào máy chính sách.

Ví dụ:

• tính tổng tiền,
• tính thời lượng buổi học,
• tính tỷ lệ hoàn thành,

có thể nằm trong vùng nghiệp vụ.

Nhưng các quyết định nhạy cảm nên có chính sách và ghi vết:

• giữ tiền,
• mở tiền,
• hoàn tiền,
• khóa bên dạy,
• ẩn đánh giá,
• cấp quyền vận hành,
• xem dữ liệu trẻ em.

12. Trí tuệ nhân tạo

Trí tuệ nhân tạo trong sàn giáo dục có thể dùng để:

• tư vấn khóa học,
• gợi ý bên dạy phù hợp,
• chấm nháp,
• viết phản hồi nháp,
• kiểm duyệt nội dung đăng bán hoặc tin nhắn,
• hỗ trợ đội chăm sóc,
• giải thích vì sao gợi ý kết quả tìm kiếm,
• phân tích chất lượng bên dạy.

Nhưng không nên để trí tuệ nhân tạo:

• gọi thẳng vào cơ sở dữ liệu,
• tự quyết định tiền,
• tự khóa tài khoản,
• tự quyết định điểm chính thức,
• tự quyết định hoàn tiền,
• tự trộn dữ liệu giữa các bên dạy hoặc khách thuê.

12.1. Kiến trúc an toàn hơn

Cần có:

• cổng gọi trí tuệ nhân tạo,
• kho mẫu yêu cầu có phiên bản,
• danh sách mô hình và phiên bản,
• bộ dựng bối cảnh,
• lọc dữ liệu cá nhân và chính sách,
• nhật ký yêu cầu,
• lưu câu trả lời thô khi phù hợp,
• kiểm tra dạng đầu ra,
• bộ phân loại an toàn,
• hàng chờ người xem lại,
• bộ dữ liệu đánh giá,
• theo dõi chi phí và độ trễ.

12.2. Nguyên tắc dùng

Khuyến nghị:

Trí tuệ nhân tạo chỉ nên soạn nháp, gợi ý hoặc gắn cờ

trong các quyết định nhạy cảm.

Điểm chính thức, hoàn tiền, khóa tài khoản, giữ tiền, mở tiền

phải đi qua chính sách và con người hoặc đội vận hành khi cần.

Mọi thứ quan trọng phải có:

• phiên bản mẫu yêu cầu,
• phiên bản mô hình,
• nguồn dữ liệu đã dùng,
• người xem lại nếu có,
• kết quả cuối cùng,
• ghi vết.

13. Dữ liệu học tập và báo cáo

Cần phân biệt hai loại dữ liệu:

Dữ liệu vận hành:

dùng để xử lý giao dịch ngay.

Dữ liệu phân tích và học tập:

dùng để hiểu chất lượng, kết quả học, xếp hạng,

rủi ro và báo cáo.

Không nên để mọi bảng báo cáo đọc thẳng từ cơ sở dữ liệu giao dịch chính.

13.1. Luồng dữ liệu đề xuất

Sự kiện nghiệp vụ

-> hộp sự kiện

-> đường sự kiện

-> kho dữ liệu

-> kho vết học tập

-> dữ liệu phục vụ xếp hạng, rủi ro và trí tuệ nhân tạo

-> bảng báo cáo và dữ liệu đọc riêng.

Ví dụ sự kiện học tập:

• học viên tham gia buổi học,
• giáo viên đánh dấu hoàn thành,
• bài tập được nộp,
• phản hồi được gửi,
• kết quả được cập nhật,
• phụ huynh xem báo cáo.

13.2. Khuyến nghị theo giai đoạn

Giai đoạn đầu:

• có sự kiện từ các vùng nghiệp vụ,
• có bảng báo cáo đơn giản,
• có dữ liệu đọc riêng cho các màn hình quan trọng.

Giai đoạn sau:

• có kho dữ liệu,
• có chuẩn sự kiện học tập,
• có kho vết học tập,
• có dữ liệu phục vụ xếp hạng, rủi ro và trí tuệ nhân tạo.

Không nên biến sự kiện thành "rác nhật ký".

Mỗi sự kiện cần có nghĩa, phiên bản và người sở hữu.

14. Kết nối với hệ ngoài

Sàn giáo dục có thể cần nối với:

• công cụ học ngoài,
• hệ trường học,
• hệ quản lý lớp,
• ngân hàng câu hỏi,
• hệ chấm điểm,
• hệ hội nghị trực tuyến,
• bên thanh toán,
• bên gửi tin nhắn,
• hệ phân tích.

Cần mô hình được:

• công cụ ngoài,
• đăng ký kết nối,
• cách xác thực,
• lần mở công cụ học ngoài,
• đường nhận thông báo,
• sự kiện vào,
• sự kiện ra,
• ánh xạ kết quả ngoài vào dữ liệu nội bộ.

14.1. Không nên kết nối tự chế quá lỏng

Không nên làm kiểu:

nhúng một trang ngoài

+ truyền user_id trong đường dẫn

+ coi như xong.

Cách này rất dễ sai quyền, lộ dữ liệu và khó bán cho trường học hoặc khách doanh nghiệp.

Khuyến nghị:

• thiết kế ranh giới kết nối ngay từ đầu,
• chỉ triển khai chuẩn nào khi có đối tác hoặc khách hàng cần,
• với công cụ nhạy cảm, phải có xác thực và quyền rõ,
• dữ liệu điểm, lớp, ghi danh cần ánh xạ có kiểm soát.

15. Theo dõi, độ tin cậy và vận hành

Sàn giáo dục phải theo dõi cả sức khỏe kỹ thuật và sức khỏe nghiệp vụ.

15.1. Theo dõi kỹ thuật

Cần theo dõi:

• mã lần theo yêu cầu qua đường gọi hệ thống, việc nền và thông báo ngoài,
• nhật ký có cấu trúc,
• chỉ số hệ thống,
• lỗi,
• tuổi hàng đợi,
• số lần thử lại,
• thông báo từ bên ngoài bị trễ,
• độ trễ tìm kiếm,
• độ trễ đối soát thanh toán.

15.2. Theo dõi nghiệp vụ

Cần theo dõi:

• tỷ lệ đặt lịch thành công,
• thời gian bên dạy phản hồi,
• tỷ lệ thanh toán thành công hoặc thất bại,
• tỷ lệ hoàn tiền,
• tỷ lệ tranh chấp,
• tỷ lệ khiếu nại thanh toán,
• tỷ lệ chuyển tiền thất bại,
• sổ tiền có mất cân bằng không,
• số lệch khi đối soát,
• tỷ lệ tìm kiếm không có kết quả,
• công bằng trong lượt hiển thị,
• giáo viên vắng,
• học viên vắng,
• tỷ lệ cần người xem lại kết quả trí tuệ nhân tạo.

Khuyến nghị:

Mọi quy trình liên quan tiền phải có màn hình dòng thời gian.

Mọi hành động hỗ trợ phải ghi vết.

Mọi thông báo từ hệ ngoài phải có hộp nhận và có thể chạy lại.

Mọi lệch sổ tiền hoặc đối soát phải cảnh báo.

Nếu thiếu phần này, đội hỗ trợ sẽ không trả lời được:

• tiền đang ở đâu,
• vì sao chưa chuyển,
• buổi học đã hoàn thành chưa,
• tranh chấp đang ở bước nào,
• ai đã sửa gì.

16. Bảo mật

Sàn giáo dục có dữ liệu nhạy cảm, nhất là dữ liệu trẻ em.

Cần:

• đăng nhập an toàn,
• phân quyền theo vai trò và bối cảnh,
• ranh giới giữa người học, phụ huynh, bên dạy và nền tảng,
• phân loại dữ liệu cá nhân,
• mã hóa khi lưu và khi truyền,
• quản lý bí mật,
• ghi vết,
• thời hạn lưu dữ liệu,
• bảo vệ dữ liệu trẻ em,
• giảm tối đa dữ liệu thanh toán chạm vào hệ nội bộ,
• kiểm soát hành động quản trị.

Ví dụ quyền:

• phụ huynh chỉ xem dữ liệu của con mình,
• bên dạy chỉ xem học viên thuộc lịch hoặc lớp liên quan,
• giáo viên không được kéo dữ liệu người mua ngoài lớp,
• nhân viên nền tảng có quyền cao nhưng phải ghi vết,
• bối cảnh đưa cho trí tuệ nhân tạo không được trộn dữ liệu giữa các bên.

16.1. Những điểm phải chặn

Không có đường gọi hệ thống nào được đọc dữ liệu sàn nếu thiếu phạm vi người tham gia hoặc tổ chức.

Các hành động nhạy cảm nên cần duyệt hoặc hai bước:

• hoàn tiền lớn,
• khóa bên dạy,
• mở giữ tiền bất thường,
• sửa sổ tiền,
• xem dữ liệu trẻ em nhạy cảm,
• thay đổi chính sách thanh toán.

Đánh đổi:

• phân quyền chi tiết phức tạp hơn vai trò đơn giản,
• ghi vết đầy đủ tốn lưu trữ,
• giảm dữ liệu thu thập có thể làm báo cáo khó hơn,
• nhưng thiếu các phần này sẽ gây rủi ro lớn hơn nhiều.

17. Thực hành tốt theo từng lớp

Tóm tắt:

18. Cách triển khai theo giai đoạn

18.1. Bản đầu tiên

Nên có:

• ứng dụng web và đường gọi hệ thống chung,
• cơ sở dữ liệu chính,
• việc nền đơn giản,
• nơi lưu tệp,
• tìm kiếm đơn giản,
• môi trường thử của bên thanh toán,
• hộp sự kiện,
• bảng báo cáo cơ bản.

Mục tiêu:

• kiểm chứng mô hình sàn,
• chưa làm quá nhiều thứ phức tạp.

18.2. Bản chạy thật đầu tiên

Nên có:

• lõi chia module rõ,
• module hoặc dịch vụ riêng cho thanh toán và sổ tiền,
• máy điều phối cho tiền và tranh chấp nếu cần,
• tìm kiếm tốt hơn,
• đường sự kiện,
• kho dữ liệu,
• theo dõi vận hành,
• màn hình hỗ trợ.

18.3. Khi mở rộng

Có thể tách:

• thanh toán và sổ tiền,
• tìm kiếm và xếp hạng,
• trí tuệ nhân tạo,
• niềm tin và an toàn,
• dữ liệu học tập và báo cáo,
• thông báo,
• ứng dụng riêng cho bên dạy hoặc người học nếu cần.

Không tách vì "nghe hiện đại".

Chỉ tách khi có lý do rõ về tải, rủi ro, ranh giới và đội sở hữu.

19. Những quyết định không nên làm sớm

Không nên:

• tách quá nhiều dịch vụ khi nghiệp vụ chưa ổn định,
• tự xây ví, giữ tiền hộ hoặc chuyển tiền nếu chưa có pháp lý và nhà cung cấp phù hợp,
• lấy trí tuệ nhân tạo làm trung tâm tìm kiếm ngay từ đầu,
• để trí tuệ nhân tạo tự quyết định hoàn tiền, khóa tài khoản hoặc điểm chính thức,
• mở sàn toàn quốc khi chưa có niềm tin và vận hành tranh chấp,
• tách cơ sở dữ liệu riêng cho mọi bên dạy nhỏ ngay từ đầu,
• triển khai đầy đủ mọi chuẩn giáo dục khi chưa có khách cần,
• làm xếp hạng máy học thời gian thật khi chưa có dữ liệu lượt hiển thị, đặt lịch và kết quả học.

20. Lộ trình kiến trúc

Giai đoạn 0. Khám phá kiến trúc

Làm rõ:

• sàn bắt đầu từ mảng học nào,
• người mua là ai,
• bên dạy là ai,
• nền tảng chịu trách nhiệm thanh toán đến đâu,
• chính sách hoàn tiền và vắng học,
• các vùng nghiệp vụ chính.

Giai đoạn 1. Khung sàn lõi

Xây:

• danh tính,
• bên dạy,
• dịch vụ đăng bán,
• đặt lịch,
• đơn hàng,
• duyệt thủ công,
• ghép thủ công,
• chưa cần giữ và chuyển tiền phức tạp.

Giai đoạn 2. Tổ chức học

Xây:

• buổi học,
• điểm danh,
• bằng chứng,
• đánh giá,
• dòng thời gian cho phụ huynh, người học và bên dạy,
• sự kiện học tập.

Giai đoạn 3. Thanh toán qua bên cung cấp

Xây:

• kết nối bên thanh toán hỗ trợ sàn,
• hộp nhận thông báo,
• trạng thái thanh toán,
• sổ tiền nội bộ,
• đối soát.

Giai đoạn 4. Giữ tiền, mở tiền, chuyển tiền và tranh chấp

Xây:

• điều kiện mở tiền,
• khoản giữ lại,
• lô chuyển tiền,
• quy trình hoàn tiền và tranh chấp,
• màn hình hỗ trợ,
• phiên bản chính sách.

Giai đoạn 5. Tìm kiếm, xếp hạng và ghép

Xây:

• dữ liệu tìm kiếm,
• tín hiệu xếp hạng,
• ghi lượt hiển thị,
• thử nghiệm,
• điểm ghép,
• công bằng và khám phá bên dạy mới.

Giai đoạn 6. Mở rộng nâng cao

Thêm:

• tìm kiếm theo nghĩa,
• mô hình xếp hạng,
• máy rủi ro,
• kho vết học tập,
• ánh xạ chuẩn giáo dục,
• nền quản trị trí tuệ nhân tạo,
• nhiều vùng hạ tầng hoặc yêu cầu tuân thủ cao hơn.

21. Câu hỏi khi duyệt kiến trúc

Khi xem một sàn giáo dục, nên hỏi:

22. Kết luận

Kiến trúc sàn giáo dục tốt phải chấp nhận một sự thật:

Đây không chỉ là hệ giáo dục.

Đây không chỉ là hệ bán hàng.

Đây không chỉ là hệ thanh toán.

Đây không chỉ là sàn nhiều bên.

Nó là giao điểm của cả bốn.

Vì vậy, kiến trúc nên có:

• lõi nghiệp vụ chia ranh giới rõ,
• thanh toán qua bên cung cấp phù hợp cho sàn,
• sổ tiền nội bộ khó sửa,
• quy trình dài có trạng thái và hộp sự kiện,
• tìm kiếm và xếp hạng có dữ liệu đọc riêng,
• bằng chứng học tập,
• lớp chính sách, niềm tin và an toàn,
• trí tuệ nhân tạo có kiểm soát,
• công cụ vận hành và hỗ trợ mạnh.

Không nên bê nguyên kiến trúc của các sàn lớn vào từ ngày đầu.

Thực dụng hơn là biết:

• phần nào cần chặt như tài chính,
• phần nào cần linh hoạt như sản phẩm,
• phần nào cần chuẩn giáo dục,
• phần nào chỉ nên dùng máy học sau khi có đủ dữ liệu,
• phần nào phải giữ con người trong vòng quyết định.

Câu chốt:

Sàn giáo dục chỉ mở rộng được khi kiến trúc nối được:

niềm tin,

tiền,

lịch học,

lớp học,

bằng chứng học tập,

và vận hành tranh chấp

thành một hệ thống nhất quán.

23. Nguồn tham khảo trong bản gốc

• Stripe Docs, Platforms and marketplaces with Stripe Connect: https://docs.stripe.com/connect
• Adyen Docs, Marketplaces: https://docs.adyen.com/marketplaces/
• PayPal Commerce Platform for platforms and marketplaces: https://www.paypal.com/business/platforms-and-marketplaces
• PCI Security Standards Council, PCI DSS: https://www.pcisecuritystandards.org/standards/pci-dss/
• Stripe Engineering, Ledger system: https://stripe.dev/blog/ledger-stripe-system-for-tracking-and-validating-money-movement
• Modern Treasury Ledgers Overview: https://docs.moderntreasury.com/ledgers/docs/overview
• Temporal Platform Documentation: https://docs.temporal.io/
• Transactional outbox pattern: https://microservices.io/patterns/data/transactional-outbox
• Debezium Outbox Event Router: https://debezium.io/documentation/reference/stable/transformations/outbox-event-router.html
• Airbnb Engineering, Improving Search Ranking for Maps: https://airbnb.tech/ai-ml/improving-search-ranking-for-maps/
• Airbnb Engineering, Embedding-Based Retrieval for Airbnb Search: https://airbnb.tech/ai-ml/embedding-based-retrieval-for-airbnb-search/
• Etsy Engineering, Bringing Personalized Search to Etsy: https://www.etsy.com/codeascraft/bringing-personalized-search-to-etsy
• Etsy Engineering, Recommendations Platform: https://www.etsy.com/codeascraft/building-a-platform-for-serving-recommendations-at-etsy
• Uber Engineering: https://eng.uber.com/
• AWS Well-Architected SaaS Lens: https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/saas-lens.html
• Amazon Verified Permissions: https://docs.aws.amazon.com/verifiedpermissions/
• Open Policy Agent: https://www.cncf.io/projects/open-policy-agent-opa/
• 1EdTech OneRoster: https://www.1edtech.org/standards/oneroster
• 1EdTech LTI Core Specification: https://standards.1edtech.org/lti/specifications/core/lti-spec.md
• 1EdTech Question and Test Interoperability: https://www.1edtech.org/standards/qti/index
• 1EdTech Caliper Metric Profiles: https://www.1edtech.org/specs/caliper/caliper-metric-profiles-common-explanations
• ADL Experience API: https://adlnet.gov/projects/xapi/
• OpenTelemetry: https://opentelemetry.io/
• Google SRE, Production Services Best Practices: https://sre.google/sre-book/service-best-practices/
• NIST AI Risk Management Framework: https://www.nist.gov/itl/ai-risk-management-framework
• UNESCO Guidance for generative AI in education and research: https://www.unesco.org/en/digital-education/ai-future-learning/guidance
• Airbnb Help Center, Verifying your identity: https://www.airbnb.com/help/article/450/what-is-verified-id
• Airbnb Reviews Policy: https://www.airbnb.com/help/article/3048
• European Commission, Digital Services Act: https://digital-strategy.ec.europa.eu/en/policies/digital-services-act-package

24. Tài liệu nội bộ đã đối chiếu trong bản gốc

• bao-cao-kinh-nghiem-thiet-ke-he-thong-san-marketplace.md
• bao-cao-kinh-nghiem-thiet-ke-he-thong-elearning-ban-khoa-hoc.md
• sy_marketplace_escrow_gap_analysis_2026-05-27.md
• sy_billing_refactor_report_2026-05-27.md
• synvia_v2_architecture_decision_report_2026-05-27.md
• edtech-real/BAO-CAO-KIEN-TRUC-SYNVIA-EDTECH-CORE-V2.md