Câu Hỏi Phỏng Vấn Microservices

Bạn đã đọc tên các pattern, có thể đọc vanh vách circuit breaker làm gì, nhưng vẫn không biết hội đồng phỏng vấn đang lắng nghe điều gì. Phần này nêu tên bốn lĩnh vực mà người phỏng vấn chấm điểm, theo thứ tự họ thường khai thác. Mỗi câu hỏi thực chất là một câu hỏi đánh giá năng lực khoác áo câu hỏi thuật ngữ.

• Phân rã hệ thống (Decomposition). Bạn cắt ở đâu, và vì sao lại ở đó? Người phỏng vấn muốn ranh giới được vẽ theo năng lực nghiệp vụ hoặc quyền sở hữu dữ liệu, không theo tầng kỹ thuật.
• Giao tiếp (Communication). Request/response đồng bộ hay sự kiện bất đồng bộ, và điều gì hỏng dưới mỗi lựa chọn. Câu trả lời họ muốn là một sự đánh đổi, không phải một sở thích.
• Dữ liệu (Data). Mỗi service một cơ sở dữ liệu nghĩa là không có join liên service và không có giao dịch phân tán. Vậy làm sao bạn giữ hệ thống đúng đắn?
• Vận hành (Operations). Triển khai, quản lý phiên bản, tracing, và điều gì xảy ra lúc ba giờ sáng khi một service chậm thay vì sập hẳn.

Hãy lưu ý rằng không điều nào trong số này liên quan đến framework. Một ứng viên giải thích được vì sao họ tách checkout khỏi inventory luôn ghi điểm cao hơn người chỉ liệt kê annotation.

Đây là những câu hỏi mở đầu phần lớn các vòng phỏng vấn microservices, cùng với điều người phỏng vấn thực sự đang kiểm tra bên dưới mỗi câu.

• Bạn sẽ tách monolith này thành các service như thế nào? Kiểm tra xem bạn cắt theo năng lực nghiệp vụ và quyền sở hữu dữ liệu, hay theo các tầng controller, service và repository. Cách trả lời thứ hai tạo ra một distributed monolith.
• Hai service giao tiếp với nhau như thế nào? Kiểm tra xem bạn có nêu được cái giá của mỗi lựa chọn không: cuộc gọi đồng bộ cho bạn một mô hình tư duy đơn giản nhưng ràng buộc tính khả dụng lẫn nhau, sự kiện bất đồng bộ tách rời tính khả dụng và cho bạn eventual consistency, thứ bạn phải giải thích được với product owner.
• Distributed monolith là gì và làm sao tránh nó? Kiểm tra xem bạn có hiểu rằng các service buộc phải triển khai cùng nhau thì thực chất không hề tách biệt.
• Một service nên lớn cỡ nào? Kiểm tra xem bạn có tránh được việc đưa ra một con số cụ thể không. Kích thước đi theo ranh giới và đội ngũ sở hữu nó.
• Bạn có cần API gateway không, và nó làm gì? Kiểm tra xem bạn có tách được routing, xác thực và giới hạn tần suất khỏi logic nghiệp vụ không.
• Các service tìm nhau bằng cách nào? Kiểm tra hiểu biết cơ bản về service discovery và vì sao host gắn cứng sẽ hỏng khi hệ thống mở rộng quy mô.

Hãy nói ra sự đánh đổi thành lời trong mọi câu trả lời. Hội đồng phỏng vấn không thể chấm điểm cho một phép so sánh bạn chỉ nghĩ thầm trong đầu.

Đây là nơi các cuộc phỏng vấn được quyết định thắng thua, vì những câu hỏi này không có đáp án gọn gàng và ứng viên thường cố lôi ra một câu trả lời học thuộc lòng.

• Bạn giữ dữ liệu nhất quán giữa các service bằng cách nào? Trước tiên hãy nêu rõ giới hạn: không có giao dịch xuyên service. Sau đó mô tả một saga, hoặc điều phối qua sự kiện (choreography) hoặc do một coordinator điều phối, và nói thẳng rằng hệ thống chỉ nhất quán cuối cùng (eventually consistent), cùng với việc người dùng sẽ thấy gì trong khoảng thời gian chưa nhất quán.
• Điều gì xảy ra khi một service downstream bị chậm? Timeout, retry kèm backoff, và một circuit breaker để một dependency chậm không làm cạn kiệt thread pool của bạn. Chậm còn tệ hơn sập, và nói được điều đó cho thấy kinh nghiệm thực chiến.
• Làm sao để retry an toàn? Idempotency. Một idempotency key trên đường ghi dữ liệu, để một lần thanh toán bị retry chỉ bị trừ tiền đúng một lần.
• Bạn xử lý lỗi cục bộ trong một luồng nhiều bước như thế nào? Hành động bù trừ, không phải rollback. Hãy giải thích việc hoàn tiền hay hủy một đặt chỗ trông như thế nào.
• Bạn debug một request đi qua sáu service như thế nào? Distributed tracing với một correlation ID được truyền qua mọi chặng, cùng với log có cấu trúc và metric.

Một kỹ sư backend phỏng vấn cho vị trí platform cấp L5 tại một nhà cung cấp public cloud gặp câu hỏi về saga và trả lời trôi chảy ngay lần đầu, bằng đúng thuật ngữ pattern, nhưng không hề nhắc đến việc khách hàng sẽ thấy gì. Câu hỏi tiếp theo, trang đơn hàng hiển thị gì trong khoảng thời gian chưa nhất quán, mới thực sự là câu hỏi quyết định kết quả vòng phỏng vấn. Hãy chuẩn bị câu trả lời thứ hai, chứ không chỉ câu đầu tiên.

Nhiều bộ câu hỏi khác theo vai trò và chủ đề được tổng hợp tại câu hỏi phỏng vấn theo vai trò.

Đọc danh sách này chỉ tạo ra cảm giác quen thuộc, và cảm giác đó biến mất ngay khi một người lạ đặt câu hỏi rồi chờ bạn trả lời. Khoảng cách giữa việc biết một pattern và việc giải thích nó dưới áp lực nhẹ chính là toàn bộ độ khó của một vòng system design, và nó chỉ thu hẹp lại bằng cách nói ra thành lời.

Hãy chọn một luồng bạn nắm rõ, chẳng hạn đặt hàng hoặc đăng ký tài khoản, rồi thuật lại toàn bộ quá trình phân rã hệ thống thành lời: ranh giới, lựa chọn giao tiếp, câu chuyện về tính nhất quán, câu chuyện về xử lý lỗi. Cứ làm vậy cho đến khi bạn không còn phải nói lại câu từ đầu. Bạn có thể chạy các câu hỏi này với một AI phỏng vấn viên biết đặt câu hỏi tiếp theo và cho bạn trả lời bằng giọng nói trong chế độ mock interview, gần với thực tế hơn nhiều so với việc chỉ đọc lại ghi chú.

Aaron Cao, người sáng lập SubcueAI, xây dựng chế độ luyện tập này xoay quanh chính khoảng cách đó, thay vì xoay quanh việc cung cấp nội dung. Danh sách câu hỏi thì có sẵn khắp nơi, thứ ứng viên thiếu là số lần lặp lại việc nói ra câu trả lời trong khi có người đang chờ. Trong một cuộc phỏng vấn thật, ứng dụng desktop và Side Panel của tiện ích mở rộng trình duyệt có thể hiển thị các gợi ý có cấu trúc trong lúc người phỏng vấn đang nói, dù một lời giải thích đã được luyện tập trước luôn tốt hơn một lời giải thích bạn đang đọc lần đầu tiên. Những gì trợ lý này làm được và không làm được, được mô tả tại tổng quan sản phẩm.