Báo cáo kiến trúc Synvia EdTech Core V2

Ngày lập: 2026-05-19 Mục tiêu: thiết kế lại một hệ thống EdTech thực sự, chỉn chu về sư phạm, dữ liệu, AI, vận hành và kiến trúc production. Stack định hướng: Django + DRF, Next.js, PostgreSQL, Celery, Redis, FastAPI cho một số service chuyên biệt, object storage, realtime, observability, documentation và testing nghiêm túc.

---

0. Ghi chú về nguồn ý tưởng

Báo cáo này tổng hợp từ định hướng sản phẩm và kiến trúc trong các tài liệu/sách nội bộ:

• edtech-da-goc-nhin/tts/edtech-book-codex/MUC-LUC-SACH.md: trong báo cáo gọi là Bản đồ EdTech thực chứng.
• edtech-da-goc-nhin/tts/edtech-book-antigravity/MUC-LUC-SACH.md: trong báo cáo gọi là Công nghệ giáo dục: Cái đúng, cái sai, và cái cần làm.
• edtech-da-goc-nhin/MUC-LUC-V2-SAU-NGHIEN-CUU.md: trong báo cáo gọi là EdTech đa góc nhìn.
• edtech-da-goc-nhin/tts/new-synvia/muc-luc-kien-truc-he-thong-thuc-dung.md và các chương liên quan: trong báo cáo gọi là Kiến trúc hệ thống thực dụng.

Khi một ý tưởng được lấy hoặc được diễn giải từ các sách này, báo cáo ghi nguồn theo dạng: (Bản đồ EdTech thực chứng, Chương 6) hoặc (Kiến trúc hệ thống thực dụng, Chương 18).

---

1. Trả lời nhanh câu hỏi Redis, RabbitMQ, Kafka

1.1. Có dễ thay Redis bằng RabbitMQ hoặc Kafka không?

Câu trả lời ngắn: dễ nếu ngay từ đầu thiết kế đúng boundary; không dễ nếu code gọi thẳng Redis Pub/Sub, Celery broker, hoặc stream API ở khắp nơi.

Redis, RabbitMQ và Kafka không phải ba phiên bản mạnh-yếu của cùng một thứ. Chúng giải quyết các bài toán hơi khác nhau:

1.2. Khuyến nghị cho Synvia V2

Ở giai đoạn đầu:

• Redis dùng cho cache, rate limit nhẹ, Celery broker/result backend nếu tải chưa lớn.
• Celery queue tách theo workload: default, ai_grading, media_processing, notification, reporting, webhook_retry.
• PostgreSQL vẫn là source of truth.
• Domain event quan trọng phải ghi vào bảng outbox_events trong PostgreSQL trước khi publish.

Khi lớn hơn:

• Nếu vấn đề là task queue cần bền hơn, routing tốt hơn, DLQ rõ hơn, chuyển Celery broker từ Redis sang RabbitMQ.
• Nếu vấn đề là nhiều consumer cần đọc lại lịch sử event, rebuild read model, analytics, replay, audit stream, thêm Kafka/Redpanda.
• Không dùng Kafka chỉ vì nghe “scale”. Kafka đáng dùng khi event log là tài sản sản phẩm, không chỉ là hàng đợi việc.

Nguyên tắc này đến từ phân biệt queue, pub/sub và event streaming: queue là công việc cần làm; pub/sub là sự kiện phát cho nhiều bên; event streaming là lịch sử sự kiện có thể đọc lại (Kiến trúc hệ thống thực dụng, Chương 18, Chương 19, Chương 20).

1.3. Làm sao để sau này thay broker dễ?

Thiết kế ngay từ đầu:

Application code

-> EventPublisher interface

-> JobDispatcher interface

-> Outbox table

-> Adapter: Redis / RabbitMQ / Kafka

Không cho business code gọi thẳng:

redis.publish(...)
producer.send(...)
channel.basic_publish(...)

Business code chỉ làm:

events.publish(SubmissionGraded(...))
jobs.enqueue(RunAIGrading(...))

Sau đó adapter quyết định dùng Redis, RabbitMQ hay Kafka.

1.4. Kết luận về Redis/RabbitMQ/Kafka

Không cần chọn “vĩnh viễn” ngay từ đầu. Cần chọn contract đúng:

• Job cần một worker xử lý: JobDispatcher.
• Event nhiều bên quan tâm: EventPublisher.
• Event cần lưu lịch sử/replay: EventStore hoặc EventStream.
• Mọi consumer phải idempotent vì retry và duplicate là bình thường (Kiến trúc hệ thống thực dụng, Chương 26).
• Mọi queue/worker phải có dashboard: queue length, oldest job age, wait time, processing time, retry rate, failure rate, DLQ (Kiến trúc hệ thống thực dụng, Chương 28).

---

2. Lập trường sản phẩm: không xây lại LMS, xây Learning Operating System

Dự án cũ dựa trên DMOJ là quyết định hợp lý ở thời điểm ban đầu, vì nó cho sẵn authentication, profile, admin, permission, celery, online judge và project shell. Nhưng hệ thống mới không nên là “DMOJ bỏ judge, thêm giao diện đẹp”. Nếu làm vậy, ta chỉ thay vỏ kỹ thuật mà giữ nghiệp vụ cũ.

Synvia V2 nên được định nghĩa là:

> Một Learning Operating System cho trung tâm, trường học và tổ chức đào tạo: quản lý vận hành học tập, đánh giá, phản hồi, AI, giáo viên, phụ huynh, dữ liệu tiến bộ, thanh toán, truyền thông và governance trong một kiến trúc modular monolith có thể tiến hóa.

Lập trường này dựa trên bốn ý chính:

1. EdTech phải được đo bằng học tập, không bằng độ mới hoặc độ nhiều tính năng (Bản đồ EdTech thực chứng, Chương 1, Chương 2). 2. Hệ thống tốt không chỉ số hóa quy trình cũ; nó phải thay đổi cách dạy, học, đánh giá và vận hành (EdTech đa góc nhìn, Chương 3). 3. Giá trị thật của EdTech thường nằm ở feedback nhanh, dữ liệu sớm để can thiệp, hỗ trợ giáo viên, accessibility và vận hành bớt mù; nhưng mỗi giá trị đều có điều kiện và chi phí ẩn (EdTech đa góc nhìn, Chương 6, Chương 7, Chương 8, Chương 9, Chương 10). 4. Modular monolith là lựa chọn thực dụng: tách trong code và domain trước, chỉ tách service vật lý khi có workload hoặc boundary đủ mạnh (Kiến trúc hệ thống thực dụng, Chương 9, Chương 10).

---

3. Những sai lầm cần tránh từ hệ thống cũ

3.1. Không để identity bị khóa vào một app lịch sử

Hệ cũ phụ thuộc quá sâu vào judge.Profile. Hệ mới phải có accounts là bounded context riêng:

• User.
• Profile.
• Membership trong tenant.
• Role.
• Parent contact.
• Teacher profile.
• Student profile.
• External identity: Google, Facebook, Zalo, Discord nếu cần.

Identity phải là xương sống độc lập, không nằm ké trong app LMS, app sale, hay app AI.

3.2. Không nhồi mọi thứ vào một app sy

Hệ mới vẫn là monolith nhưng không được là monolith rối. Các module phải có public interface rõ, không import nội bộ lung tung (Kiến trúc hệ thống thực dụng, Chương 9).

Ví dụ:

• commerce không được tự sửa enrollment trực tiếp; nó gọi use case enroll_after_purchase.
• notification không được tự query mọi bảng rồi quyết định nghiệp vụ; nó nhận command/event đã chuẩn hóa.
• ai_workflows không được ghi điểm chính thức nếu assessment policy yêu cầu teacher review.

3.3. Không coi AI là “gọi API rồi lưu kết quả”

AI app có non-determinism, cost, latency, hallucination, schema lỗi, provider lỗi, bias, safety và audit. Model không được là source of truth tuyệt đối (Kiến trúc hệ thống thực dụng, Chương 60).

3.4. Không biến analytics thành surveillance

Dữ liệu học tập có thể giúp can thiệp sớm, nhưng nếu thiếu policy và human judgment, nó biến thành nhãn dán “học viên yếu/rủi ro” (Bản đồ EdTech thực chứng, Chương 8; EdTech đa góc nhìn, Chương 9).

3.5. Không để dashboard làm giáo viên thêm việc

Dashboard tốt phải giúp giáo viên quyết định nhanh hơn, can thiệp đúng hơn, hoặc giảm việc hành chính. Dashboard tệ biến giáo viên thành người canh chỉ số (EdTech đa góc nhìn, Chương 17; Bản đồ EdTech thực chứng, Chương 19).

---

4. Nguyên tắc thiết kế sản phẩm

4.1. Bắt đầu từ nhiệm vụ học tập, không từ tính năng

Mỗi tính năng phải trả lời:

• Nó giúp người học làm gì tốt hơn?
• Nó tạo bằng chứng học tập nào?
• Giáo viên làm gì được với bằng chứng đó?
• Người học có hành động tiếp theo rõ không?

Nguồn: nguyên tắc “bắt đầu từ nhiệm vụ học tập” và “feedback phải dẫn đến hành động” (Bản đồ EdTech thực chứng, Chương 23).

4.2. Feedback phải dẫn đến hành động

Feedback không nên chỉ là:

Bạn sai câu 3.

Bạn cần cải thiện ngữ pháp.

Điểm: 7/10.

Feedback tốt phải có:

• Evidence: đoạn nào, hành vi nào, câu trả lời nào.
• Diagnosis: sai kiểu gì, thiếu kỹ năng nào.
• Next action: làm gì tiếp theo.
• Revision loop: sửa lại thế nào, nộp lại ra sao.
• Teacher visibility: giáo viên có cần duyệt/can thiệp không.

Nguồn: feedback tự động cần đúng lúc, đúng mức, có thể hành động; process-focused assessment và revision loop (Bản đồ EdTech thực chứng, Chương 6, Chương 16; EdTech đa góc nhìn, Chương 7).

4.3. Giữ ma sát nhận thức đúng chỗ

Hệ thống phải giảm ma sát thao tác: upload, nộp bài, xem feedback, đăng ký lớp, thanh toán.

Nhưng không được xóa nỗ lực học cần thiết:

• Trước khi AI gợi ý, có thể yêu cầu người học dự đoán.
• Trước khi xem đáp án, yêu cầu giải thích chiến lược.
• Sau feedback, yêu cầu revision hoặc reflection.

Nguồn: intentional friction, metacognitive laziness, cognitive offloading (Bản đồ EdTech thực chứng, Chương 15; Công nghệ giáo dục: Cái đúng, cái sai, và cái cần làm, Chương 10).

4.4. Teacher-in-the-loop thật

Teacher-in-the-loop không phải là “AI chấm xong, giáo viên có thể xem nếu muốn”. Phải có policy:

• Bài high-stakes bắt buộc teacher review.
• Low confidence bắt buộc teacher review.
• Feedback có severity cao bắt buộc teacher review.
• Học viên nhỏ tuổi hoặc tenant policy nhạy cảm bắt buộc review.
• Giáo viên có quyền sửa, reject, approve, annotate và tạo intervention.

Nguồn: AI trong vòng phản hồi, human-in-the-loop/human-on-the-loop, teacher agency (Bản đồ EdTech thực chứng, Chương 16, Chương 17, Chương 19; Công nghệ giáo dục: Cái đúng, cái sai, và cái cần làm, Chương 12).

4.5. Privacy-by-design

Hệ thống phải thiết kế dữ liệu từ đầu:

• Thu thập ít nhất có thể.
• Biết dữ liệu dùng cho mục đích gì.
• Có consent/policy.
• Có retention.
• Có export/delete.
• Có audit access.
• AI prompt/response không được lộ dữ liệu tenant khác.

Nguồn: privacy-by-design, data governance, AI context và tenant boundary (Công nghệ giáo dục: Cái đúng, cái sai, và cái cần làm, Chương 13; Kiến trúc hệ thống thực dụng, Chương 62, Chương 63).

4.6. Vận hành cũng là trải nghiệm học tập

Attendance, enrollment, payment, scheduling, submission, notification và reporting không lãng mạn, nhưng chúng làm tổ chức bớt mù và giảm thất lạc thông tin (EdTech đa góc nhìn, Chương 6; Bản đồ EdTech thực chứng, Chương 11).

Vì vậy hệ thống phải chỉn chu cả phần “hành chính”:

• Lịch học.
• Điểm danh.
• Thanh toán.
• Nhắc lịch.
• Phụ huynh.
• Báo cáo.
• Phân quyền.
• Audit.

---

5. Kiến trúc tổng thể

flowchart TD
    Client["Next.js Web App"]
    API["Django DRF Modular Monolith"]
    PG["PostgreSQL"]
    Redis["Redis Cache / Broker ban đầu"]
    Celery["Celery Worker Pools"]
    AI["FastAPI AI Assessment Service"]
    Media["Media Processing Workers"]
    Storage["S3-compatible Object Storage"]
    Realtime["Realtime Gateway: SSE/WebSocket"]
    Search["Search: PostgreSQL FTS -> OpenSearch/Meilisearch later"]
    Obs["Observability: Logs, Metrics, Tracing, Alerts"]
    Broker["RabbitMQ/Kafka/Redpanda optional later"]

    Client --> API
    API --> PG
    API --> Redis
    API --> Storage
    API --> Search
    API --> Realtime
    API --> Celery
    Celery --> AI
    Celery --> Media
    API --> Obs
    Celery --> Obs
    AI --> Obs
    Media --> Storage
    API -.outbox/events.-> Broker

5.1. Vì sao modular monolith là lõi?

Synvia V2 còn phải khám phá domain. Nếu tách microservices quá sớm, ta sẽ phải trả chi phí network, deploy, API versioning, distributed tracing, distributed transactions và coordination trước khi domain ổn định. Modular monolith cho phép tách boundary trong code trước, dễ chạy local, dễ debug, dễ transaction, nhưng vẫn mở đường tách service sau này (Kiến trúc hệ thống thực dụng, Chương 7, Chương 9, Chương 10).

5.2. Khi nào tách service?

Tách service khi có ít nhất một lý do mạnh:

• Workload khác biệt rõ: AI grading, media processing, realtime connection.
• Cần scale độc lập.
• Cần security/audit boundary riêng.
• Cần team ownership riêng.
• Cần runtime khác.
• Cần failure isolation.

Nguồn: tách service vì workload/scale/security/failure mode, không phải vì “microservices hay hơn” (Kiến trúc hệ thống thực dụng, Chương 10).

---

6. Stack đề xuất

6.1. Backend core

• Django.
• Django REST Framework.
• PostgreSQL.
• Celery.
• Redis.
• django-storages hoặc storage abstraction riêng.
• OpenAPI schema bằng drf-spectacular.
• pytest.
• ruff/black/mypy nếu team chịu được typing discipline.

Django phù hợp vì:

• Domain nhiều quan hệ.
• Admin/backoffice quan trọng.
• PostgreSQL transaction quan trọng.
• Permission/RBAC dễ xây.
• Monolith có kỷ luật hợp với Django.

6.2. Frontend

• Next.js App Router.
• TypeScript.
• React Query hoặc TanStack Query.
• Zod cho client validation.
• OpenAPI-generated client nếu được.
• Component design system riêng.

Frontend phải coi UX là sư phạm: dashboard, notification, layout, nhịp tương tác đều ảnh hưởng cách học (Bản đồ EdTech thực chứng, Chương 14).

6.3. AI service

• FastAPI.
• Pydantic schemas.
• Provider adapters: OpenAI, Gemini, Anthropic, local model nếu cần.
• Prompt registry.
• Evaluation runner.
• Cost/latency logger.
• Safety/validation layer.

AI service tách vì workload khác biệt, gọi API ngoài lâu, có policy riêng, cần quan sát riêng (Kiến trúc hệ thống thực dụng, Chương 4, Chương 10, Chương 60).

6.4. Database

• PostgreSQL là source of truth.
• JSONB dùng có kiểm soát cho metadata/payload, không dùng thay domain model.
• Row-level tenant enforcement ở application layer trước; cân nhắc PostgreSQL RLS khi domain ổn.
• Outbox table cho domain/integration events.
• Audit tables cho hành động quan trọng.

6.5. Queue/event

Giai đoạn đầu:

• Redis + Celery.
• PostgreSQL outbox.

Khi cần:

• RabbitMQ cho task queue bền/routing/DLQ tốt hơn.
• Kafka/Redpanda cho event streaming/replay/analytics/read model.

6.6. Realtime

Ban đầu ưu tiên SSE hoặc polling có kiểm soát cho:

• AI grading progress.
• Upload/processing status.
• Notification.
• Meeting state nhẹ.

WebSocket dùng khi có tương tác hai chiều thật: classroom live, collaborative workspace, meeting state, chat. Không dùng WebSocket chỉ để báo “chấm xong” nếu SSE/polling đủ (Kiến trúc hệ thống thực dụng, Chương 21 trong thư mục new-synvia và mục WebSocket/SSE trong mục lục Chương 15).

---

7. Module map của Synvia V2

7.1. accounts

Trách nhiệm:

• User.
• Profile.
• Membership trong tenant.
• Role.
• Permission.
• Teacher profile.
• Learner profile.
• Parent/guardian contact.
• External identity.
• Session/security.

Public interface:

• get_current_actor(request)
• get_membership(user, tenant)
• assert_can(actor, action, resource)
• create_user_with_profile(...)
• invite_user_to_tenant(...)

Không module nào được tự diễn giải role bằng cách query lung tung.

7.2. tenancy

Trách nhiệm:

• Tenant/center/school.
• Domain/subdomain.
• Branding.
• Plan.
• Feature flags.
• Quota.
• Tenant settings.
• Data boundary.

Multi-tenancy không chỉ là thêm tenant_id. Nó ảnh hưởng permission, billing, quota, audit, backup, export, AI context, cache, search, observability và support tooling (Kiến trúc hệ thống thực dụng, Chương 62).

7.3. curriculum

Trách nhiệm:

• Learning objective.
• Skill.
• Competency.
• Curriculum map.
• Syllabus.
• Objective-skill mapping.
• Prerequisite graph.

Lý do: AI content, AI assessment và adaptive pathway chỉ nghiêm túc nếu có bản đồ mục tiêu/kỹ năng. AI nối mục tiêu học, chuẩn đầu ra, nội dung, bài tập và đánh giá thành ontology/syllabus map (Bản đồ EdTech thực chứng, Chương 5).

7.4. content

Trách nhiệm:

• Lesson content.
• Resource.
• Media.
• Transcript.
• CMS/page/blog.
• Content version.
• Localization.

Nội dung AI-generated phải có kiểm định chất lượng vì rủi ro hallucination, bias, bản quyền, độ tuổi phù hợp và đồng nhất hóa nội dung (Bản đồ EdTech thực chứng, Chương 5; Công nghệ giáo dục: Cái đúng, cái sai, và cái cần làm, Chương 3).

7.5. classroom

Trách nhiệm:

• Course.
• Cohort/class.
• Schedule.
• Teacher assignment.
• Enrollment.
• Attendance.
• Offline/online session.

Đây là hạ tầng vận hành ít lãng mạn nhưng quan trọng: attendance, enrollment, scheduling, reporting giúp tổ chức bớt mù và phụ huynh được cập nhật (EdTech đa góc nhìn, Chương 6).

7.6. learning_activity

Trách nhiệm:

• Assignment/task.
• Question.
• Attempt.
• Submission.
• Revision.
• Deadline.
• Activity state machine.

Activity phải gắn với objective và expected evidence. Không tạo bài tập chỉ như một form nộp file.

7.7. assessment

Trách nhiệm:

• Rubric.
• Rubric criterion.
• Assessment policy.
• Grading result.
• Criterion score.
• Feedback item.
• Teacher review.
• Revision requirement.
• Official grade decision.

Assessment phải chuyển từ “điểm cuối” sang “vòng phản hồi”: formative, process-focused, ipsative, asset-based, authentic assessment (Bản đồ EdTech thực chứng, Chương 6, Chương 16).

7.8. learning_record

Trách nhiệm:

• Learning event.
• Mastery estimate.
• Progress timeline.
• Portfolio.
• Evidence record.
• Reflection.
• Intervention history.

Điểm số không phải toàn bộ học tập; cần nhìn engagement, completion, transfer, metacognition, behavior change và evidence phù hợp bối cảnh (Bản đồ EdTech thực chứng, Chương 2).

7.9. teacher_workbench

Trách nhiệm:

• Review queue.
• Low-confidence AI review.
• Error clusters.
• Class heatmap.
• Intervention plan.
• Student risk signals.
• Workload dashboard.

Workbench tốt làm giáo viên thấy rõ hơn và giữ quyền nghề nghiệp; không biến giáo viên thành người bấm duyệt dashboard (EdTech đa góc nhìn, Chương 10, Chương 17; Bản đồ EdTech thực chứng, Chương 19).

7.10. learner_workspace

Trách nhiệm:

• Dashboard người học.
• Next action.
• Feedback inbox.
• Revision flow.
• Reflection prompt.
• Mastery view.
• Practice recommendation.

Người học cần mục tiêu, chiến lược, giám sát tiến độ và phản tư; học linh hoạt không được biến thành cô đơn tự xoay sở (Bản đồ EdTech thực chứng, Chương 4, Chương 15; EdTech đa góc nhìn, Chương 18).

7.11. parent_portal

Trách nhiệm:

• Parent dashboard.
• Attendance.
• Progress summary.
• Feedback summary.
• Payment summary.
• Notification preference.

Phụ huynh cần hiểu con học được gì, không chỉ thấy con làm nhiều hoạt động hơn. Dashboard phụ huynh có thể giúp an tâm nhưng cũng có nguy cơ tăng giám sát (EdTech đa góc nhìn, Chương 19).

7.12. ai_workflows

Trách nhiệm:

• AI job request.
• AI run.
• Prompt template/version.
• Model provider.
• Context package.
• Schema validation.
• Safety check.
• Cost/latency record.
• AI incident.
• Evaluation dataset.

Không module nào gọi AI trực tiếp. Mọi tác vụ AI đi qua workflow có audit.

7.13. commerce

Trách nhiệm:

• Product/course offer.
• Order.
• Payment.
• Transaction.
• Coupon.
• Subscription.
• Installment.
• Invoice/receipt.
• Reconciliation.

Money cần ledger/audit riêng. Payment webhook phải idempotent. Không retry bừa khi timeout vì có thể tạo thanh toán/hoàn tiền trùng (Kiến trúc hệ thống thực dụng, Chương 16, Chương 26; new-synvia có Chương 64 về money ledger/reconciliation).

7.14. notification

Trách nhiệm:

• Notification template.
• Channel.
• Schedule.
• Log.
• Preference.
• Zalo/Email/Facebook/in-app adapters.
• Retry.
• Delivery status.

Notification không được là side effect mù. Mọi tin quan trọng phải có log, trạng thái, retry policy và audit.

7.15. integration

Trách nhiệm:

• Webhooks.
• External APIs.
• Import/export.
• Future LTI/xAPI/OneRoster.
• API keys.
• Service-to-service auth.

Interoperability quan trọng để hệ sinh thái không bị khóa trong một nhà cung cấp (Bản đồ EdTech thực chứng, Chương 11; EdTech đa góc nhìn, Chương 14).

7.16. audit

Trách nhiệm:

• Admin action log.
• Data access log.
• Grade change log.
• AI decision log.
• Payment action log.
• Permission change log.

Với dữ liệu giáo dục và AI, audit không phải “nice to have”. Nó là điều kiện để trust tồn tại (Công nghệ giáo dục: Cái đúng, cái sai, và cái cần làm, Chương 13; Kiến trúc hệ thống thực dụng, Chương 63).

---

8. Domain flow trung tâm

Hệ mới nên xoay quanh chu trình:

Objective

-> Activity

-> Attempt

-> Evidence

-> Feedback

-> Revision

-> Teacher Review

-> Intervention

-> Progress Update

8.1. Vì sao không xoay quanh course/class/submission như LMS thường?

Course/class/submission là dữ liệu vận hành. Nó cần, nhưng chưa đủ.

Một EdTech thật sự phải biết:

• Người học đang nhắm tới objective nào?
• Bài làm tạo evidence gì?
• Feedback dẫn tới hành động nào?
• Revision có cải thiện gì?
• Giáo viên đã can thiệp thế nào?
• Hệ thống có học được gì về lỗi lặp lại không?

Nguồn: process-focused assessment, mastery loops, reflective assessment, learning analytics biến dữ liệu thành quyết định sư phạm (Bản đồ EdTech thực chứng, Chương 6, Chương 8, Chương 13, Chương 16).

8.2. Entity lõi đề xuất

Tenant

User

Membership

LearnerProfile

TeacherProfile

GuardianContact

LearningObjective

Skill

CurriculumMap

Course

Cohort

ClassSession

Enrollment

Attendance

LearningActivity

Question

Attempt

Submission

SubmissionRevision

Evidence

Rubric

RubricCriterion

AssessmentPolicy

AssessmentResult

CriterionScore

FeedbackItem

TeacherReview

Intervention

LearningEvent

MasteryEstimate

PortfolioItem

AIJob

AIRun

PromptVersion

ModelProvider

AIIncident

---

9. AI Assessment Service

9.1. Tại sao tách FastAPI?

AI assessment có workload khác:

• Gọi model lâu.
• Có rate limit.
• Cost biến động.
• Cần retry/backoff.
• Cần schema validation.
• Cần prompt/model version.
• Có thể xử lý file/audio/video.
• Cần observability riêng.

Đây là lý do tách service vì workload khác biệt và failure isolation (Kiến trúc hệ thống thực dụng, Chương 4, Chương 10, Chương 60).

9.2. Service boundary

Django core:

• Quản domain chính.
• Tạo AI job.
• Lưu source of truth.
• Quyết định official grade.
• Quản teacher review.

FastAPI AI service:

• Nhận context package.
• Gọi provider.
• Validate output.
• Trả structured result.
• Ghi AI run metadata.
• Không tự quyết định official grade.

9.3. AI workflow

SubmissionCreated

-> Create AIJob

-> Celery dispatch RunAIGrading

-> Build context package

-> Call AI service

-> AI service validates schema

-> Store draft assessment

-> Apply assessment policy

-> If safe: publish draft feedback

-> If risky: send to TeacherReviewQueue

9.4. AI output không phải source of truth

AI chỉ tạo draft_assessment. Official assessment cần policy:

• Auto-approve được không?
• Teacher review bắt buộc không?
• Có confidence đủ cao không?
• Có safety issue không?
• Có score ngoài range không?
• Có feedback không có evidence không?

Nguồn: model không deterministic, cần schema validation, human review, prompt versioning và model observability (Kiến trúc hệ thống thực dụng, Chương 60).

9.5. AI governance tối thiểu

Mỗi AIRun phải lưu:

• Tenant.
• User/request actor.
• Purpose.
• Input refs.
• Redaction status.
• Prompt version.
• Model provider/model name.
• Temperature/config.
• Rubric version.
• Output schema version.
• Raw output reference nếu được phép.
• Parsed output.
• Validation errors.
• Cost estimate.
• Latency.
• Safety flags.
• Review status.

9.6. Evaluation

Không deploy prompt mới nếu chưa chạy evaluation set.

Evaluation set nên gồm:

• Bài làm thật đã ẩn danh.
• Bài edge case.
• Bài có lỗi phổ biến.
• Bài có nội dung nhạy cảm.
• Bài dài/quá ngắn.
• Bài có prompt injection.
• Bài giáo viên đã chấm chuẩn.

Nguồn: AI app cần evaluation, quality control, cost/latency/safety/observability ngay từ đầu (Kiến trúc hệ thống thực dụng, Chương 60; EdTech đa góc nhìn, Chương 16).

---

10. Queue, event và broker evolution

10.1. Phân loại message

Synvia V2 cần tách rõ:

Nguồn: queue khác pub/sub, event streaming khác queue (Kiến trúc hệ thống thực dụng, Chương 18, Chương 19, Chương 20).

10.2. Redis ban đầu có ổn không?

Có, nếu dùng đúng:

• Cache.
• Rate limit nhẹ.
• Celery broker giai đoạn đầu.
• Pub/Sub realtime không critical.
• Distributed lock rất cẩn thận.

Không nên dùng Redis Pub/Sub cho event quan trọng cần replay hoặc đảm bảo xử lý. Với event quan trọng, phải ghi DB outbox trước.

10.3. Khi nào thêm RabbitMQ?

Thêm RabbitMQ khi:

• Celery job nhiều, Redis broker bắt đầu kém tin cậy.
• Cần routing rõ.
• Cần priority queue tốt hơn.
• Cần ack/DLQ/retry behavior rõ.
• Cần tách worker pool lớn.

RabbitMQ phù hợp với work queue hơn Kafka.

10.4. Khi nào thêm Kafka/Redpanda?

Thêm Kafka/Redpanda khi:

• Cần nhiều consumer đọc cùng event.
• Cần replay lịch sử event.
• Cần rebuild search/read model.
• Cần analytics pipeline.
• Cần audit/event stream dài hạn.
• Cần consumer group độc lập.

Không thêm Kafka chỉ để chấm bài async. Chấm bài async là queue, không phải event streaming.

10.5. Outbox pattern

Mọi event quan trọng phải đi qua outbox:

DB transaction:

- lưu submission

- ghi outbox event SubmissionCreated

Outbox dispatcher:

- đọc event chưa publish

- publish qua adapter

- mark published

Nhờ vậy nếu request thành công mà broker chết, event không mất. Đây là cách nối transaction boundary với event boundary (Kiến trúc hệ thống thực dụng, Chương 20).

10.6. Idempotent consumers

Mọi consumer phải xử lý trùng an toàn:

• Có event_id.
• Có idempotency_key.
• Có bảng processed_events.
• Update theo natural key.
• Không cộng/trừ tiền hoặc điểm hai lần.

Retry/timeout/idempotency là bắt buộc vì worker, network, provider, webhook đều có thể lỗi hoặc gửi trùng (Kiến trúc hệ thống thực dụng, Chương 26).

---

11. Realtime/socket

11.1. Use case realtime thật

Synvia cần realtime cho:

• AI grading progress.
• Media processing progress.
• In-app notification.
• Teacher review queue update.
• Live classroom state.
• Meeting attendance/event.
• Chat hoặc collaborative activity sau này.

11.2. SSE trước, WebSocket sau

Nếu chỉ server đẩy trạng thái xuống client, SSE thường đơn giản hơn WebSocket:

• Grading progress.
• Notification feed.
• Processing progress.

WebSocket dùng khi:

• Client gửi event liên tục.
• Collaborative editing.
• Live classroom interaction.
• Chat/meeting state hai chiều.

Nguồn: chọn polling/SSE/WebSocket theo nhu cầu realtime thật, không dùng công cụ nặng khi chưa cần (Kiến trúc hệ thống thực dụng, mục WebSocket/SSE trong Chương 15/21 của new-synvia).

---

12. Storage, file và media

12.1. Nguyên tắc

• Object storage là mặc định cho file người dùng.
• Database chỉ lưu metadata và reference.
• Không phụ thuộc local path.
• Upload lớn dùng multipart/presigned URL.
• File phải có virus scan hoặc validation nếu production nghiêm túc.
• Media processing chạy async.

12.2. File types

Synvia cần quản:

• Avatar.
• Course images.
• Lesson documents.
• PDF bài tập.
• Audio/video bài nghe/nói.
• Submission attachments.
• Teacher feedback audio.
• Meeting recordings.
• Generated reports.
• AI context artifacts.

12.3. Metadata bắt buộc

Mỗi file nên có:

• Tenant.
• Owner.
• Purpose.
• Storage key.
• MIME type.
• Size.
• Checksum.
• Visibility policy.
• Retention policy.
• Processing status.
• Derived-from relation nếu file là transcript/thumbnail/chunk.

File/object storage là một phần nền tảng production, không phải thư mục upload đơn giản (Kiến trúc hệ thống thực dụng, Chương 33 trong mục lục new-synvia).

---

13. Analytics và learning data

13.1. Không trộn operational data với learning evidence

Operational data:

• Ai đăng ký lớp.
• Ai thanh toán.
• Ai điểm danh.
• Ai nộp bài.

Learning evidence:

• Người học sai kỹ năng nào.
• Sửa bài có tốt hơn không.
• Feedback nào được xem.
• Feedback nào tạo revision.
• Objective nào đạt mastery.
• Lỗi nào lặp lại ở lớp.

Dữ liệu vận hành giúp tổ chức bớt mù, nhưng không tự động là dữ liệu học tập (EdTech đa góc nhìn, Chương 6; Bản đồ EdTech thực chứng, Chương 2).

13.2. Learning events

Ví dụ event:

ActivityStarted

QuestionAnswered

SubmissionCreated

FeedbackViewed

RevisionSubmitted

TeacherFeedbackGiven

InterventionAssigned

PracticeCompleted

ObjectiveMasteryUpdated

Các event này dùng cho:

• Learner dashboard.
• Teacher dashboard.
• Parent summary.
• Intervention.
• Analytics.
• Product improvement.

Nhưng phải có privacy/data governance rõ (Kiến trúc hệ thống thực dụng, Chương 63; Bản đồ EdTech thực chứng, Chương 8).

13.3. Early warning nhưng không dán nhãn

Hệ thống có thể phát hiện:

• Nộp bài trễ liên tục.
• Không xem feedback.
• Revision không cải thiện.
• Vắng nhiều.
• Điểm giảm.
• Lỗi lặp lại.

Nhưng UI không nên gắn nhãn cứng kiểu “học viên yếu”. Nên hiển thị “tín hiệu cần chú ý” và đề xuất can thiệp cụ thể. Dữ liệu chỉ có giá trị khi có người và quy trình can thiệp (EdTech đa góc nhìn, Chương 9).

---

14. Teacher Workbench

14.1. Mục tiêu

Teacher Workbench là trái tim của hệ thống nếu Synvia muốn là EdTech thật, không chỉ là LMS.

Nó phải giúp giáo viên:

• Xem lớp nào cần chú ý.
• Xem bài nào AI không chắc.
• Duyệt/sửa/reject feedback AI.
• Gom lỗi lặp lại.
• Tạo intervention.
• Theo dõi revision.
• Giao bài luyện theo skill.
• Nhìn workload thật.

14.2. Review queue

Queue item có thể được ưu tiên theo:

• High-stakes assignment.
• Low confidence.
• Severe feedback.
• Parent-visible result.
• Learner age.
• Teacher policy.
• AI safety flag.
• Score changed unusually.

14.3. Error clustering

Không nên bắt giáo viên đọc 100 bài riêng lẻ nếu 70 bài mắc cùng một lỗi.

Hệ thống nên gom:

• Lỗi theo skill.
• Lỗi theo rubric criterion.
• Lỗi theo misconception.
• Lỗi theo câu hỏi.
• Lỗi theo nhóm học viên.

Nguồn: AI grouping/error clustering trong assessment và dashboard analytics cho giáo viên (Công nghệ giáo dục: Cái đúng, cái sai, và cái cần làm, Chương 4, Chương 6; Bản đồ EdTech thực chứng, Chương 6, Chương 8).

14.4. Intervention

Intervention phải là entity thật:

• Ai tạo.
• Vì sao tạo.
• Nhắm tới objective/skill nào.
• Áp dụng cho ai.
• Hoạt động gì.
• Deadline.
• Kết quả sau can thiệp.

Nếu không ghi lại intervention, analytics chỉ dừng ở “biết vấn đề” mà không nối tới hành động.

---

15. Learner Workspace

15.1. Không phải dashboard điểm

Learner workspace không nên chỉ hiển thị:

• Lớp của tôi.
• Bài tập của tôi.
• Điểm của tôi.

Nó phải hiển thị:

• Tôi đang học kỹ năng nào.
• Bước tiếp theo là gì.
• Feedback nào cần xử lý.
• Tôi đã sửa bài ra sao.
• Tôi tiến bộ ở đâu.
• Tôi cần luyện lại gì.
• Tôi có thể hỏi/nhờ giáo viên chỗ nào.

Nguồn: self-regulated learning cần mục tiêu, chiến lược, giám sát tiến độ và phản tư (Bản đồ EdTech thực chứng, Chương 4, Chương 15).

15.2. Revision loop

Mỗi feedback quan trọng nên có vòng:

Feedback -> Learner reflection -> Revision -> Re-assessment -> Progress update

Điều này tránh việc feedback trở thành đoạn text chết.

15.3. Chống phụ thuộc AI

Nếu có AI tutor/chat:

• Không trả đáp án ngay với bài đang làm.
• Ưu tiên hint.
• Yêu cầu người học giải thích trước.
• Có mức trợ giúp.
• Log khi người học dùng AI.
• Giáo viên thấy được pattern dùng AI.

Nguồn: Socratic scaffolding, intentional friction, cognitive offloading, AI as tutor/tool/tutee/peer/coach (Bản đồ EdTech thực chứng, Chương 7, Chương 15, Chương 17; Công nghệ giáo dục: Cái đúng, cái sai, và cái cần làm, Chương 5, Chương 10).

---

16. Parent Portal

16.1. Mục tiêu

Parent portal phải trả lời câu hỏi:

> Con tôi học được gì, cần hỗ trợ gì, và tôi nên làm gì tiếp?

Không chỉ:

> Con tôi được mấy điểm, đi học mấy buổi, làm bao nhiêu activity?

Nguồn: phụ huynh mua hy vọng và an tâm; dashboard phụ huynh có thể giúp hiểu con nhưng cũng có thể tăng giám sát (EdTech đa góc nhìn, Chương 19).

16.2. Nội dung nên có

• Attendance.
• Upcoming sessions.
• Payment/subscription.
• Progress summary theo skill.
• Feedback highlights.
• Teacher note.
• Suggested support at home.
• Alert nếu có dấu hiệu cần chú ý.

16.3. Điều không nên làm

• Không biến portal thành camera giám sát học viên.
• Không hiển thị mọi lỗi nhỏ nếu làm tăng áp lực.
• Không dùng AI summary không qua policy cho trẻ em.

---

17. Commerce và vận hành tài chính

17.1. Commerce không được phá domain học tập

Course offer để bán không luôn giống cohort/class để học. Cần tách:

• Product/offer.
• Course academic object.
• Cohort/class delivery.
• Purchase/order.
• Enrollment.

Một người có thể mua combo, subscription, installment, voucher; nhưng enrollment vào lớp phải qua rule rõ.

17.2. Ledger/reconciliation

Tiền cần audit chặt:

• Order.
• Payment intent.
• Transaction.
• Refund.
• Adjustment.
• Invoice.
• Receipt.
• Reconciliation batch.

Webhook payment phải:

• Verify signature.
• Có idempotency key.
• Lưu raw event.
• Không xử lý trùng.
• Có manual reconciliation.

Nguồn: webhook retry/idempotency, money ledger/reconciliation trong hệ thống production (Kiến trúc hệ thống thực dụng, Chương 16, Chương 26; new-synvia Chương 64 theo mục lục).

---

18. Security, privacy, compliance

18.1. Security boundary

Hệ thống cần:

• Authentication.
• Tenant-aware authorization.
• Admin role separation.
• Service-to-service authentication.
• API key management.
• Rate limiting.
• CSRF/session security.
• Webhook signature verification.
• Secrets management.
• Audit log.

18.2. Privacy/data governance

Cần định nghĩa:

• Data categories.
• Purpose.
• Legal/contract basis nếu có.
• Retention.
• Export.
• Delete/anonymize.
• Access audit.
• AI usage consent.
• Provider data policy.

Nguồn: privacy không chỉ là bảo mật; dữ liệu học tập, prompt, response, feedback, điểm, log đều nhạy cảm (Kiến trúc hệ thống thực dụng, Chương 63; Công nghệ giáo dục: Cái đúng, cái sai, và cái cần làm, Chương 13).

18.3. AI privacy

Mỗi AI workflow phải biết:

• Dữ liệu nào được đưa vào prompt.
• Có PII không.
• Có redaction không.
• Provider có lưu/training không.
• Tenant policy cho phép không.
• Prompt/response được lưu bao lâu.
• Ai được xem raw response.

18.4. Trẻ em và age-appropriate AI

Nếu phục vụ trẻ em:

• AI chat độc lập cần giới hạn.
• Parent/teacher visibility cần rõ.
• Nội dung nhạy cảm phải escalation.
• Không dùng nudging thao túng.
• Không tối ưu engagement bất chấp wellbeing.

Nguồn: age-appropriate AI, wellbeing, quan hệ người-người (Bản đồ EdTech thực chứng, Chương 18, Chương 21; EdTech đa góc nhìn, Chương 19, Chương 21).

---

19. Observability

19.1. Vì sao bắt buộc

Một hệ EdTech production có nhiều thứ chạy nền:

• AI grading.
• Media processing.
• Notification.
• Payment webhook.
• Report export.
• Sync/integration.

Nếu không có observability, web app có thể xanh nhưng người dùng vẫn bị kẹt vì worker chết hoặc queue backlog (Kiến trúc hệ thống thực dụng, Chương 28, Chương 49-53 theo mục lục).

19.2. Logging

Structured log có:

• request_id
• tenant_id
• user_id
• job_id
• event_id
• submission_id
• ai_run_id
• payment_id
• trace_id

19.3. Metrics

HTTP:

• request rate
• latency p50/p95/p99
• error rate
• DB query time

Queue:

• queue length
• oldest job age
• wait time
• processing time
• retry rate
• failure rate
• DLQ count

AI:

• latency
• token/cost
• schema failure rate
• safety flag rate
• provider error rate
• human override rate

Learning:

• feedback viewed rate
• revision submitted rate
• intervention completion
• time to feedback
• teacher review backlog

19.4. Tracing

Trace cần nối:

POST submission

-> create job

-> worker

-> AI service

-> DB save

-> event publish

-> frontend status update

Không có tracing, debug AI/job/event sẽ rất mệt.

---

20. Testing và quality

20.1. Test pyramid

Tối thiểu:

• Unit tests cho domain rule.
• Service/use case tests.
• API tests.
• Permission tests.
• Integration tests với Celery eager hoặc test broker.
• Contract tests giữa Next.js và DRF/FastAPI.
• E2E tests cho critical flows.
• AI evaluation tests.

Nguồn: test để tự tin đổi hệ thống, contract testing, event-driven testing (Kiến trúc hệ thống thực dụng, Chương 56, Chương 57, Chương 58).

20.2. Critical flows phải test

• User login/invite.
• Tenant switch.
• Create course/class.
• Enroll learner.
• Upload material.
• Create assignment/rubric.
• Submit attempt.
• AI grading job.
• Teacher review.
• Revision loop.
• Parent summary.
• Payment webhook.
• Notification send.
• Permission denial.
• Tenant data isolation.

20.3. AI tests

AI không test như function thường. Cần:

• Schema validation tests.
• Golden dataset.
• Regression evaluation.
• Safety tests.
• Prompt injection tests.
• Cost/latency threshold.
• Human override tracking.

Nguồn: AI app cần evaluation vì output non-deterministic (Kiến trúc hệ thống thực dụng, Chương 60).

---

21. Documentation

Hệ thống mới phải có docs như một phần sản phẩm kỹ thuật:

• docs/architecture/overview.md
• docs/architecture/module-boundaries.md
• docs/domain/learning-model.md
• docs/domain/assessment-policy.md
• docs/domain/ai-governance.md
• docs/api/openapi.md
• docs/events/event-catalog.md
• docs/runbooks/worker-backlog.md
• docs/runbooks/payment-reconciliation.md
• docs/runbooks/ai-provider-down.md
• docs/security/data-governance.md
• docs/testing/strategy.md

Docs không chỉ để onboarding. Nó là cách giữ modular monolith không trượt về monolith rối.

---

22. Deployment và môi trường

22.1. Môi trường

• Local.
• Dev.
• Staging.
• Production.

Mỗi môi trường có:

• DB riêng.
• Storage bucket/prefix riêng.
• Secrets riêng.
• AI provider config riêng.
• Payment sandbox/prod riêng.

22.2. CI/CD

Pipeline:

lint

type check

unit test

API schema check

frontend test

build Docker images

migration check

deploy staging

smoke test

manual approve prod

deploy prod

post-deploy smoke

22.3. Deploy an toàn

• Backward-compatible migrations.
• Feature flags.
• Rollback plan.
• Blue/green hoặc rolling deploy.
• Worker graceful shutdown.
• Queue drain policy.

Nguồn: production khác localhost, CI/CD, deploy an toàn, failure modes, backup/restore (Kiến trúc hệ thống thực dụng, Chương 40, Chương 46, Chương 54, Chương 55, Chương 59).

---

23. Roadmap đề xuất

Giai đoạn 0: Product/domain discovery

Thời lượng: 2-4 tuần.

Kết quả:

• Ubiquitous language.
• Role matrix.
• Tenant model.
• Learning flow.
• Assessment policy.
• AI governance policy.
• Module boundaries.
• Critical workflows.

Giai đoạn 1: Foundation

Thời lượng: 6-8 tuần.

Xây:

• Repo mới.
• Django/DRF.
• Next.js.
• PostgreSQL.
• Accounts.
• Tenancy.
• RBAC.
• Storage.
• Celery/Redis.
• Logging.
• OpenAPI.
• Test setup.
• CI/CD basic.

Giai đoạn 2: LMS vận hành tối thiểu

Thời lượng: 8-10 tuần.

Xây:

• Course.
• Class/cohort.
• Enrollment.
• Lesson.
• Material.
• Schedule.
• Attendance.
• Student dashboard cơ bản.
• Teacher dashboard cơ bản.

Giai đoạn 3: Assessment Core

Thời lượng: 8-10 tuần.

Xây:

• Learning objective.
• Skill.
• Assignment.
• Question/task.
• Attempt.
• Submission.
• Rubric.
• Feedback item.
• Revision.
• Teacher review.

Giai đoạn 4: AI Assessment Service

Thời lượng: 8-12 tuần.

Xây:

• FastAPI AI service.
• Context builder.
• Prompt registry.
• Provider adapter.
• Schema validation.
• AI run audit.
• Evaluation dataset.
• Celery integration.
• Progress tracking.
• Teacher review policy.

Giai đoạn 5: Commerce + Notification + Parent

Thời lượng: 8-10 tuần.

Xây:

• Order/payment.
• Coupon/subscription.
• Webhook idempotency.
• Parent portal.
• Notification templates.
• Email/Zalo/in-app.
• Delivery log.

Giai đoạn 6: Learning analytics + production hardening

Thời lượng: 8-12 tuần.

Xây:

• Learning events.
• Progress/mastery.
• Error clusters.
• Intervention.
• Observability dashboards.
• Backup/restore.
• Security review.
• Load tests.
• Data migration/import tools.

Ước lượng tổng

• MVP nghiêm túc: 5-7 tháng.
• Thay thế hệ cũ ở mức vận hành được: 9-12 tháng.
• Hệ EdTech có chiều sâu thật: 12-18 tháng.

Phần kéo dài không phải CRUD, mà là assessment, learning evidence, AI governance, teacher workflow, privacy và vận hành production.

---

24. Definition of Done cấp hệ thống

Một module chưa được coi là xong nếu thiếu:

• Domain model rõ.
• Service/use case layer.
• API documented.
• Permission tests.
• Tenant isolation tests.
• Audit log cho hành động quan trọng.
• Error handling.
• Metrics/logs.
• Admin/support tooling.
• Migration plan nếu liên quan dữ liệu cũ.
• Runbook nếu có job/webhook/provider ngoài.

Một AI workflow chưa được coi là xong nếu thiếu:

• Prompt version.
• Schema.
• Validation.
• Evaluation set.
• Cost/latency logging.
• Safety policy.
• Human review path.
• Incident reporting.
• Fallback.

Một queue/job chưa được coi là xong nếu thiếu:

• Timeout.
• Retry/backoff.
• Idempotency.
• Status tracking.
• DLQ/manual retry.
• Metrics.
• Alert.

---

25. Những quyết định kiến trúc nên chốt sớm

1. Tenant là trung tâm/trường hay workspace? 2. Một user có thể thuộc nhiều tenant không? 3. Parent là user login thật hay contact/token access? 4. Grade nào là official: AI, teacher, hay policy quyết định? 5. Feedback nào được parent thấy? 6. Dữ liệu nào được gửi sang AI provider? 7. Raw AI prompt/response lưu bao lâu? 8. Có cần online judge/coding module không? 9. Payment là core ngay hay phase sau? 10. Wagtail/CMS cần trong core hay tách content nhẹ trước? 11. RabbitMQ/Kafka có cần ngay không, hay chỉ thiết kế abstraction? 12. Có cần multi-tenant hard ngay từ đầu không? Câu trả lời gần như là có.

---

26. Rủi ro lớn nhất

26.1. Xây lại nhưng bê nghiệp vụ cũ sang

Nếu chỉ đổi stack, hệ mới vẫn sẽ là LMS/CRM rối hơn. Cần domain redesign trước code.

26.2. AI làm sản phẩm trông thông minh nhưng khó tin

Nếu thiếu evaluation, audit, teacher review và policy, AI grading sẽ gây mất niềm tin nhanh.

26.3. Multi-tenancy làm muộn

Nếu ban đầu không có tenant boundary, sau này thêm rất đau. Tenant ảnh hưởng cache, search, AI context, audit, quota, billing và support (Kiến trúc hệ thống thực dụng, Chương 62).

26.4. Queue/worker là hộp đen

Không có job dashboard, người dùng sẽ thấy “bài chấm mãi chưa xong” mà team chỉ biết đoán (Kiến trúc hệ thống thực dụng, Chương 28).

26.5. Dashboard giáo viên tăng tải

Nếu workbench chỉ thêm việc duyệt/sửa, giáo viên sẽ chống lại. Công cụ tốt phải tăng năng lực phán đoán và giảm tải tổng thể (Bản đồ EdTech thực chứng, Chương 19; EdTech đa góc nhìn, Chương 17).

---

27. Kết luận

Synvia V2 nên được xây như một hệ thống học tập có bằng chứng, không phải một LMS có AI gắn thêm.

Kiến trúc đúng là:

• Modular monolith cho core.
• Django/DRF cho domain và backoffice.
• Next.js cho trải nghiệm người dùng.
• PostgreSQL làm source of truth.
• Celery cho job nền.
• Redis ban đầu cho cache/broker.
• RabbitMQ khi task queue cần bền/routing/DLQ tốt hơn.
• Kafka/Redpanda khi event stream/replay/analytics trở thành nhu cầu thật.
• FastAPI cho AI assessment service vì workload và governance khác biệt.
• Object storage, realtime, observability, audit, docs, tests ngay từ đầu.

Sản phẩm đúng là:

• Objective-driven.
• Evidence-based.
• Feedback-to-action.
• Revision-centered.
• Teacher-in-the-loop.
• Parent-aware nhưng không surveillance.
• Privacy-by-design.
• AI-governed, không AI-autopilot.
• Production observable.

Nếu làm đúng, Synvia không chỉ là một hệ thống quản lý lớp học. Nó trở thành một nền tảng giúp tổ chức giáo dục nhìn thấy việc học đang diễn ra như thế nào, giáo viên can thiệp tốt hơn, người học biết bước tiếp theo, phụ huynh hiểu tiến bộ thật, và AI được đặt đúng vị trí: một công cụ có kiểm soát trong vòng lặp sư phạm.

---

Phụ lục A. Bảng mapping ý tưởng sang nguồn sách/chương