CDN hoạt động thế nào và khi nào nên dùng?
CDN là mạng máy chủ edge đặt gần người dùng, cache nội dung tĩnh (ảnh, JS, CSS, video) để giảm latency và tải cho origin. Khi cache miss, edge lấy từ origin rồi lưu theo TTL/Cache-Control. Có thể mở rộng cho nội dung động, chống DDoS, TLS.
Chọn SQL hay NoSQL cho hệ thống?
SQL (quan hệ) mạnh về schema chặt, JOIN, ACID transaction: hợp dữ liệu có quan hệ, cần nhất quán (tài chính, đơn hàng). NoSQL (document, key-value, wide-column, graph) ưu tiên scale ngang, schema linh hoạt, truy vấn theo pattern biết trước. Chọn theo access pattern, không theo mốt.
Horizontal scaling và vertical scaling khác nhau thế nào?
Vertical scaling (scale up) nâng cấu hình một máy: đơn giản nhưng có trần và là single point of failure. Horizontal scaling (scale out) thêm nhiều máy sau load balancer: gần như không giới hạn và chịu lỗi tốt, nhưng cần service stateless và xử lý dữ liệu phân tán.
Load balancer: L4 vs L7 và các thuật toán phân phối
L4 cân bằng ở tầng TCP/UDP theo IP và port: nhanh, không đọc nội dung. L7 hiểu HTTP nên định tuyến theo URL, header, cookie, có thể terminate TLS. Thuật toán phổ biến: round robin, weighted, least connections, IP hash; kèm health check để loại node lỗi.
Message queue dùng để làm gì? Khi nào nên dùng?
Queue tách producer và consumer: xử lý bất đồng bộ, chịu tải đột biến (buffer), retry khi lỗi và scale consumer độc lập. Đổi lại hệ thống phức tạp hơn và dữ liệu eventual consistent.
Monolith hay microservices: đánh đổi là gì?
Monolith là một khối deploy: đơn giản, dễ debug, giao dịch cục bộ nhưng khó scale từng phần và dễ rối khi lớn. Microservices tách theo bounded context, deploy và scale độc lập, nhưng thêm độ phức tạp mạng, dữ liệu phân tán, observability. Nên bắt đầu monolith module hoá.
Observability: log, metrics và tracing
Ba trụ cột: log (sự kiện chi tiết, tìm nguyên nhân), metrics (số liệu tổng hợp theo thời gian, dùng cho dashboard và alert), trace (theo một request đi qua nhiều service). Dùng correlation/trace id nối ba loại, và alert theo triệu chứng (SLO) thay vì nguyên nhân.
Rate limiting: token bucket và các thuật toán khác
Rate limiting giới hạn số request mỗi client theo thời gian để chống lạm dụng. Token bucket: xô chứa tối đa N token, nạp r token/giây, mỗi request lấy một token; cho phép burst. Các lựa chọn khác: leaky bucket, fixed window, sliding window log/counter.
Xác thực: session, JWT, OAuth2 và SSO khác nhau thế nào?
Session lưu trạng thái ở server, client giữ session id trong cookie: dễ thu hồi nhưng cần kho chia sẻ. JWT là token tự chứa đã ký, server không lưu trạng thái nhưng khó thu hồi. OAuth2 là giao thức uỷ quyền truy cập; OpenID Connect thêm xác thực danh tính, nền tảng của SSO.
Caching: các chiến lược và vấn đề cần lưu ý?
Cache-aside (app tự đọc/ghi cache), write-through, write-back. Khó nhất là invalidation, kèm các vấn đề cache stampede, penetration và dữ liệu cũ (stale).
CAP theorem là gì?
Khi hệ thống phân tán gặp network partition, bạn chỉ chọn được một: Consistency (mọi node thấy cùng dữ liệu) hoặc Availability (luôn trả lời). Partition không thể tránh nên thực tế là chọn CP hay AP.
Circuit breaker, retry và exponential backoff
Retry xử lý lỗi tạm thời nhưng phải có giới hạn, exponential backoff kèm jitter, và chỉ với thao tác idempotent. Circuit breaker ngắt gọi dịch vụ lỗi (closed, open, half-open) để fail nhanh và tránh sập dây chuyền. Luôn đặt timeout cho mọi cuộc gọi mạng.
Database replication, sharding và consistent hashing
Replication sao chép dữ liệu sang nhiều node để tăng đọc và chịu lỗi (có replication lag). Sharding chia dữ liệu theo shard key sang nhiều node để scale ghi và dung lượng. Consistent hashing đặt node và key lên một vòng hash, thêm hoặc bớt node chỉ di chuyển khoảng K/N key.
Idempotency key, eventual consistency và saga
Thao tác idempotent cho cùng kết quả dù gọi nhiều lần: client gửi Idempotency-Key, server lưu key và kết quả để trả lại khi retry. Với giao dịch xuyên nhiều service, saga chia thành chuỗi giao dịch cục bộ, mỗi bước có compensating action để hoàn tác, hệ thống nhất quán dần (eventual consistency).
Thiết kế dịch vụ rút gọn URL (URL shortener)
Mỗi URL dài ánh xạ tới mã ngắn (base62, 7 ký tự cho khoảng 3.5 nghìn tỷ mã). Sinh mã bằng bộ đếm phân tán (ID generator) mã hoá base62 để tránh trùng. Ghi ít, đọc rất nhiều nên lưu key-value và cache Redis; redirect bằng HTTP 301 hoặc 302.