Senior Software Engineer (Remote, Backend/FullStack)

Message queue tách bên gửi và bên nhận: xử lý bất đồng bộ, hấp thụ tải đột biến, cho nhiều hệ thống cùng phản ứng với một sự kiện.

• RabbitMQ: message broker truyền thống, định tuyến linh hoạt qua exchange (direct, topic, fanout), message bị xoá sau khi consumer ack. Hợp với hàng đợi tác vụ như gửi email, xử lý ảnh.
• Kafka: log phân tán chỉ ghi nối, message được giữ theo thời gian cấu hình, consumer tự quản lý offset nên đọc lại được. Thứ tự chỉ đảm bảo trong từng partition. Hợp với event streaming, thông lượng lớn, nhiều consumer group.

Lưu ý khi dùng:

• Mặc định nên coi là at-least-once, nên consumer phải idempotent.
• Có dead letter queue cho message lỗi lặp lại.
• Theo dõi consumer lag.

Người phỏng vấn muốn nghe: lý do chọn gắn với nhu cầu cụ thể, không chọn Kafka chỉ vì nghe "xịn".

CAP nói rằng khi xảy ra phân mảnh mạng (Partition), hệ phân tán phải chọn giữa Consistency (mọi node trả dữ liệu mới nhất hoặc báo lỗi) và Availability (luôn trả lời, có thể bằng dữ liệu cũ). Khi mạng bình thường, trade-off thực tế là giữa độ trễ và tính nhất quán (mô hình PACELC).

• Strong consistency: cần cho số dư tài khoản, tồn kho, đặt chỗ, nơi đọc dữ liệu cũ gây thiệt hại thật.
• Eventual consistency: chấp nhận được cho lượt thích, bảng tin, số người xem, kết quả tìm kiếm.

Một hệ thống thường kết hợp cả hai theo từng loại dữ liệu. Có những mức ở giữa như read-your-writes: người vừa sửa thì phải thấy thay đổi của mình, người khác thấy chậm vài giây cũng không sao.

Hay sai: nói "chọn 2 trong 3" như thể có thể bỏ P. Với hệ phân tán, phân mảnh mạng là chuyện chắc chắn xảy ra.

Rate limiter bảo vệ hệ thống khỏi lạm dụng và quá tải, thường đặt ở API gateway hoặc middleware, đếm theo user, API key hoặc IP.

Thuật toán:

• Fixed window: đơn giản nhưng bị dồn request ở ranh giới hai cửa sổ.
• Sliding window (log hoặc counter): mượt hơn, tốn bộ nhớ hơn.
• Token bucket: cho phép burst ngắn trong giới hạn tốc độ trung bình, được dùng phổ biến.

Khi chạy nhiều instance, bộ đếm phải dùng chung, thường là Redis. Thao tác kiểm tra và tăng phải atomic (INCR kèm EXPIRE, hoặc Lua script).

Trả về HTTP 429 kèm header Retry-After.

Người phỏng vấn muốn nghe: bạn quyết định được khi Redis lỗi thì cho qua (fail-open) hay chặn (fail-closed) và giải thích lý do, đồng thời biết giới hạn riêng cho endpoint đắt như đăng nhập, gửi OTP.

Cô lập lỗi để sự cố của một phụ thuộc không lan ra toàn hệ thống (cascading failure).

• Timeout cho mọi lời gọi mạng. Thiếu timeout là nguyên nhân hàng đầu làm cạn thread hoặc connection.
• Retry có giới hạn, exponential backoff kèm jitter, và chỉ retry thao tác idempotent.
• Circuit breaker: lỗi vượt ngưỡng thì "ngắt mạch", trả lỗi nhanh trong một thời gian, sau đó thử lại dần (half-open).
• Bulkhead: tách pool thread hoặc connection theo từng phụ thuộc.
• Fallback / graceful degradation: trả dữ liệu cache, ẩn tính năng phụ thay vì lỗi cả trang.
• Load shedding: từ chối bớt request khi quá tải để bảo vệ phần còn lại.

Hay sai: retry ở nhiều tầng cùng lúc, số request nhân lên theo cấp số và làm phụ thuộc đang yếu chết hẳn (retry storm).

Tránh two-phase commit giữa các service; thay vào đó dùng Saga kết hợp Outbox pattern.

• Saga: chuỗi transaction cục bộ, mỗi bước có hành động bù trừ nếu bước sau thất bại (vd. đặt hàng → giữ tồn kho → thanh toán; thanh toán lỗi thì hoàn tồn kho, huỷ đơn). Có hai kiểu: choreography (các service phản ứng theo event) và orchestration (một service điều phối, dễ theo dõi hơn khi luồng dài).
• Transactional outbox: ghi thay đổi nghiệp vụ và event vào bảng outbox trong cùng một transaction DB, sau đó tiến trình riêng hoặc CDC đẩy event lên broker. Cách này tránh tình huống DB đã lưu mà event bị mất.
• Consumer phải idempotent (lưu id message đã xử lý) vì event có thể đến nhiều lần.

Người phỏng vấn muốn nghe: bạn chấp nhận eventual consistency và thiết kế trạng thái trung gian rõ ràng cho người dùng, vd. đơn ở trạng thái "đang xử lý".

Tách phần nhận yêu cầu khỏi phần gửi qua hàng đợi, và tách riêng từng kênh để kênh này lỗi không ảnh hưởng kênh khác.

• Notification service nhận yêu cầu, kiểm tra cài đặt và tuỳ chọn tắt thông báo của người dùng, render template, rồi đẩy vào queue theo kênh.
• Worker theo kênh gọi nhà cung cấp (FCM/APNs, email, SMS), retry có backoff, chuyển message lỗi vĩnh viễn sang dead letter queue.
• Ưu tiên: OTP, giao dịch dùng queue riêng, không bị kẹt sau chiến dịch marketing gửi hàng loạt.
• Chống trùng: idempotency key cho mỗi thông báo.
• Giới hạn: rate limit theo nhà cung cấp và theo người dùng; tôn trọng khung giờ yên lặng.
• Lưu trạng thái gửi, mở, lỗi để theo dõi và xử lý token thiết bị hết hạn.

Người phỏng vấn muốn nghe: bạn ước lượng được lưu lượng lúc cao điểm và nêu cách scale worker theo độ dài hàng đợi.

Cần đủ ba nguồn tín hiệu được liên kết với nhau: metrics, logs, traces.

• Metrics: theo phương pháp RED cho service (Rate, Errors, Duration với p95, p99) và USE cho tài nguyên. Cảnh báo dựa trên SLO (vd. tỉ lệ lỗi, độ trễ) thay vì CPU đơn thuần.
• Logs có cấu trúc (JSON), kèm trace_id và request_id để lọc toàn bộ log của một request qua nhiều service.
• Distributed tracing với OpenTelemetry: thấy request đi qua những service nào, chậm ở đoạn nào.
• Dashboard theo từng service, ghi nhận các lần deploy để đối chiếu với thời điểm lỗi.

Khi có sự cố: ưu tiên khôi phục (rollback, tắt feature flag) trước, tìm nguyên nhân gốc sau, rồi viết postmortem không đổ lỗi cá nhân.

Người phỏng vấn muốn nghe: một sự cố thật bạn từng tham gia và điều đã cải thiện sau đó.

Quyết định kiến trúc là chọn trade-off dựa trên ràng buộc thực tế (nghiệp vụ, đội ngũ, ngân sách, thời gian), không phải chọn công nghệ "tốt nhất".

• Xác định các thuộc tính chất lượng quan trọng nhất (hiệu năng, sẵn sàng, bảo mật, chi phí, khả năng thay đổi) và sắp xếp ưu tiên cùng stakeholder.
• Đưa ra 2–3 phương án, so sánh rủi ro; làm POC hoặc spike cho điểm chưa chắc chắn.
• Ghi lại bằng ADR (Architecture Decision Record): bối cảnh, quyết định, phương án đã loại, hệ quả. Lưu cùng repo để người sau hiểu "vì sao".
• Phân biệt quyết định khó đảo ngược (chọn DB, ranh giới service) với quyết định dễ thay đổi; quyết định dễ đảo ngược thì nên làm nhanh.
• Xem lại quyết định khi bối cảnh thay đổi.

Người phỏng vấn muốn nghe: bạn thuyết phục đội ngũ bằng dữ liệu, lắng nghe phản biện, và kể được một quyết định từng sai cùng cách bạn sửa.

"Yes, I have a couple of questions. First, could you tell me what a typical week looks like for this role? And second, what are the biggest challenges the team is facing right now? I'd also like to know how you measure success for someone in this position during the first three months."

Mẹo: chuẩn bị sẵn 2–3 câu, dùng mẫu lịch sự "Could you tell me…?", "I'd like to know…". Đừng trả lời "No, I don't". Câu hỏi về chế độ, phúc lợi nên để dành cho buổi nói chuyện với HR.

Chọn điểm yếu thật, không chí mạng với vị trí, và cho thấy bạn đang cải thiện.

Cấu trúc: điểm yếu, ảnh hưởng đã gặp, việc bạn đang làm để khắc phục, tiến bộ đến nay.

Câu mẫu: "Trước đây em hay ngại hỏi khi bị kẹt, tự loay hoay quá lâu, có lần làm trễ task. Giờ em tự đặt giới hạn: kẹt quá một hai giờ mà không có hướng thì em hỏi đồng đội, kèm những gì đã thử. Từ khi làm vậy em xong việc đúng hạn hơn và học được nhanh hơn từ người khác."

Ví dụ khác có thể dùng: chưa quen nói trước đám đông, tiếng Anh nói chưa trôi chảy, hay ôm việc.

Hay sai: "Điểm yếu của em là quá cầu toàn" (nghe như né câu hỏi), hoặc nêu điểm yếu là kỹ năng cốt lõi của vị trí.