Senior System Architect (Distributed Systems)

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.

RPO là lượng dữ liệu tối đa chấp nhận mất (tính theo thời gian); RTO là thời gian tối đa để khôi phục dịch vụ. Hai con số này do nghiệp vụ quyết định và định giá chiến lược.

Từ rẻ đến đắt:

• Backup & restore: sao lưu sang region khác, dựng lại khi cần; RTO hàng giờ.
• Pilot light: dữ liệu được replicate liên tục, chỉ phần lõi chạy sẵn.
• Warm standby: bản thu nhỏ chạy sẵn ở region khác, scale lên khi failover.
• Active-active: nhiều region cùng phục vụ; RTO/RPO gần 0, phức tạp nhất.

Hay sai: có backup nhưng chưa bao giờ thử khôi phục. Kế hoạch DR phải được diễn tập định kỳ.

Dùng mô hình landing zone: tách account (AWS), subscription (Azure) hoặc project (GCP) theo môi trường và team để cô lập quyền, chi phí và phạm vi sự cố.

• Quản lý tập trung bằng AWS Organizations, Azure Management Groups, GCP Organization/Folder.
• Áp guardrail ở cấp tổ chức: chặn region không dùng, bắt buộc mã hoá, cấm tắt log audit (SCP, Azure Policy, Organization Policy).
• Đăng nhập tập trung qua SSO, cấp quyền theo nhóm.
• Tài khoản riêng cho log audit và bảo mật, team ứng dụng không xoá được.
• Mạng nối qua hub (Transit Gateway, hub-spoke VNet, Shared VPC).
• Tag bắt buộc để phân bổ chi phí.

Người phỏng vấn muốn nghe: cân bằng giữa tự chủ của team và kiểm soát tập trung.

Đo trước, tối ưu chỗ tốn nhất trước. Phần lớn trường hợp nút thắt là DB và gọi mạng, không phải tốc độ của Python.

1. Đo: APM hoặc tracing (OpenTelemetry) để biết thời gian nằm ở DB, API ngoài hay code. Profile bằng py-spy (gắn vào process đang chạy) hoặc cProfile.
2. DB: xử lý N+1, thêm index phù hợp, chỉ lấy cột cần (only, values), phân trang.
3. Cache: Redis cho dữ liệu đọc nhiều, ít đổi; nhớ chiến lược invalidate.
4. Việc nặng hoặc không cần trả ngay (gửi email, xuất file): đẩy sang Celery hoặc queue.
5. Gọi nhiều API ngoài: chạy song song, đặt timeout.
6. Cuối cùng mới tới tối ưu thuật toán, hoặc đưa đoạn nặng CPU sang thư viện C hay service khác.

Hay sai: viết lại sang async hoặc đổi ngôn ngữ trước khi biết thời gian thực sự bị tiêu ở đâu.

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.

Trả lời thẳng thắn và cân bằng: sẵn sàng khi thật sự cần, nhưng không coi OT kéo dài là bình thường.

Câu mẫu: "Em sẵn sàng làm thêm khi có việc gấp như sự cố production hay trước một đợt release quan trọng. Nhưng nếu OT diễn ra thường xuyên, em nghĩ cần xem lại cách estimate hoặc phạm vi, và em sẽ chủ động nêu điều đó với team. Em cũng muốn hỏi thêm: ở team mình OT thường xảy ra trong trường hợp nào và được tính như thế nào ạ?"

Đây cũng là lúc bạn tìm hiểu ngược: OT có được trả lương hoặc nghỉ bù theo quy định không, tần suất ra sao. Câu trả lời của họ cho bạn biết nhiều về văn hoá công ty.

Hay sai: hứa "OT thoải mái" để lấy điểm, rồi vào làm mới thấy không chịu nổi.