Phỏng vấn dev truyền kỳ #3: ACID – Chống xung đột một tài nguyên

Chào mừng các bạn quay trở lại với series phỏng vấn lập trình cùng Lucas!

Trong các bài trước, chúng ta đã cùng “mổ xẻ” những câu hỏi phỏng vấn cơ bản nhưng quan trọng trong phỏng vấn dev như sắp xếp mảng và cơ chế Session. Hôm nay, chúng ta sẽ đi sâu vào một vấn đề thực tế hơn một chút, thường gặp trong lập trình backend khi nhiều người dùng cùng thao tác trên một tài nguyên chung: Chống xung đột một tài nguyên.

Đây là một kịch bản phỏng vấn IT mà Lucas rất thích sử dụng, bởi nó không chỉ kiểm tra kiến thức nền tảng về database và các khái niệm như ACID, mà còn phơi bày khả năng tư duy và giải quyết vấn đề của ứng viên qua nhiều cấp độ.

Kịch Bản Phỏng Vấn – Lucas Sẽ Dẫn Chuyện Như Thế Nào?

Khi phỏng vấn, mình thường bắt đầu bằng một câu hỏi mở và dựa vào câu trả lời của ứng viên để đi sâu hơn qua các cấp độ khác nhau. Ở từng cấp độ, tùy theo khả năng của ứng viên mà các câu hỏi sẽ xoay quanh để kiểm tra thêm các kỹ năng khác của bạn. Sau đây là một kịch bản giả định về cuộc trò chuyện giả định hoàn hảo mà Lucas thường mong đợi:

Cảnh 1: Tư duy và khả năng giải quyết vấn đề

Lucas: Chào bạn, chúng ta cùng thảo luận một chút về một tình huống thực tế nhé. Giả sử bạn đang làm một trang quản trị đơn giản cho website, có các chức năng thêm, bớt, sửa bài viết. Bây giờ, có một yêu cầu mới: tại một thời điểm bất kỳ, đối với cùng một bài viết, chỉ có duy nhất một người admin được phép mở trang chỉnh sửa (edit) bài viết đó. Nếu có admin khác cố gắng mở trang edit của bài viết đang có người làm việc, họ sẽ nhận được thông báo kiểu như “Bài viết này đang có người chỉnh sửa, bạn vui lòng chờ người đó làm xong đã.” Theo bạn, chúng ta sẽ làm thế nào để triển khai tính năng này?

(Đây là câu hỏi mở để kiểm tra tư duy ban đầu của ứng viên.)

• Nếu ứng viên không có ý tưởng gì: Tình huống này hơi khó nói. Mình sẽ cố gắng gợi ý thêm hoặc chuyển sang chủ đề khác phù hợp hơn với kinh nghiệm của bạn.
• Nếu ứng viên trả lời được hoàn hảo ngay lập tức: Rất tốt! Điều này chứng tỏ bạn đã có kinh nghiệm xử lý bài toán tương tự hoặc đã tìm hiểu rất kỹ về vấn đề này. Bạn có thể đã “trúng tủ” rồi đấy. Mình sẽ chuyển sang các cấp độ cao hơn để đánh giá sâu hơn tùy theo mức độ tự tin và kinh nghiệm bạn thể hiện.
• Nếu ứng viên đưa ra giải pháp logic thông thường: Ví dụ, bạn nói: “Em sẽ thêm một trường (field) vào bảng bài viết, đặt tên là is_editing chẳng hạn, kiểu boolean. Mỗi khi có yêu cầu mở trang edit một bài viết, em sẽ kiểm tra trường này. Nếu is_editing đang là false, em sẽ cập nhật nó thành true và cho phép người dùng vào trang edit. Ngược lại, nếu nó đang là true, em sẽ hiển thị thông báo ‘Có người đang edit’.”Nếu bạn trả lời được như vậy, thì về mặt logic cơ bản, bạn đã nắm khá ổn cách tiếp cận vấn đề. Lúc này, chúng ta có thể chuyển qua cấp độ tiếp theo.

Cảnh 2: Xác nhận rõ bạn đã chú ý đến ACID hay chưa

Lucas: Cách tiếp cận dùng trường is_editing nghe có vẻ hợp lý. Vậy bạn làm thế nào để đảm bảo rằng khi kiểm tra is_editing và cập nhật nó thành true, sẽ không có hai người cùng lúc “lọt” qua được bước kiểm tra và cùng vào trang edit? Bạn có thấy sơ hở nào ở đây không?

(Mình muốn xem ứng viên có nhận ra vấn đề race condition (điều kiện tranh chấp) và tầm quan trọng của tính Atomic trong ACID không.)

• Nếu ứng viên không hiểu ý: Mình sẽ gợi ý rõ hơn: “Sơ hở ở đây ý là có khả năng có 2 người cùng kiểm tra is_editing và thấy nó đều là false cùng một lúc không?” Nếu bạn vẫn chưa nghĩ ra được, Lucas sẽ cố gắng gợi ý thêm, sẽ làm chậm quá trình đọc và ghi database – ví dụ database bị chậm và query đọc và ghi mất vài giây mới xong một query chẳng hạn. Vì các bạn thường nghĩ db đọc ghi nhanh kinh khủng sao mà bị lỗi gì được.
• Thường các bạn có tư duy tốt: Sẽ nhận ra ngay vấn đề race condition và nói rằng giữa bước kiểm tra và bước cập nhật có một khoảng thời gian nhỏ, đủ để người thứ hai cũng kiểm tra và thấy false trước khi người thứ nhất kịp cập nhật thành true.
• Nếu bạn tự tin vào giải pháp và nói thêm: “Em có chú ý đến tính Atomic (Nguyên tố) trong database rồi, nên em sẽ dùng transaction để đảm bảo hai thao tác kiểm tra và cập nhật này diễn ra như một đơn vị không thể chia cắt, và em đã thiết lập chế độ lock phù hợp để đảm bảo 2 transaction không “đan” vào nhau.” -> Perfect! Bạn đã thể hiện sự hiểu biết sâu sắc.

Cảnh 3: Thử khả năng giải quyết vấn đề

Nếu ứng viên thể hiện tư duy tốt, nhưng lại chưa có kinh nghiệm xử lý race condition. Đây là lúc hỏi phần này.

Lucas: Đúng vậy, vấn đề race condition có thể xảy ra, và nếu không xử lý cẩn thận, cách của bạn có khả năng cho phép nhiều người cùng lọt vào trang edit. Vậy với kinh nghiệm và tất cả kiến thức về lập trình và database bạn có, có bất cứ cách nào khác để xử lý tình huống chống xung đột một tài nguyên này một cách hiệu quả và đáng tin cậy hơn không?

(Câu hỏi này đẩy ứng viên suy nghĩ về các giải pháp khả dĩ, có thể dựa trên các tính năng của database.)

• Cũng rất khó nói: Thường đến đây, nhiều bạn sẽ gặp khó khăn và không nghĩ ra được giải pháp ngay lập tức.

Cảnh 4: Bẻ lái qua một chủ đề khác tương tự

Lucas: Đừng lo lắng nếu chưa nghĩ ra ngay. Chúng ta thử chuyển sang một tình huống quen thuộc hơn nhé. Bạn đã bao giờ làm tính năng đăng ký người dùng chưa? Bạn làm thế nào để đảm bảo rằng không có hai người dùng nào đăng ký với cùng một địa chỉ email?

(Câu hỏi này gợi ý về việc sử dụng các ràng buộc của database.)

• Case 1: “Dạ em cũng kiểm tra thôi, trước khi thêm vào database thì em query xem email đó có tồn tại chưa.” -> Lúc này mình hiểu là bạn vẫn chưa biết hoặc chưa quen với việc sử dụng UNIQUE KEY trong database.
• Case 2: “Dạ, em sử dụng ràng buộc UNIQUE KEY trên cột email trong bảng người dùng ạ. Database sẽ tự động báo lỗi nếu có ai đó cố gắng thêm một email đã tồn tại.” -> Rất tốt! Bạn đã biết sử dụng tính năng quan trọng của database để đảm bảo tính toàn vẹn dữ liệu.

Cảnh 5: Đấy, vẫn có cách đấy thôi, bẻ lái lại câu hỏi trước đó

Lucas: Chính xác! Sử dụng UNIQUE KEY là cách rất hiệu quả để ngăn chặn dữ liệu trùng lặp ở mức database, đảm bảo tính Consistency (Nhất quán). Vậy bạn thử suy nghĩ xem, có thể áp dụng cách tương tự, dựa trên ý tưởng về UNIQUE KEY, cho câu hỏi chống xung đột một tài nguyên khi edit bài viết lúc trước không?

(Câu hỏi này gợi ý ứng viên kết nối kiến thức vừa thảo luận về UNIQUE KEY với bài toán ban đầu.)

• Nếu bạn ứng viên nảy số nhanh: Sẽ nhanh chóng nghĩ ra giải pháp: tạo một bảng tạm hoặc một bảng riêng (ví dụ: article_editing_locks) chỉ có hai cột: article_id và admin_id. Đặt ràng buộc UNIQUE KEY trên cột article_id. Khi một admin muốn edit bài viết X, ứng dụng sẽ cố gắng chèn một bản ghi { article_id: X, admin_id: Y } vào bảng này. Nếu chèn thành công, admin đó được phép edit. Nếu database báo lỗi UNIQUE KEY (vì article_id X đã tồn tại), tức là có người khác đang edit, và ứng dụng sẽ hiển thị thông báo chờ. Khi admin edit xong, bản ghi đó sẽ bị xóa đi.
• Ngược lại, nếu bạn ứng viên vẫn không nghĩ ra được giải pháp này sau gợi ý ở Cảnh 4, thì đây là một điều khá đáng tiếc cho khả năng áp dụng các mẫu giải quyết vấn đề tương tự của bạn.

Cảnh 6: Với các bạn trả lời hoàn hảo ngay từ đầu, và có kinh nghiệm

Đối với những ứng viên đã đưa ra giải pháp dựa trên UNIQUE KEY hoặc các cơ chế khóa (locking) của database ngay từ đầu, mình sẽ đào sâu hơn để đánh giá kinh nghiệm thực chiến của bạn:

• Bạn đã áp dụng nguyên lý ACID này trong các hệ thống database cụ thể nào? (MySQL, PostgreSQL, MongoDB, Redis, etc.)
• Cơ chế locking trong các database đó hoạt động thế nào? (Row-level lock, Table-level lock…)
• Làm thế nào để xử lý tình huống deadlock (nghẽn)?
• Nếu lưu trạng thái edit vào các hệ thống phân tán như Redis, bạn sẽ dùng những lệnh hay cơ chế nào để đảm bảo tính atomic và chống xung đột? (Ví dụ: SET NX, EXPIRE…)
• Cơ chế này có áp dụng được khi mình đọc ghi xử lý file không? (File locking…)

Cảnh 7: Xử lý bằng cách sử dụng Queue

Nếu ứng viên không nghĩ ra giải pháp dựa trên ACID/UNIQUE KEY nhưng lại có ý tưởng sử dụng Queue (hàng đợi) hoặc Message Broker để xử lý bài toán này (ví dụ: mỗi yêu cầu edit sẽ được đưa vào một hàng đợi, và chỉ có một worker xử lý từng yêu cầu một), Lucas sẽ hỏi thêm:

Lucas: Ý tưởng dùng Queue cũng thú vị. Nếu dùng Queue trong trường hợp này để đảm bảo chỉ một yêu cầu edit được xử lý tại một thời điểm, thì mình sẽ phải làm thêm những gì để hoàn thiện giải pháp này?

• Câu trả lời mong đợi: Ứng viên cần nói được rằng sẽ phải thêm một Message Broker (như RabbitMQ, Kafka…), cấu hình cho hàng đợi chỉ xử lý với concurrency = 1 (chỉ một worker đọc message mỗi lần), phải implement một worker (tiến trình nền) để đọc message từ queue và thực hiện logic kiểm tra/cập nhật trạng thái edit trong database. Quan trọng hơn, client gửi yêu cầu edit sẽ không nhận được phản hồi ngay lập tức. Cần implement một cơ chế chờ bất đồng bộ (polling từ client) hoặc một endpoint khác để client kiểm tra xem yêu cầu của mình đã được xử lý xong và có được phép edit hay chưa.Trả lời được vậy chứng tỏ bạn có tư duy sắp xếp vấn đề rất tốt dựa trên kiến thức về kiến trúc hệ thống phân tán, dù có thể chưa biết về các tính năng ACID của database.

Bài Học Từ Kịch Bản Phỏng Vấn Này

Các bạn có thể thấy đó, kịch bản phỏng vấn dev về bài toán chống xung đột một tài nguyên này, dù trọng tâm là các vấn đề liên quan đến ACID và cơ chế khóa của database, nhưng lại có thể cung cấp cho các bạn ứng viên nhiều bài học và cơ hội để thể hiện kỹ năng:

• Khả năng tư duy và giải quyết vấn đề: Bạn có tiếp cận bài toán một cách logic không? Có nhìn ra được các vấn đề tiềm ẩn như race condition không?
• Kiến thức nền tảng về Database: Bạn có hiểu các khái niệm quan trọng như UNIQUE KEY, Transaction, và các thuộc tính ACID không?
• Kiến thức về kiến trúc hệ thống: Bạn có biết về các giải pháp khác như Queue/Message Broker để xử lý các bài toán đồng bộ hóa trong môi trường phân tán không?
• Khả năng giao tiếp và trình bày: Bạn có thể diễn đạt ý tưởng và giải thích giải pháp của mình một cách rõ ràng không?

Tại Sao Nhiều Bạn Fresher/Junior Thường Hổng Kiến Thức Này?

Giống như câu chuyện về Session hay sắp xếp mảng, kiến thức về chống xung đột một tài nguyên và ACID cũng là một điểm yếu phổ biến ở nhiều bạn mới vào nghề trong ngành Công nghệ thông tin:

Không có người chỉ dẫn hoặc chương trình học không sâu:

Các khóa học hoặc tài liệu ban đầu có thể chỉ dạy cách sử dụng database cơ bản mà không đi sâu vào các vấn đề đồng bộ hóa hay đảm bảo tính toàn vẹn dữ liệu trong môi trường đa người dùng. Nếu thiếu người hướng dẫn phù hợp, việc tự tìm hiểu sâu có thể gặp khó khăn.

Chỉ làm theo hướng dẫn, thiếu sự tò mò “tại sao”:

Nhiều bạn chỉ quen dùng ORM và các câu lệnh SQL đơn giản mà không tìm hiểu sâu hơn về cách database hoạt động “trong chiếc hộp đen” để đảm bảo các thuộc tính ACID. Khi gặp các bài toán phức tạp hơn như chống xung đột, sẽ lúng túng.

Thiếu kinh nghiệm thực tế với hệ thống đa người dùng:

Trong các dự án cá nhân hoặc bài tập nhỏ, ít khi gặp phải tình huống nhiều người dùng thao tác cùng lúc trên cùng một tài nguyên, nên các bạn chưa có cơ hội đối mặt và tìm hiểu cách giải quyết bài toán xung đột.

Lời Kết

Bài toán chống xung đột một tài nguyên là một thử thách thú vị trong phỏng vấn IT, giúp nhà tuyển dụng đánh giá toàn diện khả năng của bạn. Việc hiểu rõ các khái niệm như ACID, giải thuật sắp xếp, và các cơ chế đồng bộ hóa không chỉ giúp bạn “ghi điểm” mà còn trang bị cho bạn những kiến thức nền tảng vững chắc để xây dựng các hệ thống phần mềm đáng tin cậy. Để trở thành một lập trình viên giỏi, việc nắm vững những kiến thức này là rất cần thiết.

Đừng ngại đối mặt với những câu hỏi khó. Hãy coi đó là cơ hội để học hỏi và thể hiện bản thân. Chúc các bạn ôn tập tốt và tự tin trong các buổi phỏng vấn dev sắp tới!

Hẹn gặp lại các bạn trong bài “Phỏng vấn truyền kỳ” tiếp theo!