Báo cáo kiến trúc hệ thống sàn giáo dục

Ngày viết: 30/05/2026 Phạm vi: kiến trúc hệ thống sàn giáo dục nhiều bên, nơi learner/phụ huynh mua dịch vụ học tập từ provider/giáo viên/trung tâm, platform đứng giữa điều phối discovery, booking, học tập, payment, hold/release, payout, refund, dispute, rating, trust & safety, learning evidence và AI. Trọng tâm: cần những thành phần gì, giải quyết bài toán bằng kiến trúc nào, lựa chọn nào đang là SOTA/industry practice, vì sao dùng, đánh đổi gì.

Lưu ý: báo cáo này là kiến trúc domain/kỹ thuật. Những phần escrow, payout, tax, KYC/KYB, trẻ em, dữ liệu học viên và AI trong giáo dục cần review pháp lý/compliance riêng trước production.

1. Cách nghiên cứu đúng phạm vi

Tôi đối chiếu bốn nhóm tài liệu:

Kết luận nghiên cứu: kiến trúc sàn giáo dục tốt không phải là một LMS cộng thêm seller_id. Nó là một hệ thống nhiều bounded context, trong đó marketplace, learning delivery, payment ledger, trust & safety, search/matching và AI governance đều là các trục kiến trúc riêng.

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

Nếu xây thực tế, tôi khuyến nghị:

Giai đoạn đầu:

Modular monolith API-first

+ payment provider marketplace flow

+ internal double-entry ledger

+ outbox/event backbone

+ search/read model riêng

+ workflow state machines

+ ops/support console mạnh

Khi scale:

Tách riêng payment/ledger, search/ranking, AI workflow, notification, analytics/LRS

nhưng chỉ tách khi boundary, workload và team ownership đủ rõ.

Không nên bắt đầu bằng microservices toàn diện. Cũng không nên bắt đầu bằng monolith rối.

Hình dạng đúng hơn:

Modular monolith with hard boundaries

-> services by risk/workload later

Lý do:

• Marketplace có domain phức tạp, cần thay đổi nhanh.
• Payment/ledger cần độ chính xác và audit cao hơn các phần khác.
• Search/ranking cần read model và ML pipeline riêng.
• AI workflow có latency/cost/risk khác core transaction.
• EdTech delivery cần consistency về class/session/attempt/evidence.

Đánh đổi:

• Modular monolith dễ ship hơn microservices, nhưng cần kỷ luật module nghiêm.
• Tách service sớm giúp scale một số workload, nhưng tăng chi phí vận hành, distributed consistency, observability và incident response.
• Với team nhỏ/vừa, "boundary sạch trong một deployment" thường tốt hơn "20 service nhưng data vẫn rối".

3. Kiến trúc tổng thể đề xuất

Client apps

- Buyer/learner app

- Provider console

- Teacher workspace

- Parent portal

- Platform ops console

API layer

- API gateway / BFF

- Auth/session

- Tenant/participant context

- Rate limit / abuse guard

Core bounded contexts

- Identity & tenancy

- Marketplace catalog/listing

- Search & discovery

- Booking/scheduling

- Learning delivery

- Assessment/evidence

- Payment orchestration

- Marketplace ledger

- Payout/settlement

- Refund/dispute

- Trust & safety/risk

- Review/reputation

- Notification

- AI workflow

- Analytics/LRS

- Integration

Data/platform

- PostgreSQL OLTP

- Ledger store

- Outbox/event bus

- Search index/vector index

- Object storage

- Warehouse/lakehouse

- Observability stack

Điểm quan trọng: mỗi context có source of truth riêng, nhưng không nhất thiết mỗi context là một process/service riêng ngay từ đầu.

4. Bounded contexts bắt buộc

4.1. Identity & tenancy

Cần:

User

Identity

Tenant

Organization

Membership

RoleAssignment

ParentLearnerLink

ProviderAccount

ProviderOrganization

PlatformOperator

Giải quyết:

• Một người có thể là phụ huynh, học viên, giáo viên, provider member và platform staff ở các ngữ cảnh khác nhau.
• Multi-tenant SaaS và marketplace public không phải một thứ.
• Provider organization có thể là trung tâm nhỏ trong marketplace, không nhất thiết là tenant isolated.

SOTA/practice:

• AWS SaaS Lens nhấn mạnh tenant isolation, tenant-aware operations, onboarding, tiers, activity/consumption.[^aws-saas-lens]
• Với authorization phức tạp, dùng policy engine/authorization model tách khỏi business logic như Cedar/Amazon Verified Permissions hoặc OPA.[^cedar-avp][^opa]

Đánh đổi:

• Shared DB + tenant_id nhanh và rẻ, nhưng dễ leak nếu thiếu guardrail.
• DB-per-tenant mạnh về isolation, nhưng migration, reporting, onboarding và ops nặng.
• Policy engine giúp kiểm soát quyền tốt hơn, nhưng tăng latency, policy lifecycle và debugging khó hơn.

Khuyến nghị:

MVP: shared DB, tenant_id bắt buộc, row-level guard ở application + test leak.

Enterprise: hỗ trợ isolated deployment hoặc isolated database.

Marketplace: tách ProviderAccount khỏi Tenant để không nhầm SaaS tenant với marketplace seller.

4.2. Marketplace catalog/listing

Cần:

ProviderProfile

Listing

Offering

CourseOffering

LiveSessionOffering

TrialOffering

PricingPolicy

CancellationPolicy

ListingReviewWorkflow

ListingVersion

Giải quyết:

• Provider tự đăng dịch vụ/khóa học.
• Platform kiểm duyệt trước khi public.
• Listing là promise với buyer, nên cần version/policy.
• Nếu dispute xảy ra, phải biết buyer mua theo listing version nào.

SOTA/practice:

• Marketplace lớn không chỉ index text. Listing có structured metadata để search/ranking/moderation dùng.
• Etsy/Airbnb đều dựa mạnh vào listing quality, price, review, availability và nhiều tín hiệu khác trong discovery/ranking.[^airbnb-ranking][^etsy-personalized-search]

Đánh đổi:

• Listing schema chặt giúp search/policy tốt, nhưng provider nhập liệu khó hơn.
• Rich text tự do dễ onboarding, nhưng dispute/search/moderation yếu.

Khuyến nghị:

structured required fields + flexible content blocks

không cho provider public trực tiếp nếu chưa qua policy/moderation

4.3. Booking/scheduling

Cần:

BookingRequest

Booking

BookingParticipant

ScheduleSlot

AvailabilityPolicy

RescheduleRequest

CancellationRequest

NoShowCase

Session

CompletionEvidence

Giải quyết:

• Buyer mua dịch vụ học/live session.
• Provider accept/reject hoặc auto-confirm theo policy.
• Attendance/completion evidence dùng cho payout/refund/dispute.

SOTA/practice:

• Với service marketplace, booking không chỉ là order. Nó là lifecycle dài, có accept, schedule, attendance, completion, review, dispute.
• Với workflow dài ngày, dùng workflow/state machine hoặc durable execution. Temporal mô tả durable execution có thể resume sau crash/network failure và phù hợp với long-running workflows.[^temporal]

Đánh đổi:

• Workflow engine mạnh cho quy trình dài, retry, compensation, timeout, nhưng tăng vận hành và cách dev phải học.
• State machine trong DB đơn giản hơn, nhưng khi flow nhiều bước/timeout/webhook thì dễ rối.

Khuyến nghị:

MVP: explicit DB state machine + outbox + scheduled jobs.

Scale: Temporal/Cadence hoặc workflow engine cho booking/payment/dispute/payout.

4.4. Learning delivery

Cần:

LearningProduct

Curriculum

ClassCohort

Enrollment

Session

Attendance

LessonSnapshot

LearningActivity

Material

Giải quyết:

• Một listing marketplace có thể bán trial, khóa live, cohort, course async, tutoring package.
• Delivery phải tạo learning evidence cho marketplace payout và quality.

SOTA/practice:

• 1EdTech OneRoster chuẩn hóa people, courses, enrollments, organizations, grades để exchange giữa SIS/LMS/tools.[^oneroster]
• LTI cho phép platform launch external learning tools với context/user/role/security thay vì iframe tự chế.[^lti]

Đánh đổi:

• Implement chuẩn đầy đủ rất nặng.
• Không implement chuẩn từ đầu thì dễ khóa hệ sinh thái.

Khuyến nghị:

Không cần full LTI/OneRoster ngay.

Nhưng data model nên map được sang: user, org, course, class, enrollment, result.

Integration boundary nên LTI-ready.

4.5. Assessment/evidence

Cần:

AssignmentTemplate

AssessmentItem

Rubric

ActivitySnapshot

Attempt

Submission

EvidenceRecord

Feedback

Revision

TeacherReview

LearningOutcome

Giải quyết:

• Sàn giáo dục cần chứng minh chất lượng học, không chỉ hoàn tất buổi học.
• Evidence giúp dispute, ranking, provider quality và parent insight.

SOTA/practice:

• QTI cho item/test/result interoperability giữa authoring tools, item banks, delivery systems, scoring/analytics.[^qti]
• Caliper/xAPI dùng event/statement để learning analytics/LRS có dữ liệu chuẩn hóa.[^caliper][^xapi]

Đánh đổi:

• QTI/xAPI/Caliper đầy đủ sẽ tốn nhiều effort.
• Schema nội bộ tự chế nhanh hơn nhưng dễ thành ngõ cụt.

Khuyến nghị:

Nội bộ dùng schema tối thiểu nhưng có version.

Thiết kế mapper ra QTI/Caliper/xAPI sau.

Không lưu learning evidence chính trong JSON tự do không version.

5. Payment architecture

5.1. Thành phần cần có

PaymentIntent

Charge

PaymentProviderAccount

MarketplaceOrder

LedgerAccount

LedgerTransaction

LedgerEntry

ProviderPayable

PlatformFee

ReserveHold

ReleaseCondition

PayoutBatch

PayoutItem

Refund

Dispute

Chargeback

ReconciliationRun

WebhookInbox

5.2. SOTA/practice

Stripe Connect, Adyen for Platforms và PayPal Commerce Platform đều được thiết kế cho platform/marketplace: onboarding seller/provider, split payments, payouts, refunds, disputes.[^stripe-connect][^adyen-marketplaces][^paypal-commerce]

Stripe Ledger và Modern Treasury Ledgers đều nhấn mạnh double-entry/immutable ledger cho dòng tiền phức tạp.[^stripe-ledger][^modern-treasury-ledger]

Điểm mấu chốt:

Payment provider balance không phải source of truth nội bộ.

Invoice không phải ledger.

Order không phải payout.

Webhook không phải sự thật tuyệt đối nếu chưa reconcile.

5.3. Kiến trúc đề xuất

Buyer checkout

-> PaymentOrchestrator tạo payment intent/charge

-> WebhookInbox nhận event từ PSP

-> Payment state machine cập nhật charge/order

-> Ledger ghi double-entry

-> Release workflow đợi completion evidence

-> ProviderPayable chuyển eligible

-> Payout batch gửi PSP

-> Reconciliation đối chiếu PSP/ledger/bank

5.4. Vì sao dùng payment provider marketplace thay vì tự làm?

Lý do:

• KYC/KYB/payout/global payment là một sản phẩm tài chính riêng.
• PCI DSS nếu tự chạm card data sẽ tăng scope bảo mật/compliance.[^pci-dss]
• Refund/dispute/chargeback cần hạ tầng provider.
• Tự giữ tiền hộ có rủi ro pháp lý.

Đánh đổi:

• Vendor lock-in.
• Fee cao.
• Flow bị giới hạn bởi provider.
• Một số quốc gia/payment method không đủ tính năng.
• Phải map nhiều trạng thái provider về state machine nội bộ.

Khuyến nghị:

MVP marketplace payment: Stripe Connect/Adyen/PayPal equivalent.

Nội bộ vẫn phải có ledger riêng để audit và reconciliation.

Không tự xây wallet/escrow khi chưa có legal/payment license.

6. Ledger architecture

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

Sàn có các câu hỏi không thể trả lời bằng bảng payment đơn giản:

• Provider A còn bao nhiêu tiền được nhận?
• Order B đã refund một phần thì commission reverse thế nào?
• Chargeback sau payout làm provider âm bao nhiêu?
• Platform fee đã earn hay còn deferred?
• Payout batch C gồm những ledger entries nào?
• PSP báo payout failed thì reverse ra sao?

6.2. SOTA/practice

Stripe mô tả ledger dựa trên double-entry để đảm bảo money movement được account bằng credits/debits.[^stripe-ledger] Modern Treasury gọi immutable, scalable double-entry ledger là gold standard cho dòng tiền phức tạp/high-velocity.[^modern-treasury-ledger]

6.3. Kiến trúc

LedgerAccount

- cash_at_psp

- provider_payable

- platform_fee_revenue

- refund_liability

- dispute_reserve

- provider_negative_balance

- promotion_expense

- tax_payable

LedgerTransaction

- immutable

- idempotency_key

- external_ref

- business_ref

- transaction_type

- status: posted/reversed/voided

LedgerEntry

- account

- debit/credit

- amount

- currency

6.4. Đánh đổi

• Tự xây ledger cần kỹ năng kế toán/kỹ thuật cao.
• Dùng Modern Treasury/ledger vendor nhanh hơn nhưng lock-in/cost.
• Ledger immutable làm sửa lỗi khó hơn: phải reversal/adjustment, không update tay.
• Multi-currency làm phức tạp hơn nhiều.

Khuyến nghị:

Nếu chỉ MVP discovery chưa giữ/split tiền: chưa cần ledger đầy đủ.

Nếu đã hold/split/payout/refund/dispute: ledger là P0.

7. Workflow architecture

7.1. Những flow dài

Provider onboarding -> verification -> capability -> payout enabled

Booking -> payment -> session -> evidence -> release -> review

Refund request -> evidence -> decision -> ledger reversal -> PSP refund

Dispute -> collect evidence -> submit to PSP -> decision -> ledger adjustment

Payout -> batch -> PSP payout -> bank result -> reconciliation

AI grading -> context -> model -> validation -> teacher review -> publish

7.2. SOTA/practice

Temporal/durable execution dùng cho workflow dài, có crash recovery và resume execution.[^temporal] Transactional outbox/Debezium Outbox xử lý bài toán update DB và publish event đáng tin cậy mà không cần distributed transaction.[^transactional-outbox][^debezium-outbox]

7.3. Kiến trúc

Command handler

-> write domain state + outbox event trong cùng DB transaction

-> event relay publish

-> workflow/process manager nhận event

-> gọi activity/job

-> ghi state transition

-> phát event tiếp theo

7.4. Đánh đổi

• Workflow engine giảm rối cho long-running flow, nhưng tăng hạ tầng và cần deterministic workflow discipline.
• Outbox tăng reliability, nhưng event consumer phải idempotent.
• Event-driven dễ scale, nhưng debugging khó nếu không có tracing/timeline.

Khuyến nghị:

MVP: outbox + explicit state machine + idempotency.

Scale: workflow engine cho payment/booking/dispute/payout, không dùng cron rời rạc.

8. Search/ranking architecture

8.1. Cần gì?

Listing index

Provider index

Availability index

Learning outcome index

Quality/risk signals

Buyer intent

Query understanding

Retrieval

Ranking

Business/risk guardrails

Experimentation

Exposure logging

8.2. SOTA/practice

Airbnb Search dùng ranking để kết nối guest với host; Airbnb EBR dùng embedding-based retrieval, ANN và online serving để lấy candidate chất lượng trong không gian listing lớn.[^airbnb-ranking][^airbnb-ebr] Etsy dùng personalized search, ML ranking và recommendation architecture cho catalog hàng chục triệu listing/seller.[^etsy-personalized-search][^etsy-recs]

SOTA thực tế hiện nay:

Stage 1: hard filters + lexical retrieval

Stage 2: vector/embedding retrieval hoặc semantic expansion

Stage 3: learning-to-rank reranker

Stage 4: business/risk/fairness guardrails

Stage 5: diversification/exploration

Stage 6: logging + offline/online evaluation

8.3. Kiến trúc đề xuất cho sàn giáo dục

SearchWriteModel

-> ListingPublished event

-> ProviderUpdated event

-> AvailabilityChanged event

-> QualityScoreUpdated event

-> SearchIndexer

-> SearchDocument

-> Search API

-> Retrieval

-> Ranker

-> PolicyGuardrail

-> Results + explanation hints

-> ExposureLog

Signals nên có:

teacher qualification

schedule fit

subject/level fit

language fit

parent/student review

completion rate

refund/dispute rate

response time

price competitiveness

provider reliability

new provider exploration quota

child safety flags

8.4. Vì sao không dùng LLM search ngay?

LLM có thể giúp query understanding, summarization, recommendation explanation. Nhưng search marketplace cần:

• latency thấp;
• deterministic filters;
• ranking explainability;
• anti-gaming;
• experimentation;
• compliance;
• exposure fairness.

LLM không thay thế retrieval/ranking stack. Nó là một layer hỗ trợ.

Đánh đổi:

• Search lexical đơn giản dễ làm nhưng relevance kém.
• Vector search tăng semantic match nhưng có latency/cost và khó giải thích.
• ML ranker tốt hơn nhưng cần dữ liệu, feature pipeline, A/B test.
• Fairness/exploration giảm short-term conversion nhưng giúp marketplace khỏe dài hạn.

Khuyến nghị:

MVP: Postgres/OpenSearch lexical + structured filters + simple scoring.

V1: add signal-based ranking + exposure logs + A/B tests.

V2: add embedding retrieval/vector index + ML ranker + fairness/exploration.

9. Matching/scheduling architecture

Search để buyer tự chọn. Matching để platform đề xuất/gán.

Cần:

LearnerIntent

PlacementProfile

ProviderCapability

Availability

Constraints

MatchCandidate

MatchScore

ManualReview

AssignmentDecision

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

• môn học/level;
• độ tuổi;
• timezone/lịch rảnh;
• format 1-1/group;
• ngân sách;
• ngôn ngữ;
• teacher quality;
• parent preference;
• workload/fairness;
• policy/risk.

SOTA:

• Marketplace real-time như Uber dùng forecasting/matching/pricing ở quy mô lớn, nhưng giáo dục không cần realtime milliseconds ở MVP.[^uber-marketplace]
• SOTA thực dụng là constraint-based matching trước, ML sau khi có dữ liệu.

Đánh đổi:

• Manual matching chất lượng tốt nhưng không scale.
• Constraint solver dễ explain hơn ML nhưng cần model hóa rule tốt.
• ML matching tối ưu conversion nhưng dễ bias và khó giải thích.

Khuyến nghị:

MVP: assisted matching + constraint scoring.

Scale: optimize bằng ML sau khi có đủ booking/outcome data.

10. Trust & Safety architecture

Cần:

IdentityVerification

CredentialVerification

ProviderRiskProfile

ListingModeration

MessageModeration

ReviewModeration

FraudSignal

RiskScore

PolicyViolation

EnforcementAction

Appeal

AuditLog

Giải quyết:

• Provider giả.
• Bằng cấp giả.
• Listing cam kết quá đà.
• Lôi kéo giao dịch off-platform.
• Review gian lận.
• Nội dung không phù hợp trẻ em.
• Account takeover.
• Chargeback/refund abuse.

SOTA/practice:

• Airbnb identity verification và review policy cho thấy trust là feature lõi, không phải hậu trường.[^airbnb-identity][^airbnb-review-policy]
• EU DSA đặt yêu cầu minh bạch/trader traceability/recommender controls với online platforms/marketplaces ở EU.[^eu-dsa]

Đánh đổi:

• Review thủ công tăng chất lượng nhưng chậm.
• AI moderation nhanh nhưng false positive/false negative.
• Identity/KYC chặt giảm fraud nhưng giảm provider conversion.
• Policy minh bạch giúp trust nhưng cũng giúp bad actors học cách lách.

Khuyến nghị:

Risk-based friction:

provider mới/rủi ro cao -> kiểm chặt, payout chậm

provider tốt/lịch sử sạch -> ít friction hơn

11. Policy architecture

Marketplace có rất nhiều policy:

access policy

provider capability policy

listing approval policy

booking cancellation policy

refund policy

payout policy

reserve policy

review policy

child safety policy

AI review policy

Không nên hard-code tất cả trong view/service rời rạc.

SOTA/practice:

• OPA là general-purpose policy engine, đã là CNCF graduated project.[^opa]
• Cedar/Amazon Verified Permissions dùng PARX principal-action-resource-context, hỗ trợ policy-based fine-grained authorization.[^cedar-avp]

Đề xuất:

PolicyDecisionService

input: actor, action, resource, context

output: allow/deny/review_required + reason_code + policy_version

PolicyStore

PolicyVersion

DecisionLog

PolicyTestSuite

Đánh đổi:

• Policy engine tốt cho audit/consistency.
• Nhưng policy externalization có thể làm dev khó debug.
• Không nên đưa mọi business rule nhỏ vào OPA/Cedar từ ngày đầu.

Khuyến nghị:

Core authorization + sensitive decisions dùng policy engine/policy service.

Business calculation thuần domain vẫn ở domain service.

Mọi quyết định tiền/trust/suspend/refund phải log policy_version.

12. AI architecture

AI trong sàn giáo dục có nhiều vai trò:

• tư vấn khóa học;
• gợi ý matching;
• chấm bài draft;
• sinh feedback;
• moderation listing/message;
• support assistant;
• ranking explanation;
• provider quality insight.

Không nên để AI gọi thẳng DB và tự quyết định tiền/quyền/điểm.

12.1. Kiến trúc

AI Gateway

Prompt Registry

Model Registry

Context Builder

PII/Policy Filter

Request Log

Response Raw Store

Structured Output Validator

Safety Classifier

Human Review Queue

Evaluation Set

Cost/Latency Monitor

12.2. SOTA/practice

NIST AI RMF là framework quản lý rủi ro AI theo hướng trustworthy/responsible.[^nist-ai-rmf] UNESCO guidance for generative AI in education nhấn mạnh human agency, inclusion, equity, privacy và governance trong giáo dục.[^unesco-ai]

12.3. Đánh đổi

• AI tăng tốc tư vấn/chấm/moderation, nhưng hallucination và bias ảnh hưởng trust.
• RAG giúp dùng context nội bộ, nhưng có rủi ro leak dữ liệu tenant/provider.
• Multi-model gateway tránh lock-in, nhưng tăng test/eval complexity.
• Human review tăng an toàn nhưng tốn ops.

Khuyến nghị:

AI chỉ draft/recommend/flag ở các quyết định nhạy cảm.

Official grade, refund, suspend, payout hold phải có policy + human/ops path.

Prompt/model/context phải versioned và audit được.

13. Analytics/LRS/data architecture

Cần hai loại dữ liệu:

Operational data: phục vụ giao dịch ngay.

Analytical/learning data: phục vụ insight, ranking, quality, learning outcome.

Không nên query dashboard trực tiếp từ OLTP cho mọi thứ.

Kiến trúc:

Domain events/outbox

-> event bus

-> warehouse/lakehouse

-> learning record store

-> feature pipeline

-> reporting/read models

SOTA/practice:

• Caliper chuẩn hóa learning analytics events/profiles.[^caliper]
• xAPI dùng statements và LRS cho learning activity records.[^xapi]
• OpenTelemetry chuẩn hóa traces/metrics/logs cho observability, không thay thế learning analytics.[^opentelemetry]

Đánh đổi:

• Warehouse/LRS sớm giúp analytics, nhưng tăng chi phí.
• Event schema cần governance, nếu không trở thành log rác.
• Near-real-time feature pipeline phức tạp hơn batch.

Khuyến nghị:

MVP: outbox events + analytics tables/read models.

V1: event bus + warehouse + learning event schema.

V2: LRS/Caliper/xAPI mapping + feature store cho ranking/risk/AI.

14. Integration architecture

Cần:

ExternalTool

IntegrationRegistration

OAuth/OIDC client

LTI Launch

WebhookEndpoint

InboundEvent

OutboundEvent

ExternalResultMapping

SOTA/practice:

• LTI Core 1.3 dùng IMS Security Framework cho message/service authentication và integration external learning tools.[^lti]
• OneRoster/Edu-API giúp exchange roster/grade/class data.
• QTI giúp assessment interoperability.

Đánh đổi:

• Tự làm integration nhanh hơn nhưng khó bán B2B/enterprise.
• LTI/QTI/OneRoster cần effort, certification có thể tốn.

Khuyến nghị:

Thiết kế integration boundary ngay.

Chỉ implement chuẩn nào khi có partner/customer cần.

Không nhúng iframe + truyền user_id tự chế cho tool nhạy cảm.

15. Observability, reliability và ops architecture

Marketplace cần quan sát cả technical và domain health.

15.1. Technical observability

trace_id xuyên API/job/workflow/webhook

structured logs

metrics

distributed traces

error budget

queue age

job retry/failure

webhook lag

search latency

payment reconciliation lag

OpenTelemetry cung cấp framework observability cho cloud-native software, gồm traces, metrics, logs và context propagation.[^opentelemetry] Google SRE dùng SLO/error budget để cân bằng release speed và reliability.[^google-sre]

15.2. Domain observability

booking success rate

provider response time

payment success/failure

refund rate

dispute rate

chargeback rate

payout failure rate

ledger imbalance = 0

reconciliation mismatch count

search zero-result rate

ranking exposure fairness

teacher no-show rate

student no-show rate

AI review required rate

Đánh đổi:

• Logging nhiều tốn tiền và có rủi ro PII.
• Metrics ít thì incident mù.
• Tracing mọi thứ có overhead.

Khuyến nghị:

Mọi money workflow phải có timeline/debug view.

Mọi support action phải audit.

Mọi external webhook phải có inbox/replay.

Mọi ledger/reconciliation mismatch phải alert.

16. Security architecture

Cần:

AuthN: OIDC/OAuth/session

AuthZ: RBAC + ABAC + policy engine

Tenant/provider boundary

PII classification

Encryption at rest/in transit

Secrets management

Audit log

Data retention

Child data protections

Payment data minimization

Admin action controls

Với giáo dục:

• Phụ huynh chỉ xem con mình.
• Provider không được xem dữ liệu học viên ngoài booking/lớp.
• Teacher không được kéo data buyer/provider khác.
• Platform ops có quyền cao nhưng phải audit.
• AI context không được trộn tenant/provider.

Đánh đổi:

• Fine-grained auth phức tạp hơn role đơn giản.
• Audit đầy đủ tốn storage và thiết kế tốt.
• Data minimization đôi khi làm analytics khó hơn.

Khuyến nghị:

Không có endpoint nào được query marketplace data nếu thiếu participant/tenant scope.

Sensitive admin actions cần maker-checker hoặc approval khi liên quan tiền/suspend/refund lớn.

17. SOTA tổng hợp theo lớp

18. Deployment topology đề xuất

MVP

Web/API monolith

PostgreSQL

Redis/Celery

Object storage

Search engine đơn giản

Payment provider sandbox

Outbox table

Basic warehouse/read model

V1 production

API/BFF

Core modular backend

Dedicated payment/ledger module or service

Workflow engine for money/dispute

OpenSearch/vector-capable search

Event bus

Warehouse

Observability stack

Ops console

Scale

Payment/ledger service isolated

Search/ranking service

AI workflow service

Trust & safety/risk service

Analytics/LRS platform

Notification service

Provider/buyer mobile apps if needed

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

Không nên:

• Full microservices trước khi có domain stability.
• Tự xây escrow/wallet/payout nếu chưa có legal/provider.
• LLM-first search.
• AI tự quyết định refund/suspend/official grade.
• Public marketplace toàn quốc ngay.
• DB-per-tenant mặc định cho mọi khách nhỏ.
• Full 1EdTech certification khi chưa có integration customer.
• Real-time ML ranking khi chưa có exposure/conversion/outcome data.

20. Roadmap kiến trúc

Phase 0: Architecture discovery

• Chốt marketplace wedge.
• Chốt buyer/provider roles.
• Chốt payment responsibility.
• Chốt policy/refund/no-show.
• Vẽ bounded contexts.

Phase 1: Core marketplace skeleton

• Identity/tenant/provider.
• Listing/offering.
• Booking/order.
• Manual approval.
• Manual matching.
• No hold/payout yet.

Phase 2: Learning delivery integration

• Session/attendance.
• Evidence.
• Review.
• Parent/learner/provider timeline.
• Learning event schema.

Phase 3: Payment provider marketplace flow

• Connect/Adyen/PayPal integration.
• Webhook inbox.
• Payment state machine.
• Internal double-entry ledger.
• Reconciliation.

Phase 4: Hold/release/payout/dispute

• Release condition.
• Reserve.
• Payout batch.
• Refund/dispute workflow.
• Support console.
• Policy versions.

Phase 5: Search/ranking/matching

• Search index.
• Ranking signals.
• Exposure logs.
• Experimentation.
• Matching score.
• Fairness/exploration.

Phase 6: SOTA expansion

• Vector/embedding retrieval.
• ML ranker.
• Risk engine.
• LRS/Caliper/xAPI mapping.
• AI governance/eval platform.
• Multi-region/compliance.

21. Kết luận

Kiến trúc hệ thống sàn giáo dục tốt phải chấp nhận một sự thật: đây không chỉ là EdTech, không chỉ là ecommerce, không chỉ là payment, và không chỉ là marketplace. Nó là giao điểm của cả bốn.

Kiến trúc nên dùng:

Domain-first modular core

+ payment provider marketplace flow

+ internal immutable double-entry ledger

+ workflow/outbox reliability

+ search/ranking read models

+ learning evidence/LRS-ready data

+ policy/trust/safety layer

+ AI governance

+ ops/support tooling

SOTA đáng học không phải là bê nguyên kiến trúc Airbnb/Uber/Stripe vào từ ngày đầu. SOTA thực dụng là biết lớp nào cần độ chặt như fintech, lớp nào cần linh hoạt như product, lớp nào cần chuẩn edtech, lớp nào cần ML/ranking sau khi có data, và lớp nào phải giữ con người trong vòng quyết định.

Một câu chốt:

Sàn giáo dục chỉ scale được khi kiến trúc nối được niềm tin, tiền, 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.

22. Nguồn tham khảo

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

23. Tài liệu nội bộ đã đối chiếu

• 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