EngineeringSenior DeveloperInterview Sessions

Interview Answers - Phase 4: Azure & DevOps (System Design)

7 min read10 lessons in this module

Bộ trả lời phân tích Trade-off cho việc lựa chọn "Đúng hàng - Đủ xài - Đúng lúc" trên môi trường Cloud, hạn chế việc over-engineering.

1. Cloud Architecture & Compute

Câu 1: Chọn Host cho Background Job 10 phút

  • Trả lời:
    • Azure Functions (Consumption Plan): BỌ BỎ QUA. Quá trễ và Timeout mặc định là 5 phút (Max nhích lên được 10 phút). Rủi ro job bị ngắt ngang xương khi đang chạy là rất lớn. Tốt nhất cho short-lived logic (resizing ảnh, push mail).
    • Azure App Service (WebJobs): Tốt nếu đã có sẵn 1 cái App Service Plan (Trưng dụng CPU RAM rảnh chéo sang). Bật tính năng Always On. Nhược điểm: Khó scale độc lập cái Job mà ko ảnh hưởng API chính.
    • Azure Container Apps (ACA - Jobs): LỰA CHỌN TỐT NHẤT. Hỗ trợ Serverless Jobs theo cơ chế KEDA (Kubernetes Event-driven Autoscaling). Chỉ run khi có 1 Job sinh ra, xong 10 phút tự diệt Container về số 0 $\implies$ Pay-per-use chuẩn xác mà ko bị giới hạn Timeout như Function.

Câu 2: Scale-out lag và Peak Traffic (Đỉnh tải)

  • Trả lời: Cảnh huống Scale-out (Thêm máy) cần 3-5 phút provisioning. Server bị ngập lụt trước khi máy mới kịp khởi động.
  • Giải pháp Architect: Áp dụng mô hình Queue-Based Load Leveling (Hồ điều hòa).
    1. API Gateway (YARP hoặc Azure API Management) không gọi thẳng xuống App Service.
    2. Gateway hoặc một Lightweight API đặt ở Edge chỉ làm đúng 1 việc nhanh như chớp: Nhận Body Reuqest $\to$ Quăng vào Azure Service Bus Queue $\to$ Return HTTP 202 Accepted cho User. Giao diện báo: "Đơn hàng đang xử lý, sẽ thông báo sau".
    3. App Service (Worker) bây giờ đóng vai trò Consumer chầm chậm rút Queue ra xử lý. Dù hàng triệu request đến tấp nập, Queue sẽ phình to ra (chứa tạm) để bảo vệ DB và App Service ko bị chìm nghỉm. Scale out dần lên và xử lý hết Queue.

2. Messaging & Integration

Câu 3: Service Bus vs Event Grid vs Event Hubs

  • Trả lời:
    • Service Bus (Pull): Hệ thống tin nhắn High-Value (Giao dịch tài chính, Order). Yêu cầu Transaction đàng hoàng, cam kết giao đủ (At-least-once hoặc Exactly-once).
    • Event Grid (Push): Trọng tâm là Reactive Programming ("Sự kiện báo trạng thái"). Vd: Azure Blob đẩy thông báo "Có file ảnh vừa tải lên", Trigger 1 Http Webhook. Pay-per-event. Cực kỳ lightweight.
    • Event Hubs (Stream): Big Data Pipeline. Bơm Log, Telemetry ngập lụt (1 triệu events/s). Không quan tâm logic rút ra rút lại từng cái, mà chỉ Streaming tuần tự theo thời gian vào DataLake/Stream Analytics. ($\to$ CHỌN CÁI NÀY cho bài toán IoT Telemetry).

Câu 4: Session Id vs Dead-letter Queue (Race Condition)

  • Trả lời:
    • Use Case Session Id (Banking): Giao dịch trừ tiền T1 (-$100) và T2 (-$50) của tài khoản Bob vào Queue. Nếu có 2 Consumers (Worker) rút ngẫu nhiên, T2 bị rút trước T1, tài khoản Bob (hiện tại $100) trừ T2 còn $50, sau đó trừ T1 âm lủng đáy báo lỗi (Race condition thứ tự).
    • Gắn SessionId = "Bob" cho 2 tin nhắn đó. Service Bus tháo khoá (Lock) toàn bộ tin nhận có chữ "Bob" dồn cho DUY NHẤT 1 Worker Thread xử lý tuần tự (FIFO) $\to$ Giải quyết bài toán Race Condition cấp độ Cluster.
    • DLQ Dealing: Lỗi logic code khiến T1 rớt xuống Dead-letter. Cách xử lý ko mất thứ tự:
      1. Worker Alert cho Admin.
      2. Admin xem Logs, fix code, Deploy lại Worker.
      3. Trả ngược (Requeue) Message T1 đó đưa trở lại Queue chính.
      4. Lúc này có thể T2, T3 cũng đã bị rớt DLQ do dính lỗi tương tự hoặc do T1 kẹt $\implies$ Replay Bulk tuần tự nguyên lô đó, Session Lock sẽ đảm bảo nó chạy lại y như thứ tự gốc.

3. Database & Storage Strategy

Câu 5: Rời bỏ Azure SQL sang Cosmos DB (NoSQL)

  • Trả lời:
    • Lý do rời: Dữ liệu có cấu trúc thay đổi liên tục nhưng cực nhiều (Ví dụ: IoT Sensor Metadata mỗi nhà sản xuất trả JSON 1 kiểu). Yêu cầu Latency đọc Write < 10ms trên Toàn Cầu (Global Distribution). SQL Server Replicate đa lục địa chịu độ trễ R/W quá khó khăn.
    • Cosmos DB & Partition Key sai lầm: RU/s biểu thị Tốc độ Đọc/Ghi CPU RAM mướn. Cosmos chia dữ liệu vật lý (Physical Storage) thành nhiều tủ dựa trên Partition Key.
    • Nếu chọn key là TenantId mà 90% traffics dồn vào 1 Tenant là một Cty khổng lồ (Hot Partition) $\implies$ RU/s của riêng cái Tủ (Phân mảnh) đó bốc cháy, chạm ngưỡng Rate Limiting, 429 Error, trong khi các tủ khác trống trơn (Tài nguyên lãng phí trầm trọng). Phải chọn Key có độ phân tán cao (High Cardinality) như DeviceId hay kết hợp Compound Key.

Câu 6: Data Pipeline Data Warehouse Siêu Thị

  • Giải pháp Architect:
    1. (Ingestion Realtime mỏng): 500 cửa hàng gõ API/Event, hạ cánh vào Azure SQL / Cosmos tạm thời (Operational DB).
    2. Azure Data Factory (ADF) đóng vai trò Orchestator. Lập lịch Trigger lúc 12h đêm.
    3. ADF cẩu toàn bộ Log Data mới của hôm nay ném lưu trữ vào Data Lake (Azure Blob Storage gen 2). Định dạng Parquet (nén cột cực rẻ). Việc này (EL = Extract Load) chạy rất lẹ và ko làm chết Operational DB.
    4. ADF gọi Azure Databricks (Spark). Databricks lôi cái đóng Parquet đó lên RAM, nhào nặn (T=Transform), tính toán Lợi nhuận hàng ngày.
    5. Đổ kết quả khối (DataMart) vào Azure Synapse Analytics hoặc nhả ra bảng Report để PowerBI mút lên $\implies$ Tối ưu Costs (Lưu trữ rác lạnh nằm ở Blob Lake rẻ rề, Tính toán nặng đẩy vào Databricks Pay-per-minute).

4. DevOps & Observability

Câu 7: Aspire vs docker-compose.yml

  • Trả lời:
    • Aspire nhúng vào mã C# (viết bằng C#). Compose viết bằng YAML.
    • Tính năng lõi builder.AddProject() thay vì Developer phải hardcode localhost:5001, localhost:5002. Aspire tự động tiêm Endpoint URI qua các biến môi trường tại Runtime mà ko cần Config. Tự chích (Auto-Instrument) Opentelemetry (Trace/Log/Metrics) đẩy ra cái Dashboard Console có sẵn quá đẹp dẽ gỡ lỗi tại Local.
    • Azure Deployment: Aspire sinh ra lệnh azd up. Dịch toàn bộ System C# đó thành file Bicep hạ tầng IaC đẩy bay thẳng lên Azure Container Apps chỉ bằng 1 câu lệnh, Cắm Auto-scaling tự động. Docker-compose không dịch native sang Azure trơn chu tới vậy (thường phải config lại ra YAML Manifest của cụm K8s thủ công mỏi tay).

Câu 8: Disaster Recovery - RPO=0, RTO=15m

  • Giải pháp Architect (RPO=0 & RTO=15m): Yêu cầu CẮT KHE KHẮT RPO=0 nghĩa là Bắt Buộc Replication Đồng Bộ (Synchronous Commit).
    • Không thể Active-Active (Xung nhịp Clock, Consistency Xuyên lục địa Sing - HK sẽ cho ra Latency >30ms mỗi transaction, làm sập băng thông và hiệu năng).
    • Mô hình Active-Passive với Failover Group:
      1. Hạ Tầng Web: Triển khai 2 cụm AppService tại Sing và HK. Front-face dùng Azure Front Door (Traffic Manager). Trỏ DNS 100% Traffic vào Sing (Active). HK ở trạng thái Warm Standby.
      2. Database: Dùng Azure SQL Database Auto-Failover Group. Chọn Node HK Replicate Synchronous. Tín hiệu Ghi lệnh tiền vào Sing sẽ đợi confirm ghi qua HK mới báo OK (Đánh đổi Latency để lấy RPO=0). Cả 2 được bọc bằng 1 Connection String chung.
      3. Sing sập mảng Network? Front Door theo dõi Health Check Probe Sing xịt 3 lần (60 giây), lập tức đổi DNS Route vè HK (RTO khoảnh khắc, RPO 100% bảo lưu do Đồng bộ realtime hoàn hảo).