TL;DR

Nếu phần 1 đặt nền móng cho hệ thống có thể scale, thì phần 2 này giải quyết câu hỏi: hệ thống sẽ làm gì khi có thành phần fail? Message Queues, API Gateway, Fault Tolerance, Distributed Systems và Monitoring & Logging là những building blocks quyết định hệ thống của bạn có thể recover gracefully hay sập hoàn toàn khi gặp sự cố.

Circuit Breaker pattern và Observability stack diagram

6. Message Queues - Giao tiếp bất đồng bộ

Khi hệ thống scale, synchronous communication - service A gọi trực tiếp service B và chờ kết quả - trở thành điểm yếu. Nếu service B chậm hoặc down, service A bị block theo. Message queues giải quyết vấn đề này bằng cách tách producer khỏi consumer thông qua một buffer trung gian.

Cách hoạt động: Producer gửi message vào queue và tiếp tục công việc ngay lập tức, không chờ. Consumer nhận và xử lý message theo pace của riêng mình. Queue buffer những message khi consumer bận, đảm bảo không mất data khi có traffic spike.

Các tool phổ biến:

  • Kafka: High-throughput, distributed event streaming. Phù hợp real-time analytics, data pipelines, event sourcing

  • RabbitMQ: Flexible routing, nhiều messaging patterns. Phù hợp task queues, microservices communication

  • AWS SQS: Managed service, dễ integrate với AWS ecosystem

Ba delivery semantics quan trọng cần hiểu:

  • At-most-once: Message có thể bị mất, nhưng không bao giờ duplicate. Dùng cho log events không critical

  • At-least-once: Message không bao giờ mất, nhưng có thể duplicate. Consumer phải idempotent

  • Exactly-once: Không mất, không duplicate. Phức tạp và tốn kém nhất. Dùng cho payment processing

Năm 2026, event-driven architecture ngày càng phổ biến, đặc biệt trong hệ thống tích hợp AI workflows và analytics. via Qodequay

7. API Gateway - Cổng vào duy nhất

API Gateway là single entry point cho tất cả clients kết nối vào hệ thống backend. Thay vì client phải biết address của từng microservice, tất cả traffic đi qua một điểm duy nhất.

Những gì API Gateway xử lý tập trung:

  • Authentication & Authorization: Xác thực token, kiểm tra quyền truy cập - không cần duplicate logic này trong mỗi service

  • Rate Limiting: Giới hạn số request từ mỗi client trong khoảng thời gian nhất định, bảo vệ backend khỏi abuse và DDoS

  • Request Routing: Chuyển request đến đúng service dựa trên path, header, hoặc content

  • TLS Termination: Xử lý HTTPS tại gateway, giảm overhead cho services bên trong

  • Request Aggregation: Gộp nhiều service calls thành một response cho client

API Gateway về bản chất là extension của load balancing layer, nhưng hoạt động ở application level thay vì network level. Centralize những cross-cutting concerns này giúp hệ thống dễ secure và monitor hơn đáng kể so với phân tán logic khắp nơi.

8. Fault Tolerance - Thiết kế cho failure

Nguyên tắc cốt lõi của fault tolerance: đừng hỏi "liệu component có fail không?" - hỏi "khi nó fail, hệ thống làm gì?"

Trong distributed systems, failure là điều chắc chắn xảy ra - network partition, server crash, dependency timeout. Mục tiêu là kiểm soát impact của failure, không phải ngăn nó hoàn toàn.

Các pattern thiết yếu:

  • Circuit Breaker: Giống như cầu dao điện - khi một service fail nhiều lần liên tiếp, circuit "trips" và subsequent requests fail ngay lập tức mà không cố kết nối. Sau một thời gian, circuit chuyển sang "half-open" để test service. Ngăn cascading failures và cho service downstream thời gian recover.

  • Retry với Exponential Backoff: Tự động retry khi request fail, với khoảng chờ tăng dần (1s, 2s, 4s, 8s...) để tránh overwhelm service đang recover.

  • Bulkhead Pattern: Chia resources thành các pool cô lập - như các khoang không thấm nước của tàu. Nếu một khoang bị rò, các khoang khác không bị ảnh hưởng. Trong software: isolate database connections, thread pools cho từng microservice.

  • Timeout: Không bao giờ để request chờ vô thời hạn. Định nghĩa timeout rõ ràng để tránh resource exhaustion.

Fault tolerance không chỉ về pattern - còn về test. Chaos engineering (Chaos Monkey, Gremlin) là practice inject failure có chủ ý vào production để verify hệ thống recover đúng như thiết kế. via GeeksforGeeks

9. Distributed Systems - Nhiều máy, một hệ thống

Distributed system là hệ thống chạy trên nhiều máy tính hoặc data centers, phối hợp để cung cấp một dịch vụ thống nhất cho user. Đây là nền tảng của mọi hệ thống scale lớn - từ Google Search đến Netflix.

Các thách thức đặc trưng:

  • Network latency: Giao tiếp giữa các nodes tốn thời gian và không đáng tin cậy. Design phải tính đến partial connectivity.

  • Consistency vs Availability (CAP Theorem): Trong distributed system, bạn chỉ có thể đảm bảo tối đa 2 trong 3: Consistency (mọi nodes thấy data giống nhau), Availability (hệ thống luôn respond), Partition Tolerance (tiếp tục hoạt động khi network bị chia cắt). Hầu hết systems hiện đại chọn AP hoặc CP tùy use case.

  • Partial failures: Một node có thể fail trong khi các nodes khác vẫn hoạt động. Hệ thống phải handle graceful degradation thay vì all-or-nothing.

  • Distributed consensus: Làm sao nhiều nodes đồng ý về một giá trị khi có thể có network failures? (Raft, Paxos protocols)

Consistency models quan trọng:

  • Strong consistency: Mọi read đều thấy write gần nhất. An toàn nhưng tốn kém về latency.

  • Eventual consistency: Tất cả nodes cuối cùng sẽ converge về cùng state, nhưng tại một thời điểm có thể khác nhau. Phù hợp cho social feeds, shopping carts.

10. Monitoring & Logging - Quan sát để hiểu hệ thống

Trong năm 2026, observability không còn là optional. Đây là first-class building block. Không có monitoring và logging tốt, scaling hệ thống là... đoán mò.

Ba trụ cột của observability:

  • Metrics (Prometheus/Grafana): Số liệu định lượng về trạng thái hệ thống - request rate, error rate, latency percentiles (p50, p95, p99), resource utilization. Metrics là hệ thống cảnh báo sớm.

  • Logs (ELK Stack: Elasticsearch + Logstash + Kibana, hoặc Loki): Bản ghi sự kiện có cấu trúc từ tất cả services. Trong microservices, logs phải có correlation ID để trace một request qua nhiều services.

  • Distributed Tracing: Track hành trình của một request từ entry point qua tất cả services nó đi qua. Jaeger, Zipkin là các tools phổ biến. Giúp identify bottleneck không rõ ràng.

Distributed logging trong microservices đặc biệt quan trọng:

  • Log aggregation: Thu thập logs từ tất cả services vào một centralized platform

  • Correlation IDs: Mỗi request được gán một unique ID, truyền qua tất cả services để link logs liên quan lại

  • Structured logging: Log dưới dạng JSON thay vì plain text để dễ query và filter

Lưu ý quan trọng: over-instrumentation có hại không kém under-instrumentation. Log quá nhiều = tốn storage + khó tìm signal trong noise. Thiết kế observability cần balance giữa visibility và cost.

Kết - 10 Khái Niệm, Một Tư Duy

Mười khái niệm system design này không phải checklist để implement từ đầu. Chúng là vocabulary để tư duy về trade-offs khi hệ thống phát triển.

Bắt đầu đơn giản. Scale khi cần. Nhưng hiểu rõ từng khái niệm để biết mình sẽ cần gì tiếp theo khi traffic tăng, khi team mở rộng, khi một component bắt đầu trở thành bottleneck.

Trong thời đại AI có thể viết code, system design là kỹ năng ngày càng quan trọng - AI không thể đưa ra quyết định kiến trúc thay bạn về consistency vs availability, hay khi nào nên shard database.