📌 Chủ đề: Architecture & System Design
Kiến trúc không phải là việc chọn Framework, mà là việc quản lý sự phức tạp và các luồng dữ liệu trong hệ thống.
#🟢 Cấp độ: Người mới bắt đầu (Beginner)
Q1: Tại sao chúng ta cần phân chia Layer (Tầng) trong ứng dụng?
Trả lời: Để đảm bảo tính Separation of Concerns. Giúp thay đổi một bộ phận (ví dụ: đổi giao diện) mà không làm hỏng bộ phận khác (ví dụ: logic tính toán).
Q2: Dependency Injection (DI) là gì?
Trả lời: Là kỹ thuật cung cấp các phụ thuộc từ bên ngoài vào Class thay vì để Class tự khởi tạo. Giúp code linh hoạt và dễ test.
Q3: Client-Server model là gì?
Trả lời: Mô hình mà Client (trình duyệt/app) gửi yêu cầu và Server xử lý yêu cầu đó rồi trả về kết quả.
Q4: Monolith Architecture (Kiến trúc đơn khối) là gì?
Trả lời: Toàn bộ ứng dụng nằm chung trong một source code duy nhất và chạy trên một server duy nhất.
Q5: API là gì và tại sao nó quan trọng trong thiết kế hệ thống?
Trả lời: Application Programming Interface. Là “cửa sổ” để các phần mềm khác nhau có thể giao tiếp và trao đổi dữ liệu với nhau một cách chuẩn hóa.
Q6: Khái niệm "Don't Repeat Yourself" (DRY) trong kiến trúc?
Trả lời: Hạn chế lặp lại code. Mỗi phần kiến thức hoặc logic phải có một biểu diễn duy nhất và rõ ràng trong hệ thống.
Q7: Stateless ứng dụng nghĩa là gì?
Trả lời: Ứng dụng không lưu giữ dữ liệu phiên làm việc của người dùng trên bộ nhớ máy chủ, giúp dễ dàng mở rộng bằng cách thêm nhiều server.
Q8: Vai trò của một Database trong hệ thống lớn?
Trả lời: Đảm bảo dữ liệu được lưu trữ an toàn, nhất quán, hỗ trợ truy vấn nhanh và phục hồi dữ liệu khi có sự cố.
Q9: Phân biệt Frontend và Backend.
Trả lời: Frontend: Phần người dùng thấy và tương tác. Backend: Phần xử lý logic, tính toán và lưu trữ dữ liệu ngầm.
Q10: "Single Point of Failure" (SPOF) là gì?
Trả lời: Một thành phần mà nếu nó lỗi thì cả hệ thống sập theo. Mục tiêu của kiến trúc sư là loại bỏ SPOF.
#🟡 Cấp độ: Trung cấp (Intermediate)
Q1: Phân biệt Coupling (Độ kết dính) và Cohesion (Độ gắn kết).
Trả lời: Cohesion: Các thành phần trong 1 module liên quan chặt chẽ (nên cao). Coupling: Sự phụ thuộc giữa các module (nên thấp).
Q2: Repository Pattern là gì? Lợi ích?
Trả lời: Lớp trung gian giữa Business Logic và Data Source. Giúp tách biệt logic nghiệp vụ khỏi cách dữ liệu được lưu trữ.
Q3: Inversion of Control (IoC) hoạt động như thế nào?
Trả lời: Đảo ngược quyền điều khiển. Framework sẽ gọi code của bạn thay vì bạn gọi Framework.
Q4: Service-Oriented Architecture (SOA) là gì?
Trả lời: Thiết kế phần mềm dựa trên các dịch vụ có thể tái sử dụng, giao tiếp với nhau qua mạng.
Q5: Phân biệt Authentication và Authorization trong hệ thống phân tán.
Trả lời: AuthN xác định bạn là ai (Login). AuthZ xác định bạn được làm gì (Permissions). Trong hệ thống phân tán thường dùng JWT để truyền thông tin AuthZ.
Q6: Cơ chế Pub/Sub (Publisher/Subscriber) pattern?
Trả lời: Bên gửi (Publisher) không gửi tin nhắn trực tiếp cho bên nhận, mà bắn lên một kênh. Các bên nhận (Subscriber) đăng ký kênh đó sẽ nhận được tin. Giúp giảm sự phụ thuộc trực tiếp.
Q7: Layered Architecture (Kiến trúc phân tầng) gồm những tầng nào phổ biến?
Trả lời: Presentation Layer, Business/Service Layer, Persistence/Data Layer, Database Layer.
Q8: Phân biệt MVC và MVVM.
Trả lời: MVC: Controller điều phối. MVVM: ViewModel đồng bộ dữ liệu tự động với View qua Data Binding (phổ biến trong Frontend framework).
Q9: Rate Limiting là gì? Tại sao hệ thống cần nó?
Trả lời: Giới hạn số lượng request một user/IP có thể gửi trong một khoảng thời gian để bảo vệ server khỏi bị quá tải hoặc tấn công.
Q10: Idempotency (Tính lũy đẳng) trong thiết kế API là gì?
Trả lời: Đảm bảo thực hiện một yêu cầu nhiều lần cũng có kết quả giống như một lần duy nhất (rất quan trọng cho các lệnh thanh toán).
#🔴 Cấp độ: Nâng cao (Advanced)
Q1: Clean Architecture hoạt động như thế nào? Quy tắc phụ thuộc?
Trả lời: Chia ứng dụng thành các vòng tròn đồng tâm. Quy tắc: Sự phụ thuộc chỉ được trỏ vào bên trong. Lõi (Entities) không được biết gì về Framework bên ngoài.
Q2: Domain-Driven Design (DDD) - Entity vs Value Object vs Aggregate Root.
Trả lời: Entity có ID. Value Object xác định bằng thuộc tính. Aggregate Root là cổng giao tiếp duy nhất của một nhóm đối tượng liên quan.
Q3: CQRS (Command Query Responsibility Segregation) giải quyết vấn đề gì?
Trả lời: Tách biệt logic Đọc và Ghi. Giúp tối ưu hóa hiệu năng cho từng loại thao tác (ví dụ: Ghi vào MySQL, Đọc từ Elasticsearch).
Q4: Event Sourcing là gì? Ưu và nhược điểm?
Trả lời: Lưu trữ mọi thay đổi trạng thái thành một chuỗi các Event thay vì chỉ lưu trạng thái cuối cùng. Ưu: Audit log tuyệt vời, khôi phục dữ liệu tại mọi thời điểm. Nhược: Phức tạp để truy vấn trạng thái hiện tại.
Q5: Microservices vs Monolith: Phân tích sự đánh đổi về mặt Network và Data Consistency.
Trả lời: Microservices: Linh hoạt, scale độc lập nhưng gặp vấn đề về độ trễ mạng và khó khăn trong việc đảm bảo dữ liệu nhất quán giữa các dịch vụ (Eventual Consistency).
Q6: Giải thích mẫu thiết kế Sidecar trong kiến trúc Container.
Trả lời: Chạy một container phụ cạnh container chính để hỗ trợ (ví dụ: log agent, proxy bảo mật) mà không làm thay đổi code của container chính.
Q7: Circuit Breaker pattern hoạt động như thế nào?
Trả lời: Ngắt kết nối tới một dịch vụ đang lỗi để tránh làm sập hệ thống dây chuyền. Có 3 trạng thái: Closed, Open, Half-Open.
Q8: API Gateway đóng vai trò gì trong hệ thống Microservices?
Trả lời: Cổng vào duy nhất cho Client. Đảm nhận: Routing, Authentication, Rate Limiting, Logging, và gộp dữ liệu từ nhiều service (Aggregator).
Q9: Phân biệt Orchestration và Choreography trong điều phối Microservices.
Trả lời: Orchestration: 1 bộ não trung tâm chỉ đạo. Choreography: Mỗi service tự phản ứng dựa trên các sự kiện (Events) nhận được.
Q10: CAP Theorem - Tại sao bạn không thể có cả 3?
Trả lời: Consistency, Availability, Partition Tolerance. Trong hệ thống phân tán luôn có rủi ro đứt mạng (P), nên bạn buộc phải chọn giữa sự nhất quán (C) hoặc tính sẵn sàng (A).
#🧠 Cấp độ: Kiến trúc sư (Architect)
Q1: Thiết kế hệ thống xử lý 1 triệu giao dịch mỗi giây.
Trả lời: Dùng kiến trúc Distributed & Scalable. Load Balancer tầng 4/7. Microservices stateless. Message Queue (Kafka) để buffer dữ liệu. In-memory DB (Redis) cho hot data. Database sharding.
Q2: Làm thế nào để xử lý "Data Consistency" trong Microservices (Saga Pattern)?
Trả lời: Thay vì Transaction toàn cục, Saga chia thành chuỗi các transaction cục bộ. Nếu 1 bước lỗi, thực hiện Compensating Transaction để hoàn tác các bước trước đó.
Q3: Thiết kế giải pháp cho hệ thống bị "Thundering Herd" khi Cache hết hạn.
Trả lời: Dùng Mutex lock (chỉ 1 request đi vào DB nạp cache), hoặc nạp cache ngầm (Soft Expiration) khi gần hết hạn.
Q4: Phân tích kiến trúc Serverless: Khi nào nó là "bẫy chi phí"?
Trả lời: Rẻ khi tải thấp và không đều. Đắt kinh khủng khi tải cao và ổn định 24/7. Gặp vấn đề về “Cold Start” và khó debug.
Q5: Thiết kế hệ thống "Distributed Tracing" để theo dõi request qua hàng chục service.
Trả lời: Dùng Trace ID duy nhất đính kèm vào Header của mọi request. Sử dụng các công cụ như Jaeger hoặc Zipkin để thu thập và trực quan hóa luồng đi của dữ liệu.
Q6: Làm thế nào để thực hiện "Zero-Downtime Migration" cho một Database khổng lồ?
Trả lời: Dùng Dual-Write: Ghi vào cả DB cũ và mới. Copy dữ liệu cũ sang mới ngầm. So sánh dữ liệu. Chuyển Đọc sang DB mới. Ngắt DB cũ.
Q7: Thiết kế kiến trúc "Multi-tenant" cho ứng dụng SaaS (Shared vs Isolated DB).
Trả lời: Shared DB: Tiết kiệm, dễ quản lý nhưng rủi ro lộ dữ liệu chéo. Isolated DB: Bảo mật tuyệt đối, dễ scale riêng từng khách hàng nhưng chi phí hạ tầng cao.
Q8: Phân tích sự đánh đổi giữa Latency và Throughput.
Trả lời: Latency: Thời gian xử lý 1 request. Throughput: Tổng số request xử lý được trong 1 giây. Tối ưu 1 cái thường làm giảm cái kia (ví dụ: Batching tăng throughput nhưng tăng latency cho từng request).
Q9: Thiết kế hệ thống "Real-time Analytics" cho hàng tỷ sự kiện mỗi ngày.
Trả lời: Dùng mô hình Lambda Architecture hoặc Kappa Architecture. Kafka cho stream dữ liệu. Apache Druid hoặc ClickHouse cho việc truy vấn phân tích siêu nhanh.
Q10: Làm thế nào để đảm bảo hệ thống "Resilient" trước thảm họa (Disaster Recovery)?
Trả lời: Deploy Multi-region. Dữ liệu replication liên tục. Có kịch bản diễn tập định kỳ (Chaos Engineering) để tự động switch sang Region dự phòng khi Region chính sập.
#💻 Practical Scenarios (Thực chiến)
S1: Hệ thống bị treo do một vòng lặp sự kiện (Event Loop) bị block. Bạn xử lý thế nào?
Xử lý: Tìm đoạn code xử lý CPU intensive hoặc I/O block đồng bộ. Chuyển các tác vụ đó sang Worker pool hoặc xử lý bất đồng bộ hoàn toàn.
S2: Database quá tải do vạn lượt truy cập vào cùng 1 bài viết hot. Giải pháp?
Xử lý: Triển khai Hot Key Caching với Redis. Sử dụng Local Cache ngay tại App server để không phải gọi ra Redis/DB liên tục.
#🚨 MUST-KNOW
- Sự khác biệt bản chất giữa Monolith và Microservices.
- Hiểu rõ 5 nguyên lý SOLID.
- Biết cách áp dụng Design Patterns phù hợp.
#⚠️ Pitfalls
- Over-engineering: Áp dụng kiến trúc quá phức tạp cho bài toán đơn giản.
- Quên không xử lý lỗi mạng giữa các service (Network is unreliable).
- Database trở thành nút thắt cổ chai do join quá nhiều bảng.
#🧩 Tips & Tricks
- Luôn thiết kế hệ thống theo hướng Stateless ngay từ đầu.
- Sử dụng Feature Flags để bật/tắt tính năng mới mà không cần deploy lại.
Biên soạn bởi Senior Software Architect.