system-design

Hầu hết team viết code trước rồi mới viết doc — đây chính là nguyên nhân gây ra contract drift giữa backend và frontend. Bài này giải thích tại sao OpenAPI spec phải là nơi bắt đầu.

Sau 34 bài về agent system, bài cuối tổng kết: core mechanics không thay đổi từ CLI đến enterprise. Chỉ có infrastructure xung quanh thay đổi — và biết điều này là lợi thế lớn.

Human-in-the-Loop không phải dấu hiệu agent kém. Đó là design pattern cho high-stakes decisions. Bài này xây dựng framework quyết định khi nào agent tự làm, khi nào phải hỏi.

LLM API không reliable như database. Agent system phải design for partial failure từ đầu. Bài này xây dựng retry, fallback và timeout strategy cho production agent.

Token cost trong enterprise agent system không phải afterthought. Bài này xây dựng model routing strategy và token optimization để giảm cost mà không hy sinh quality.

Agent không nên kế thừa 100% permission của user. Principle of least privilege áp dụng cho agent cũng như người — nhưng cơ chế enforcement khác biệt căn bản.

Audit log trong agent system không phải debug tool — là compliance và accountability record. Thiết kế sai từ đầu, không thể fix sau. Bài này phân tích anatomy của audit record đúng.

Monitoring service thông thường đo latency và error rate. Agent cần biết tại sao LLM quyết định gì. Đây là sự khác biệt căn bản trong observability design.

Multi-agent failures không rõ ràng như single-agent failures. Bài này phân tích 5 failure mode đặc trưng của distributed agent system và cách phòng chống mỗi loại.

Context sharing giữa agents tạo ra implicit coupling mà bạn chỉ phát hiện khi sảy ra vấn đề. Bài này phân tích khi nào chia sẻ, khi nào cô lập, và tại sao orchestrator là gateway.

Agents communicate theo ba pattern: Push, Pull, và Event-driven. Mỗi pattern có coupling, reliability và latency khác nhau. Bài này phân tích khi nào dùng cái nào.

Task decomposition quyết định multi-agent system hiệu quả hay không. Bài này phân tích các nguyên tắc decompose đúng và dependency graph để orchestration rõ ràng.

Orchestrator Pattern là nnền tảng của multi-agent system. Orchestrator không làm việc — nó plan, delegate, monitor và synthesize. Bài này phân tích ranh giới và communication protocol.

Multi-agent không phải giải pháp cho mọi vấn đề. Bài này phân tích ba giới hạn thực sự của single-agent và framework quyết định khi nào cần mở rộng.

RAG không phải magic bullet. Nó shift vấn đề từ context size sang retrieval quality. Bài này phân tích khi nào RAG thực sự cần và khi nào nó là over-engineering.

Summarization không phải lossy compression — là information distillation. Bài này phân tích các strategy nén conversation history mà vẫn giữ được signal quan trọng.

Token budget không phải afterthought — là resource management bắt buộc trong production agent. Bài này xây dựng hệ thống đếm, phân bổ và cắt token chủ động.

Thứ tự các phần trong context window không ngẫu nhiên. LLM attend khác nhau theo vị trí. Bài này thiết kế context stack tối ưu cho coding agent.

Context window không chỉ là giới hạn kỹ thuật. Nó là design constraint ảnh hưởng đến mọi quyết định trong agent architecture. Bài này giải thích tại sao.

Agent không chỉ có một loại memory. Bài này xây dựng taxonomy đầy đủ: in-context, external, episodic, semantic — mỗi loại phục vụ một use case khác nhau.

Viết tool cho LLM khác viết function cho human developer. Bài này đưa ra 6 nguyên tắc thiết kế tool dựa trên cách LLM reason và ra quyết định.

Error handling trong agent system khác fundamentally so với trong service thường. Lỗi không chỉ được throw — nó có thể được đưa về cho LLM để tự recover. Bài này xây dựng taxonomy lỗi và chiến lược xử lý từng loại.

Tool Dispatcher là security boundary giữa LLM decision và actual execution. Bài này phân tích toàn bộ pipeline: từ khi nhận tool_use block cho đến khi trả tool_result về LLM.

Tool Registry là pattern giữ cho agent core không bị ô nhiễm bởi implementation của từng tool. Bài này thiết kế một registry tập trung, pluggable và type-safe.

LLM đọc JSON Schema để hiểu tool — giống như developer đọc API docs. Chất lượng schema quyết định LLM có dùng đúng tool không. Bài này phân tích anatomy của schema tốt và các anti-patterns.

Misconception phổ biến nhất về Tool Calling: LLM không execute gì cả. Nó chỉ trả về structured data. Bài này phân tích toàn bộ request/response cycle và tại sao sự phân biệt này quan trọng.

System prompt là code, không phải text. Nó định nghĩa toàn bộ behavior, constraints và personality của coding agent. Bài này phân tích anatomy của một system prompt hiệu quả và các nguyên tắc thiết kế.

Agent Core là trung tâm điều phối của CLI Agent — nơi agentic loop sống, context được build, và tool dispatch xảy ra. Bài này phân tích từng component và sequence diagram của một complete turn.

CLI Layer không chỉ là I/O đơn giản — nó định nghĩa UX của agent. Bài này phân tích pipeline từ keystroke đến khi request được gửi đến Agent Core, bao gồm input handling, command parsing và output streaming.

Một CLI Agent được tổ chức thành 4 layer với boundary rõ ràng: CLI, Agent Core, Tool, và Context. Bài này phân tích từng layer, trách nhiệm của nó, và lý do boundary tồn tại.

CLI loại bỏ toàn bộ noise của UI/UX và infrastructure để lộ core agent mechanics. Bài này giải thích tại sao bắt đầu với CLI là chiến lược đúng để hiểu sâu agent design.

Cách bạn tư duy về agent quyết định cách bạn thiết kế nó. Bài này xây dựng mental model thực tế — agent như một junior developer với guardrails — thay vì xem nó như AI magic.

Agentic Loop là vòng lặp Observe–Think–Act nằm ở trung tâm của mọi AI Agent. Bài này phân tích từng bước trong loop, điều kiện thoát, và các failure mode phổ biến nhất.

Kafka không chỉ là message queue. Bài viết phân tích sâu Event-Driven Architecture — từ core concepts, partitioning, consumer groups đến các anti-pattern thường gặp trong thực tế.

Sau khi thiết kế và vẽ flow, bước tiếp theo là test. Bài này đi vào cách test hệ thống token limit — đặc biệt là concurrent sessions, race condition trong quota enforcement, và Stripe Webhook idempotency.

Bài trước mình đã thiết kế hệ thống token limit. Bài này đi sâu hơn: vẽ toàn bộ flow từ lúc user bấm Submit đến lúc token được deduct — cả từ góc UX lẫn góc kỹ thuật.

OpenAI Codex vừa chuyển sang token-based pricing từ tháng 4/2026. Bài viết này phân tích cách thiết kế hệ thống rate limiting và token quota tương tự — từ data model, đến sliding window counter, đến fair-use enforcement.

Hành trình áp dụng C4 Model để tài liệu hóa kiến trúc hệ thống EdTech thực tế - từ Context đến Component, những bài học rút ra và tại sao nó thay đổi cách team mình làm việc.