Báo cáo quyết định kiến trúc toàn hệ thống OPSKOO Global

Ngày lập: 2026-05-30

Phạm vi: quyết định kiến trúc toàn hệ thống cho OPSKOO - một nền tảng sàn giáo dục global có marketplace, trust layer, transaction/payment, LMS, CRM/operation, AI engine, social/community và SaaS subscription cho giáo viên/trung tâm.

Tài liệu nội bộ đã đọc:

• [BẢN RÚT GỌN] OPSKOO - DẠNG TEXT.MD: tầm nhìn CEO, mô tả hệ sinh thái OPSKOO rộng: marketplace, AI, trust score, escrow, LMS, CRM, social, live class, reputation, learner achievement, subscription.
• Bản sao của [OPSKOO] KẾ HOẠCH TRIỂN KHAI MVP & CÁC HẠNG MỤC CẦN THỰC HIỆN _27052026.xlsx: kế hoạch MVP thực dụng hơn: validate giáo viên/trung tâm có sẵn sàng dùng OPSKOO để có thêm học viên; ưu tiên discovery, profile/trust, marketplace transaction, LMS cơ bản, CRM đơn giản; live class dùng link ngoài; AI/social chưa làm sâu.
• bao-cao-danh-gia-gemini-huong-dan-chon-kien-truc.md: đánh giá lại tranh luận Django vs .NET/NestJS trong bối cảnh AI agent và không cần Django Admin.
• Các báo cáo đã viết trước: eLearning/LMS, sàn giáo dục, marketplace, payments/ledger, identity/IAM, media/streaming, SaaS, microservices, data platform, AI agent, search/ranking, nguyên lý hệ thống lớn/global.

1. Kết luận điều hành

Nếu OPSKOO là dự án mới, không cần Django Admin, API-first, có AI agent hỗ trợ code, mục tiêu là nền tảng dài hạn cho marketplace + LMS + SaaS + global, tôi khuyến nghị:

Core backend: ASP.NET Core modular monolith.

Frontend: Next.js App Router cho web marketplace, teacher/center console, student app và ops console.

Database: PostgreSQL managed, pooled multi-tenant, module boundary rõ, chưa tách database per service.

Architecture style: domain-first modular monolith, ports/adapters ở biên giới thật, outbox cho event quan trọng.

Payments: provider-first, ledger-aware, không tự gọi là escrow nếu chưa có pháp lý/payment provider phù hợp.

Identity: ASP.NET Core Identity ban đầu, thiết kế OIDC-ready; Keycloak/OpenIddict/Cognito chỉ khi cần SSO/enterprise.

Search: Postgres FTS + filter/scoring trước; OpenSearch/Meilisearch/vector/LLM matching sau khi có dữ liệu.

Media/live: dùng object storage + CDN; live class dùng Zoom/Meet/external link ở MVP; không tự build video platform.

AI: workflow-first, human-in-the-loop, AI hỗ trợ format nội dung/bài tập trước; chưa làm agent tự trị/chấm điểm chính thức.

Deployment: managed cloud, single-region trước, global edge/CDN trước, multi-region sau.

Nói ngắn:

OPSKOO không nên bắt đầu bằng microservices.

OPSKOO cũng không nên bắt đầu bằng Django nếu không cần Django Admin.

OPSKOO nên bắt đầu bằng .NET modular monolith có kỷ luật.

Lý do chính:

• OPSKOO là hệ thống nhiều domain: marketplace, learning, payment, entitlement, trust, CRM, media, AI, SaaS tenant. Nếu dùng framework lỏng và không có type/boundary tốt, AI agent dễ tạo code dính chéo.
• Bạn không cần lợi thế lớn nhất của Django là Admin dựng nhanh.
• .NET hiện đại có ASP.NET Core, EF Core, Identity, DI, middleware, background services, type safety, performance và project boundary tốt cho modular monolith.[^aspnet-overview][^ef-core][^ms-identity]
• AI agent làm giảm chi phí học syntax/boilerplate, nhưng compiler/type system mới là lớp kiểm soát quan trọng khi AI viết nhiều code.
• SOTA thực dụng không phải "microservices ngay", mà là domain-first, observable, evolvable modular core; chỉ tách service khi có boundary, owner, data và pain thật.[^fowler-microservices][^fowler-prereq]

2. Điều OPSKOO thực sự đang xây

Tài liệu CEO mô tả OPSKOO như một hệ sinh thái:

Marketplace -> AI Engine -> Trust & Rating -> Payment & Escrow

-> LMS -> Data & Analytics -> Social/Community

File MVP của bạn thực dụng hơn:

Mục tiêu MVP:

"Validate rằng giáo viên và trung tâm sẵn sàng dùng Opskoo để có thêm học viên."

Đây là điểm cực kỳ quan trọng. MVP không phải để chứng minh:

• AI có thể cá nhân hóa toàn bộ việc học,
• social network giáo dục có thể tự tăng trưởng,
• escrow hoàn chỉnh có thể hoạt động ở nhiều quốc gia,
• live class native có thể thay Zoom,
• LMS cạnh tranh ngay với Moodle/Open edX,
• marketplace ranking có thể tối ưu như Airbnb/Uber.

MVP phải chứng minh một vòng lặp hẹp:

Provider onboard -> profile/listing đủ tin -> learner discover -> booking/enroll

-> payment/order evidence -> learner được access class/course

-> provider quản lý lead/lớp/học viên cơ bản -> Opskoo thu được phí/hoa hồng.

Do đó kiến trúc phải phục vụ 2 mục tiêu đồng thời:

1. Ra sản phẩm đủ nhanh để validate provider acquisition. 2. Không tự khóa mình vào model sai ở các domain khó: payment, entitlement, trust, tenant, learning progress, data, AI.

3. Nguyên tắc kiến trúc nền

3.1. Domain-first, không framework-first

Quyết định quan trọng nhất không phải .NET hay Django. Quyết định quan trọng nhất là OPSKOO phải có các domain source of truth rõ.

Các source of truth ban đầu:

SOTA không phải dùng DDD để vẽ sơ đồ đẹp. SOTA là biết mỗi trạng thái quan trọng thuộc về ai, ai được sửa, sửa khi nào, có audit không, và state machine là gì.

Đánh đổi:

• Chia domain kỹ hơn sẽ chậm hơn lúc đầu.
• Nhưng nếu không chia, AI agent sẽ viết code nhanh hơn nhưng tạo nợ kiến trúc nhanh hơn.

3.2. Modular monolith trước, microservices sau

Microservices chỉ đáng dùng khi có:

• domain boundary ổn định,
• owner/team rõ,
• deployment độc lập có giá trị,
• data ownership rõ,
• observability và CI/CD đủ,
• failure mode được hiểu,
• nhu cầu scale/failure isolation thật.

Fowler nhấn mạnh microservices cần automation, monitoring và rapid deployment; nếu chưa có những điều này, microservices tạo chi phí vận hành lớn hơn lợi ích.[^fowler-prereq]

Quyết định:

OPSKOO MVP/V1 dùng modular monolith.

Không tách microservices theo bảng hoặc theo tính năng ngay.

SOTA không?

Có. Với startup/product mới, modular monolith là SOTA thực dụng khi domain còn đang khám phá. Microservices là bước tiến hóa, không phải điểm xuất phát.

Giải pháp tệ hơn:

• Tách sớm Identity, Course, Payment, LMS, CRM, AI thành nhiều service khi domain chưa rõ.
• Dùng Kafka/OpenSearch/Keycloak/Kubernetes từ ngày đầu chỉ để trông "global".

Giải pháp tốt hơn trong tương lai:

• Extract Search, Media processing, AI workflow, Payment reconciliation hoặc Notification khi có workload/owner/data contract thật.

Đánh đổi:

• Modular monolith cần kỷ luật boundary, architecture tests và code review.
• Nếu team thiếu kỷ luật, nó dễ thành big ball of mud.

3.3. Global-first không có nghĩa multi-region-first

OPSKOO có thể phục vụ global bằng:

• CDN global,
• object storage,
• internationalized UI,
• timezone/currency/language model đúng,
• payment provider theo thị trường,
• privacy/data residency chuẩn bị sẵn,
• single-region core app ban đầu.

Không cần multi-region active-active ngay.

AWS Well-Architected nhấn mạnh vận hành, bảo mật, reliability, performance, cost và sustainability như các trụ cột thiết kế; multi-region chỉ là một phương án trong reliability/performance, không phải mặc định.[^aws-waf]

Quyết định:

MVP/V1: single primary region, edge/CDN global.

Scale: thêm read replica/region/cell khi có dữ liệu traffic và compliance.

Đánh đổi:

• Single region có latency xa hơn cho một số thị trường.
• Nhưng complexity thấp hơn rất nhiều, phù hợp giai đoạn validate.

4. Quyết định stack tổng thể

4.1. Backend core: ASP.NET Core

Quyết định:

Chọn ASP.NET Core cho backend core OPSKOO.

Vì sao chọn:

• Không cần Django Admin, nên lợi thế lớn của Django giảm mạnh.
• ASP.NET Core là cross-platform, high-performance, open-source và cloud-ready.[^aspnet-overview]
• C# type system + compiler giúp kiểm soát code do AI agent sinh ra tốt hơn Python động.
• DI/middleware/options/background services/Auth/EF Core là nền chính quy, không cần tự ráp nhiều như Node/FastAPI.
• Project references trong .NET giúp ép boundary giữa modules tốt hơn Django apps.
• EF Core đủ mạnh cho domain transactional phức tạp nếu dùng có kỷ luật.[^ef-core]

SOTA không?

Có, nếu hiểu SOTA là practice hiện đại cho API-first enterprise backend: type-safe, modular, observable, cloud-native, containerized. .NET không phải "lựa chọn lạ" nữa.

Giải pháp tốt hơn trong vài case:

• Django: nếu cần admin/backoffice rất nhanh và team Python mạnh.
• FastAPI: nếu lõi sản phẩm là AI/data Python hoặc API nhẹ.
• NestJS: nếu team fullstack TypeScript và muốn một ngôn ngữ cả FE/BE.
• Go: nếu cần service nhỏ, cực nhẹ, throughput cao, ít domain ORM.

Vì sao không chọn Django cho OPSKOO mới:

• Không cần Django Admin.
• Domain OPSKOO phức tạp, cần boundary/type/refactor an toàn.
• AI agent trong Python dễ viết logic vào view/serializer/model nếu không kiểm soát rất chặt.
• Django vẫn tốt, nhưng không còn là lựa chọn mặc định khi lợi thế Admin bị loại.

Vì sao không chọn NestJS:

• TypeScript tốt, nhưng Node/NestJS yếu hơn .NET ở CPU-bound và backend enterprise primitives.
• ORM/transaction maturity của .NET/EF Core tốt hơn nhiều case TypeORM/Prisma.
• NestJS vẫn hợp nếu muốn fullstack TS, nhưng không có lợi thế quyết định cho OPSKOO.

Đánh đổi:

• Bạn phải chấp nhận học .NET hiện đại: Minimal API, EF Core, Identity, middleware, background jobs, LINQ.
• Thiếu Django Admin có sẵn; ops console phải tự build.
• EF Core có bẫy N+1, tracking, query translation, migration; cần discipline.

4.2. Backend architecture style: modular monolith + Clean Architecture vừa đủ

Quyết định:

Không dùng ABP làm nền chính.

Không dùng eShop làm template.

Dùng ASP.NET Core modular monolith với Clean Architecture vừa đủ.

Cấu trúc đề xuất:

opskoo/

src/

Opskoo.Api/ # HTTP host, middleware, auth, endpoint registration

Opskoo.Modules.Identity/

Opskoo.Modules.Tenancy/

Opskoo.Modules.Catalog/

Opskoo.Modules.Trust/

Opskoo.Modules.Marketplace/

Opskoo.Modules.Orders/

Opskoo.Modules.Payments/

Opskoo.Modules.Entitlements/

Opskoo.Modules.Learning/

Opskoo.Modules.Assessment/

Opskoo.Modules.Crm/

Opskoo.Modules.Media/

Opskoo.Modules.Search/

Opskoo.Modules.AI/

Opskoo.Modules.Notifications/

Opskoo.Modules.Operations/

Opskoo.SharedKernel/

Opskoo.Infrastructure/

tests/

ArchitectureTests/

ModuleTests/

IntegrationTests/

ContractTests/

deploy/

terraform-or-pulumi/

docker/

github-actions/

Nguyên tắc:

• Module chỉ expose application contracts/use cases cần thiết.
• Không truy cập DbContext/bảng của module khác tùy tiện.
• Không tạo interface cho mọi class; chỉ dùng ports/adapters ở boundary thật: payment, email, storage, AI provider, search engine, external meeting provider, future service call.
• Domain events trong monolith là công cụ giảm coupling, không phải cái cớ để làm event soup.
• Outbox cho event quan trọng liên quan payment, entitlement, notification, analytics.

SOTA không?

Có. "Clean Architecture vừa đủ" là SOTA thực dụng: giữ domain/application/infrastructure tách nhưng không biến project thành giáo điều.

Giải pháp tốt hơn trong vài case:

• ABP: nếu muốn có sẵn multi-tenancy, admin, audit, permission và chấp nhận học luật ABP.
• Vertical slice architecture: nếu muốn mỗi feature/use case tự chứa handler/validator/endpoint, giảm layer ceremony.
• Full CQRS/MediatR: nếu team đã quen và domain workflow phức tạp.

Giải pháp tệ hơn:

• Controller gọi thẳng EF Core khắp nơi.
• Shared CommonService chứa mọi business logic.
• Interface cho mọi class, dẫn tới ceremony vô ích.

Đánh đổi:

• Clean Architecture cần discipline.
• Nếu quá nhiều layer, AI agent có thể gen nhiều file nhưng logic khó đọc.
• Cần architecture tests để boundary không bị phá.

4.3. Frontend: Next.js App Router

Quyết định:

Chọn Next.js App Router cho web marketplace, provider console, student app và ops console.

Vì sao chọn:

• Marketplace cần SEO cho profile giáo viên/trung tâm/khóa học.
• Next.js App Router dùng Server Components, streaming, server-side data fetching và route conventions hiện đại.[^next-app][^next-rsc]
• Dễ xây nhiều app shell: public marketplace, learner portal, provider console, ops console.
• React ecosystem mạnh cho UI/interaction/dashboard.

SOTA không?

Có, với web marketplace/API-first hiện nay. Server Components là hướng hiện đại để giảm JS client và fetch data gần nguồn hơn, nhưng cần hiểu caching/server-client boundary.

Kiến trúc frontend đề xuất:

apps/web-marketplace # public SEO pages

apps/learner-portal # learner app

apps/provider-console # teacher/center dashboard

apps/ops-console # Opskoo internal operations

packages/ui

packages/api-client

packages/design-system

BFF có cần không?

Ban đầu:

Không cần BFF service riêng.

Next.js server layer có thể đóng vai thin web BFF cho SSR/session/page aggregation.

Khi scale:

• Mobile app có thể có Mobile BFF riêng.
• Ops console có thể cần Ops BFF riêng để aggregate data/report/support safely.

BFF pattern của Sam Newman hợp khi nhiều client có nhu cầu khác nhau; mỗi client có backend riêng để tránh một API backend phình to phục vụ mọi UI.[^sam-bff]

Đánh đổi:

• Next.js App Router có mental model phức tạp: cache, server/client boundary, server actions.
• Nếu lạm dụng Next.js làm business backend, sẽ tạo hai backend.
• Business truth vẫn phải nằm trong .NET core.

4.4. Mobile

Quyết định:

Không build mobile native trong MVP.

Ưu tiên responsive web/PWA-ish cho learner.

Mobile app sau khi marketplace có retention thật.

Vì sao:

• MVP cần validate provider acquisition và enrollment, không phải app store strategy.
• Mobile native kéo thêm release process, push notification, deep link, app review, offline state.

SOTA không?

Với startup marketplace, web-first là thực dụng. Mobile app hợp khi có thói quen học tập lặp lại và push/streak thực sự đóng vai trò retention.

Đánh đổi:

• Trải nghiệm mobile có thể kém native.
• Nhưng tiết kiệm lớn cho team nhỏ.

5. Domain capability map cho OPSKOO

5.1. Identity & Access

Nhiệm vụ:

• login/register,
• user identity,
• role base: learner, teacher, center owner, center staff, ops admin,
• organization membership,
• session/token,
• permission enforcement,
• audit.

Quyết định:

MVP: ASP.NET Core Identity + JWT/session strategy phù hợp web.

Thiết kế subject id ổn định, không dùng email làm identity.

Chưa dùng Keycloak ngày đầu.

Vì sao:

• ASP.NET Core Identity đủ tốt cho app-owned identity.[^ms-identity]
• Keycloak thêm ops/RAM/DB/realm complexity, không cần nếu MVP chưa có enterprise SSO.
• Nhưng data model phải OIDC-ready: subject_id, external identities, tenant memberships, login providers.

SOTA không?

Có cho MVP/SaaS early. Enterprise SSO/OIDC platform để sau.

Giải pháp tốt hơn sau này:

• OpenIddict nếu muốn chính .NET app trở thành OIDC server.[^openiddict]
• Keycloak/Cognito/Auth0/Entra ID khi có nhiều app, SSO, enterprise federation, MFA policies.

Giải pháp tệ hơn:

• Tự chế password hashing/token/session.
• Nhét toàn bộ permission vào JWT.
• Chỉ check quyền ở frontend.

Đánh đổi:

• Chuyển từ app-owned Identity sang IdP sau này cần migration.
• Nhưng nếu model subject/external identity đúng từ đầu, migration kiểm soát được.

5.2. Tenancy & Organization

OPSKOO vừa là marketplace vừa là SaaS cho giáo viên/trung tâm. Tenant không chỉ là "center".

Actor model:

Quyết định:

MVP: pooled multi-tenant PostgreSQL, tenant_id/org_id ở các bảng tenant-owned.

Tenant registry, membership, plan, limits, feature entitlement từ đầu.

Không schema-per-tenant/database-per-tenant ở MVP.

Vì sao:

• Pooled tenancy đơn giản, rẻ, nhanh.
• OPSKOO cần marketplace data chung: listing/search/review.
• Center lớn có thể cần isolation sau, nhưng chưa nên tối ưu sớm.

SOTA không?

Với SaaS early-stage, pooled tenancy + tenant-aware authorization/observability là practice thực dụng. AWS SaaS guidance cũng phân biệt pooled, silo và bridge isolation; không có một kiểu đúng cho mọi tenant.[^aws-saas]

Giải pháp tốt hơn sau này:

• Bridge model: tenant lớn có dedicated database/schema.
• Cell-based architecture cho nhóm tenant lớn.

Giải pháp tệ hơn:

• Chỉ thêm tenant_id rồi quên authorization/query safety.
• Cho support query DB thủ công.

Đánh đổi:

• Pooled tenancy có rủi ro data leak nếu query/filter sai.
• Cần architecture tests, global query filters hoặc repository guards, audit và tenant-aware metrics.

5.3. Provider Profile & Trust

Nhiệm vụ:

• teacher/center profile,
• documents: CCCD, GPKD, certificates,
• verification workflow,
• badges,
• review thật,
• trust score/rank đơn giản.

Quyết định:

MVP: verification thủ công + badge rõ + review chỉ từ enrollment thật.

OTS đầy đủ chưa làm; chỉ làm trust facts và simple trust tier.

Vì sao:

• Trust là lõi marketplace, nhưng trust score phức tạp dễ bị gaming.
• File CEO có OTS công thức 100 điểm; đây là tầm nhìn, không nên implement cứng ở MVP.
• File MVP của bạn đúng: beta chỉ cần xác thực/chưa xác thực, profile portfolio tốt, duyệt thủ công.

SOTA không?

SOTA thực dụng của trust marketplace là evidence-first:

• ai xác minh,
• xác minh cái gì,
• nguồn chứng cứ,
• hết hạn khi nào,
• ai approve/reject,
• appeal flow,
• review eligibility.

Giải pháp tốt hơn sau này:

• Credential verification APIs nếu có nguồn chính thức.
• Risk scoring/fraud detection.
• Reputation system có decay, confidence, abuse signals.

Giải pháp tệ hơn:

• Hiển thị "Top Rated" khi data mỏng.
• Dùng review trung bình 5 sao làm ranking chính.
• Cho người chưa học review.

Đánh đổi:

• Duyệt thủ công tốn ops.
• Nhưng trust thủ công ban đầu tốt hơn automation giả.

5.4. Catalog, Course Offering và Listing

Nhiệm vụ:

• course/product được bán,
• teacher/center profile,
• learning format: 1-1, group, trial, cohort/class,
• price package,
• schedule options,
• location/online,
• publish workflow.

Quyết định:

Tách Course Offering khỏi LMS Course/Class.

Marketplace bán Offering/Product.

LMS vận hành Course Run/Class/Cohort/Session.

Vì sao:

Trong LMS chuẩn, "course template", "course run/class", "lesson/session", "enrollment", "entitlement" khác nhau. Báo cáo eLearning đã nhấn mạnh Course không được ôm tất cả. Course product là lớp commerce, không phải LMS core.

Model tối thiểu:

ProviderProfile

CourseTemplate

CourseOffering # thứ bán trên marketplace

PricePackage

CourseRun/Class # lớp mở cụ thể

Session

Enrollment

Entitlement

SOTA không?

Có. Đây là domain modeling tốt hơn nhiều so với Course có tất cả field: title, price, sessions, students, progress, payment.

Giải pháp tệ hơn:

• Một bảng Course chứa cả marketing page, lớp học, học viên, bài học, payment, progress.

Đánh đổi:

• Model nhiều entity hơn.
• Nhưng tránh chết khi thêm group class, trial, package, cohort, refund, access.

5.5. Discovery, Search và Matching

Quyết định:

MVP: Postgres full-text search + structured filters + simple scoring.

V1: dedicated search engine khi corpus/query tăng.

AI matching: assistant/consulting flow, không thay search/ranking core.

Vì sao:

• File MVP cần search theo môn học, mục tiêu, trình độ, ngôn ngữ, địa chỉ, thời gian, verified, rating, price.
• PostgreSQL FTS hỗ trợ full-text search ngay trong database, đủ cho MVP nếu dữ liệu chưa lớn.[^postgres-fts]
• Search/ranking SOTA không phải "dùng vector search"; SOTA là measurable relevance: corpus truth, filters, scoring, evaluation, anti-gaming.

SOTA không?

MVP dùng lexical + filters là SOTA thực dụng. Vector/LLM matching chỉ nên thêm khi có query logs, conversion labels và feedback.

Giải pháp tốt hơn sau này:

• OpenSearch/Meilisearch khi cần dedicated search UX.
• Hybrid BM25 + vector retrieval.
• Learning-to-rank khi có dữ liệu.
• Relevance dashboard: zero-result rate, CTR, booking rate, unfair exposure.

Giải pháp tệ hơn:

• Dùng LLM để chọn top khóa học cho mọi query ngay từ đầu.
• Ranking theo revenue/commission thuần, phá trust marketplace.

Đánh đổi:

• Postgres FTS có giới hạn về relevance tuning/facets/scale.
• Nhưng giảm vận hành OpenSearch quá sớm.

5.6. Marketplace Booking, Order và Entitlement

Quyết định:

Order và Entitlement là domain riêng.

Payment paid không đồng nghĩa learner có access.

Access phải do Entitlement cấp theo rule rõ.

Vì sao:

Flow đúng:

Learner chọn offering/class -> tạo checkout/order

-> payment succeeds -> order paid

-> entitlement granted

-> enrollment active

-> learner thấy class/material/session

Nếu gộp payment/enrollment/access làm một trạng thái, refund, dispute, trial, partial access, installment, cancellation sẽ rất rối.

SOTA không?

Có. Commerce và LMS nên nối nhau bằng entitlement/access, không để payment chọc trực tiếp vào LMS.

Giải pháp tệ hơn:

• is_paid=true trên enrollment.
• Webhook payment tự tạo học viên vào lớp không idempotency.

Đánh đổi:

• Thêm một domain Entitlement ban đầu có vẻ "nặng".
• Nhưng đây là xương sống của sàn giáo dục bán khóa học.

5.7. Payments, Ledger, Refund và "Escrow"

Quyết định:

Không tự xây payment processor.

Không gọi là escrow thật nếu chưa có pháp lý/provider flow.

MVP dùng payment provider/checkout, record internal ledger-lite, idempotency, webhook verification.

Marketplace split/hold/release dùng provider platform flow khi sẵn sàng.

Vì sao:

• Marketplace payment là domain tài chính; PCI DSS áp dụng nếu chạm dữ liệu thẻ nhạy cảm.[^pci]
• Stripe Connect hỗ trợ mô hình platform/marketplace như connected accounts, separate charges and transfers/destination charges tùy flow.[^stripe-connect]
• Nhưng Việt Nam có VNPay/MoMo/ZaloPay và pháp lý riêng; cần provider phù hợp thị trường.
• "Escrow" là từ pháp lý/tài chính, không nên dùng nếu thực tế chỉ là platform hold/order guarantee.

SOTA không?

SOTA thực dụng là provider-first + ledger-aware + reconciliation-driven:

• không tự xử lý thẻ,
• webhook idempotent,
• payment state machine,
• internal ledger/journal,
• refund/dispute flow,
• reconciliation với provider,
• audit.

Giải pháp tốt hơn sau này:

• Provider hỗ trợ marketplace sub-merchant/split/hold/release.
• Double-entry ledger đầy đủ.
• Payout schedule, reserves, negative balance management.

Giải pháp tệ hơn:

• Lưu một cột teacher_balance.
• Payout ngay khi payment success.
• Tự giữ tiền hộ khi chưa rõ pháp lý.
• Không reconciliation.

Đánh đổi:

• Provider marketplace flow phức tạp, có thể giới hạn tại Việt Nam.
• Ledger chuẩn tốn công, nhưng là bảo hiểm chống sai tiền.

5.8. LMS Core

Quyết định:

MVP LMS: class/session/material/homework/progress/manual grading.

Không build SCORM/LTI/QTI đầy đủ ngay.

Thiết kế boundary chuẩn để tương lai tích hợp standards.

Vì sao:

File MVP cần:

• vào lớp sau khi đăng ký,
• tạo lớp học/lớp học thử,
• lộ trình/module,
• danh sách buổi học,
• lịch học,
• tài liệu/bài học/bài tập/đề thi,
• link vào lớp online,
• bài tập và nộp bài,
• chấm bài thủ công,
• dashboard học viên,
• progress cơ bản,
• cảnh báo bỏ học rule đơn giản.

Các chuẩn cần biết nhưng chưa implement full:

• LTI để tích hợp external learning tools.[^lti]
• OneRoster cho roster/enrollment/grade exchange.[^oneroster]
• QTI cho question/test interoperability.[^qti]
• xAPI cho learning activity events.[^xapi]

SOTA không?

SOTA MVP là standards-aware, không standards-heavy. Tức là model đúng để không bị khóa, nhưng không implement đủ chuẩn khi chưa có khách yêu cầu.

Giải pháp tốt hơn sau này:

• LTI Advantage cho tích hợp tool.
• QTI import/export question bank.
• xAPI/LRS cho analytics.
• Gradebook/rubric/override/audit chuẩn.

Giải pháp tệ hơn:

• Course = video list + completion percentage.
• Gradebook không audit override.
• AI chấm điểm chính thức không human review.

Đánh đổi:

• LMS đúng domain nhiều entity hơn.
• Nhưng giáo dục là domain có lifecycle, không phải CRUD tài liệu.

5.9. Live Class và Video/Media

Quyết định:

MVP: live class dùng Zoom/Google Meet/external link.

Không tự build WebRTC, whiteboard, recording native.

Tài liệu/video upload dùng object storage + signed URL/CDN.

Vì sao:

• Native live video/whiteboard/recording là domain lớn.
• Media system SOTA là supply chain: ingest, storage, encoding, packaging, entitlement, CDN, QoE, DRM/watermark nếu cần.
• OPSKOO MVP cần học viên vào lớp và tracking cơ bản, không cần thay thế Zoom.

SOTA không?

Có. SOTA thực dụng là buy/build đúng lớp:

• buy live class,
• build enrollment/access/schedule/evidence,
• later integrate recording/VOD pipeline.

Giải pháp tốt hơn sau này:

• Native VOD pipeline: upload -> transcode HLS/DASH -> CDN -> player telemetry.
• DRM/watermark cho premium content.
• Live-to-VOD recording pipeline.

Giải pháp tệ hơn:

• Lưu MP4 private trên server app.
• Dùng link file trực tiếp không entitlement.
• Tự build WebRTC trước khi product-market fit.

Đánh đổi:

• Dùng Zoom/Meet làm trải nghiệm rời rạc.
• Nhưng giảm rủi ro kỹ thuật khổng lồ.

5.10. CRM & Operations

Quyết định:

MVP CRM: lead profile, pipeline kanban, source, notes, follow-up, booking/enrollment link.

Không build full CRM/marketing automation như HubSpot.

Vì sao:

File MVP nói rõ:

• hồ sơ CRM của học viên,
• Kanban lead,
• lead tự sinh từ booking/đăng ký,
• phễu tuyển sinh,
• dashboard doanh thu/hoa hồng,
• dashboard hiệu quả trung tâm/GV,
• dashboard vận hành OPSKOO.

Đây là lõi vận hành của provider acquisition. OPSKOO không chỉ bán khóa học; nó giúp giáo viên/trung tâm vận hành tuyển sinh.

SOTA không?

SOTA thực dụng là operational workflow trước automation:

• mỗi lead có source/stage/owner/next action,
• mọi booking/order/enrollment sinh evidence,
• dashboard từ read models,
• manual override có audit.

Giải pháp tốt hơn sau này:

• Automation rules,
• email/SMS sequences,
• integration với CRM bên ngoài,
• lead scoring,
• retention prediction.

Giải pháp tệ hơn:

• Chỉ dashboard số tổng, không có workflow xử lý lead.
• Export Excel thủ công là ops chính.

Đánh đổi:

• CRM dễ scope creep.
• Cần giữ MVP ở mức pipeline + evidence + follow-up.

5.11. AI Engine

Quyết định:

MVP: AI workflow có kiểm soát cho format tài liệu, bài tập, đề thi, gợi ý nội dung.

Không làm AI agent tự trị, không làm AI grading chính thức high-stakes.

Vì sao:

File MVP của bạn đúng: chưa cần AI dạy học/quản lý phức tạp; làm AI format nội dung, tài liệu, bài tập trước.

SOTA thực dụng của AI agent không phải multi-agent tự trị, mà là bounded autonomy: tool rõ, permission rõ, human approval, eval, tracing, rollback. NIST AI RMF nhấn mạnh govern, map, measure, manage rủi ro AI.[^nist-ai-rmf] OWASP LLM Top 10 liệt kê các rủi ro như prompt injection, sensitive information disclosure, insecure output handling, excessive agency.[^owasp-llm]

Trong giáo dục, AI có thể bị xem là high-risk ở một số jurisdiction nếu ảnh hưởng đánh giá/học tập/tiếp cận giáo dục. EU AI Act xếp một số hệ AI trong giáo dục/đào tạo nghề là high-risk.[^eu-ai-act]

SOTA không?

Có. Workflow-first, human-in-the-loop là cách đúng.

AI MVP use cases:

• format tài liệu upload,
• tạo outline lesson plan từ input của giáo viên,
• tạo quiz draft,
• gợi ý rubric/feedback draft,
• tóm tắt lead/class activity cho teacher,
• AI search assistant hỏi đáp theo catalog public.

Không làm sớm:

• AI tự quyết định học viên đậu/rớt,
• AI tự ranking provider mà không giải thích,
• AI tự refund/dispute,
• AI agent tự gửi tin nhắn/sửa dữ liệu không approval.

Đánh đổi:

• Human-in-the-loop chậm hơn.
• Nhưng tránh sai, tránh mất trust, tránh compliance risk.

5.12. Social & Community

Quyết định:

Không build full social/newsfeed trong MVP.

MVP: teacher/center profile posts, comments cơ bản nếu cần, moderation thủ công.

Vì sao:

CEO vision có social/newsfeed/community/gamification. Nhưng social network là hệ thống riêng: feed ranking, moderation, spam, abuse, notifications, privacy, reporting.

File MVP của bạn đúng: chỉ cần giáo viên tạo bài viết/chia sẻ tài liệu trên profile, chưa cần newsfeed.

SOTA không?

SOTA thực dụng là content marketing/profile content trước, social graph/feed sau.

Giải pháp tốt hơn sau này:

• Community groups,
• learning circles,
• event/webinar posts,
• feed ranking,
• moderation tooling.

Giải pháp tệ hơn:

• Mở public feed ngay, bị spam/seeding/review manipulation.

Đánh đổi:

• Thiếu social có thể giảm engagement.
• Nhưng tránh xây một sản phẩm thứ hai trước khi marketplace/LMS sống.

5.13. Subscription, Billing và Packaging

Quyết định:

MVP cần plan/entitlement model cho provider, nhưng billing subscription có thể đơn giản.

Không hardcode plan limits vào business logic.

CEO có pricing:

• Individual: Free, Starter, Growth, Pro.
• Center: Free, Basic, Scale, Enterprise.

Đây là SaaS packaging. Cần model:

Plan

Subscription

FeatureEntitlement

UsageMeter

Limit

AddOn

Invoice/BillingAccount

SOTA không?

Có. SaaS tốt phải có entitlement và usage metering sớm. Feature flag không phải entitlement.

Giải pháp tốt hơn sau này:

• Stripe Billing/Paddle/Chargebee hoặc provider tương đương.
• Usage-based billing cho AI/storage/live class.

Giải pháp tệ hơn:

• plan_name string trên teacher profile.
• Check if plan == "PRO" rải khắp code.

Đánh đổi:

• Làm entitlement model ban đầu tốn công.
• Nhưng tránh phá pricing khi sales đổi gói.

6. Data architecture

6.1. Operational database

Quyết định:

PostgreSQL managed là operational source of truth.

MVP: một database logical, schema/module boundary rõ.

Vì sao:

• Domain transactional nhiều: order, payment, enrollment, entitlement, lead, class/session.
• PostgreSQL mạnh, có FTS, JSONB khi cần, transaction tốt, extension ecosystem.
• Managed Postgres giảm ops backup/failover.

SOTA không?

Có. Đừng tách database per service khi chưa có service. Database-per-service là pattern khi microservice thật sự độc lập, không phải mục tiêu MVP.

Đánh đổi:

• Shared DB dễ bị module truy cập chéo.
• Cần boundary enforcement bằng code/project references/tests.

6.2. Events và outbox

Quyết định:

Domain event + transactional outbox cho state quan trọng.

Không dùng Kafka ngay.

Event cần từ đầu:

• ProviderVerified,
• CoursePublished,
• BookingRequested,
• OrderPaid,
• EntitlementGranted,
• EnrollmentActivated,
• AssignmentSubmitted,
• GradePosted,
• RefundRequested,
• RefundApproved,
• PaymentWebhookReceived.

Transactional outbox ghi event cùng transaction với state, rồi worker publish/dispatch sau.[^outbox]

SOTA không?

Có. Outbox là pattern thực dụng để tránh dual-write bug.

Giải pháp tốt hơn sau này:

• Message broker như RabbitMQ/SQS/Kafka khi event volume/consumer tăng.
• CDC/Debezium khi cần streaming data.

Giải pháp tệ hơn:

• Ghi DB xong gọi email/payment/analytics trực tiếp; timeout là mất side effect.

Đánh đổi:

• Outbox thêm worker, retry, dead-letter, idempotency.
• Nhưng đây là chi phí đáng trả cho payment/entitlement/notification.

6.3. Analytics và data platform

Quyết định:

MVP: operational read models + analytics tables + product events tối thiểu.

Chưa làm lakehouse/warehouse lớn.

Metrics cần định nghĩa từ đầu:

• provider activation,
• profile completion,
• course published,
• search result impressions,
• lead created,
• booking conversion,
• enrollment conversion,
• paid GMV,
• commission,
• learner activation,
• class attendance,
• assignment submission,
• provider retention,
• refund/dispute rate.

SOTA không?

Có. Data platform tốt bắt đầu bằng metric governance và event taxonomy, không phải mua BigQuery/Snowflake/Databricks.

Giải pháp tốt hơn sau này:

• Warehouse/lakehouse,
• dbt/semantic layer,
• product analytics,
• feature store for ranking/AI.

Giải pháp tệ hơn:

• Dashboard query trực tiếp production tables bằng SQL tùy hứng.
• Event tracking không schema.

Đánh đổi:

• Làm event taxonomy sớm cần tư duy product.
• Nhưng nếu không làm, AI/ranking/BI sau này thiếu dữ liệu sạch.

7. Security, privacy và compliance

7.1. Security baseline

Quyết định:

OWASP API Security + ASVS làm security baseline.

OWASP API Security Top 10 2023 liệt kê các rủi ro như broken object level authorization, broken authentication, broken object property level authorization, unrestricted resource consumption.[^owasp-api] ASVS cung cấp bộ yêu cầu xác minh bảo mật app.[^owasp-asvs]

Controls MVP:

• object-level authorization ở mọi API,
• tenant scoping bắt buộc,
• audit log cho hành động quan trọng,
• rate limiting,
• webhook signature verification,
• secret management,
• file upload scanning/validation,
• secure headers/CORS,
• least privilege DB/storage,
• admin/support access có audit.

Đánh đổi:

• Security làm chậm delivery.
• Nhưng OPSKOO đụng payment, identity, trẻ em/học viên, tài liệu, chứng chỉ; không thể làm sau.

7.2. Privacy và dữ liệu học viên

Quyết định:

Privacy-by-design: data classification, consent, retention, export/delete request từ sớm.

OPSKOO có thể có học viên trẻ em, dữ liệu học tập, bài nói/bài viết, chứng chỉ, thanh toán. Nếu đi global, cần chuẩn bị GDPR/COPPA/FERPA-like concerns tùy thị trường.

SOTA không?

Có. Không cần full compliance ngày đầu, nhưng data model phải không phá privacy sau này.

Controls:

• phân loại PII/sensitive/education/payment/credential,
• giới hạn ai thấy dữ liệu học viên,
• audit giáo viên/trung tâm truy cập dữ liệu,
• retention policy cho tài liệu xác minh,
• signed URL cho media,
• không dùng dữ liệu học viên train AI nếu chưa consent rõ.

7.3. Accessibility

Quyết định:

WCAG 2.2 AA làm mục tiêu thiết kế frontend.

WCAG 2.2 là chuẩn W3C cho accessibility.[^wcag22]

Vì sao:

• Giáo dục phải bao trùm.
• Sửa accessibility sau rất tốn.
• Marketplace/profile/LMS đều có form, video, tài liệu, dashboard.

Đánh đổi:

• Design/dev mất công hơn.
• Nhưng đây là quality attribute, không phải polish.

8. Infrastructure và operations

8.1. Cloud strategy

Quyết định:

Chọn một cloud chính, không multi-cloud.

Reference architecture theo AWS-like stack; có thể thay bằng GCP/Azure nếu team/market quyết.

Stack đề xuất:

• Compute: container app trên managed container service hoặc VM + Docker ban đầu.
• Database: managed PostgreSQL.
• Cache/queue: Redis/RabbitMQ/SQS khi cần.
• Object storage: S3-compatible.
• CDN: CloudFront/Cloudflare.
• Email: SES/SendGrid/Mailgun.
• Observability: OpenTelemetry + managed log/metrics/tracing.
• Secrets: cloud secrets manager.
• IaC: Terraform/Pulumi.

SOTA không?

Có. SOTA cho startup global là managed services có chọn lọc, không tự host mọi thứ.

Giải pháp tốt hơn sau này:

• Kubernetes khi có nhiều services/team/deployment patterns.
• Multi-region khi compliance/latency/business yêu cầu.

Giải pháp tệ hơn:

• Tự cài Postgres/Redis/OpenSearch/Kafka trên một VPS production vì rẻ.
• Multi-cloud từ ngày đầu.

Đánh đổi:

• Managed services tốn tiền hơn raw VM.
• Nhưng giảm rủi ro mất dữ liệu, backup/failover/patching.

8.2. Observability

Quyết định:

OpenTelemetry từ đầu cho traces, metrics, logs.

Domain metrics là first-class.

OpenTelemetry là chuẩn mở cho telemetry: traces, metrics, logs.[^opentelemetry]

Technical metrics:

• latency p50/p95/p99,
• error rate,
• DB slow query,
• queue lag,
• outbox backlog,
• webhook failures,
• storage upload failures,
• email delivery failures.

Domain metrics:

• provider onboarding conversion,
• profile verification SLA,
• course publish rate,
• search zero-result rate,
• booking conversion,
• payment success/failure,
• entitlement grant delay,
• refund/dispute rate,
• class attendance,
• assignment submission.

SOTA không?

Có. Hệ marketplace/LMS không quan sát được domain state thì không vận hành được.

Đánh đổi:

• Instrumentation tốn công.
• Nhưng nếu không làm từ đầu, production incident sẽ mù.

8.3. CI/CD và environments

Quyết định:

GitHub Actions/GitLab CI + Docker + IaC + staging/prod tách rõ.

Pipeline:

1. lint/format, 2. unit tests, 3. architecture tests, 4. integration tests với Postgres, 5. security/dependency scan, 6. build Docker image, 7. migration dry-run, 8. deploy staging, 9. smoke test, 10. manual approval production, 11. deploy production, 12. post-deploy health check.

DORA research đo software delivery performance bằng deployment frequency, lead time, change fail rate, failed deployment recovery time.[^dora]

SOTA không?

Có. Delivery safety là architecture, không phải DevOps phụ trợ.

Đánh đổi:

• Pipeline kỹ hơn mất thời gian setup.
• Nhưng giảm rủi ro AI agent merge code sai.

8.4. Backup, restore và disaster recovery

Quyết định:

Backup tự động chưa đủ; phải test restore.

Controls:

• managed Postgres automated backups + PITR,
• object storage versioning/lifecycle,
• backup encryption,
• restore drill định kỳ,
• RPO/RTO theo tier,
• runbook cho DB corruption/payment incident.

SOTA không?

Có. Hệ có payment/enrollment không được chỉ tin "cloud backup".

Đánh đổi:

• Restore drill tốn thời gian.
• Nhưng backup chưa test thì không phải backup.

9. SLO và reliability

Quyết định:

Đặt SLO theo user journey, không chỉ uptime backend.

MVP SLO gợi ý:

SOTA không?

Có. Google SRE nhấn mạnh SLO là cách nói rõ reliability kỳ vọng và error budget.[^sre-slo]

Đánh đổi:

• SLO buộc team đo đạc.
• Nhưng không có SLO thì mọi quyết định scale chỉ là cảm giác.

10. Kiến trúc AI trong thời đại AI agent

10.1. AI agent cho engineering

Quyết định:

Thiết kế repo để AI agent làm việc an toàn:

type-safe, tests, architecture boundaries, generated scaffolds, ADR.

Vì sao:

• AI agent làm giảm chi phí syntax và boilerplate.
• Nhưng AI agent tăng rủi ro tạo code "chạy được" nhưng sai domain.
• .NET/C# compiler giúp bắt lỗi cấu trúc tốt hơn Python động.

Controls:

• strict nullable/reference types,
• no business logic trong endpoints,
• architecture tests,
• unit tests cho domain invariants,
• integration tests cho payment/entitlement,
• codeowners theo module,
• ADR bắt buộc cho quyết định lớn,
• prompts/templates nội bộ cho module/use case.

Đánh đổi:

• Cần đầu tư engineering system.
• Nhưng đây là cách tận dụng AI agent thay vì bị AI agent làm bẩn hệ thống.

10.2. AI trong sản phẩm

Quyết định:

AI là workflow capability, không phải core truth.

AI không được sở hữu sự thật như:

• điểm chính thức,
• entitlement,
• refund,
• ranking final không giải thích,
• verification approval không human.

AI có thể hỗ trợ:

• soạn bài,
• chuẩn hóa tài liệu,
• tạo quiz draft,
• gợi ý feedback,
• tóm tắt lead/class,
• search assistant,
• retention risk suggestion.

SOTA không?

Có. NIST AI RMF và OWASP LLM đều nhấn mạnh governance, evaluation, guardrails, security và monitoring.[^nist-ai-rmf][^owasp-llm]

Đánh đổi:

• AI bị giới hạn nên kém "wow".
• Nhưng OPSKOO là trust platform; trust quan trọng hơn demo wow.

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

Không nên làm trong MVP:

• Full microservices.
• Kubernetes nếu team nhỏ và chỉ có một app core.
• Keycloak nếu chưa có SSO/enterprise identity.
• OpenSearch nếu Postgres FTS đủ.
• Kafka nếu outbox + background worker đủ.
• Native live class/WebRTC/whiteboard.
• Full social newsfeed.
• Full OTS/LAS gamification phức tạp.
• AI grading official/high-stakes.
• Escrow pháp lý nếu chưa có provider/legal foundation.
• Multi-region active-active.
• Data lakehouse.
• ABP nếu mục tiêu là học/kiểm soát .NET core tinh gọn.

Điều nên làm từ đầu:

• domain model đúng,
• tenant model đúng,
• entitlement model đúng,
• payment state/idempotency đúng,
• verification/review audit đúng,
• media access control đúng,
• observability/domain metrics đúng,
• security/object-level authorization đúng,
• ADR và architecture tests.

12. Roadmap kiến trúc đề xuất

Phase 0: Architecture foundation

Mục tiêu:

• .NET solution skeleton,
• Next.js app skeleton,
• Postgres schema baseline,
• identity/tenancy,
• CI/CD,
• architecture tests,
• observability baseline,
• ADR folder.

Không làm:

• microservices,
• AI phức tạp,
• payment split/escrow thật.

Phase 1: Provider onboarding và Trust MVP

Build:

• teacher/center registration,
• provider profile,
• document upload,
• manual verification,
• badge,
• course/offering draft/publish,
• ops approval console.

Critical:

• audit approve/reject,
• file storage secure,
• role/permission correct.

Phase 2: Discovery marketplace

Build:

• public search,
• filters,
• course/profile detail,
• structured SEO pages,
• listing analytics,
• lead/booking CTA.

Search:

• Postgres FTS + filters + simple scoring.

Phase 3: Booking, Order, Payment, Entitlement

Build:

• booking trial,
• checkout/order,
• payment provider integration,
• webhook idempotency,
• internal ledger-lite,
• entitlement grant,
• enrollment activation,
• refund request manual workflow.

Critical:

• order/payment/entitlement state machines.
• reconciliation report.

Phase 4: LMS cơ bản

Build:

• class/course run,
• sessions,
• external meeting link,
• materials,
• homework,
• submissions,
• manual grading/comment,
• progress,
• learner dashboard,
• teacher dashboard.

Không build:

• native live class,
• full gradebook,
• SCORM/LTI/QTI.

Phase 5: CRM/Ops dashboards

Build:

• lead pipeline,
• follow-up,
• source attribution cơ bản,
• provider dashboard,
• ops dashboard,
• commission dashboard,
• support/dispute tooling.

Phase 6: AI-assisted workflows

Build:

• AI format tài liệu/bài tập,
• quiz draft,
• feedback draft,
• search/matching assistant,
• eval logs,
• approval workflow,
• cost/latency tracking.

Không build:

• autonomous agents,
• official grading automation.

Phase 7: Scale and specialization

Extract candidates khi có pain thật:

• Search service,
• AI workflow service,
• Media processing service,
• Notification service,
• Payment reconciliation worker,
• Analytics pipeline,
• Mobile BFF.

Chỉ tách khi:

• có owner,
• có data contract,
• có observability,
• có rollback,
• có deployment independence thật.

13. Decision matrix ngắn

14. Kết luận cuối

OPSKOO là một hệ thống phức tạp hơn "bán khóa học online". Nó là giao điểm của:

• marketplace,
• SaaS,
• LMS,
• CRM,
• payment/ledger,
• trust & safety,
• media,
• AI,
• data platform,
• global operations.

Nếu build như một website khóa học, OPSKOO sẽ nhanh ra demo nhưng chết khi có provider thật, payment thật, refund thật, học viên thật và ops thật.

Nếu build như một hệ microservices global ngay, OPSKOO sẽ chết vì phức tạp trước khi validate thị trường.

Quyết định cân bằng là:

ASP.NET Core modular monolith, domain-first, operations-aware, AI-assisted,

global-ready nhưng không global-overengineered.

Trong bối cảnh bạn không cần Django Admin và đang ở thời đại AI agent, .NET là lựa chọn hợp lý hơn Django cho dự án OPSKOO mới từ đầu.

Nhưng .NET chỉ thắng nếu bạn dùng nó để tạo kỷ luật:

• domain boundary,
• type safety,
• tests,
• architecture fitness functions,
• state machines,
• audit,
• observability,
• ADR.

Nếu chỉ dùng .NET để viết CRUD nhanh bằng AI, nó cũng sẽ thành mớ rối như mọi stack khác.

15. Nguồn tham khảo

[^aspnet-overview]: Microsoft Learn, "Overview of ASP.NET Core": https://learn.microsoft.com/en-us/aspnet/core/overview [^ef-core]: Microsoft Learn, "Overview of Entity Framework Core": https://learn.microsoft.com/en-us/ef/core/ [^ms-identity]: Microsoft Learn, "Introduction to Identity on ASP.NET Core": https://learn.microsoft.com/en-us/aspnet/core/security/authentication/identity [^openiddict]: OpenIddict documentation: https://documentation.openiddict.com/ [^fowler-microservices]: Martin Fowler, "Microservices": https://martinfowler.com/articles/microservices.html [^fowler-prereq]: Martin Fowler, "Microservice Prerequisites": https://martinfowler.com/bliki/MicroservicePrerequisites.html [^aws-waf]: AWS Well-Architected Framework: https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html [^aws-saas]: AWS SaaS Factory / SaaS architecture resources: https://aws.amazon.com/partners/programs/saas-factory/ [^next-app]: Next.js Docs, "App Router": https://nextjs.org/docs/app [^next-rsc]: Next.js Docs, "Server and Client Components": https://nextjs.org/docs/app/building-your-application/rendering/server-components [^sam-bff]: Sam Newman, "Pattern: Backends For Frontends": https://samnewman.io/patterns/architectural/bff/ [^lti]: 1EdTech, "Learning Tools Interoperability": https://www.1edtech.org/standards/lti [^oneroster]: 1EdTech, "OneRoster": https://www.1edtech.org/standards/oneroster [^qti]: 1EdTech, "Question and Test Interoperability": https://www.1edtech.org/standards/qti [^xapi]: ADL, "xAPI Specification": https://github.com/adlnet/xAPI-Spec [^postgres-fts]: PostgreSQL Documentation, "Full Text Search": https://www.postgresql.org/docs/current/textsearch.html [^pci]: PCI Security Standards Council, "PCI DSS": https://www.pcisecuritystandards.org/standards/pci-dss/ [^stripe-connect]: Stripe Docs, "Connect": https://docs.stripe.com/connect [^nist-ai-rmf]: NIST, "AI Risk Management Framework": https://www.nist.gov/itl/ai-risk-management-framework [^owasp-llm]: OWASP, "Top 10 for LLM Applications": https://owasp.org/www-project-top-10-for-large-language-model-applications/ [^eu-ai-act]: EUR-Lex, Regulation (EU) 2024/1689 Artificial Intelligence Act: https://eur-lex.europa.eu/eli/reg/2024/1689/oj [^wcag22]: W3C, "Web Content Accessibility Guidelines (WCAG) 2.2": https://www.w3.org/TR/WCAG22/ [^owasp-api]: OWASP, "API Security Top 10 2023": https://owasp.org/API-Security/editions/2023/en/0x00-header/ [^owasp-asvs]: OWASP, "Application Security Verification Standard": https://owasp.org/www-project-application-security-verification-standard/ [^outbox]: Microservices.io, "Transactional outbox": https://microservices.io/patterns/data/transactional-outbox.html [^opentelemetry]: OpenTelemetry Documentation: https://opentelemetry.io/docs/ [^dora]: DORA, "2024 Accelerate State of DevOps Report": https://dora.dev/research/2024/dora-report/ [^sre-slo]: Google SRE Book, "Service Level Objectives": https://sre.google/sre-book/service-level-objectives/