Đáp án Quiz System Design — 74 câu hỏi có giải thích

Đáp án: D

Đọc cache trước; miss thì đọc DB, ghi kết quả vào cache kèm TTL, rồi trả về. Chỉ dữ liệu được yêu cầu thật mới vào cache — đơn giản và tiết kiệm, nên là mẫu mặc định.

Đáp án: B

Qua queue. Việc cốt lõi (ghi đơn hàng) và việc phụ (gửi mail) phải tách nhau: user nhận phản hồi ngay, mail được gửi bởi worker và retry được nếu SMTP lỗi. Đơn hàng không nên thất bại chỉ vì mail lỗi.

Đáp án: C

Buộc một user vào một instance cụ thể: instance chết là mất phiên, deploy làm user bị đăng xuất, và tải lệch vì instance nào có nhiều user "dính" thì nặng hơn. Cách đúng là làm ứng dụng stateless.

Đáp án: A

Tách hai loại. Liveness: tiến trình còn chạy và không treo → fail thì restart. Readiness: đã kết nối được DB, cache, đã nạp cấu hình → fail thì rút khỏi load balancer nhưng không restart.

Đáp án: A

N+1 query: 1 truy vấn lấy danh sách, rồi 50 truy vấn lấy dữ liệu liên quan cho từng dòng. Sửa bằng JOIN, hoặc nạp trước theo lô: lấy hết id rồi một truy vấn WHERE order_id IN (...).

Đáp án: D

Quay lại hàng đợi và thử lại có giới hạn (kèm backoff), quá N lần thì chuyển vào dead-letter queue để người vận hành xem. Hai đầu cực đoan đều sai: bỏ luôn thì mất việc, thử vô hạn thì tắc.

Đáp án: A

Các mối quan tâm chung ở biên: kết thúc TLS, xác thực token, rate limit, định tuyến, ghi log truy cập, đôi khi cả gộp response. Nhờ đó service phía sau chỉ tập trung vào nghiệp vụ của nó.

Đáp án: C

Hàng đợi tách rời bên gửi khỏi bên xử lý: request trả về ngay sau khi ghi thông điệp, việc nặng chạy nền. Nó cũng hấp thụ đợt tải tăng đột biến — thông điệp xếp hàng chờ thay vì làm bên xử lý quá tải.

Đáp án: C

Bên xử lý phải idempotent: xử lý cùng một thông điệp hai lần phải cho kết quả như xử lý một lần. Điều này xảy ra khi bên xử lý hoàn tất nhưng xác nhận bị mất, nên hệ thống giao lại thông điệp đó.

Đáp án: D

Hợp khi thời gian xử lý chênh lệch nhiều: chia đều theo lượt sẽ tiếp tục gửi request mới vào máy đang xử lý các request dài. Chia theo số kết nối đang mở phản ánh tải thực tế tốt hơn trong tình huống đó.

Đáp án: C

Vì khoá được ánh xạ tới một node cố định, mọi truy cập tới nó dồn vào node đó và thêm node vào cụm cũng không chia tải được. Cách xử lý: nhân bản khoá thành nhiều bản, hoặc cache ở tầng ứng dụng để phần lớn truy cập không ra tới cụm.

Đáp án: B

SLI là chỉ số đo được (tỷ lệ request thành công, độ trễ ở phân vị 99). SLO là mục tiêu nội bộ cho chỉ số đó (99,9% trong 30 ngày). SLA là cam kết với khách hàng kèm hậu quả nếu vi phạm — thường đặt lỏng hơn SLO để có biên an toàn.

Đáp án: D

BFF là một lớp riêng cho mỗi loại client: web, di động, đối tác. Mỗi lớp gộp dữ liệu từ các dịch vụ và trả về đúng hình dạng client đó cần. Cổng API chung thì phục vụ mọi client bằng một tập endpoint và tập trung vào xác thực, định tuyến, giới hạn tần suất.

Đáp án: C

Nó trả lời câu hỏi dịch vụ X đang chạy ở những địa chỉ nào. Instance được tạo và huỷ liên tục trong môi trường co giãn, nên danh sách địa chỉ phải được cập nhật động thay vì ghi cứng trong cấu hình.

Đáp án: D

Phải có cảnh báo khi có thông điệp vào, quy trình điều tra nguyên nhân, và công cụ để xử lý lại sau khi sửa hoặc bỏ có chủ đích với lý do được ghi lại. Hàng đợi lỗi không ai xem chỉ là nơi dữ liệu biến mất im lặng.

Đáp án: D

Bloom filter trả lời câu hỏi tồn tại với đặc tính không bao giờ báo thiếu: nếu nó nói không có thì chắc chắn không có, còn nếu nói có thì có thể sai. Dùng để tránh một lượt tra cứu tốn kém khi phần lớn câu trả lời là không tồn tại.

Đáp án: C

Ngang là thêm máy và chia tải giữa chúng — không có trần cứng và có sẵn khả năng chịu lỗi, nhưng đòi hỏi ứng dụng không giữ trạng thái cục bộ. Dọc là tăng cấu hình một máy — đơn giản nhất nhưng chạm trần phần cứng và máy đó vẫn là điểm hỏng đơn lẻ.

Đáp án: A

Vì mọi instance tương đương: request nào cũng xử lý được ở bất kỳ máy nào, nên cân bằng tải tự do phân phối, thêm hoặc bớt máy không làm ai mất phiên, và một máy hỏng chỉ ảnh hưởng các request đang dở.

Đáp án: A

Bốn tầng thường có: trình duyệt (tài nguyên tĩnh), CDN (nội dung dùng chung, gần người dùng), tầng ứng dụng (kết quả truy vấn, dữ liệu tính toán), và cơ sở dữ liệu (bộ đệm trang, kế hoạch truy vấn). Cache càng gần người dùng thì càng tiết kiệm nhiều.

Đáp án: C

Không có độ lệch ngẫu nhiên, mọi client gặp lỗi cùng lúc sẽ thử lại cùng lúc, tạo ra các đợt tải dồn đúng vào lúc dịch vụ đang cố hồi phục. Thêm phần ngẫu nhiên vào khoảng chờ khiến các lần thử rải đều theo thời gian.

Đáp án: D

Retry ngay và dày sẽ dồn thêm tải vào service vốn đang quá tải, biến sự cố nhỏ thành sập kéo dài. Cần exponential backoff + jitter: mỗi lần chờ lâu hơn, cộng một khoảng ngẫu nhiên để nhiều client không đồng loạt retry cùng lúc.

Đáp án: A

Idempotency key: client sinh một khoá duy nhất cho mỗi ý định thanh toán, gửi kèm request. Server lưu (key → kết quả); request sau cùng key trả về kết quả cũ mà không trừ tiền lần nữa.

Đáp án: C

Trước cả replica: kiểm tra index và truy vấn chậm — phần lớn "DB quá tải" là vài truy vấn thiếu index. Sau đó thêm read replica cho tải đọc, và cache cho các truy vấn lặp lại. Sharding là bước cuối.

Đáp án: D

Chặn lỗi lan truyền: khi service phụ thuộc lỗi liên tục, breaker mở ra và fail ngay lập tức thay vì để mỗi request chờ timeout. Nhờ đó thread pool không bị chiếm hết và service của bạn còn phục vụ được các luồng khác.

Đáp án: C

DB vẫn phải đi qua rồi loại bỏ 100000 dòng trước khi lấy 20 dòng cần — thời gian tăng theo độ sâu trang. Dùng cursor/keyset: WHERE (created_at, id) < (:lastCreatedAt, :lastId) ORDER BY created_at DESC, id DESC LIMIT 20.

Đáp án: A

SSE: một chiều server→client trên HTTP thường, browser tự reconnect và tự gửi Last-Event-ID để tiếp tục từ chỗ đứt. Đơn giản hơn WebSocket, đi qua proxy và CDN dễ hơn.

Đáp án: A

Presigned URL: server xác thực rồi phát một URL có thời hạn, client PUT thẳng lên S3/R2. Server không bao giờ giữ 500MB trong bộ nhớ hay băng thông, và upload không bị giới hạn thời gian request.

Đáp án: A

DB riêng cho mỗi service (database per service). DB chung là cái bẫy phổ biến nhất: hai service cùng đọc ghi một bảng thì đổi schema phải deploy đồng thời — bạn có đủ chi phí của microservices mà không có lợi ích deploy độc lập.

Đáp án: B

Cả hai tầng. Gateway đặt giới hạn chung theo IP/token để chặn lạm dụng sớm; service đặt thêm giới hạn cho endpoint đắt (xuất báo cáo, gọi model AI, gửi mail). Một tầng duy nhất luôn thiếu một trong hai góc nhìn.

Đáp án: D

Đặt tường minh, dựa trên p99 đo được cộng một khoảng dự phòng — không dựa vào mặc định, vì nhiều HTTP client mặc định chờ vô hạn. Không có timeout là nguyên nhân phổ biến nhất của việc lỗi lan từ service này sang service khác.

Đáp án: A

Với JSON riêng theo user thì không cache chung được, nhưng CDN vẫn hữu ích: kết thúc TLS ở điểm gần người dùng (giảm thời gian bắt tay), giữ kết nối sẵn tới origin, và chặn tấn công ở biên. Phần cache thật chỉ áp dụng cho dữ liệu dùng chung.

Đáp án: B

Ký tự đại diện ở đầu chuỗi làm index B-tree vô dụng — DB phải quét toàn bảng mỗi lần tìm. Với Postgres thì dùng tsvector + index GIN; ngoài ra pg_trgm cho tìm gần đúng.

Đáp án: A

Canary: chuyển dần traffic (1% → 10% → 50% → 100%), quan sát chỉ số ở từng mức. Blue-green: dựng môi trường mới song song rồi chuyển toàn bộ traffic một lần, rollback bằng cách trỏ lại môi trường cũ.

Đáp án: C

Để DB làm trọng tài. Cách gọn nhất là UPDATE có điều kiện: UPDATE seats SET remaining = remaining - 1 WHERE id = ? AND remaining > 0 rồi kiểm tra số dòng bị ảnh hưởng — 0 dòng nghĩa là hết vé. Hoặc SELECT ... FOR UPDATE để khoá bản ghi trong transaction.

Đáp án: D

Chọn khoá tăng dần: số tự tăng, hoặc UUID v7 nếu cần id sinh ở phía client. UUID v4 ngẫu nhiên làm mỗi lần chèn rơi vào một chỗ khác trong B-tree, gây phân mảnh và ghi nhiều page hơn.

Đáp án: C

Chữ ký (HMAC của raw body với secret). Đây là bước không được bỏ: thiếu nó thì bất kỳ ai biết endpoint đều gửi được request báo "đã thanh toán". Sau khi chữ ký hợp lệ mới đối chiếu số tiền và trạng thái đơn.

Đáp án: C

Khoá phân tán: mỗi lần đến giờ, instance nào giành được khoá (SET key NX EX ttl trong Redis, hoặc advisory lock trong Postgres) thì chạy, còn lại bỏ qua. Cách sạch hơn nữa là tách scheduler ra ngoài app.

Đáp án: B

Tổng lên tới 1000 kết nối trong khi DB chỉ nhận 200 — dưới tải cao sẽ lỗi "too many connections". Pool phải tính theo tổng: số instance × pool ≤ giới hạn, trừ đi phần dành cho migration và công cụ quản trị.

Đáp án: C

Trace id (correlation id): sinh ở điểm vào, truyền qua header ở mọi lời gọi nội bộ, và ghi vào mọi dòng log. Có nó thì một câu truy vấn theo trace id dựng lại được toàn bộ hành trình.

Đáp án: A

Thiếu graceful shutdown: tiến trình nhận SIGTERM rồi thoát ngay, bỏ dở request đang xử lý. Luồng đúng: nhận SIGTERM → báo readiness fail để LB rút traffic → chờ request hiện tại xong → đóng kết nối → thoát.

Đáp án: A

Thay đổi cộng thêm: thêm field mới, giữ field cũ trả về song song, đánh dấu deprecated, theo dõi xem còn ai dùng, rồi mới gỡ. Chỉ ra phiên bản mới khi thay đổi thật sự không thể tương thích.

Đáp án: D

Phân vị: p50 cho trải nghiệm điển hình, p95/p99 cho phần đuôi. Trung bình che mất đúng phần cần biết — với 1 triệu request/ngày thì "chỉ 1% chậm" vẫn là 10.000 lần người dùng phải chờ.

Đáp án: A

Hỏi nghiệp vụ trước: dữ liệu cũ bao lâu thì còn chấp nhận được? Giá sản phẩm có thể chỉ chịu được vài giây, còn danh mục thì vài giờ. Kết hợp TTL với việc xoá cache khi dữ liệu thay đổi.

Đáp án: B

Mặc định chung DB, cột tenant_id trên mọi bảng: một lần migration cho tất cả, một chỗ giám sát. Tách riêng khi có lý do cụ thể — yêu cầu tuân thủ dữ liệu, tenant lớn cần tài nguyên riêng.

Đáp án: C

Vì JWT được xác thực bằng chữ ký chứ không tra cứu, nên server không có cách vô hiệu hoá một token đã phát. Cho nó sống ngắn để cửa sổ bị lạm dụng nhỏ; refresh token lưu ở server nên thu hồi được ngay.

Đáp án: B

Mỗi truy vấn phải thêm WHERE deleted_at IS NULL — quên một chỗ là dữ liệu đã xoá hiện lại. Ngoài ra ràng buộc unique không còn đúng: email của user đã xoá vẫn chặn người khác dùng lại email đó.

Đáp án: C

Load shedding: từ chối sớm một phần request (429/503) để phần còn lại được phục vụ đúng hạn. Nhận hết rồi ai cũng timeout là kết quả tệ nhất — tốn tài nguyên mà không ai nhận được kết quả.

Đáp án: C

Hai nghi phạm chính: replication lag (đọc từ replica chưa có dữ liệu mới) và cache chưa xoá. Cả hai đều vi phạm "read your own writes" — người vừa ghi phải thấy được dữ liệu của chính mình.

Đáp án: B

Nó giải quyết tình huống ghi database thành công nhưng phát sự kiện thất bại (hoặc ngược lại). Sự kiện được ghi vào một bảng outbox trong cùng transaction với dữ liệu nghiệp vụ; một tiến trình riêng đọc bảng đó và gửi ra ngoài, xoá sau khi gửi xong.

Đáp án: A

Điều phối tập trung: một thành phần biết toàn bộ luồng và gọi từng service theo thứ tự — dễ theo dõi và dễ sửa luồng, nhưng thành phần đó trở thành điểm tập trung. Theo chuỗi sự kiện: mỗi service phản ứng với sự kiện của service trước — ghép nối lỏng hơn nhưng không ai nhìn thấy toàn bộ luồng.

Đáp án: A

Back-pressure là cơ chế để bên nhận báo ngược cho bên gửi giảm tốc khi không xử lý kịp. Không có nó, bộ đệm phình ra tới khi cạn bộ nhớ, hoặc thông điệp bị mất — cả hai đều tệ hơn việc chủ động chậm lại.

Đáp án: B

Ghép ba phần: dấu thời gian (cho thứ tự), định danh máy sinh (tránh trùng giữa các máy), và bộ đếm trong cùng mili giây. Đây là cấu trúc của các thuật toán sinh id kiểu snowflake, và cũng là ý tưởng của UUID v7.

Đáp án: C

Cập nhật chỉ mục bất đồng bộ qua sự kiện thay đổi: ghi database rồi phát sự kiện (dùng outbox hoặc change data capture), một tiến trình riêng cập nhật chỉ mục. Chấp nhận độ trễ vài giây và có cơ chế đồng bộ lại toàn bộ khi cần.

Đáp án: D

Dùng mô hình kết hợp: với tài khoản thường thì đẩy bài vào dòng thời gian của người theo dõi ngay khi đăng; với tài khoản có rất nhiều người theo dõi thì không đẩy, mà trộn vào lúc người dùng đọc. Đây là cách các mạng xã hội lớn xử lý.

Đáp án: B

Kết nối gắn với một máy chủ cụ thể, nên khi cần gửi tin cho một người dùng, hệ thống phải biết họ đang ở máy nào. Cách xử lý: một lớp phát tin nội bộ (Pub/Sub) để mọi máy đều nhận được thông điệp và gửi cho các kết nối nó đang giữ.

Đáp án: B

Chiến lược thường dùng là lấy mẫu theo kết quả: giữ toàn bộ trace của request lỗi hoặc vượt ngưỡng độ trễ, và lấy một tỷ lệ nhỏ trace bình thường để có mốc so sánh. Quyết định giữ được đưa ra sau khi trace hoàn tất.

Đáp án: C

Không nên tách khi đội còn nhỏ và ranh giới nghiệp vụ chưa rõ. Tách sai ranh giới tạo ra các dịch vụ phải thay đổi cùng nhau — gánh toàn bộ chi phí của hệ phân tán mà không được lợi ích triển khai độc lập.

Đáp án: C

Với cách chia theo phép lấy dư, đổi số node làm gần như mọi khoá đổi vị trí. Consistent hashing xếp node và khoá lên một vòng băm, nên thêm hoặc bớt một node chỉ khiến khoảng một phần N số khoá phải chuyển — phần còn lại giữ nguyên.

Đáp án: C

Nó bảo đảm tập node đọc và tập node ghi giao nhau: nếu ghi cần W node xác nhận và đọc hỏi R node, với R + W > N thì luôn có ít nhất một node vừa nhận bản ghi vừa được hỏi — nên lần đọc thấy được giá trị mới nhất.

Đáp án: C

Các cấu trúc dữ liệu hợp nhất được (CRDT) cho phép gộp cả hai thay đổi mà không mất bên nào, vì mọi thứ tự áp dụng đều cho cùng kết quả. Cách "giữ bản mới hơn" đơn giản hơn nhưng luôn hy sinh một bên và phụ thuộc đồng hồ giữa các máy.

Đáp án: B

Ba thứ tối thiểu: thử lại có backoff khi endpoint đối tác lỗi; ký thông điệp để đối tác xác minh nguồn gốc; và lưu lịch sử gửi để tra cứu khi có tranh chấp. Kèm theo là cơ chế tạm dừng endpoint hỏng lâu để không lãng phí tài nguyên.

Đáp án: C

Hai vấn đề trung tâm: khử trùng (cùng một sự kiện không gửi hai lần, và các sự kiện liên quan nên được gộp) và tôn trọng tuỳ chọn người dùng theo từng loại thông báo và từng kênh. Gửi quá nhiều là cách nhanh nhất khiến người dùng tắt toàn bộ thông báo.

Đáp án: A

Dùng độ sâu hàng đợi hoặc tuổi của thông điệp cũ nhất. Hai chỉ số này cho biết worker có theo kịp không, trong khi CPU có thể rất thấp nếu worker chủ yếu chờ phản hồi từ dịch vụ khác.

Đáp án: D

Theo lô đơn giản hơn, dễ xử lý lại khi logic thay đổi, và rẻ hơn với khối lượng lớn. Theo luồng cho kết quả trong vài giây thay vì vài giờ, đổi lại phải xử lý trạng thái, cửa sổ thời gian và dữ liệu tới muộn — những thứ làm hệ thống phức tạp hơn hẳn.

Đáp án: D

Dùng giảm độ phân giải theo tuổi: giữ dữ liệu từng giây trong vài ngày, gộp thành từng phút cho vài tháng, từng giờ cho vài năm, rồi xoá. Kết hợp với phân mảnh theo thời gian để việc xoá dữ liệu cũ chỉ là thao tác xoá một phân mảnh.

Đáp án: B

Đặt hạn mức theo từng khách hàng ở tầng cổng và cách ly tài nguyên cho các thao tác nặng. Đây là vấn đề hàng xóm ồn ào, và cách xử lý gốc rễ là bảo đảm không ai chiếm được phần vượt quá mức đã phân bổ.

Đáp án: D

Chỉ khi đã đo được rằng truy vấn đọc là điểm nghẽn và các cách rẻ hơn đã thử: thêm index, viết lại truy vấn, thêm cache. Phi chuẩn hoá đánh đổi bằng chi phí ghi và nguy cơ dữ liệu lệch nhau giữa các bản sao.

Đáp án: B

Hai tiêu chí chính: mẫu truy vấn (đọc theo khoá, theo khoảng, tìm kiếm toàn văn, tổng hợp) và yêu cầu nhất quán của nghiệp vụ. Sau đó mới tới các yếu tố thực dụng: đội có kinh nghiệm vận hành không, và hệ thống hiện tại đã có sẵn gì.

Đáp án: C

Hai cách đều hợp lý: xử lý bất đồng bộ sau khi tải lên (sự kiện kích hoạt worker tạo các kích thước cần), hoặc tạo theo yêu cầu lần đầu rồi cache ở CDN. Điều quan trọng là không xử lý ảnh trong chính request của người dùng.

Đáp án: B

Dùng phát theo luồng thích ứng: video được mã hoá ở nhiều mức chất lượng và cắt thành các đoạn vài giây; client đo tốc độ mạng và chọn mức phù hợp cho từng đoạn. Nhờ đó video vẫn chạy liên tục khi mạng thay đổi.

Đáp án: A

Dùng hàng đợi riêng cho từng mức ưu tiên, mỗi hàng đợi có worker được phân bổ riêng. Cách này bảo đảm việc gấp không xếp sau hàng nghìn việc thường, và một loại công việc bị dồn ứ không chiếm hết năng lực của loại kia.

Đáp án: D

Dùng con trỏ dựa trên giá trị: trang sau lấy các bản ghi có giá trị nhỏ hơn dòng cuối của trang trước, kèm một cột phá vỡ trùng để thứ tự luôn xác định. Cách này không bị lệch khi có bản ghi mới chèn vào giữa các lần lật trang.

Đáp án: A

Băm định danh người dùng cùng với tên của tính năng, rồi lấy phần dư để phân nhóm. Cách này cho kết quả xác định: cùng một người luôn rơi vào cùng nhóm ở mọi request và mọi thiết bị, và các tính năng khác nhau phân nhóm độc lập với nhau.

Đáp án: A

Đây là vấn đề đọc thấy thứ mình vừa ghi: thao tác ghi vào bản chính nhưng lần đọc kế tiếp lại đi vào một bản sao chưa nhận được thay đổi. Cache ở tầng ứng dụng hoặc CDN cũng gây hiện tượng tương tự.