Trắc nghiệm Backend Core — 38 câu có đáp án và giải thích

Đáp án: A

GET, PUT và DELETE là idempotent: lặp lại lời gọi không làm trạng thái khác đi so với gọi một lần. POST thì không — mỗi lần gọi sinh thêm một bản ghi. PATCH tuỳ nội dung: đặt status = "paid" là idempotent, còn cộng thêm 10 vào số dư thì không. Tính chất này quyết định client có được phép retry an toàn khi mạng lỗi hay không.

Đáp án: D

201 Created, kèm header Location trỏ tới tài nguyên mới và thường kèm cả body chứa bản ghi vừa tạo. 200 dùng cho đọc hoặc cập nhật có trả nội dung, 204 cho thao tác thành công mà không trả body, còn 202 chỉ dành cho việc đã nhận nhưng chưa xử lý xong.

Đáp án: B

SHA-256 sinh ra để chạy nhanh, nên một GPU thử được hàng tỉ tổ hợp mỗi giây. bcrypt và Argon2 có tham số chi phí điều chỉnh được và tự sinh salt riêng cho mỗi bản ghi, khiến việc dò trở nên đắt và vô hiệu hoá bảng tra sẵn. Argon2 còn tốn nhiều bộ nhớ, thứ mà GPU không nhân bản rẻ được.

Đáp án: C

Atomicity nghĩa là transaction được nhìn như một đơn vị không chia nhỏ: hoặc toàn bộ lệnh có hiệu lực, hoặc không lệnh nào có hiệu lực. Nhờ đó luồng chuyển tiền không bao giờ dừng ở trạng thái đã trừ tài khoản nguồn mà chưa cộng tài khoản đích, dù ứng dụng crash ngay giữa chừng.

Đáp án: D

Index là một cấu trúc sắp xếp riêng giúp database tìm hàng mà không phải quét cả bảng. Đổi lại, mỗi lần insert, update hay delete phải cập nhật thêm cấu trúc đó, và nó chiếm dung lượng. Vì vậy chỉ đánh index cho cột thực sự xuất hiện trong điều kiện lọc, join hoặc sắp xếp.

Đáp án: B

Queue tách thời điểm nhận việc khỏi thời điểm làm việc. Request trả về ngay sau khi ghi việc vào queue, nên độ trễ không còn phụ thuộc nhà cung cấp email. Nếu bên đó lỗi, worker thử lại theo lịch thay vì làm hỏng luôn thao tác đăng ký của người dùng.

Đáp án: B

Log có cấu trúc biến mỗi dòng thành dữ liệu có trường rõ ràng, nên hệ thống thu thập lọc và tổng hợp được ngay: đếm lỗi theo endpoint, xem mọi dòng của một request, cảnh báo khi độ trễ vượt ngưỡng. Log ghép chuỗi buộc phải bóc tách bằng regex, và mọi thay đổi câu chữ là một lần vỡ.

Đáp án: A

Giao diện chỉ là một trong nhiều cách gọi API: bất kỳ ai cũng gửi request thẳng bằng công cụ dòng lệnh. Validate ở client là để phản hồi nhanh cho người dùng, còn validate ở server mới là ràng buộc thật sự bảo vệ dữ liệu. Thiếu lớp thứ hai thì mọi quy tắc nghiệp vụ đều có thể bị vượt qua.

Đáp án: C

PUT mang ý nghĩa thay thế toàn bộ: body là trạng thái đầy đủ mà tài nguyên phải có sau lời gọi, nên field bị bỏ sót sẽ thành rỗng. PATCH chỉ mô tả phần thay đổi và giữ nguyên phần còn lại. Bug hay gặp là dùng PUT với form chỉ có vài field và vô tình xoá trắng các field không hiển thị.

Đáp án: D

401 nghĩa là danh tính chưa được xác lập: thiếu token, token sai chữ ký hoặc đã hết hạn — client nên refresh hoặc đăng nhập lại. 403 nghĩa là danh tính đã rõ nhưng tài khoản này không được phép làm việc đó — đăng nhập lại vô ích. Trả nhầm sẽ đẩy người dùng vào vòng lặp đăng nhập.

Đáp án: B

Client sinh một Idempotency-Key cho mỗi ý định thanh toán và gửi kèm mọi lần retry. Server lưu key đó cùng kết quả trong một bảng có ràng buộc unique: key mới thì xử lý bình thường, key đã có thì trả nguyên phản hồi cũ. Nhờ vậy một lần bấm nút luôn ứng với đúng một giao dịch, dù mạng có lỗi bao nhiêu lần.

Đáp án: D

OFFSET 100000 buộc database đọc rồi vứt bỏ 100.000 hàng, nên trang càng sâu càng chậm. Nó còn lệch dữ liệu: một bản ghi mới chèn vào đầu danh sách sẽ đẩy phần tử cuối trang 1 sang trang 2, khiến người dùng thấy trùng hoặc mất bản ghi. Cursor neo vào giá trị của hàng cuối nên tránh được cả hai.

Đáp án: B

Breaking change nên được triển khai theo kiểu mở rộng rồi thu hẹp: thêm field mới bên cạnh field cũ, ghi cả hai, để client chuyển dần, rồi mới gỡ field cũ khi số liệu cho thấy không còn ai gọi. Bump version cả API chỉ xứng đáng khi phải đổi nhiều thứ cùng lúc.

Đáp án: C

JWT tự chứa cho phép mọi service kiểm tra chữ ký mà không cần tra store, đổi lại là không thu hồi được: khoá tài khoản lúc 10 giờ nhưng token cấp lúc 9 giờ 55 vẫn chạy tới khi hết hạn. Session ở server thì ngược lại — xoá một dòng là mất quyền ngay, nhưng mỗi request phải đọc store.

Đáp án: C

Access token xuất hiện trong mọi lời gọi, đi qua log, proxy và code phía client, nên xác suất lộ cao — vòng đời ngắn giới hạn thiệt hại. Refresh token chỉ gửi tới đúng một endpoint, có thể để trong cookie HttpOnly với path hẹp, nên sống dài mà vẫn kiểm soát được và có thể thu hồi bất cứ lúc nào.

Đáp án: B

Token trong localStorage bị bất kỳ script nào trên trang đọc được, nên một lỗ XSS là mất token. Cookie HttpOnly thì JavaScript không chạm tới, nhưng trình duyệt tự gửi kèm mọi request nên phải chống CSRF bằng SameSite và token chống giả mạo. Thực tế cookie HttpOnly kèm Secure và SameSite là lựa chọn mặc định tốt hơn.

Đáp án: D

Đây là lỗi phân quyền theo đối tượng: hệ thống xác thực xong rồi coi như xong, không hỏi tiếp đơn hàng này có thuộc về người gọi hay không. Cách sửa là gắn điều kiện chủ sở hữu ngay trong truy vấn, ví dụ where id = ? and user_id = ?, chứ không lọc sau khi đã đọc lên.

Đáp án: D

Đếm theo phút cố định có khe hở ở ranh giới: 100 request vào giây cuối phút này cộng 100 request vào giây đầu phút sau là 200 request trong hai giây mà vẫn hợp lệ. Token bucket nạp token đều theo thời gian và cho phép tiêu một lượng dự trữ, nên vừa chịu được burst hợp lý vừa giữ đúng tốc độ trung bình.

Đáp án: C

Bạn lấy 50 bài viết bằng một truy vấn, rồi vòng lặp gọi thêm một truy vấn cho tác giả của từng bài: tổng cộng 51 lần đi lại database. Cách sửa là gom id lại và lấy tất cả tác giả trong một truy vấn dùng in, hoặc dùng join. Với GraphQL thì gộp theo lô bằng DataLoader trong cùng một request.

Đáp án: A

Index gộp giống danh bạ sắp theo họ rồi mới tới tên: tìm theo họ, hoặc theo họ kèm tên đều nhanh, nhưng tìm mọi người tên "An" mà không biết họ thì phải lật cả quyển. Truy vấn chỉ dùng được index khi nó phủ từ cột đầu tiên trở đi, gọi là quy tắc tiền tố bên trái.

Đáp án: C

Mỗi kết nối chiếm bộ nhớ và một đơn vị xử lý ở phía database, nên vượt quá khả năng của máy thì mọi truy vấn cùng chậm đi thay vì chỉ một số phải chờ. Pool giới hạn số truy vấn chạy song song và xếp hàng phần còn lại — hàng đợi có kiểm soát luôn tốt hơn là làm database tranh chấp tài nguyên.

Đáp án: D

Đây là race condition kiểu đọc rồi ghi. Cách rẻ và chắc nhất là không mang giá trị về ứng dụng để tính: viết update accounts set balance = balance - 30 where id = ? and balance >= 30, rồi kiểm tra số hàng bị ảnh hưởng để biết có đủ số dư hay không. Database khoá hàng trong lúc update nên hai lệnh tự nối tiếp.

Đáp án: A

Transaction giữ khoá cho tới lúc commit, nên một lời gọi mạng chậm biến thành khoá kéo dài, kết nối trong pool bị chiếm và deadlock dễ xảy ra hơn. Ngoài ra rollback không rút lại được thứ đã gửi đi: email đã bay, tiền đã trừ ở cổng thanh toán, còn dữ liệu trong database thì quay về như cũ.

Đáp án: A

Cache-aside: ứng dụng hỏi cache trước, trúng thì trả luôn; trượt thì đọc database, ghi kết quả vào cache kèm TTL rồi trả về. Đường ghi thì cập nhật database và xoá key liên quan, để lần đọc kế tiếp tự nạp lại. Ưu điểm là chỉ dữ liệu thực sự có người đọc mới chiếm chỗ trong cache.

Đáp án: A

Xoá đúng những key liên quan ngay trong đường ghi, và giữ TTL vừa phải làm lưới an toàn cho các nhánh ghi bị bỏ sót hoặc thay đổi đến từ bên ngoài. Đọc nhiều ghi ít là trường hợp lý tưởng: chi phí xoá gần như không đáng kể, còn tỉ lệ trúng vẫn cao suốt phần lớn thời gian.

Đáp án: A

Key thiếu định danh tenant nên toàn hệ thống dùng chung một ô nhớ: tenant A nạp trước thì tenant B đọc trúng dữ liệu của A. Đây là rò rỉ dữ liệu chứ không đơn thuần là bug hiển thị. Key phải chứa mọi yếu tố làm kết quả khác nhau — tenant, người dùng, ngôn ngữ, tham số lọc và phiên bản schema.

Đáp án: B

Dịch vụ lỗi thường vì quá tải, nên hàng nghìn client thử lại ngay lập tức sẽ giữ nó ở trạng thái sập. Backoff giãn dần khoảng chờ để nhường không gian hồi phục, còn jitter làm lệch pha các client để chúng không cùng quay lại một lúc và tạo ra đợt sóng thứ hai.

Đáp án: D

Một dịch vụ không trả lời mà không có timeout sẽ giữ kết nối và tài nguyên của bên gọi vô thời hạn. Chỉ vài phút là pool cạn, hàng đợi đầy, và một sự cố ở dịch vụ phụ lan thành sự cố toàn hệ thống. Timeout biến "treo mãi mãi" thành một lỗi rõ ràng để xử lý.

Đáp án: D

At-least-once nghĩa là message chắc chắn đến nhưng có thể đến nhiều lần: worker xử lý xong rồi chết trước khi ack thì broker giao lại. Consumer phải idempotent — thường bằng cách lưu id message đã xử lý với ràng buộc unique, hoặc viết thao tác dưới dạng đặt trạng thái thay vì cộng dồn.

Đáp án: C

Một message không bao giờ xử lý được — sai định dạng, tham chiếu tới bản ghi đã xoá — sẽ thất bại rồi quay lại queue mãi mãi và chặn những message phía sau. Sau vài lần thử, broker chuyển nó sang dead letter queue để luồng chính chạy tiếp, còn con người thì có chỗ để xem xét.

Đáp án: B

Queue là mô hình chia việc: nhiều worker cùng rút, mỗi việc chỉ một worker nhận, thêm worker là xử lý nhanh hơn. Pub/sub là mô hình phát tin: mỗi subscriber nhận một bản sao, nên "đơn hàng đã tạo" có thể đồng thời kích hoạt gửi email, cập nhật kho và ghi nhận số liệu mà bên phát không cần biết ai đang nghe.

Đáp án: A

Một hành động của người dùng đi qua nhiều dịch vụ và sinh ra log ở nhiều nơi. Correlation id được sinh ở cửa ngõ, truyền theo header xuống mọi lời gọi và ghi vào mọi dòng log, nhờ đó một lần lọc là dựng lại được toàn bộ đường đi thay vì đoán theo mốc thời gian.

Đáp án: D

Log được đọc bởi nhiều người, đồng bộ sang dịch vụ giám sát bên thứ ba và giữ lại hàng tháng. Ghi nguyên body nghĩa là mật khẩu, token và số thẻ nằm rải rác ở những nơi không có kiểm soát truy cập tương xứng. Phải lọc theo danh sách trường được phép và che phần còn lại ngay tại tầng ghi log.

Đáp án: D

Liveness trả lời "tiến trình này còn cứu được không" — hỏng thì nền tảng khởi động lại. Readiness trả lời "lúc này có nên gửi request tới đây không" — hỏng thì chỉ bị rút khỏi danh sách nhận tải rồi quay lại khi khoẻ. Nhầm hai cái sẽ khiến một sự cố tạm thời của database làm khởi động lại toàn bộ dịch vụ.

Đáp án: A

Backend chỉ cấp một URL có chữ ký và thời hạn ngắn, còn dữ liệu đi thẳng từ trình duyệt tới object storage. Server ứng dụng không phải nhận 500 MB, không giữ kết nối suốt nhiều phút và không cần đĩa tạm. Khi tải xong, client báo lại để backend ghi nhận và bắt đầu xử lý.

Đáp án: C

Tính lại chữ ký HMAC trên đúng body thô rồi so sánh bằng hàm chống rò rỉ theo thời gian; kiểm tra mốc thời gian trong header để chặn phát lại; và lưu id sự kiện đã xử lý để lần giao lại không cộng tiền hai lần. Endpoint webhook là cửa công khai, mọi thứ đi vào đều phải coi là không tin cậy.

Đáp án: C

Nhận yêu cầu, tạo bản ghi công việc, đẩy vào queue và trả 202 kèm id cùng đường dẫn kiểm tra trạng thái. Client hỏi định kỳ hoặc nhận thông báo khi xong, rồi tải kết quả qua một URL riêng. Giữ kết nối ba phút là đặt cược vào proxy, trình duyệt và mạng của người dùng.

Đáp án: C

Giá trị bí mật nạp lúc chạy từ biến môi trường hoặc từ một secret manager, còn repository chỉ chứa file mẫu liệt kê tên biến. Nhờ vậy mỗi môi trường có giá trị riêng, việc thay khoá không cần triển khai lại code, và lịch sử commit không bao giờ lưu giá trị thật.