Làm thế nào để thiết kế hệ thống xử lý lỗi một cách uyển chuyển?

Question

Accepted Answer

Ở quy mô lớn, **lỗi là không thể tránh khỏi** — server crash, network lỗi, dependency trở nên không khả dụng. Thiết kế cho lỗi nghĩa là xây dựng những hệ thống **chịu đựng và phục hồi từ lỗi một cách uyển chuyển** thay vì giả định mọi thứ đều hoạt động. Điều này thiết yếu cho hệ thống reliable.

## Thiết kế cho lỗi (tư duy)

```text
GIẢ ĐỊNH mọi thứ SẼ lỗi → ở quy mô lớn, lỗi là BÌNH THƯỜNG, không phải ngoại lệ:
  → server crash, network partition, disk hỏng, dependency down, traffic tăng đột biến
  → thiết kế hệ thống để KỲ VỌNG và XỬ LÝ lỗi uyển chuyển (đừng giả định mọi thứ hoạt động)
→ "mọi thứ đều lỗi mọi lúc" → xây dựng resilience vào hệ thống.
```

## Các kỹ thuật resilience

```text
✓ REDUNDANCY → nhiều instance, không single point of failure (failover sang cái khỏe)
✓ RETRIES (với backoff) → retry các lỗi nhất thời (với exponential backoff + jitter để
  tránh làm quá tải một service đang phục hồi)
✓ TIMEOUTS → đừng chờ mãi một dependency đang lỗi (fail fast)
✓ CIRCUIT BREAKERS → tạm dừng gọi một service đang lỗi (ngăn lỗi cascading;
  cho nó thời gian phục hồi) → fail fast và fall back
✓ GRACEFUL DEGRADATION → chức năng giảm bớt thay vì lỗi hoàn toàn (vd hiển thị dữ liệu
  cache/một phần nếu một service down)
✓ FALLBACKS → một mặc định/thay thế khi có gì đó lỗi
✓ BULKHEADS / isolation → khoanh vùng lỗi (một phần lỗi không làm chìm tất cả)
```

## Tránh lỗi cascading

```text
⚠️ Lỗi CASCADING → một lỗi kích hoạt các lỗi khác (vd một service chậm làm cạn kiệt tài nguyên
  của bên gọi → chúng cũng lỗi → lan ra)
→ ngăn bằng: timeout, circuit breaker, isolation/bulkhead, load shedding, backpressure
✓ MONITORING/alerting → phát hiện lỗi nhanh; test các kịch bản lỗi (chaos engineering)
```

## Tại sao điều này quan trọng

Hiểu cách thiết kế hệ thống xử lý lỗi uyển chuyển là giá trị vì **lỗi là không thể tránh khỏi ở quy mô lớn**, và thiết kế cho chúng là thiết yếu cho hệ thống reliable, nên đây là kiến thức system design quan trọng.

Tư duy cơ bản — **giả định mọi thứ sẽ lỗi** (vì ở quy mô lớn, lỗi là bình thường, không phải ngoại lệ — server crash, network partition, dependency down) và thiết kế hệ thống để kỳ vọng cùng xử lý lỗi uyển chuyển thay vì giả định mọi thứ hoạt động — là nền tảng của việc xây dựng hệ thống reliable, được tóm gọn trong nguyên tắc "mọi thứ đều lỗi mọi lúc".

Hiểu các **kỹ thuật resilience** là kiến thức thực tế then chốt: **redundancy** (không single point of failure), **retries với backoff** (xử lý lỗi nhất thời, với exponential backoff và jitter để tránh làm quá tải các service đang phục hồi), **timeouts** (fail fast thay vì chờ mãi), **circuit breakers** (dừng gọi một service đang lỗi để ngăn lỗi cascading và cho nó phục hồi), **graceful degradation** (chức năng giảm bớt thay vì lỗi hoàn toàn, như hiển thị dữ liệu cache), **fallbacks**, và **bulkheads/isolation** (khoanh vùng lỗi).

Những kỹ thuật này là cách hệ thống chịu đựng và phục hồi từ những lỗi tất yếu xảy ra.

Hiểu cách **tránh lỗi cascading** — nơi một lỗi kích hoạt các lỗi khác (một service chậm làm cạn kiệt tài nguyên của bên gọi, lan truyền lỗi), được ngăn bằng timeout, circuit breaker, isolation, load shedding và backpressure — đặc biệt quan trọng, vì lỗi cascading biến những vấn đề nhỏ thành những sự cố lớn.

Hiểu vai trò của monitoring và test các kịch bản lỗi (chaos engineering) hoàn thiện bức tranh.

Vì lỗi là không thể tránh khỏi ở quy mô lớn và thiết kế cho chúng (với tư duy thiết-kế-cho-lỗi và các kỹ thuật resilience) là thiết yếu cho hệ thống reliable, và vì hiểu tư duy, các kỹ thuật, và việc ngăn lỗi cascading là quan trọng để xây dựng hệ thống vững chắc, nên hiểu cách thiết kế cho lỗi là kiến thức system design có giá trị, quan trọng thực tế — thiết yếu để xây dựng hệ thống reliable chịu đựng những lỗi tất yếu ở quy mô lớn, trung tâm của resilience qua redundancy, retry, circuit breaker và graceful degradation, và phản ánh tư duy thiết-kế-cho-lỗi phân biệt hệ thống vững chắc với hệ thống mong manh.