Trong kiến trúc microservice, một request thường phải đi qua call chain của nhiều service. Nếu một service trên chain gặp vấn đề, chẳng hạn response chậm, timeout hoặc thậm chí dừng hẳn, tài nguyên của upstream rất dễ bị kéo sập, cuối cùng biến thành avalanche trên toàn bộ chain. Service degradation và circuit breaker là hai tuyến phòng thủ để xử lý loại vấn đề này: degradation chủ động "bỏ phần phụ để giữ phần chính" khi hệ thống chịu tải lớn, còn circuit breaker kịp thời "ngắt mạch" để giảm thiệt hại khi downstream liên tục bất thường.

Dù là website mua sắm bạn thường truy cập, dịch vụ thanh toán online bạn sử dụng hay hệ thống nghiệp vụ cốt lõi trong công ty, người dùng ngày càng khó chấp nhận việc "dịch vụ không khả dụng". Một sự cố kéo dài vài phút có thể khiến nhiều người dùng rời bỏ dịch vụ, thậm chí gây thiệt hại kinh tế trực tiếp.

Câu hỏi phỏng vấn về high availability thường bắt đầu bằng câu “Hệ thống làm thế nào để không sập?”, sau đó hỏi tiếp về single point of failure, rate limiting, circuit breaker, timeout, retry, API idempotency và disaster recovery ở nhiều địa điểm. Chỉ liệt kê các component thường chưa đủ; bạn còn phải giải thích cách phát hiện sự cố, cách kiểm soát ảnh hưởng, cách khôi phục service và liệu dữ liệu có giữ được tính chính xác hay không.

Idempotency của API là câu hỏi thường gặp trong phỏng vấn, đồng thời cũng là vấn đề thường phải giải quyết trong quá trình phát triển hằng ngày.

Idempotency là gì?

Idempotency là một khái niệm toán học, thường gặp trong đại số trừu tượng, biểu thị việc một thao tác được thực hiện một lần hay nhiều lần đều cho ra cùng một hiệu quả. Áp dụng vào hàm, có thể hiểu là $f(f(x)) = f(x)$. Ví dụ, $f(x)=|x|$ là idempotent, vì lấy giá trị tuyệt đối của một số một lần hay nhiều lần đều cho cùng kết quả.

Đối với hệ thống phần mềm, rate limiting là giới hạn tốc độ request để tránh lượng request lớn đột ngột làm sập hệ thống. Suy cho cùng, năng lực xử lý của hệ thống phần mềm là có hạn. Nếu lượng request vượt quá năng lực xử lý, hệ thống phần mềm có thể sập ngay.

Rate limiting có thể khiến request của người dùng không được xử lý đúng hoặc không được xử lý ngay, nhưng đây thường là phương án tối ưu sau khi cân nhắc tính ổn định của hệ thống phần mềm.

Performance testing thường do đội ngũ kiểm thử chuyên nghiệp phụ trách. Vậy tại sao developer vẫn cần học? Hiểu các chỉ số, loại hình và công cụ của performance testing giúp bạn viết chương trình có performance tốt hơn. Ngoài ra, nếu developer biết performance testing, đây cũng là điểm cộng đáng kể cho hồ sơ năng lực.

Dù là hardware failure, mất điện tại data center hay một service đột ngột dừng hoạt động, single point luôn là mắt xích yếu nhất trong hệ thống. Muốn hệ thống vẫn chịu được nhiều tình huống bất ngờ, cách cơ bản và hiệu quả nhất là redundancy — chuẩn bị nhiều bản sao cho tài nguyên quan trọng để khi một bản hỏng, bản khác có thể thay thế.

Do tính bất định của network jitter, hardware failure, process exception, dependency service không khả dụng và các vấn đề khác, hệ thống hoặc service của chúng ta không thể luôn duy trì trạng thái khả dụng.

Để giảm tối đa ảnh hưởng do sự cố hệ thống hoặc service, chúng ta cần dùng cơ chế timeout và retry.