Phỏng vấn dev truyền kỳ #2: Session – Cơ chế quan trọng trong mô hình client-server

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 bài trước, chúng ta đã cùng “giải mã” câu hỏi sắp xếp mảng – một “điểm liệt” bất ngờ với nhiều bạn Fresher/Junior. Hôm nay, chúng ta sẽ tiếp tục với một câu hỏi phỏng vấn khác, thường xuyên xuất hiện trong các buổi phỏng vấn dev backend, và nó liên quan đến một cơ chế quan trọng trong mô hình client-server: Session.

Lucas rất hay hỏi câu hỏi về cơ chế Session này khi phỏng vấn IT các vị trí backend. Tại sao ư? Bởi vì nó thực sự phơi bày gần như tất cả những gì cơ bản nhất của mô hình client-server nói chung và lập trình web backend nói riêng. Có thể nói, nếu bạn nắm vững cơ chế Session, bạn hoàn toàn có thể tự tin rằng mình đã “nằm lòng” những điều quan trọng nhất liên quan đến việc kiểm soát trạng thái trong mô hình client-server.

Một điểm thuận lợi là hầu hết tất cả các công nghệ làm backend hiện nay đều hỗ trợ sẵn cơ chế Session ở các mức độ khác nhau. Từ PHP truyền thống đến các framework hiện đại của .NET hay Java, Python, Node.js… đều có cách để làm việc với Session một cách dễ dàng. Tuy nhiên, việc sử dụng được không đồng nghĩa với việc hiểu rõ bản chất của nó.

Kịch Bản Phỏng Vấn Về Session – 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ấp độ 1: Biết chưa?

Lucas: Chào bạn, chúng ta cùng trao đổi một chút về kiến thức backend nhé. Bạn đã bao giờ làm việc hoặc tìm hiểu về cơ chế Session trong các ứng dụng web chưa?

(Nếu ứng viên trả lời “chưa”, cuộc trao đổi về Session có thể dừng lại ở đây hoặc chỉ đi rất cơ bản.)

Ứng viên: Dạ, em có tìm hiểu và cũng có sử dụng Session trong các dự án của mình rồi ạ.

Cấp độ 2: Dùng chưa?

Lucas: Tốt quá. Vậy theo bạn, chúng ta sử dụng Session để làm gì trong các ứng dụng web? Mục đích chính của nó là gì?

(Mình muốn xem ứng viên có hiểu vai trò của Session trong việc quản lý trạng thái không.)

Ứng viên: Dạ, Session dùng để lưu trữ thông tin về trạng thái của người dùng trong suốt quá trình họ tương tác với ứng dụng, ví dụ như trạng thái đăng nhập, các mục trong giỏ hàng, hoặc các tùy chọn cá nhân ạ.

Cấp độ 3: Dữ liệu trạng thái lưu ở đâu?

Lucas: Chính xác! Session giúp duy trì trạng thái giữa các request không trạng thái của giao thức HTTP. Vậy những dữ liệu Session đó thường được lưu trữ ở đâu? Ở phía trình duyệt của người dùng hay ở phía máy chủ (server) của ứng dụng?

(Câu hỏi đi sâu hơn vào nơi lưu trữ dữ liệu.)

Ứng viên: Dạ, dữ liệu Session thường được lưu trữ ở phía backend, trên máy chủ ạ.

Cấp độ 4: Cơ chế định danh

Lucas: Rất đúng. Session data nằm ở server. Giả sử có hai người dùng cùng truy cập vào website và đều có Session data lưu trên server. Làm sao ứng dụng phân biệt được đâu là Session data của người dùng A và đâu là của người dùng B khi họ gửi request lên? Tại sao không bị nhầm lẫn giữa hai người?

(Câu hỏi kiểm tra hiểu biết về cơ chế phân biệt Session.)

Ứng viên: Dạ, server sẽ tạo ra một mã định danh duy nhất cho mỗi Session, gọi là Session ID. Session ID này sẽ được gửi về cho trình duyệt của người dùng. Mỗi khi người dùng gửi request tiếp theo, trình duyệt sẽ đính kèm Session ID này lên server. Server dựa vào Session ID nhận được để tìm đúng Session data tương ứng của người dùng đó ạ.

Lucas: Rất tốt. Và Session ID đó thường được lưu trữ và gửi đi bằng cách nào phổ biến nhất trong môi trường web?

Ứng viên: Dạ, thường là thông qua Cookie của trình duyệt ạ.

Cấp độ 5: Đảm bảo làm chủ vấn đề

Lucas: Chính xác! Hiểu được cơ chế này là rất quan trọng. Bây giờ, một câu hỏi khó hơn một chút nhé. Nếu không dùng cơ chế Session có sẵn mà các framework cung cấp, bạn có tự nghĩ ra cách để xây dựng một cơ chế quản lý trạng thái tương tự Session không? Bạn sẽ làm nó như thế nào?

(Câu hỏi kiểm tra khả năng tư duy và thiết kế hệ thống cơ bản.)

Ứng viên: Dạ, em nghĩ là có thể làm được ạ. Về cơ bản, mình sẽ cần tạo ra một ID duy nhất cho mỗi người dùng khi họ bắt đầu phiên làm việc. ID này sẽ được lưu trữ ở phía client (ví dụ, trong Cookie hoặc Local Storage). Ở phía server, mình sẽ cần một nơi để lưu trữ dữ liệu trạng thái tương ứng với mỗi ID đó, có thể là trong bộ nhớ, file, hoặc database. Mỗi khi nhận request từ client, mình sẽ đọc ID từ request, dùng ID đó để lấy dữ liệu trạng thái tương ứng từ nơi lưu trữ ở server và xử lý logic dựa trên trạng thái đó ạ.

Cấp độ 6: Mở rộng

Lucas: Rất mạch lạc. Quay lại chuyện lưu trữ Session data. Nếu chúng ta chọn lưu Session data vào file system trên server, bạn thấy phương án này có điểm bất lợi lớn nào khi triển khai ứng dụng thực tế không?

(Câu hỏi về triển khai và scaling.)

Ứng viên: Dạ, bất lợi lớn nhất là khi mình triển khai ứng dụng trên nhiều máy chủ (multiple instances) phía sau một Load Balancer. Khi đó, request của cùng một người dùng có thể đi đến các máy chủ khác nhau. Nếu Session data chỉ được lưu trên file system của từng máy chủ riêng lẻ, thì máy chủ nhận request có thể không tìm thấy Session data của người dùng đó, dẫn đến việc mất trạng thái, ví dụ như người dùng bị đăng xuất đột ngột ạ.

Cấp độ 7: Mở rộng hơn

Lucas: Chính xác! Đó là vấn đề lớn khi scale ứng dụng. Vậy theo bạn, đâu là những lựa chọn lưu trữ Session data tốt hơn trong môi trường phân tán, và ưu nhược điểm của từng lựa chọn đó là gì? Nên lưu vào file, database, hay dịch vụ lưu trữ khác?

(Câu hỏi về phân tích và lựa chọn giải pháp.)

Ứng viên: Dạ, thay vì lưu vào file, mình có thể lưu vào các hệ thống lưu trữ tập trung mà tất cả các máy chủ ứng dụng đều có thể truy cập được. Phổ biến nhất là lưu vào database (SQL hoặc NoSQL như MongoDB) hoặc các dịch vụ cache phân tán như Redis, Memcached. Lưu vào database thì dễ quản lý và bền vững, nhưng có thể chậm hơn. Lưu vào Redis hoặc Memcached thì rất nhanh, phù hợp cho việc đọc/ghi Session thường xuyên, nhưng cần cân nhắc về tính bền vững nếu dịch vụ đó gặp sự cố. Lựa chọn cụ thể sẽ phụ thuộc vào yêu cầu về hiệu năng, tính sẵn sàng và chi phí của ứng dụng ạ.

Lucas: Rất tốt! Cảm ơn bạn về những chia sẻ vừa rồi.

Tại Sao Nhiều Bạn Fresher/Junior Lại “Vấp” Ở Đây?

Các bạn thấy đó, một vấn đề tưởng chừng đơn giản như cơ chế Session lại có thể được khai thác để kiểm tra ứng viên ở nhiều trình độ khác nhau trong buổi phỏng vấn dev. Vậy tại sao nhiều bạn Fresher/Junior lại thường không nắm rõ về nội dung quan trọng này?

Thiếu người chỉ dẫn:

Giống như nhiều kiến thức nền tảng khác, nếu thiếu người hướng dẫn hoặc chương trình học không chú trọng, các bạn có thể bỏ qua hoặc chỉ biết Session một cách hời hợt.

Chỉ làm và hài lòng với kết quả, không đào sâu “tại sao”:

Nhiều bạn khi làm bài tập hoặc dự án, chỉ cần sử dụng Session theo hướng dẫn và thấy nó chạy được là dừng lại. Thiếu đi sự tò mò, không đặt câu hỏi “Tại sao nó lại hoạt động như vậy?”, “Dữ liệu lưu ở đâu?”, “Làm sao để phân biệt các người dùng khác nhau?”…

“Nhảy cóc” sang các công nghệ mới:

Với sự phát triển nhanh chóng của công nghệ, nhiều bạn có xu hướng bỏ qua các kiến thức nền tảng như Session để nhảy thẳng vào làm việc với API sử dụng JWT (JSON Web Token) hoặc các cơ chế xác thực/ủy quyền khác. Mặc dù JWT rất phổ biến hiện nay, việc hiểu về Session vẫn là cực kỳ quan trọng để nắm vững nguyên lý quản lý trạng thái trong mô hình client-server.

Lời Kết

Hiểu rõ cơ chế Session không chỉ giúp bạn trả lời tốt câu hỏi phỏng vấn IT mà còn xây dựng nền tảng vững chắc cho sự nghiệp lập trình của mình. Nó giúp bạn hiểu cách các ứng dụng web duy trì trạng thái người dùng, cách server xử lý các request từ nhiều client cùng lúc, và cách các công nghệ backend làm việc “trong chiếc hộp đen”. Để 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 dành thời gian tìm hiểu sâu hơn về những khái niệm cơ bản này nhé. Chúng có vẻ đơn giản, nhưng lại là chìa khóa để bạn tiến xa hơn trong con đường lập trình. Chết thật, Lucas đã tiết lộ hết ra đây rồi, nhưng đừng có lo, Lucas còn nhiều kịch bản phỏng vấn khác hay hơn nữa đấy.

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