Giai đoạn 15 - Source Code Reading (Ngày 904–959)

Đọc source có hệ thống. Sau 14 giai đoạn xây nền tảng, đây là lúc áp dụng toàn bộ vào việc đọc hiểu các thư viện production thật - kỹ năng nên duy trì liên tục cả sau mốc 959 ngày này.

Nhóm 1: Giới thiệu (Ngày 904–905)

Ngày 904: Phương pháp đọc Source Thư viện Lớn

• Mục tiêu: Có phương pháp nhất quán trước khi đọc 13 thư viện trong giai đoạn này.

• Lý thuyết: Ôn lại phương pháp đã học Ngày 457: bắt đầu từ entry point, đọc README/architecture doc trước code, dùng debugger trace thay vì đọc tuyến tính, ưu tiên hiểu "happy path" trước edge case.

• Thực hành: Với mỗi thư viện sắp đọc, chuẩn bị sẵn 3 câu hỏi cụ thể muốn trả lời (VD: với Netty - "EventLoop xử lý bao nhiêu connection trên 1 thread?") thay vì đọc lan man.

Ngày 905: Reading Log

• Mục tiêu: Xây thói quen ghi chú hiệu quả để không quên kiến thức đã đọc.

• Lý thuyết: Reading log tốt ghi lại: vấn đề thư viện giải quyết, kiến trúc tổng quan, 1-2 đoạn code/pattern đáng nhớ nhất, liên hệ với kiến thức đã học trước đó trong roadmap.

• Thực hành: Tạo template reading log sẽ dùng xuyên suốt 56 ngày tới, áp dụng thử cho 1 thư viện nhỏ đã biết trước (VD: 1 thư viện quen thuộc).

PHẦN A: JAVA TRACK (Ngày 906–921)

Ngày 906: Spring WebFlux - Reactive Programming Model

• Mục tiêu: Học mô hình lập trình khác hẳn Spring MVC đã học Giai đoạn 10.

• Lý thuyết: WebFlux dựa trên Project Reactor (Mono/Flux) - reactive streams, non-blocking từ đầu tới cuối, liên hệ trực tiếp Asyncio (Giai đoạn 5) và ASGI (Giai đoạn 10) nhưng ở hệ sinh thái Java.

• Thực hành: Viết 1 endpoint đơn giản bằng WebFlux (Mono<Order>), so sánh với endpoint tương đương ở Spring MVC (Giai đoạn 10), giải thích khác biệt về threading model.

Ngày 907: Đọc Source Spring Cloud - Service Discovery Client

• Mục tiêu: Liên hệ lại Service Discovery đã tự thiết kế ở Giai đoạn 12.

• Lý thuyết: Spring Cloud tích hợp sẵn client cho Eureka/Consul - đọc cách nó tự động đăng ký service khi ApplicationContext khởi động (liên hệ Bean Lifecycle, Giai đoạn 10).

• Thực hành: Đọc source 1 phần đăng ký service tự động của Spring Cloud, ghi chú lại vào Reading Log.

Ngày 908: Hibernate - Kiến trúc Tổng quan

• Mục tiêu: Hiểu Hibernate là implementation nằm dưới Spring Data JPA đã dùng ở Giai đoạn 10.

• Lý thuyết: Hibernate implement JPA spec - Spring Data JPA chỉ là lớp tiện ích xây trên Hibernate (hoặc EclipseLink), không phải công nghệ riêng biệt.

• Thực hành: Vẽ sơ đồ quan hệ: Spring Data JPA → JPA Specification → Hibernate implementation.

Ngày 909: Hibernate - Session Internals & First-level Cache

• Mục tiêu: Đào sâu hơn Unit of Work/Identity Map đã học ở SQLAlchemy (Giai đoạn 10), giờ ở phía Java.

• Lý thuyết: Hibernate Session cũng implement Unit of Work + Identity Map (gọi là "Persistence Context") - cùng ý tưởng, khác ngôn ngữ.

• Thực hành: So sánh Hibernate Session với SQLAlchemy Session đã học, lập bảng điểm giống/khác.

Ngày 910: Hibernate - Lazy Loading Proxy

• Mục tiêu: Liên hệ trực tiếp Bytecode Manipulation đã học Giai đoạn 14 (ASM).

• Lý thuyết: Hibernate implement lazy loading bằng cách tạo proxy class runtime (dùng bytecode enhancement, tương tự CGLIB/ASM đã học) - khi truy cập field lazy, proxy mới thực sự query database.

• Thực hành: Giải thích cơ chế proxy lazy loading dưới góc nhìn ASM/CGLIB đã học, liên hệ lại N+1 problem (Giai đoạn 10).

Ngày 911: Đọc Source Hibernate - SessionImpl

• Mục tiêu: Đọc source thật, không chỉ tài liệu.

• Lý thuyết: Ôn lại phương pháp đọc source (Ngày 904).

• Thực hành: Đọc source SessionImpl (hoặc phần tương đương), trace luồng khi gọi session.get(Order.class, id), ghi chú vào Reading Log.

Ngày 912: Kafka Broker - Kiến trúc Lưu trữ

• Mục tiêu: Liên hệ trực tiếp WAL đã học Giai đoạn 11.

• Lý thuyết: Mỗi Kafka partition thực chất là 1 append-only log trên disk - chính là ý tưởng WAL đã tự implement ở Mini KV Store, giờ thấy nó ở quy mô production.

• Thực hành: So sánh cấu trúc file log của Kafka với WAL đã tự viết (Giai đoạn 11), tìm điểm tương đồng.

Ngày 913: Kafka - KRaft (Kafka Raft)

• Mục tiêu: Liên hệ trực tiếp Raft đã học Giai đoạn 12.

• Lý thuyết: Kafka hiện đại dùng KRaft (biến thể Raft) để tự quản lý metadata cluster, thay thế phụ thuộc vào ZooKeeper trước đây.

• Thực hành: Đọc tài liệu KRaft, xác định phần nào của Raft đã tự implement ở Giai đoạn 12 (Leader Election, Log Replication) tương ứng với cơ chế KRaft.

Ngày 914: Kafka - Log Segment & Index File

• Mục tiêu: Hiểu cách Kafka tối ưu việc đọc log lớn.

• Lý thuyết: Log được chia thành nhiều segment file, mỗi segment có index file riêng (offset → vị trí byte) - liên hệ B+Tree Index đã học Giai đoạn 11 (dù đơn giản hơn, dùng sparse index).

• Thực hành: Đọc tài liệu cấu trúc segment/index file của Kafka, so sánh với B+Tree index đã tự viết.

Ngày 915: Đọc Source Kafka - LogSegment

• Mục tiêu: Đọc source thật của thành phần cốt lõi nhất.

• Lý thuyết: Ôn lại phương pháp đọc source.

• Thực hành: Đọc source LogSegment (Scala/Java tuỳ phiên bản), trace luồng append 1 message mới, ghi chú vào Reading Log.

Ngày 916: Netty - EventLoop

• Mục tiêu: Liên hệ trực tiếp epoll/event loop đã học Giai đoạn 6.

• Lý thuyết: Netty EventLoop chính là implementation production-grade của mini event loop đã tự viết ở Giai đoạn 6 (Ngày 293) - mỗi EventLoop chạy trên 1 thread, xử lý nhiều connection qua epoll.

• Thực hành: So sánh kiến trúc Netty EventLoopGroup với mini event loop tự viết, xác định điểm nào Netty tối ưu/mở rộng thêm.

Ngày 917: Netty - ChannelPipeline & ChannelHandler

• Mục tiêu: Liên hệ trực tiếp Chain of Responsibility (Giai đoạn 3) và Middleware (Giai đoạn 3/10).

• Lý thuyết: ChannelPipeline là 1 chuỗi ChannelHandler xử lý dữ liệu qua từng bước (inbound/outbound) - chính là Chain of Responsibility áp dụng cho network data processing.

• Thực hành: Viết 1 ChannelHandler đơn giản, thêm vào pipeline, verify thứ tự xử lý.

Ngày 918: Netty - ByteBuf & Zero-copy

• Mục tiêu: Học tối ưu hiệu năng đặc trưng của Netty.

• Lý thuyết: ByteBuf thay thế java.nio.ByteBuffer mặc định, hỗ trợ zero-copy (tránh copy dữ liệu không cần thiết giữa các buffer) - liên hệ lại chi phí copy dữ liệu đã bàn tới ở nhiều nơi (Allocator, Giai đoạn 14).

• Thực hành: Đọc tài liệu về CompositeByteBuf, giải thích cách nó tránh copy khi ghép nhiều buffer lại.

Ngày 919: Netty - Reactor Pattern

• Mục tiêu: Hình thức hoá pattern đã dùng ngầm từ Giai đoạn 6.

• Lý thuyết: Reactor Pattern - 1 (hoặc nhiều) thread demultiplex event từ nhiều I/O source (qua epoll) và dispatch tới handler tương ứng - đây chính là tên chính thức của kiến trúc mini event loop đã xây.

• Thực hành: Vẽ sơ đồ Reactor Pattern áp dụng cho Netty, đối chiếu với mini event loop (Giai đoạn 6) và Boost.Asio (Giai đoạn 10) - cả 3 đều cùng 1 pattern.

Ngày 920: Lab - Viết Netty Server Đơn giản

• Mục tiêu: Thực hành trực tiếp.

• Lý thuyết: Ôn lại ServerBootstrap, ChannelInitializer.

• Thực hành: Viết 1 TCP echo server bằng Netty, so sánh độ dài code với bản tự viết bằng epoll (Giai đoạn 6) và Boost.Asio (Giai đoạn 10).

Ngày 921: Đọc Source Netty - 1 Handler cụ thể

• Mục tiêu: Đọc source thật của 1 thành phần production.

• Lý thuyết: Ôn lại phương pháp đọc source.

• Thực hành: Đọc source 1 handler có sẵn trong Netty (VD: HttpServerCodec), ghi chú vào Reading Log, kết thúc Java Track.

PHẦN B: PYTHON TRACK (Ngày 922–939)

Ngày 922: FastAPI Advanced - Starlette Internals

• Mục tiêu: Đào sâu hơn lớp nền tảng đã học sơ qua ở Giai đoạn 10.

• Lý thuyết: Đọc source Starlette routing - cách nó dùng regex compile từ path pattern để match URL, tương tự nhưng chi tiết hơn Router đã tự viết (Giai đoạn 3).

• Thực hành: Đọc source Starlette.Router, so sánh thuật toán match route với Router tự viết.

Ngày 923: FastAPI - Pydantic v2 Internals

• Mục tiêu: Biết về sự thay đổi kiến trúc lớn của Pydantic.

• Lý thuyết: Pydantic v2 viết lại core validation bằng Rust (pydantic-core) để tăng tốc đáng kể so với v1 thuần Python - minh hoạ thực tế việc dùng ngôn ngữ hiệu năng cao hơn cho phần hot path (liên hệ lại C Extension nhả GIL, Giai đoạn 14).

• Thực hành: Đọc benchmark công khai so sánh Pydantic v1 vs v2, tóm tắt lý do cải thiện tốc độ.

Ngày 924: SQLAlchemy Advanced - Query Compilation

• Mục tiêu: Đào sâu cách SQLAlchemy sinh SQL cuối cùng.

• Lý thuyết: SQLAlchemy có hệ thống "dialect" - cùng 1 query Core/ORM được compile khác nhau tuỳ database đích (PostgreSQL/MySQL/SQLite có cú pháp SQL hơi khác nhau).

• Thực hành: Viết cùng 1 query, generate SQL cho 2 dialect khác nhau, so sánh khác biệt.

Ngày 925: Đọc Source SQLAlchemy - Session Internals

• Mục tiêu: Đọc source thật của Unit of Work đã dùng nhiều ở Giai đoạn 7/10.

• Lý thuyết: Ôn lại phương pháp đọc source.

• Thực hành: Đọc source Session.flush() (phần quan trọng nhất - nơi Unit of Work thực sự sinh SQL), ghi chú vào Reading Log.

Ngày 926: Django - Kiến trúc Tổng quan

• Mục tiêu: Hiểu triết lý "batteries included" của Django.

• Lý thuyết: MTV pattern (Model-Template-View, biến thể của MVC) - khác Spring/FastAPI ở chỗ Django đi kèm rất nhiều thứ có sẵn (admin site, auth, forms) thay vì để ghép từ nhiều thư viện.

• Thực hành: Liệt kê những gì Django có sẵn mà FastAPI/Spring cần thêm thư viện riêng (admin UI, ORM tích hợp, auth system).

Ngày 927: Django - Middleware & Request/Response Cycle

• Mục tiêu: Liên hệ lại Middleware Pipeline (Giai đoạn 3/10).

• Lý thuyết: Django Middleware xử lý request/response theo dạng "onion" (mỗi middleware bọc quanh middleware tiếp theo) - hơi khác cấu trúc tuyến tính đã tự viết, gần giống Interceptor lồng nhau.

• Thực hành: Đọc source cách Django gọi chuỗi middleware, vẽ sơ đồ minh hoạ cấu trúc "onion" này.

Ngày 928: Django Admin - Liên hệ Metaclass

• Mục tiêu: Liên hệ trực tiếp Metaclass đã học Giai đoạn 14 (Ngày 824-825).

• Lý thuyết: Django Model dùng metaclass (ModelBase) để tự động biến class attribute thành field mapping và đăng ký model vào registry - chính là ứng dụng thực tế của metaclass đã tự viết thử nghiệm.

• Thực hành: Đọc source ModelBase.__new__, đối chiếu với metaclass tự viết ở Giai đoạn 14, xác định điểm giống nhau về ý tưởng.

Ngày 929: Đọc Source Django - 1 phần cụ thể

• Mục tiêu: Đọc source thật, kết thúc phần Django.

• Lý thuyết: Ôn lại phương pháp đọc source.

• Thực hành: Đọc source QuerySet (đã dùng khái niệm lazy evaluation ở Giai đoạn 10), trace 1 query đơn giản từ lúc gọi .filter() tới lúc thực sự chạy SQL.

Ngày 930: Airflow - Kiến trúc Tổng quan

• Mục tiêu: Học công cụ orchestration workflow phổ biến nhất, liên hệ Distributed Job System (Giai đoạn 12).

• Lý thuyết: Airflow định nghĩa workflow bằng DAG (Directed Acyclic Graph) - mỗi node là 1 Task, cạnh biểu diễn dependency giữa các task.

• Thực hành: So sánh khái niệm DAG của Airflow với Saga (Giai đoạn 8) - cả 2 đều mô tả chuỗi bước có thứ tự, nhưng khác nhau ở mục đích (Airflow cho batch/ETL, Saga cho transaction xuyên service).

Ngày 931: Airflow - Scheduler Internals

• Mục tiêu: Liên hệ trực tiếp Distributed Job System đã tự xây ở Giai đoạn 12.

• Lý thuyết: Airflow Scheduler liên tục quét DAG definition, xác định task nào đã sẵn sàng chạy (dependency đã hoàn thành), đẩy vào queue cho Executor xử lý - cùng ý tưởng với Scheduler đã tự viết.

• Thực hành: So sánh Airflow Scheduler với OrderSagaOrchestrator/Scheduler đã tự viết (Giai đoạn 8/12), chỉ ra điểm giống về vai trò.

Ngày 932: Airflow - Executor Types

• Mục tiêu: Học các chiến lược thực thi task khác nhau.

• Lý thuyết: LocalExecutor (chạy trên cùng máy Scheduler), CeleryExecutor (phân phối qua Celery - sẽ học ngay sau), KubernetesExecutor (mỗi task chạy trong 1 Pod riêng, liên hệ Giai đoạn 13).

• Thực hành: Lập bảng so sánh 3 Executor theo tiêu chí: khả năng scale, độ phức tạp vận hành, use case phù hợp.

Ngày 933: Airflow - Task Dependency & XCom

• Mục tiêu: Hiểu cách task truyền dữ liệu cho nhau.

• Lý thuyết: XCom (cross-communication) cho phép task này truyền kết quả nhỏ cho task khác - tương tự khái niệm truyền dữ liệu giữa các bước trong Saga (Giai đoạn 8).

• Thực hành: Thiết kế 1 DAG đơn giản (3 task: extract → transform → load) với dependency rõ ràng, sử dụng XCom truyền dữ liệu giữa extract và transform.

Ngày 934: Lab - Viết DAG Đơn giản

• Mục tiêu: Thực hành trực tiếp.

• Lý thuyết: Ôn lại cú pháp định nghĩa DAG bằng Python decorator (@dag, @task).

• Thực hành: Cài Airflow (qua Docker), viết và chạy DAG đã thiết kế Ngày 933.

Ngày 935: Đọc Source Airflow - Scheduler Loop

• Mục tiêu: Đọc source thật của thành phần trung tâm.

• Lý thuyết: Ôn lại phương pháp đọc source.

• Thực hành: Đọc source vòng lặp chính của Scheduler, ghi chú vào Reading Log, kết thúc phần Airflow.

Ngày 936: Celery - Kiến trúc Tổng quan

• Mục tiêu: Liên hệ trực tiếp Distributed Job System (Giai đoạn 12) và Task Queue.

• Lý thuyết: Celery là distributed task queue cho Python - kiến trúc gần giống hệ thống đã tự xây ở Giai đoạn 12 (Producer gửi task, Broker lưu trữ, Worker xử lý).

• Thực hành: Vẽ lại sơ đồ kiến trúc Celery, đối chiếu trực tiếp với Distributed Job System đã tự xây.

Ngày 937: Celery - Broker & Result Backend

• Mục tiêu: Hiểu 2 thành phần hạ tầng Celery cần.

• Lý thuyết: Broker (RabbitMQ/Redis, nơi task được gửi tới) tách biệt với Result Backend (nơi lưu kết quả task để truy vấn sau) - 2 trách nhiệm khác nhau dù có thể dùng chung 1 công nghệ (VD: Redis cho cả 2).

• Thực hành: Cấu hình Celery với RabbitMQ làm Broker, Redis làm Result Backend, giải thích lý do tách biệt 2 vai trò.

Ngày 938: Celery - Worker Internals

• Mục tiêu: Liên hệ trực tiếp Concurrency (Giai đoạn 5).

• Lý thuyết: Celery Worker hỗ trợ nhiều concurrency pool (prefork/threads/eventlet) - prefork (multiprocessing, mặc định, tránh giới hạn GIL đã học Giai đoạn 5/14) phù hợp CPU-bound task, eventlet (event-based) phù hợp I/O-bound.

• Thực hành: Chọn concurrency pool phù hợp cho 2 loại task khác nhau (tính toán nặng vs gọi API nhiều), giải thích lựa chọn dựa trên kiến thức GIL đã học.

Ngày 939: Đọc Source Celery - Worker Loop

• Mục tiêu: Đọc source thật, kết thúc Python Track.

• Lý thuyết: Ôn lại phương pháp đọc source.

• Thực hành: Đọc source vòng lặp chính của Celery Worker, ghi chú vào Reading Log.

PHẦN C: C++ TRACK (Ngày 940–957)

Ngày 940: RocksDB - Kiến trúc Tổng quan

• Mục tiêu: Liên hệ trực tiếp LSM Tree đã tự implement ở Giai đoạn 11.

• Lý thuyết: RocksDB (Facebook, fork từ LevelDB của Google) là implementation LSM Tree production-grade - Mini KV Store đã tự xây chính là phiên bản đơn giản hoá của chính RocksDB.

• Thực hành: Vẽ lại sơ đồ kiến trúc RocksDB, đối chiếu trực tiếp từng thành phần với Mini KV Store đã tự viết.

Ngày 941: RocksDB - MemTable Implementation

• Mục tiêu: Đào sâu MemTable đã học lý thuyết ở Giai đoạn 11.

• Lý thuyết: RocksDB MemTable mặc định dùng SkipList (không phải Red-Black Tree hay B-Tree) - SkipList cho hiệu năng tương đương balanced tree nhưng implementation đơn giản hơn nhiều, đặc biệt cho concurrent access.

• Thực hành: Đọc khái niệm SkipList (nếu chưa quen), giải thích ưu điểm so với balanced tree truyền thống cho use case MemTable.

Ngày 942: RocksDB - Compaction Strategy

• Mục tiêu: Đào sâu Compaction đã học lý thuyết ở Giai đoạn 11.

• Lý thuyết: Leveled Compaction (nhiều level, mỗi level lớn hơn level trước gấp 10 lần, tối ưu read) vs Universal Compaction (tối ưu write, ít read amplification hơn nhưng tốn disk space hơn tạm thời).

• Thực hành: Lập bảng so sánh 2 chiến lược compaction theo tiêu chí: write amplification, read amplification, space amplification.

Ngày 943: RocksDB - Bloom Filter

• Mục tiêu: Học cấu trúc dữ liệu xác suất tối ưu read cho LSM Tree.

• Lý thuyết: Bloom Filter cho biết "chắc chắn không có" hoặc "có thể có" 1 key trong 1 SSTable - giúp tránh phải đọc SSTable không chứa key cần tìm, giảm đáng kể read amplification (vấn đề cố hữu của LSM Tree đã học Giai đoạn 11).

• Thực hành: Đọc khái niệm Bloom Filter (hash function, bit array), giải thích tại sao nó có thể false positive nhưng không thể false negative.

Ngày 944: Lab - Benchmark RocksDB

• Mục tiêu: Thực hành trực tiếp, so sánh với Mini KV Store đã tự viết.

• Lý thuyết: Ôn lại db_bench - công cụ benchmark có sẵn của RocksDB.

• Thực hành: Chạy benchmark RocksDB cho workload write-heavy, so sánh throughput với Mini KV Store (Giai đoạn 11) đã benchmark trước đó (Ngày 643).

Ngày 945: Đọc Source RocksDB - 1 phần cụ thể

• Mục tiêu: Đọc source thật.

• Lý thuyết: Ôn lại phương pháp đọc source.

• Thực hành: Đọc source MemTable::Add() hoặc DBImpl::Get(), so sánh trực tiếp với implementation tương ứng trong Mini KV Store tự viết.

Ngày 946: ClickHouse - Kiến trúc Columnar Database

• Mục tiêu: Học loại database hoàn toàn khác những gì đã học ở Giai đoạn 11 (vốn tập trung row-based).

• Lý thuyết: Columnar storage lưu dữ liệu theo cột thay vì theo hàng - tối ưu cho analytical query (đọc ít cột nhưng nhiều hàng) thay vì transactional query (đọc/ghi 1 hàng đầy đủ).

• Thực hành: Vẽ sơ đồ so sánh row-based storage (đã học Giai đoạn 11) vs columnar storage cho cùng 1 bảng dữ liệu, giải thích tại sao columnar nhanh hơn nhiều cho query kiểu SELECT AVG(price).

Ngày 947: ClickHouse - Vectorized Execution

• Mục tiêu: Học kỹ thuật tối ưu CPU đặc trưng của columnar database.

• Lý thuyết: Vectorized execution xử lý dữ liệu theo batch (vector) thay vì từng row 1, tận dụng SIMD instruction của CPU và giảm overhead function call - liên hệ Cache/CPU Architecture đã học Giai đoạn 0.

• Thực hành: Giải thích tại sao xử lý theo batch giúp tận dụng cache locality tốt hơn xử lý từng row (liên hệ lại bài học row-major vs column-major, Giai đoạn 0 Ngày 2).

Ngày 948: ClickHouse - MergeTree Engine

• Mục tiêu: Học storage engine chính của ClickHouse.

• Lý thuyết: MergeTree lưu dữ liệu đã sort theo primary key thành nhiều part, định kỳ merge các part nhỏ thành part lớn hơn - có điểm tương đồng với LSM Tree/Compaction đã học nhưng tối ưu cho analytical workload thay vì key-value lookup.

• Thực hành: So sánh MergeTree với LSM Tree (RocksDB) - điểm giống (đều dùng merge/compaction) và điểm khác (tối ưu cho range scan phân tích thay vì point lookup).

Ngày 949: Đọc Source ClickHouse - 1 phần cụ thể

• Mục tiêu: Đọc source thật, kết thúc phần ClickHouse.

• Lý thuyết: Ôn lại phương pháp đọc source.

• Thực hành: Đọc source 1 phần đơn giản của MergeTree engine, ghi chú vào Reading Log.

Ngày 950: Envoy Advanced - Filter phức tạp hơn

• Mục tiêu: Đào sâu hơn Envoy đã học sơ bộ ở Giai đoạn 10.

• Lý thuyết: Đọc 1 filter phức tạp hơn (VD: rate limiting filter hoặc circuit breaker filter - liên hệ trực tiếp Resilience Patterns đã tự implement ở Giai đoạn 12).

• Thực hành: Đọc source filter đã chọn, so sánh implementation của Envoy với Circuit Breaker tự viết (Giai đoạn 12, Ngày 694).

Ngày 951: Envoy - xDS Implementation Chi tiết

• Mục tiêu: Đào sâu cơ chế cấu hình động đã học sơ bộ.

• Lý thuyết: Đọc cách Envoy xử lý cập nhật xDS (nhận config mới qua gRPC streaming - liên hệ Server Streaming RPC đã học Giai đoạn 10) mà không làm gián đoạn traffic đang xử lý.

• Thực hành: Vẽ sơ đồ luồng cập nhật cấu hình động, giải thích vì sao cần cơ chế "hot swap" config an toàn (không drop connection đang có).

Ngày 952: LLVM - Kiến trúc Tổng quan

• Mục tiêu: Học compiler infrastructure đứng sau Clang (và gián tiếp, mọi chương trình C++ đã compile suốt roadmap).

• Lý thuyết: Compiler pipeline: Frontend (parse source → AST) → Middle-end (tối ưu trên IR) → Backend (sinh machine code cho kiến trúc CPU cụ thể) - LLVM là middle-end + backend dùng chung cho nhiều frontend (Clang cho C++, nhưng cũng có frontend cho Rust, Swift...).

• Thực hành: Vẽ sơ đồ compiler pipeline, liên hệ lại toàn bộ quá trình từ .cpp file tới binary đã dùng suốt roadmap.

Ngày 953: LLVM IR

• Mục tiêu: Học ngôn ngữ trung gian LLVM dùng để tối ưu.

• Lý thuyết: LLVM IR (Intermediate Representation) là dạng assembly-like nhưng độc lập kiến trúc CPU - mọi optimization pass hoạt động trên IR này trước khi sinh machine code thật.

• Thực hành: Dùng clang -S -emit-llvm sinh LLVM IR cho 1 file C++ đơn giản, đọc và giải thích cấu trúc IR cơ bản.

Ngày 954: LLVM - Pass System

• Mục tiêu: Hiểu cách LLVM tổ chức các bước tối ưu.

• Lý thuyết: Optimization Pass - mỗi pass thực hiện 1 loại tối ưu cụ thể (dead code elimination, inlining, loop unrolling - liên hệ lại Inlining đã học ở JIT, Giai đoạn 14, nhưng ở đây xảy ra lúc compile-time thay vì runtime).

• Thực hành: Dùng opt (công cụ LLVM) chạy 1 vài pass tối ưu lên IR đã sinh ở Ngày 953, so sánh IR trước/sau tối ưu.

Ngày 955: Clang Frontend

• Mục tiêu: Hiểu phần đầu của pipeline, liên hệ lại toàn bộ C++ Track đã học.

• Lý thuyết: Clang parse source C++ thành AST, thực hiện type checking, template instantiation (liên hệ Giai đoạn 14) - rồi mới lower xuống LLVM IR.

• Thực hành: Dùng clang -Xclang -ast-dump xem AST của 1 đoạn code C++ đơn giản có template, đối chiếu với kiến thức Template Instantiation đã học.

Ngày 956: Lab - Đọc 1 LLVM Pass Có sẵn

• Mục tiêu: Thực hành đọc source thật của 1 optimization pass.

• Lý thuyết: Ôn lại cấu trúc chung 1 Pass (run() method nhận Function/Module, trả về IR đã biến đổi).

• Thực hành: Đọc source 1 pass đơn giản (VD: Dead Code Elimination), giải thích logic chính bằng lời của mình.

Ngày 957: Đọc Source LLVM - 1 phần cụ thể

• Mục tiêu: Đọc source thật, kết thúc C++ Track và toàn bộ Giai đoạn 15.

• Lý thuyết: Ôn lại phương pháp đọc source.

• Thực hành: Chọn 1 phần nhỏ khác của LLVM (VD: 1 phần Backend sinh machine code cho x86), đọc ở mức tổng quan, ghi chú vào Reading Log.

Nhóm cuối: Review (Ngày 958–959)

Ngày 958: Review Tổng hợp 3 Track

• Mục tiêu: Tổng hợp toàn bộ 13 thư viện đã đọc trong 56 ngày.

• Lý thuyết: Nhìn lại Reading Log đã ghi chú xuyên suốt, tìm ra các pattern/ý tưởng lặp lại nhiều lần across nhiều thư viện khác nhau (VD: Reactor Pattern xuất hiện ở cả Netty, Boost.Asio, mini event loop tự viết).

• Thực hành: Viết bài tổng hợp: liệt kê 5 pattern/ý tưởng xuất hiện lặp lại nhiều nhất qua 13 thư viện đã đọc, giải thích vì sao chúng phổ biến tới vậy.

Ngày 959: Retrospective Giai đoạn 15

• Mục tiêu: Tổng kết toàn bộ Giai đoạn Source Code Reading.

• Lý thuyết: Nhấn mạnh đây là kỹ năng cần duy trì liên tục (ongoing) chứ không dừng lại ở ngày 959 - đọc source thư viện mới sẽ luôn là 1 phần công việc của Framework/Platform Engineer.

• Thực hành: Viết báo cáo retrospective, lên kế hoạch duy trì thói quen đọc source định kỳ (VD: 1 thư viện mới mỗi tháng) sau khi hoàn thành toàn bộ roadmap.

---

Giai đoạn 16 - System Design Practice (Ngày 960–1001)

Giai đoạn mới bổ sung. Sau 15 giai đoạn học kiến thức nền tảng, đây là lúc luyện phản xạ áp dụng toàn bộ vào các bài toán thiết kế hệ thống kinh điển - kỹ năng cốt lõi của Technical Architect.

Nhóm 1: Framework Thiết kế Hệ thống (Ngày 960–963)

Ngày 960: Giới thiệu System Design Practice

• Mục tiêu: Hiểu vì sao cần luyện tập riêng dù đã học đủ kiến thức nền tảng.

• Lý thuyết: Biết từng viên gạch (Database, Caching, Messaging, Consensus...) khác với biết cách ghép chúng lại đúng thứ tự dưới áp lực thời gian và yêu cầu mơ hồ - đây là kỹ năng tổng hợp cần luyện riêng.

• Thực hành: Liệt kê 5 "viên gạch" đã tự xây trong roadmap (Mini KV Store, Distributed Job System, 3-service project...) sẽ dùng lại làm block trong các case study sắp tới.

Ngày 961: Framework - Clarify Requirements & Estimate Scale

• Mục tiêu: Học 2 bước đầu tiên, thường bị bỏ qua bởi người mới.

• Lý thuyết: Clarify Requirements (xác định functional/non-functional requirement, phạm vi bài toán - tránh thiết kế lan man); Back-of-envelope Estimation (ước tính QPS, storage, bandwidth từ số liệu giả định - quyết định trực tiếp lựa chọn kiến trúc).

• Thực hành: Với đề bài "thiết kế Twitter", viết ra 5 câu hỏi clarify quan trọng nhất và làm 1 estimation cơ bản (số user, số tweet/ngày, storage cần thiết).

Ngày 962: Framework - High-level Design

• Mục tiêu: Học cách vẽ kiến trúc tổng thể trước khi đi vào chi tiết.

• Lý thuyết: High-level Design xác định các thành phần chính (API layer, service, database, cache, message queue) và luồng dữ liệu chính - chưa cần chọn công nghệ cụ thể, ưu tiên đúng vai trò từng thành phần.

• Thực hành: Vẽ High-level Design cho 1 bài toán đơn giản (VD: "thiết kế Pastebin") chỉ với các khối chữ nhật và mũi tên, không đi sâu chi tiết.

Ngày 963: Framework - Deep Dive & Trade-off Discussion

• Mục tiêu: Học bước cuối cùng, nơi thể hiện chiều sâu kiến thức.

• Lý thuyết: Deep Dive chọn 1-2 thành phần quan trọng nhất để đào sâu (dựa trên yêu cầu non-functional đã clarify) - luôn đi kèm Trade-off discussion (không có giải pháp hoàn hảo, chỉ có lựa chọn phù hợp với ngữ cảnh).

• Thực hành: Với High-level Design Ngày 962, chọn 1 thành phần để deep dive (VD: database choice), viết ra 2 lựa chọn khả thi và trade-off giữa chúng.

Nhóm 2: Case Study - URL Shortener (Ngày 964–967)

Ngày 964: URL Shortener - Requirements & Estimation

• Mục tiêu: Áp dụng bước 1-2 của framework.

• Lý thuyết: Functional: tạo short URL, redirect khi truy cập. Non-functional: latency thấp cho redirect, tỷ lệ đọc/ghi rất lệch (đọc nhiều hơn ghi rất nhiều).

• Thực hành: Ước tính QPS cho cả write (tạo URL) và read (redirect) với giả định 100 triệu URL mới/tháng, tỷ lệ đọc/ghi 100:1.

Ngày 965: URL Shortener - High-level Design

• Mục tiêu: Vẽ kiến trúc tổng thể.

• Lý thuyết: API tạo short URL → encoding scheme (base62 cho ID ngắn gọn, dễ đọc) → lưu mapping vào database → API redirect tra cứu mapping.

• Thực hành: Vẽ High-level Design, thiết kế encoding scheme base62 cho ID.

Ngày 966: URL Shortener - Deep Dive

• Mục tiêu: Đào sâu 2 vấn đề cốt lõi.

• Lý thuyết: Database choice (đọc nhiều → cân nhắc Read Replica, liên hệ Replication Giai đoạn 11); ID Generation ở quy mô phân tán (liên hệ Consensus/Distributed ID generator đã bàn ở Giai đoạn 12 - tránh 2 node sinh trùng ID).

• Thực hành: Thiết kế cơ chế sinh ID phân tán không trùng lặp (VD: chia range ID cho mỗi node, hoặc dùng Snowflake-like ID).

Ngày 967: URL Shortener - Trade-off & Review

• Mục tiêu: Chốt lại case study đầu tiên.

• Lý thuyết: Ôn lại toàn bộ: Caching layer (liên hệ Buffer Pool, Giai đoạn 11) cho redirect nóng, trade-off giữa random ID (khó đoán, cần check trùng) và sequential ID (dễ đoán, cần cơ chế phân tán).

• Thực hành: Viết bản thiết kế hoàn chỉnh (1 trang) tổng hợp toàn bộ 4 bước cho URL Shortener.

Nhóm 3: Case Study - Rate Limiter (Ngày 968–971)

Ngày 968: Rate Limiter - Thuật toán

• Mục tiêu: Học các thuật toán rate limiting phổ biến.

• Lý thuyết: Token Bucket (nạp token theo tốc độ cố định, request tiêu token - liên hệ Flow Control TCP đã học Giai đoạn 6), Sliding Window (đếm request trong cửa sổ thời gian trượt, chính xác hơn Fixed Window).

• Thực hành: Lập bảng so sánh Token Bucket vs Sliding Window Counter theo tiêu chí: độ chính xác, chi phí tính toán, khả năng chịu burst traffic.

Ngày 969: Rate Limiter - High-level Design

• Mục tiêu: Xác định vị trí đặt rate limiter trong hệ thống.

• Lý thuyết: Client-side (không đáng tin cậy), Server-side per-service (đơn giản nhưng không nhất quán giữa nhiều instance), API Gateway/Envoy (tập trung, liên hệ trực tiếp Envoy Giai đoạn 10).

• Thực hành: Vẽ High-level Design đặt Rate Limiter tại API Gateway (Envoy) phía trước 3-service project.

Ngày 970: Rate Limiter - Deep Dive Phân tán

• Mục tiêu: Giải quyết bài toán khi có nhiều instance Gateway/service.

• Lý thuyết: Cần 1 store trung tâm (VD: Redis) lưu trạng thái rate limit dùng chung - liên hệ Consistent Hashing (Giai đoạn 12) nếu cần shard trạng thái ra nhiều Redis instance.

• Thực hành: Thiết kế schema Redis lưu token bucket cho từng user/API key, tính toán độ trễ thêm vào do phải gọi Redis mỗi request.

Ngày 971: Rate Limiter - Review

• Mục tiêu: Chốt lại case study.

• Lý thuyết: Ôn lại trade-off: rate limit chính xác tuyệt đối (cần đồng bộ chặt, chậm hơn) vs rate limit xấp xỉ (nhanh hơn, chấp nhận sai số nhỏ, liên hệ Eventual Consistency Giai đoạn 12).

• Thực hành: Viết bản thiết kế hoàn chỉnh cho Rate Limiter.

Nhóm 4: Case Study - News Feed (Ngày 972–977)

Ngày 972: News Feed - Requirements & Estimation

• Mục tiêu: Áp dụng framework cho bài toán phức tạp hơn.

• Lý thuyết: Functional: đăng bài, xem feed cá nhân hoá theo người đang follow. Non-functional: feed phải load nhanh, chấp nhận độ trễ nhỏ khi bài mới chưa xuất hiện ngay (Eventual Consistency).

• Thực hành: Ước tính scale: số user, số bài đăng/ngày, tỷ lệ đọc feed/viết bài.

Ngày 973: News Feed - Fanout on Write vs Fanout on Read

• Mục tiêu: Học 2 chiến lược kinh điển, liên hệ trực tiếp CQRS (Giai đoạn 8).

• Lý thuyết: Fanout on Write (khi đăng bài, đẩy ngay vào feed của mọi follower - đọc nhanh, ghi tốn kém) vs Fanout on Read (feed tính toán lúc đọc, join dữ liệu từ người đang follow - ghi nhanh, đọc tốn kém) - chính là ứng dụng thực tế Write Model vs Read Model của CQRS.

• Thực hành: Vẽ sơ đồ cả 2 chiến lược, xác định chiến lược nào phù hợp hơn cho hệ thống có tỷ lệ đọc feed rất cao.

Ngày 974: News Feed - Ranking & Feed Generation Service

• Mục tiêu: Đào sâu thành phần tạo nên trải nghiệm chính.

• Lý thuyết: Feed không chỉ hiển thị theo thời gian mà thường được rank theo nhiều tín hiệu (độ tương tác, độ mới, mối quan hệ) - Feed Generation Service tách biệt khỏi phần lưu trữ bài đăng gốc.

• Thực hành: Thiết kế kiến trúc Feed Generation Service như 1 read model riêng (liên hệ CQRS), được cập nhật qua domain event khi có bài đăng mới/tương tác mới.

Ngày 975: News Feed - Caching Strategy

• Mục tiêu: Áp dụng Caching (liên hệ Buffer Pool Giai đoạn 11, Rate Limiter Ngày 970) cho bài toán đọc-nhiều.

• Lý thuyết: Cache feed đã tính toán sẵn cho user active, invalidate/refresh khi có bài mới liên quan - cân bằng giữa độ tươi của dữ liệu và tải lên hệ thống backend.

• Thực hành: Thiết kế cache layer cho feed, xác định TTL hợp lý và chiến lược invalidate khi có tương tác mới.

Ngày 976: News Feed - Celebrity Problem

• Mục tiêu: Giải quyết edge case kinh điển của Fanout on Write.

• Lý thuyết: Với user có hàng triệu follower (celebrity), Fanout on Write thuần tuý gây ra lượng ghi khổng lồ mỗi lần họ đăng bài - giải pháp lai (hybrid): celebrity dùng Fanout on Read, user thường dùng Fanout on Write.

• Thực hành: Thiết kế giải pháp hybrid, xác định ngưỡng follower để chuyển chiến lược.

Ngày 977: News Feed - Review & Trade-off

• Mục tiêu: Chốt lại case study phức tạp nhất tới thời điểm này.

• Lý thuyết: Tổng hợp: Fanout strategy → Ranking → Caching → Celebrity Problem.

• Thực hành: Viết bản thiết kế hoàn chỉnh cho News Feed System, nhấn mạnh các trade-off đã đưa ra.

Nhóm 5: Case Study - Chat System (Ngày 978–983)

Ngày 978: Chat System - Requirements & Estimation

• Mục tiêu: Áp dụng framework cho hệ thống real-time.

• Lý thuyết: Functional: gửi/nhận tin nhắn 1-1 và group, hiển thị trạng thái online. Non-functional: độ trễ cực thấp, đảm bảo message không mất.

• Thực hành: Ước tính scale: số concurrent connection, số message/giây.

Ngày 979: Chat System - WebSocket vs Long Polling

• Mục tiêu: Liên hệ trực tiếp HTTP Evolution đã học Giai đoạn 6.

• Lý thuyết: Long Polling (client liên tục hỏi server, tốn resource) vs WebSocket (kết nối 2 chiều bền vững, hiệu quả hơn nhiều cho real-time) - liên hệ lại HTTP/2 Server Push và HTTP/3 đã học.

• Thực hành: Lập bảng so sánh WebSocket vs Long Polling theo tiêu chí: độ trễ, chi phí resource server, độ phức tạp implementation.

Ngày 980: Chat System - Connection Management

• Mục tiêu: Liên hệ trực tiếp epoll/Event Loop (Giai đoạn 6/15).

• Lý thuyết: Mỗi WebSocket connection cần duy trì lâu dài - chính là bài toán C10K/C10M đã học ở Giai đoạn 6, cần kiến trúc event-driven (Netty/epoll) để 1 server xử lý được hàng trăm nghìn connection đồng thời.

• Thực hành: Thiết kế kiến trúc Connection Server dùng Netty (đã học Giai đoạn 15) để quản lý connection, xác định cách route message giữa các Connection Server khác nhau (user A và B có thể kết nối tới 2 server khác nhau).

Ngày 981: Chat System - Message Delivery Guarantee

• Mục tiêu: Liên hệ trực tiếp Kafka/RabbitMQ (Giai đoạn 12).

• Lý thuyết: Đảm bảo message không mất khi người nhận offline - cần lưu trữ tạm (message queue hoặc database) và đảm bảo delivery khi user online lại, liên hệ tương tự Message Queue với Consumer Acknowledgment.

• Thực hành: Thiết kế luồng: message gửi tới Connection Server → nếu recipient online, forward ngay; nếu offline, lưu vào queue/database → deliver khi recipient reconnect.

Ngày 982: Chat System - Group Chat & Online Status

• Mục tiêu: Mở rộng thêm tính năng phức tạp hơn.

• Lý thuyết: Group chat cần fanout tin nhắn tới nhiều recipient (liên hệ Fanout đã học ở News Feed); Online status cần cập nhật liên tục nhưng có thể chấp nhận Eventual Consistency (không cần chính xác tuyệt đối theo mili giây).

• Thực hành: Thiết kế cơ chế fanout cho group chat nhỏ (dưới 100 người) khác với group lớn (liên hệ Celebrity Problem đã học).

Ngày 983: Chat System - Review & Trade-off

• Mục tiêu: Chốt lại case study.

• Lý thuyết: Tổng hợp: WebSocket → Connection Management → Delivery Guarantee → Group Chat.

• Thực hành: Viết bản thiết kế hoàn chỉnh cho Chat System.

Nhóm 6: Case Study - Distributed Cache (Ngày 984–987)

Ngày 984: Distributed Cache - Requirements & Estimation

• Mục tiêu: Thiết kế chính hạ tầng cache đã dùng ngầm ở nhiều case study trước.

• Lý thuyết: Functional: get/set/delete key-value với TTL. Non-functional: latency cực thấp (dưới 1ms), throughput cao.

• Thực hành: Ước tính scale: QPS, kích thước dữ liệu trung bình, tỷ lệ cache hit mong muốn.

Ngày 985: Distributed Cache - Eviction Policy

• Mục tiêu: Liên hệ trực tiếp Buffer Pool Replacement Policy (Giai đoạn 11).

• Lý thuyết: Ôn lại LRU/Clock algorithm đã học - áp dụng y hệt cho cache layer ở quy mô lớn hơn.

• Thực hành: Chọn eviction policy phù hợp và giải thích lựa chọn dựa trên access pattern giả định.

Ngày 986: Distributed Cache - Consistent Hashing & Invalidation

• Mục tiêu: Liên hệ trực tiếp Consistent Hashing (Giai đoạn 12).

• Lý thuyết: Phân phối key ra nhiều cache node bằng Consistent Hashing (đã học Ngày 650) để thêm/bớt node không làm mất gần hết cache; Cache invalidation khi dữ liệu gốc thay đổi (write-through, write-behind, hoặc TTL-based).

• Thực hành: Thiết kế cluster cache với Consistent Hashing, chọn chiến lược invalidation phù hợp cho dữ liệu Order (liên hệ 3-service project).

Ngày 987: Distributed Cache - Review

• Mục tiêu: Chốt lại case study.

• Lý thuyết: Ôn lại toàn bộ, liên hệ lại Redis đã dùng ở nhiều case study trước (Rate Limiter, Chat System) - giờ hiểu rõ hơn cách nó được thiết kế bên trong.

• Thực hành: Viết bản thiết kế hoàn chỉnh cho Distributed Cache.

Nhóm 7: Case Study - Search Autocomplete (Ngày 988–991)

Ngày 988: Search Autocomplete - Requirements & Estimation

• Mục tiêu: Áp dụng framework cho bài toán có yêu cầu latency cực khắt khe.

• Lý thuyết: Functional: gợi ý top-K kết quả khi user gõ từng ký tự. Non-functional: latency phải dưới 100ms để cảm giác "tức thời".

• Thực hành: Ước tính QPS (rất cao vì mỗi ký tự gõ là 1 request).

Ngày 989: Search Autocomplete - Trie

• Mục tiêu: Liên hệ trực tiếp BST/B+Tree (Giai đoạn 0/11).

• Lý thuyết: Trie (prefix tree) tối ưu cho tra cứu theo tiền tố - mỗi node đại diện 1 ký tự, đường đi từ root biểu diễn 1 chuỗi - khác B+Tree (tối ưu range query theo giá trị) ở chỗ Trie tối ưu theo cấu trúc chuỗi.

• Thực hành: Vẽ Trie đơn giản cho vài từ khoá, giải thích cách tra cứu top-K gợi ý từ 1 node trong Trie.

Ngày 990: Search Autocomplete - Ranking & Data Pipeline

• Mục tiêu: Hoàn thiện thiết kế thực tế.

• Lý thuyết: Trie cần được xây định kỳ từ dữ liệu truy vấn thực tế (offline data pipeline, liên hệ Airflow Giai đoạn 15) - không xây real-time vì tốn kém, chấp nhận độ trễ cập nhật gợi ý (Eventual Consistency).

• Thực hành: Thiết kế pipeline: log truy vấn → aggregate định kỳ (VD: mỗi giờ) → build Trie mới → swap Trie đang phục vụ (tương tự Blue-Green Deployment, Giai đoạn 13).

Ngày 991: Search Autocomplete - Review

• Mục tiêu: Chốt lại case study.

• Lý thuyết: Tổng hợp: Trie → Ranking → Offline Pipeline.

• Thực hành: Viết bản thiết kế hoàn chỉnh cho Search Autocomplete.

Nhóm 8: Case Study - Video Streaming/File Storage (Ngày 992–997)

Ngày 992: Video Streaming - Requirements & Estimation

• Mục tiêu: Áp dụng framework cho hệ thống có dữ liệu lớn nhất từ trước tới giờ.

• Lý thuyết: Functional: upload video, xem video (nhiều chất lượng). Non-functional: storage khổng lồ, cần phục vụ traffic đọc rất lớn với latency thấp toàn cầu.

• Thực hành: Ước tính storage cần thiết (số video, kích thước trung bình, số bản chất lượng khác nhau cho mỗi video).

Ngày 993: Video Streaming - Upload Flow & Transcoding

• Mục tiêu: Thiết kế luồng xử lý video sau khi upload.

• Lý thuyết: Video gốc cần transcode ra nhiều độ phân giải/bitrate (cho adaptive streaming) - quá trình này tốn tài nguyên, nên xử lý bất đồng bộ (liên hệ trực tiếp Distributed Job System, Giai đoạn 12).

• Thực hành: Thiết kế luồng: upload → lưu tạm → publish job transcode → Worker xử lý (dùng lại kiến trúc Distributed Job System) → lưu các bản đã transcode.

Ngày 994: Video Streaming - CDN

• Mục tiêu: Liên hệ trực tiếp Envoy/API Gateway (Giai đoạn 10/12).

• Lý thuyết: CDN (Content Delivery Network) cache video ở nhiều điểm gần người dùng toàn cầu - giảm độ trễ và tải cho origin server, nguyên lý tương tự Caching (Ngày 984-987) nhưng phân tán theo địa lý.

• Thực hành: Vẽ sơ đồ luồng: user request video → CDN edge node gần nhất → nếu cache miss, lấy từ origin storage → cache lại cho request sau.

Ngày 995: Video Streaming - Storage Strategy

• Mục tiêu: Thiết kế lưu trữ cho dữ liệu lớn (blob), khác hẳn database quan hệ đã học Giai đoạn 11.

• Lý thuyết: Video được chia nhỏ thành chunk, lưu trên Object Storage (VD: S3-like) thay vì database truyền thống - Object Storage tối ưu cho việc lưu blob lớn, không cần transaction phức tạp.

• Thực hành: Thiết kế schema chunking cho 1 video (chia theo segment thời gian để hỗ trợ streaming từ giữa video).

Ngày 996: Video Streaming - Metadata Database vs Blob Storage

• Mục tiêu: Hiểu sự tách biệt giữa 2 loại lưu trữ cần dùng cùng lúc.

• Lý thuyết: Metadata (tiêu đề, mô tả, owner, danh sách chunk) lưu ở database quan hệ/NoSQL (cần query linh hoạt); Blob thật (video data) lưu ở Object Storage (tối ưu cho việc đọc tuần tự khối lớn) - liên hệ lại Repository pattern (Giai đoạn 7) trừu tượng hoá cả 2 nguồn.

• Thực hành: Thiết kế schema Metadata Database và giải thích tại sao không lưu video data trực tiếp trong đó.

Ngày 997: Video Streaming - Review & Trade-off

• Mục tiêu: Chốt lại case study cuối cùng, phức tạp nhất.

• Lý thuyết: Tổng hợp: Upload/Transcode → CDN → Chunking → Metadata/Blob separation.

• Thực hành: Viết bản thiết kế hoàn chỉnh cho Video Streaming System.

Nhóm 9: Mock Interview & Review (Ngày 998–1001)

Ngày 998: Mock Interview 1

• Mục tiêu: Luyện áp dụng framework dưới áp lực thời gian thực tế (mô phỏng phỏng vấn 45 phút).

• Lý thuyết: Ôn lại toàn bộ 4 bước framework (Ngày 960-963), tự đặt đồng hồ đếm ngược.

• Thực hành: Chọn 1 đề bài mới chưa làm (VD: "thiết kế hệ thống đặt vé xem phim" hoặc "thiết kế Uber"), tự làm hoàn chỉnh trong 45 phút không xem lại tài liệu.

Ngày 999: Mock Interview 2

• Mục tiêu: Lặp lại với đề bài khác để củng cố phản xạ.

• Lý thuyết: Ôn lại phản hồi/điểm yếu nhận ra từ Mock Interview 1.

• Thực hành: Chọn 1 đề bài mới khác (VD: "thiết kế hệ thống thông báo (notification system)" hoặc "thiết kế Google Docs collaborative editing"), làm hoàn chỉnh trong 45 phút.

Ngày 1000: Review Tổng hợp Giai đoạn 16

• Mục tiêu: Tổng hợp toàn bộ 7 case study + 2 mock interview.

• Lý thuyết: Nhìn lại: mọi case study đều tái sử dụng cùng 1 bộ "viên gạch" đã học xuyên suốt roadmap (Caching, Message Queue, Consistent Hashing, CQRS, Distributed Job System...) - đây chính là bằng chứng cho thấy kiến trúc sư giỏi không cần nhớ hàng trăm giải pháp riêng lẻ, chỉ cần thành thạo 1 bộ nguyên lý cốt lõi và biết kết hợp linh hoạt.

• Thực hành: Viết bảng tổng hợp: liệt kê 10 "viên gạch" xuất hiện nhiều nhất qua 7 case study, đánh dấu case study nào dùng chúng.

Ngày 1001: Retrospective Giai đoạn 16

• Mục tiêu: Tổng kết toàn bộ Giai đoạn System Design Practice.

• Lý thuyết: Đây là giai đoạn "tổng duyệt" trước khi bước vào Capstone cuối cùng (Framework Engineering) - mọi kỹ năng thiết kế hệ thống đã sẵn sàng để áp dụng vào việc tự xây 1 platform hoàn chỉnh.

• Thực hành: Viết báo cáo retrospective, tự đánh giá mức độ tự tin khi đối mặt với 1 đề bài System Design hoàn toàn mới, so với trước khi bắt đầu Giai đoạn 16.

---

Giai đoạn 17 - Framework Engineering (Ngày 1002–1099)

Capstone cuối cùng. Xây một platform thực sự, tổng hợp toàn bộ 16 giai đoạn trước - từ Cache CPU (Ngày 2) tới System Design Practice (Ngày 1001) - thành 1 hệ thống hoàn chỉnh.

Nhóm 1: Giới thiệu (Ngày 1002–1003)

Ngày 1002: Giới thiệu Capstone - Framework Engineering

• Mục tiêu: Hiểu đây không phải 1 project mới, mà là sự hội tụ của mọi thứ đã xây trước đó.

• Lý thuyết: 8 thành phần sắp xây (DI Container, ORM, Event Bus, Workflow Engine, Plugin System, REST API Framework, Configuration System, Scheduler) đều đã có "bản nháp" từ các giai đoạn trước - Mini Spring (Giai đoạn 10), Mini ORM (Giai đoạn 10), Mini Web Framework (Giai đoạn 3), Plugin System (Giai đoạn 1), Concurrent Task Scheduler (Giai đoạn 5) và Distributed Job System (Giai đoạn 12).

• Thực hành: Lập bảng liệt kê 8 thành phần sẽ xây, ghi chú "bản nháp" tương ứng đã xây ở giai đoạn nào và ngày nào - đây sẽ là tài liệu tham chiếu xuyên suốt capstone.

Ngày 1003: Thiết kế Kiến trúc Tổng thể Platform Framework

• Mục tiêu: Vẽ bức tranh cuối cùng trước khi bắt tay xây từng module.

• Lý thuyết: Ôn lại Framework Thiết kế Hệ thống (Giai đoạn 16) - áp dụng chính framework đó cho bài toán "thiết kế 1 platform framework": Clarify (framework này phục vụ ai, giải quyết vấn đề gì), Estimate (quy mô ứng dụng dự kiến chạy trên nó), High-level Design (8 module quan hệ với nhau ra sao), Deep Dive (module nào là lõi, cần thiết kế cẩn thận nhất).

• Thực hành: Vẽ sơ đồ kiến trúc tổng thể: DI Container ở trung tâm (mọi module khác đều là bean được quản lý bởi nó - đúng triết lý Spring đã học), các module còn lại kết nối qua nó.

Nhóm 2: DI Container (Ngày 1004–1013)

Ngày 1004: Ôn lại Mini Spring DI - Xác định Gap

• Mục tiêu: Đánh giá khoảng cách giữa bản nháp và yêu cầu production.

• Lý thuyết: Ôn lại MiniBeanFactory (Giai đoạn 10) - còn thiếu: xử lý edge case đầy đủ, performance (reflection cache), hỗ trợ đa dạng cấu hình.

• Thực hành: Viết danh sách gap cụ thể cần lấp đầy trong 10 ngày tới.

Ngày 1005: Thiết kế API cho DI Container

• Mục tiêu: Xác định public API trước khi implement.

• Lý thuyết: Ôn lại nguyên tắc thiết kế API tốt - ổn định, tối giản, dễ đoán (liên hệ REST Maturity Model, Giai đoạn 9, áp dụng cho API nội bộ).

• Thực hành: Viết interface Container với các method chính: register(), resolve(), registerSingleton().

Ngày 1006: Implement Bean Definition + Registry

• Mục tiêu: Xây nền tảng lưu trữ metadata.

• Lý thuyết: Ôn lại BeanDefinition (Giai đoạn 10, Ngày 461).

• Thực hành: Implement BeanDefinitionRegistry production-grade, hỗ trợ đăng ký qua annotation lẫn code cấu hình tường minh.

Ngày 1007: Implement Constructor/Setter Injection

• Mục tiêu: Hoàn thiện cơ chế inject đầy đủ.

• Lý thuyết: Ôn lại Autowiring (Giai đoạn 10, Ngày 474) - giờ cần cache reflection metadata (tránh quét lại class mỗi lần resolve, ảnh hưởng performance).

• Thực hành: Implement injection với reflection cache, benchmark trước/sau cache.

Ngày 1008: Implement Scope

• Mục tiêu: Hỗ trợ đầy đủ vòng đời bean khác nhau.

• Lý thuyết: Ôn lại Bean Scope (Giai đoạn 10, Ngày 462) - thêm scope tuỳ chỉnh (custom scope) cho use case đặc thù.

• Thực hành: Implement Singleton/Prototype đầy đủ, thiết kế extension point cho custom scope.

Ngày 1009: Implement Lifecycle Hooks + BeanPostProcessor

• Mục tiêu: Hoàn thiện extension point mạnh nhất.

• Lý thuyết: Ôn lại BeanPostProcessor (Giai đoạn 10, Ngày 464) - đây chính là điểm cho phép AOP (đã tự viết Mini AOP Proxy) cắm vào sau này.

• Thực hành: Implement đầy đủ lifecycle + BeanPostProcessor chain.

Ngày 1010: Implement Circular Dependency Detection

• Mục tiêu: Xử lý đúng edge case quan trọng.

• Lý thuyết: Ôn lại Circular Dependency (Giai đoạn 10, Ngày 471) - implement cơ chế phát hiện và báo lỗi rõ ràng (khác Spring chấp nhận qua setter injection, ở đây chọn báo lỗi tường minh để đơn giản hoá).

• Thực hành: Implement detection dùng "đang resolve" set, ném exception có thông tin đầy đủ chuỗi dependency gây vòng lặp.

Ngày 1011: Implement Component Scanning

• Mục tiêu: Tự động hoá việc đăng ký bean.

• Lý thuyết: Ôn lại Component Scanning (Giai đoạn 10, Ngày 473).

• Thực hành: Implement classpath scanning tự động tìm class có annotation, đăng ký vào registry.

Ngày 1012: Test DI Container Toàn diện

• Mục tiêu: Đảm bảo độ tin cậy trước khi các module khác phụ thuộc vào nó.

• Lý thuyết: Ôn lại Testing Strategy (Giai đoạn 4).

• Thực hành: Viết bộ test đầy đủ: injection các loại, scope, lifecycle, circular dependency, component scanning.

Ngày 1013: Review DI Container

• Mục tiêu: Chốt lại module đầu tiên và quan trọng nhất.

• Lý thuyết: Ôn lại toàn bộ tuần - DI Container giờ là nền tảng mọi module tiếp theo sẽ đăng ký vào.

• Thực hành: Viết tài liệu API cho DI Container (sẽ dùng làm phần đầu của Documentation cuối capstone).

Nhóm 3: ORM (Ngày 1014–1023)

Ngày 1014: Ôn lại Mini ORM - Xác định Gap

• Mục tiêu: Đánh giá khoảng cách với yêu cầu production.

• Lý thuyết: Ôn lại MiniSession/IdentityMap (Giai đoạn 10) - còn thiếu: relationship mapping, lazy loading, migration.

• Thực hành: Viết danh sách gap cần lấp đầy.

Ngày 1015: Thiết kế Session/Unit of Work Production-grade

• Mục tiêu: Nâng cấp thiết kế nền tảng.

• Lý thuyết: Ôn lại Unit of Work (Giai đoạn 10, Ngày 523).

• Thực hành: Thiết kế lại Session API hỗ trợ transaction boundary rõ ràng (liên hệ @Transactional, Giai đoạn 10).

Ngày 1016: Implement Identity Map + Dirty Tracking

• Mục tiêu: Hoàn thiện theo dõi thay đổi.

• Lý thuyết: Ôn lại Identity Map (Ngày 542) - thêm dirty tracking hiệu quả (dùng Descriptor Protocol nếu chọn Python, hoặc Proxy nếu chọn Java - liên hệ Giai đoạn 14).

• Thực hành: Implement dirty tracking tự động khi field của entity bị sửa.

Ngày 1017: Implement Relationship Mapping

• Mục tiêu: Hỗ trợ quan hệ giữa entity, gap lớn nhất so với Mini ORM cũ.

• Lý thuyết: Ôn lại relationship() của SQLAlchemy (Giai đoạn 10, Ngày 525).

• Thực hành: Implement one-to-many relationship, tự động load object liên quan khi truy cập.

Ngày 1018: Implement Lazy Loading qua Proxy

• Mục tiêu: Liên hệ trực tiếp Bytecode Manipulation/Proxy (Giai đoạn 10/14/15 - Hibernate).

• Lý thuyết: Ôn lại cơ chế lazy loading proxy đã đọc ở Hibernate (Giai đoạn 15, Ngày 910).

• Thực hành: Implement lazy loading dùng Dynamic Proxy (nếu Java) hoặc __getattr__ override (nếu Python), chỉ query database khi field thực sự được truy cập.

Ngày 1019: Implement Query Builder Nâng cao

• Mục tiêu: Cho phép truy vấn linh hoạt hơn Mini ORM cũ.

• Lý thuyết: Ôn lại QueryBuilder (Giai đoạn 10, Ngày 543) - mở rộng thêm filter phức tạp, join, order by.

• Thực hành: Implement QueryBuilder hỗ trợ .filter()/.join()/.orderBy()/.limit() kết hợp linh hoạt.

Ngày 1020: Implement Migration System

• Mục tiêu: Học và tự viết phiên bản đơn giản của Alembic (Giai đoạn 10, Ngày 528).

• Lý thuyết: Ôn lại cách Alembic diff schema và sinh migration script.

• Thực hành: Implement cơ chế migration cơ bản: so sánh schema hiện tại với model definition, sinh ra migration script cần chạy.

Ngày 1021: Tích hợp Transaction

• Mục tiêu: Đảm bảo ORM hoạt động đúng trong ngữ cảnh transaction.

• Lý thuyết: Ôn lại Transaction (Giai đoạn 11) - Session commit phải đảm bảo Atomicity.

• Thực hành: Đảm bảo Session.commit() chạy trong 1 database transaction thật, rollback đúng cách khi có lỗi giữa chừng.

Ngày 1022: Test ORM Toàn diện

• Mục tiêu: Đảm bảo độ tin cậy.

• Lý thuyết: Ôn lại Testcontainers (Giai đoạn 4) cho test có phụ thuộc database thật.

• Thực hành: Viết test đầy đủ: CRUD, relationship, lazy loading, dirty tracking, migration, transaction rollback.

Ngày 1023: Review ORM

• Mục tiêu: Chốt lại module thứ 2.

• Lý thuyết: Ôn lại toàn bộ tuần.

• Thực hành: Viết tài liệu API cho ORM module.

Nhóm 4: Event Bus (Ngày 1024–1031)

Ngày 1024: Thiết kế Event Bus

• Mục tiêu: Liên hệ trực tiếp Observer (Giai đoạn 3) và Domain Event (Giai đoạn 7).

• Lý thuyết: Event Bus là Observer pattern hình thức hoá thành 1 module riêng - publisher không biết ai đang lắng nghe, subscriber đăng ký theo loại event quan tâm.

• Thực hành: Thiết kế API: publish(event), subscribe(eventType, handler).

Ngày 1025: Implement In-process Event Bus

• Mục tiêu: Xây phiên bản đơn giản nhất trước.

• Lý thuyết: Ôn lại Observer implementation (Giai đoạn 3, Ngày 163).

• Thực hành: Implement EventBus xử lý trong cùng process, đồng bộ.

Ngày 1026: Implement Async Event Handler

• Mục tiêu: Liên hệ trực tiếp Concurrency (Giai đoạn 5).

• Lý thuyết: Ôn lại Thread Pool/ExecutorService - handler không nên chặn publisher, cần chạy bất đồng bộ.

• Thực hành: Implement chế độ async cho EventBus, dùng Thread Pool xử lý handler song song.

Ngày 1027: Tích hợp Message Broker

• Mục tiêu: Mở rộng Event Bus ra ngoài phạm vi 1 process, liên hệ trực tiếp Kafka/RabbitMQ (Giai đoạn 12).

• Lý thuyết: Ôn lại Outbox Pattern (Giai đoạn 8) - Event Bus cần hỗ trợ publish ra message broker thật để giao tiếp giữa nhiều service.

• Thực hành: Implement DistributedEventBus publish event ra Kafka/RabbitMQ, subscriber ở service khác nhận được.

Ngày 1028: Implement Retry + Dead Letter

• Mục tiêu: Liên hệ trực tiếp Resilience Patterns (Giai đoạn 12).

• Lý thuyết: Ôn lại Retry/Dead Letter Queue (Giai đoạn 12, Ngày 689/662).

• Thực hành: Implement retry với backoff cho handler thất bại, chuyển vào dead letter sau N lần retry.

Ngày 1029: Hỗ trợ Event Sourcing (Optional)

• Mục tiêu: Liên hệ trực tiếp Event Sourcing (Giai đoạn 8).

• Lý thuyết: Ôn lại Event Store - Event Bus có thể tích hợp thêm khả năng lưu trữ toàn bộ event đã publish (làm nguồn cho Event Sourcing nếu ứng dụng cần).

• Thực hành: Thiết kế interface EventStore optional, plug vào EventBus để lưu lại mọi event đã publish.

Ngày 1030: Test Event Bus

• Mục tiêu: Đảm bảo độ tin cậy.

• Lý thuyết: Ôn lại kỹ thuật test concurrency (Giai đoạn 5) và test message broker (Testcontainers, Giai đoạn 4).

• Thực hành: Viết test cho cả in-process và distributed mode, test retry/dead letter.

Ngày 1031: Review Event Bus

• Mục tiêu: Chốt lại module thứ 3.

• Lý thuyết: Ôn lại toàn bộ tuần.

• Thực hành: Viết tài liệu API cho Event Bus.

Nhóm 5: Workflow Engine (Ngày 1032–1043)

Ngày 1032: Thiết kế Workflow Engine

• Mục tiêu: Liên hệ trực tiếp Airflow đã đọc source ở Giai đoạn 15.

• Lý thuyết: Ôn lại DAG (Directed Acyclic Graph) - workflow là chuỗi Task có dependency, tương tự Saga (Giai đoạn 8) nhưng tổng quát hơn (không giới hạn ở transaction xuyên service).

• Thực hành: Thiết kế API định nghĩa workflow (fluent API hoặc declarative YAML).

Ngày 1033: Implement Task & Dependency Graph

• Mục tiêu: Xây cấu trúc dữ liệu lõi.

• Lý thuyết: Ôn lại Graph traversal - cần detect cycle (workflow phải là DAG thật, không được có vòng lặp).

• Thực hành: Implement Task/Workflow với dependency graph, thuật toán topological sort xác định thứ tự thực thi.

Ngày 1034: Implement Workflow Definition API

• Mục tiêu: Cho phép người dùng framework định nghĩa workflow dễ dàng.

• Lý thuyết: Ôn lại Fluent API (Builder pattern, Giai đoạn 3).

• Thực hành: Implement API cho phép viết workflow.addTask("extract").then("transform").then("load").

Ngày 1035: Implement Scheduler cho Workflow

• Mục tiêu: Liên hệ trực tiếp Distributed Job System (Giai đoạn 12).

• Lý thuyết: Ôn lại Scheduler đã tự xây - quyết định Task nào sẵn sàng chạy (dependency đã hoàn thành).

• Thực hành: Implement Scheduler quét dependency graph, đẩy Task sẵn sàng vào queue thực thi.

Ngày 1036: Implement Executor

• Mục tiêu: Hỗ trợ cả chạy local và phân tán.

• Lý thuyết: Ôn lại Executor Types đã học ở Airflow (Giai đoạn 15, Ngày 932).

• Thực hành: Implement LocalExecutor (dùng Thread Pool, Giai đoạn 5) và thiết kế interface cho DistributedExecutor (tích hợp với Distributed Job System nếu cần scale).

Ngày 1037: Implement State Tracking

• Mục tiêu: Theo dõi trạng thái workflow run.

• Lý thuyết: Ôn lại State pattern (Giai đoạn 3) - mỗi Task run có trạng thái Pending/Running/Success/Failed.

• Thực hành: Implement WorkflowRun/TaskRun với state tracking, lưu vào database qua ORM module vừa xây.

Ngày 1038: Implement Retry & Error Handling

• Mục tiêu: Liên hệ trực tiếp Resilience Patterns (Giai đoạn 12).

• Lý thuyết: Ôn lại Retry Pattern - Task thất bại cần retry theo policy, workflow cần quyết định tiếp tục hay dừng khi 1 Task fail hẳn.

• Thực hành: Implement retry policy cho Task, cơ chế "skip" hoặc "fail workflow" khi Task fail sau khi hết retry.

Ngày 1039: Implement Data Passing giữa Task

• Mục tiêu: Liên hệ trực tiếp XCom đã học ở Airflow (Giai đoạn 15, Ngày 933).

• Lý thuyết: Ôn lại cách Task truyền dữ liệu nhỏ cho Task tiếp theo.

• Thực hành: Implement cơ chế context.push()/context.pull() cho phép Task truyền dữ liệu qua nhau.

Ngày 1040: Implement Trigger

• Mục tiêu: Cho phép workflow tự động chạy theo lịch hoặc theo sự kiện.

• Lý thuyết: Liên hệ trực tiếp Event Bus vừa xây (Nhóm 4) - workflow có thể được trigger bởi cron schedule hoặc bởi 1 domain event cụ thể.

• Thực hành: Implement CronTrigger và EventTrigger (subscribe vào Event Bus, tự động chạy workflow khi nhận đúng event).

Ngày 1041: Lab - Workflow Mẫu

• Mục tiêu: Kiểm chứng engine hoạt động với use case thật.

• Lý thuyết: Ôn lại ETL pattern (Extract-Transform-Load) đã thiết kế ở Airflow lab (Giai đoạn 15, Ngày 934).

• Thực hành: Viết 1 workflow mẫu 3 bước chạy trên Workflow Engine tự viết, verify chạy đúng thứ tự và data passing hoạt động.

Ngày 1042: Test Workflow Engine

• Mục tiêu: Đảm bảo độ tin cậy cho module phức tạp nhất.

• Lý thuyết: Ôn lại Testing Strategy cho hệ thống có state phức tạp.

• Thực hành: Viết test: DAG hợp lệ/không hợp lệ (có cycle), retry, data passing, trigger.

Ngày 1043: Review Workflow Engine

• Mục tiêu: Chốt lại module phức tạp nhất, dài nhất trong capstone.

• Lý thuyết: Ôn lại toàn bộ 12 ngày.

• Thực hành: Viết tài liệu API cho Workflow Engine.

Nhóm 6: Plugin System (Ngày 1044–1051)

Ngày 1044: Ôn lại 3 Phiên bản Plugin System Đã Xây

• Mục tiêu: Tổng hợp trước khi thống nhất thành 1 phiên bản cuối.

• Lý thuyết: Ôn lại Plugin System Java/Python (Giai đoạn 1) và C++ (Giai đoạn 10) - mỗi phiên bản dùng cơ chế load động khác nhau (reflection/importlib/dlopen) nhưng cùng chung ý tưởng.

• Thực hành: Lập bảng so sánh 3 phiên bản đã xây, xác định phần chung có thể trừu tượng hoá.

Ngày 1045: Thiết kế Plugin System Thống nhất

• Mục tiêu: Thiết kế phiên bản cuối cùng cho Platform Framework.

• Lý thuyết: Ôn lại Interface Segregation - Plugin interface nên tối giản, mở rộng qua nhiều loại plugin cụ thể (route plugin, event handler plugin, task plugin cho Workflow Engine).

• Thực hành: Thiết kế Plugin interface gốc và các interface con chuyên biệt.

Ngày 1046: Implement Plugin Interface + Registry

• Mục tiêu: Xây nền tảng.

• Lý thuyết: Ôn lại Plugin Registry (Giai đoạn 1, Ngày 89).

• Thực hành: Implement PluginRegistry tích hợp với DI Container (plugin cũng được quản lý như bean).

Ngày 1047: Implement Dynamic Loading

• Mục tiêu: Hỗ trợ load plugin không cần biên dịch lại framework.

• Lý thuyết: Ôn lại cơ chế load động đã chọn cho ngôn ngữ chính của capstone.

• Thực hành: Implement PluginLoader load plugin từ thư mục ngoài, đăng ký vào PluginRegistry.

Ngày 1048: Implement Plugin Lifecycle + Configuration

• Mục tiêu: Hoàn thiện vòng đời plugin.

• Lý thuyết: Ôn lại Plugin Lifecycle (Giai đoạn 1, Ngày 94) và Plugin Configuration (Ngày 95).

• Thực hành: Implement init/start/stop lifecycle, tích hợp với Configuration System (sẽ xây ở Nhóm 7) để mỗi plugin nhận config riêng.

Ngày 1049: Implement Plugin Isolation

• Mục tiêu: Liên hệ trực tiếp Error Handling & Isolation (Giai đoạn 1, Ngày 96).

• Lý thuyết: Ôn lại nguyên tắc: 1 plugin lỗi không được làm sập cả framework.

• Thực hành: Implement error boundary quanh mỗi lời gọi plugin, log lỗi riêng biệt, không để exception lan ra ngoài.

Ngày 1050: Test Plugin System

• Mục tiêu: Đảm bảo độ tin cậy.

• Lý thuyết: Ôn lại test đã viết ở Giai đoạn 1 (Ngày 97), mở rộng cho phiên bản thống nhất.

• Thực hành: Viết test: load plugin thành công/thất bại, isolation khi plugin lỗi, lifecycle đúng thứ tự.

Ngày 1051: Review Plugin System

• Mục tiêu: Chốt lại module thứ 5.

• Lý thuyết: Ôn lại toàn bộ tuần.

• Thực hành: Viết tài liệu API cho Plugin System.

Nhóm 7: REST API Framework (Ngày 1052–1061)

Ngày 1052: Ôn lại Mini Web Framework - Xác định Gap

• Mục tiêu: Đánh giá khoảng cách với yêu cầu production.

• Lý thuyết: Ôn lại Mini Web Framework (Giai đoạn 3) - còn thiếu: validation tự động, OpenAPI, tích hợp DI.

• Thực hành: Viết danh sách gap.

Ngày 1053: Implement Router Nâng cao

• Mục tiêu: Hỗ trợ pattern route phức tạp hơn.

• Lý thuyết: Ôn lại Router (Giai đoạn 3, Ngày 181) - thêm wildcard, path param với type constraint.

• Thực hành: Implement Router hỗ trợ /orders/{id:int}.

Ngày 1054: Implement Middleware Pipeline Nâng cao

• Mục tiêu: Hoàn thiện Chain of Responsibility đã xây.

• Lý thuyết: Ôn lại MiddlewarePipeline (Giai đoạn 3, Ngày 182).

• Thực hành: Thêm khả năng middleware theo route cụ thể (không chỉ global), thứ tự ưu tiên rõ ràng.

Ngày 1055: Implement Request Validation

• Mục tiêu: Liên hệ trực tiếp Pydantic đã học Giai đoạn 15.

• Lý thuyết: Ôn lại validation dựa trên schema/type hint.

• Thực hành: Implement cơ chế validate request body dựa trên schema định nghĩa (class/struct), tự động trả lỗi 422 khi validate thất bại.

Ngày 1056: Implement OpenAPI Tự động Generate

• Mục tiêu: Liên hệ trực tiếp FastAPI (Giai đoạn 10/15).

• Lý thuyết: Ôn lại cách FastAPI sinh OpenAPI spec từ type hint.

• Thực hành: Implement tự động sinh OpenAPI spec từ route + schema đã định nghĩa.

Ngày 1057: Implement Exception Handling Tập trung

• Mục tiêu: Liên hệ trực tiếp @ControllerAdvice (Spring, Giai đoạn 10).

• Lý thuyết: Ôn lại cơ chế đăng ký exception handler tập trung.

• Thực hành: Implement ExceptionHandlerRegistry, tự động route exception nghiệp vụ tới đúng handler trả response phù hợp.

Ngày 1058: Tích hợp DI Container

• Mục tiêu: Kết nối module đầu tiên với module thứ 7 - bước tích hợp đầu tiên của capstone.

• Lý thuyết: Ôn lại DI Container (Nhóm 2) - Controller/Handler nên được quản lý bởi DI Container, tự động inject Service/Repository cần thiết.

• Thực hành: Sửa REST API Framework để resolve Controller qua DI Container thay vì tự khởi tạo trực tiếp.

Ngày 1059: Implement Auth Middleware

• Mục tiêu: Liên hệ trực tiếp AuthN/AuthZ (Giai đoạn 9).

• Lý thuyết: Ôn lại JWT validation.

• Thực hành: Implement middleware xác thực JWT tích hợp sẵn, expose decorator/annotation đơn giản để bảo vệ route (VD: @RequireAuth).

Ngày 1060: Test REST API Framework

• Mục tiêu: Đảm bảo độ tin cậy.

• Lý thuyết: Ôn lại Testing Strategy cho framework code.

• Thực hành: Viết test: routing, validation, exception handling, DI integration, auth middleware.

Ngày 1061: Review REST API Framework

• Mục tiêu: Chốt lại module thứ 6.

• Lý thuyết: Ôn lại toàn bộ tuần.

• Thực hành: Viết tài liệu API cho REST API Framework.

Nhóm 8: Configuration System (Ngày 1062–1067)

Ngày 1062: Thiết kế Configuration System

• Mục tiêu: Liên hệ trực tiếp 12-Factor App (Giai đoạn 13).

• Lý thuyết: Ôn lại nguyên tắc config qua environment - Configuration System cần hỗ trợ nhiều nguồn (file, env var, remote config server) với thứ tự ưu tiên rõ ràng.

• Thực hành: Thiết kế API Config.get("database.host") với cơ chế fallback qua nhiều nguồn.

Ngày 1063: Implement Config Loader

• Mục tiêu: Hỗ trợ đa định dạng.

• Lý thuyết: Ôn lại YAML/JSON/env var.

• Thực hành: Implement loader đọc config từ file YAML, override bởi biến môi trường nếu có.

Ngày 1064: Implement Config Hot Reload

• Mục tiêu: Cho phép thay đổi config mà không cần restart ứng dụng.

• Lý thuyết: Liên hệ trực tiếp xDS của Envoy (Giai đoạn 10/15) - cập nhật config động, không gián đoạn service.

• Thực hành: Implement cơ chế watch file config, tự động reload và publish event (qua Event Bus vừa xây) khi có thay đổi.

Ngày 1065: Tích hợp Secrets

• Mục tiêu: Liên hệ trực tiếp Secrets Management (Giai đoạn 9/13).

• Lý thuyết: Ôn lại nguyên tắc không hardcode secret - Configuration System cần phân biệt config thường và secret (không log ra, không hiện trong debug output).

• Thực hành: Implement SecretConfig riêng biệt, tự động mask giá trị khi log.

Ngày 1066: Test Configuration System

• Mục tiêu: Đảm bảo độ tin cậy.

• Lý thuyết: Ôn lại Testing Strategy.

• Thực hành: Viết test: thứ tự ưu tiên nguồn config, hot reload, secret masking.

Ngày 1067: Review Configuration System

• Mục tiêu: Chốt lại module thứ 7.

• Lý thuyết: Ôn lại toàn bộ.

• Thực hành: Viết tài liệu API cho Configuration System.

Nhóm 9: Scheduler (Ngày 1068–1075)

Ngày 1068: Ôn lại Concurrent Task Scheduler + Distributed Job System

• Mục tiêu: Tổng hợp 2 phiên bản đã xây (Giai đoạn 5 và 12) trước khi hợp nhất.

• Lý thuyết: Ôn lại Concurrent Task Scheduler (đơn máy, đa luồng) và Distributed Job System (nhiều máy, có Leader Election).

• Thực hành: Xác định Scheduler cho Platform Framework cần hỗ trợ cả 2 chế độ (single-node cho ứng dụng nhỏ, distributed cho ứng dụng lớn).

Ngày 1069: Thiết kế Scheduler Thống nhất

• Mục tiêu: Thiết kế API chung cho cả 2 chế độ.

• Lý thuyết: Ôn lại Strategy pattern (Giai đoạn 3) - chọn chiến lược thực thi (Local/Distributed) qua Configuration System vừa xây.

• Thực hành: Thiết kế interface Scheduler với 2 implementation LocalScheduler/DistributedScheduler.

Ngày 1070: Implement Cron-based Scheduling

• Mục tiêu: Hỗ trợ lịch chạy định kỳ.

• Lý thuyết: Ôn lại cú pháp cron expression.

• Thực hành: Implement parser cho cron expression, cơ chế tính thời điểm chạy tiếp theo.

Ngày 1071: Implement Distributed Scheduling

• Mục tiêu: Liên hệ trực tiếp Leader Election (Giai đoạn 12).

• Lý thuyết: Ôn lại etcd Leader Election đã dùng ở Distributed Job System.

• Thực hành: Implement DistributedScheduler dùng leader election, đảm bảo chỉ 1 instance thực sự trigger job dù chạy nhiều instance Platform Framework.

Ngày 1072: Tích hợp Scheduler với Workflow Engine

• Mục tiêu: Kết nối 2 module đã xây riêng biệt.

• Lý thuyết: Ôn lại CronTrigger đã thiết kế ở Workflow Engine (Ngày 1040).

• Thực hành: Sửa CronTrigger để dùng Scheduler module vừa xây thay vì tự implement logic cron riêng.

Ngày 1073: Implement Job History & Monitoring

• Mục tiêu: Liên hệ trực tiếp Observability (Giai đoạn 13).

• Lý thuyết: Ôn lại Structured Logging/Metrics - Scheduler cần expose metric (job success rate, execution time) và log lịch sử chạy.

• Thực hành: Implement lưu job history qua ORM module, expose metrics endpoint tương thích Prometheus.

Ngày 1074: Test Scheduler

• Mục tiêu: Đảm bảo độ tin cậy.

• Lý thuyết: Ôn lại test Leader Election/Failover đã làm ở Giai đoạn 12 (Ngày 717).

• Thực hành: Viết test: cron trigger đúng giờ, distributed mode không double-trigger, failover khi leader chết.

Ngày 1075: Review Scheduler

• Mục tiêu: Chốt lại module cuối cùng trong 8 module - hoàn thành toàn bộ các thành phần riêng lẻ.

• Lý thuyết: Ôn lại toàn bộ 8 module đã xây (74 ngày): DI Container, ORM, Event Bus, Workflow Engine, Plugin System, REST API Framework, Configuration System, Scheduler.

• Thực hành: Viết tài liệu API cho Scheduler, cập nhật bảng tổng hợp 8 module đã hoàn thành từ Ngày 1002.

Nhóm 10: Tích hợp Cuối cùng - Platform Framework Hoàn chỉnh (Ngày 1076–1099)

Ngày 1076: Thiết kế Kiến trúc Tích hợp

• Mục tiêu: Lên kế hoạch ghép 8 module thành 1 thể thống nhất.

• Lý thuyết: Ôn lại sơ đồ đã vẽ Ngày 1003, cập nhật dựa trên thực tế implementation.

• Thực hành: Vẽ sơ đồ kiến trúc cuối cùng của Platform Framework với đầy đủ 8 module và quan hệ giữa chúng.

Ngày 1077: Xác định Demo Application

• Mục tiêu: Chọn use case chứng minh framework hoạt động thật.

• Lý thuyết: Ôn lại 3-service project (Giai đoạn 8/12/13) - sẽ tái tạo lại 1 phần bằng chính Platform Framework tự viết, để so sánh trực tiếp.

• Thực hành: Xác định phạm vi demo: tái tạo Order Service bằng Platform Framework.

Ngày 1078: Tích hợp DI Container + REST API Framework

• Mục tiêu: Ghép 2 module cốt lõi.

• Lý thuyết: Ôn lại Ngày 1058 đã bắt đầu, giờ hoàn thiện toàn diện.

• Thực hành: Verify toàn bộ Controller trong REST API Framework được quản lý qua DI Container.

Ngày 1079: Tích hợp ORM

• Mục tiêu: Kết nối persistence layer vào hệ thống.

• Lý thuyết: Ôn lại Repository pattern (Giai đoạn 7) - Repository là bean được DI Container quản lý, dùng ORM module bên trong.

• Thực hành: Viết OrderRepository dùng ORM module, đăng ký vào DI Container, inject vào Controller.

Ngày 1080: Tích hợp Event Bus

• Mục tiêu: Kết nối domain event vào toàn hệ thống.

• Lý thuyết: Ôn lại Domain Event (Giai đoạn 7) - khi Order thay đổi state, publish event qua Event Bus module.

• Thực hành: Sửa Order aggregate để publish event qua Event Bus, viết 1 event handler đơn giản lắng nghe.

Ngày 1081: Tích hợp Plugin System

• Mục tiêu: Cho phép mở rộng framework qua plugin.

• Lý thuyết: Ôn lại thiết kế Plugin interface chuyên biệt (Ngày 1045) - 1 loại plugin có thể tự đăng ký thêm route vào REST API Framework.

• Thực hành: Viết 1 plugin mẫu tự động thêm route /health khi được load.

Ngày 1082: Tích hợp Configuration System

• Mục tiêu: Đảm bảo mọi module đọc config qua 1 nguồn thống nhất.

• Lý thuyết: Ôn lại 12-Factor App - không module nào nên tự đọc file config riêng.

• Thực hành: Sửa toàn bộ 8 module để inject config qua Configuration System thay vì hardcode.

Ngày 1083: Tích hợp Workflow Engine + Scheduler

• Mục tiêu: Hoàn thiện nhóm xử lý bất đồng bộ.

• Lý thuyết: Ôn lại Ngày 1072 đã kết nối sơ bộ.

• Thực hành: Viết 1 workflow mẫu chạy định kỳ (VD: tổng hợp báo cáo Order hàng ngày) dùng cả Workflow Engine và Scheduler.

Ngày 1084: Implement Observability

• Mục tiêu: Liên hệ trực tiếp Giai đoạn 13, đảm bảo Platform Framework production-ready thật sự.

• Lý thuyết: Ôn lại 3 trụ cột Observability (Logs/Metrics/Traces).

• Thực hành: Tích hợp structured logging, metrics endpoint, tracing (OpenTelemetry) làm sẵn cho mọi ứng dụng dùng Platform Framework, không cần config thêm.

Ngày 1085: Demo Application 1 - CRUD Service

• Mục tiêu: Chứng minh REST API Framework + DI + ORM hoạt động cùng nhau.

• Lý thuyết: Ôn lại toàn bộ tích hợp đã làm.

• Thực hành: Hoàn thiện Order Service CRUD chạy hoàn toàn trên Platform Framework tự viết.

Ngày 1086: Demo Application 2 - Workflow ETL

• Mục tiêu: Chứng minh Workflow Engine hoạt động với use case thực tế.

• Lý thuyết: Ôn lại ETL pattern.

• Thực hành: Viết workflow tổng hợp dữ liệu Order theo ngày (Extract từ database → Transform tính tổng → Load vào bảng báo cáo).

Ngày 1087: Demo Application 3 - Plugin Mở rộng

• Mục tiêu: Chứng minh Plugin System hoạt động thật.

• Lý thuyết: Ôn lại use case mở rộng framework không cần sửa core.

• Thực hành: Viết 1 plugin thêm tính năng mới (VD: export Order ra CSV) mà không cần sửa code core của Platform Framework.

Ngày 1088: Viết Documentation

• Mục tiêu: Tổng hợp toàn bộ tài liệu API đã viết rải rác qua từng module.

• Lý thuyết: Ôn lại nguyên tắc viết documentation tốt - có Quick Start, API Reference, và ví dụ thực tế cho mỗi module.

• Thực hành: Tổng hợp thành 1 tài liệu hoàn chỉnh cho Platform Framework, gồm cả 3 Demo Application làm ví dụ.

Ngày 1089: Test Integration Toàn diện

• Mục tiêu: Đảm bảo cả hệ thống hoạt động đúng cùng nhau, không chỉ từng module riêng lẻ.

• Lý thuyết: Ôn lại Integration Testing (Giai đoạn 4).

• Thực hành: Viết test end-to-end cho cả 3 Demo Application, verify toàn bộ 8 module phối hợp đúng.

Ngày 1090: Benchmark So với Framework Thật

• Mục tiêu: Đánh giá khách quan thành quả 1099 ngày.

• Lý thuyết: Ôn lại benchmark methodology đã dùng xuyên suốt roadmap.

• Thực hành: Benchmark Platform Framework tự viết so với Spring Boot/FastAPI (đã học sâu ở Giai đoạn 10) cho cùng use case CRUD, phân tích chênh lệch hiệu năng.

Ngày 1091: Containerize Platform Framework

• Mục tiêu: Liên hệ trực tiếp Docker (Giai đoạn 13).

• Lý thuyết: Ôn lại Dockerfile Best Practice.

• Thực hành: Viết Dockerfile tối ưu cho Demo Application chạy trên Platform Framework.

Ngày 1092: Deploy lên Kubernetes

• Mục tiêu: Liên hệ trực tiếp Kubernetes (Giai đoạn 13).

• Lý thuyết: Ôn lại Deployment/Service/ConfigMap.

• Thực hành: Viết manifest và deploy Demo Application lên Kubernetes cluster local, verify chạy đúng qua toàn bộ pipeline đã xây từ Giai đoạn 13.

Ngày 1093: Security Review

• Mục tiêu: Liên hệ trực tiếp OWASP Top 10 (Giai đoạn 9).

• Lý thuyết: Ôn lại Security Checklist đã viết ở Giai đoạn 9 (Ngày 455).

• Thực hành: Review toàn bộ Platform Framework theo checklist, đặc biệt Auth Middleware và Secrets handling.

Ngày 1094: Performance Tuning Cuối cùng

• Mục tiêu: Áp dụng toàn bộ kiến thức tối ưu đã học (GC Tuning Giai đoạn 14, Allocator Giai đoạn 14, Index Giai đoạn 11).

• Lý thuyết: Ôn lại nguyên tắc: đo trước khi tối ưu (benchmark Ngày 1090 làm baseline).

• Thực hành: Xác định 1-2 điểm nghẽn hiệu năng lớn nhất qua benchmark, thực hiện tối ưu, đo lại để verify cải thiện.

Ngày 1095: Code Review Toàn diện

• Mục tiêu: Áp dụng lại Refactoring (Giai đoạn 2) như bước hoàn thiện cuối cùng.

• Lý thuyết: Ôn lại Code Smells catalog đã học.

• Thực hành: Review lại toàn bộ 8 module, tìm và sửa code smell còn sót lại.

Ngày 1096: Viết Final Report

• Mục tiêu: Tổng hợp toàn bộ hành trình 1099 ngày thành 1 tài liệu.

• Lý thuyết: Không có lý thuyết mới - đây là lúc tổng kết.

• Thực hành: Viết Final Report: kiến trúc Platform Framework, các quyết định thiết kế quan trọng, benchmark kết quả, bài học rút ra.

Ngày 1097: Retrospective Toàn bộ Roadmap

• Mục tiêu: Nhìn lại toàn bộ hành trình từ Ngày 1 (CPU/Cache) tới Ngày 1096 (Platform Framework hoàn chỉnh).

• Lý thuyết: Ôn lại 17 giai đoạn đã đi qua, xác định giai đoạn nào ảnh hưởng nhiều nhất tới cách tư duy hệ thống hiện tại.

• Thực hành: Viết bài retrospective toàn diện: 5 khoảnh khắc "a-ha" lớn nhất trong toàn bộ hành trình, 3 kỹ năng tự tin nhất, 3 mảng cần tiếp tục đào sâu sau roadmap.

Ngày 1098: Xác định Hướng Phát triển Tiếp theo

• Mục tiêu: Roadmap kết thúc không có nghĩa là việc học dừng lại.

• Lý thuyết: Liên hệ lại Ngày 959 (duy trì thói quen đọc source định kỳ) - mở rộng thành kế hoạch dài hạn: đóng góp cho 1 open-source project thật, tiếp tục phát triển Platform Framework, hoặc đi sâu 1 chuyên môn cụ thể (VD: chuyên gia Database Internals, chuyên gia Distributed Systems).

• Thực hành: Viết kế hoạch phát triển 6-12 tháng tiếp theo, chọn 1-2 hướng chuyên sâu dựa trên những gì thấy hứng thú nhất qua 1099 ngày vừa qua.

Ngày 1099: Kết thúc Roadmap

• Mục tiêu: Khép lại hành trình 1099 ngày - từ "hiểu OOP đang che giấu gì" (Ngày 1) tới "tự xây 1 platform framework hoàn chỉnh" (Ngày 1099).

• Lý thuyết: Con đường của người thiết kế framework, platform và hệ thống production không kết thúc ở đây - nó chỉ vừa mới có đủ nền tảng để thực sự bắt đầu.

• Thực hành: Present Platform Framework hoàn chỉnh (repo, documentation, 3 demo application) như thành quả cuối cùng - dùng nó làm portfolio piece hoặc làm nền tảng thực tế cho công việc/dự án tiếp theo.

---