DEV Community: Đạt Trương Thành

Chia sẽ câu hỏi pv backend dev

Đạt Trương Thành — Wed, 27 May 2026 02:46:14 +0000

Hôm trước mình vừa trải qua một buổi phỏng vấn vị trí Backend Developer Intern tại FPT Telecom. Và mình được tech lead hỏi 3 bài toán sau. Mình đưa ra được solution cho case 1, case 2 thì dự án mình chưa xử lý đến mức đó =)))), case 3 thì mình có dùng Redis nhưng không solve cho case này =))), nên cũng cook luôn

Nay mình viết bài này để chia sẽ đến mọi người 3 case này và solution của nó như sau:

Case 1: Xử lý Race Condition

Câu hỏi: Giả sử trong kho chỉ còn đúng 1 sản phẩm cuối cùng. Có 2 người dùng cùng lúc ấn nút thanh toán ở cùng 1 thời điểm thì điều gì sẽ xảy ra và làm sao để xử lý chuyện kho bị âm?

Và đây là cách mình giải quyết:

Lúc này mình đã nhớ đến quy tắc isolation và consistency trong ACID để xử lý transaction. Và mình đã dùng perssimistic locking trong database transaction để giải quyết.

Nói nôm na cho dễ hiểu, isolation giống như việc bạn đi mua đồ vậy. Khi user A bắt đầu quá trình mua hàng, hệ thống sẽ mở một transaction và dùng lệnh SQL để locking dòng dữ liệu của sản phẩm đó lại.

Lúc này, user B cũng gửi request tới, nhưng vì dòng dữ liệu đang bị locking, request của B buộc phải đứng ngoài đợi.
Khi A thanh toán xong, số lượng cập nhật thành 0 và transaction đóng lại.
Lúc này B mới được phép vào đọc dữ liệu, nhưng kho đã về 0 nên hệ thống sẽ ném exception (throw exception) hết hàng.

Nhờ việc cô lập 2 user này, dữ liệu kho hàng không bao giờ bị âm, từ đó giữ vững được tính consistency cho hệ thống.

Case 2: Xử lý mất Webhook IPN

Câu hỏi: Hệ thống có tích hợp cổng thanh toán VNPay. Khách hàng đã thanh toán thành công, ngân hàng trừ tiền rồi, VNPay chuẩn bị gọi API về server để báo kết quả thì rớt mạng ở browse của client. Vậy hệ thống đã xử lý như nào để đơn hàng của khách không ở mãi ở trạng thái "Chờ thanh toán"?

Và đây là cách mình giải quyết (mình có hỏi Gemini để hỗ trợ case này):

Bản chất của Webhook là một luồng giao tiếp thụ động. Chờ người ta gọi tới thì mới biết kết quả.

Để giải quyết triệt để, backend phải thiết kế thêm một luồng chủ động. Giải pháp ở đây là dùng Cron job.

Cứ mỗi 5-10 phút, Cron job sẽ âm thầm quét trong database, tìm ra những đơn hàng nào đang "Chờ thanh toán" quá lâu.
Sau đó, hệ thống sẽ mang cái transaction_id đó, chủ động gọi API ngược sang phía VNPay để hỏi đơn hàng này đã thanh toán hay chưa.
Nếu VNPay check và báo "Thành công", server của mình sẽ tự động cập nhật trạng thái đơn hàng cho khách hàng.

Case 3: Xử lý High Traffic vào các ngày flash sale

Câu hỏi: Cứ đến các ngày lễ, đặc biệt hay flash sale thì hàng trăm ngàn người dùng truy cập vào app cùng lúc. Database chắc chắn sẽ quá tải và sập. Thì em có giải pháp gì cho vấn đề này?"

Và đây là cách mình giải quyết (tham khảo thêm Gemini):

Với lượng request spike traffic như vậy, nếu bắt database tính toán, truy vấn ổ cứng liên tục thì chắc sẽ cook mất =))))

Giải pháp ở đây là sử dụng Caching và Rate Limiting

Caching: Thực hiện sao lưu những dữ liệu tĩnh từ database lên in-memory cache (ví dụ như Redis). Redis lưu dữ liệu trên RAM, nên khi cả ngàn request ập tới, backend chỉ cần vào Redis lấy dữ liệu trả về ngay lập tức, giảm tải áp lực truy cập vào database để querry data.
Rate Limiting: Dùng trong trường hợp bị spam bot hoặc tấn công DDoS. Mình sẽ cấu hình giới hạn số lượng request/s từ một địa chỉ IP. Nếu IP nào bấm tải lại trang liên tục vượt quá con số này, chặn ngay để bảo vệ server.

Kết luận:
Hi vọng bài viết này sẽ giúp các bác nào phỏng vấn backend dev có thể dùng để ôn tập nhé, ngoài phần solve problem này ra, các bác cần phải ôn thêm DSA, SQL,... và đừng fake CV. Chúc may mắn!!!

À mình còn được hỏi một câu so sánh stateful và stateless trong xử lý user session nhưng bài viết đã khá dài nên mình chia sẽ sau nhé

Ảo giác từ Vibecoding, Vibecoders

Đạt Trương Thành — Sun, 10 May 2026 17:09:38 +0000

Nay tôi viết blog này vì nhận ra bản thân tôi và có thể các SV đang theo khối ngành IT/Software Engineer nói chung đang gặp phải. Đó là việc dùng AI trong việc xây dựng mã nguồn!!!

Lập trình bằng cảm giác thay vì hiểu biết

Vibecoding là việc tạo ra phần mềm chủ yếu thông qua các prompt bằng ngôn ngữ tự nhiên với AI. Người dùng tập trung vào kết quả hiển thị có vẻ đúng, bỏ qua việc hiểu cấu trúc mã nguồn bên trong.
Khả năng dựng prototype nhanh chóng tạo ra ảo giác về một lập trình viên 10x. Không cần lo nghĩ về cú pháp, chỉ cần ra lệnh là có kết quả.

Không thể mở rộng quy mô

Bề mặt mượt mà đã che dấu đi một cỗ máy đang rỉ sét. Vibecoding đang tạo ra nợ kỹ thuật ở tốc độ chưa từng có trong lịch sử phần mềm.

Một vài lí do đã tạo ra các repo rác, code rác, khó scale up

1. Sự sụp đổ của System Architecture

AI rất xuất sắc trong việc viết các đoạn mã chức năng nhỏ lẻ, nhưng hoàn toàn thiếu khả năng thiết kế hệ thống một cách toàn diện và tổng thể bao quát.
Hệ thống chắp vá từ hàng ngàn đoạn mã rời rạc → Điều này dẫn đến các logic bị lặp lại, luồng dữ liệu rối rắm và tạo ra spaghetti code. Không có tầm nhìn kiến trúc bao trùm, mỗi prompt mới lại làm gãy vỡ cấu trúc cũ

2. Tạo ra cơn ác mộng mang tên Debug

Mã nguồn hoạt động được chưa chắc là mã sạch. Việc tìm lỗi trong một hệ thống mà không phải do bạn xây dựng chẳng khác nào mò kim đáy bể.
Và điều này cũng dẫn đến việc biến bản thân thành trò hề trong chính mã nguồn của mình → Khi lập trình viên không tự tay viết các logic cốt lõi, họ không hiểu luồng xử lý thật sự. Việc sửa một lỗi nhỏ mất thời gian gấp 10 lần vì họ phải học lại chính hệ thống do mình tạo ra.

3. Tạo ra các lỗ hổng bảo mật

Bề ngoài trong có vẻ tốt nhưng bên trong chưa chắc ổn định. Các Vibecoders hiếm khi check kỹ lưỡng các trường hợp ngoại lệ
Các mô hình ngôn ngữ lớn thường xuyên bị ảo giác tạo ra các thư viện không tồn tại hoặc sử dụng các phiên bản cũ → Các lỗ hổng được tạo ra giúp hacker dễ dàng xâm nhập, hay cho cái gọi là code vẫn chạy được.

4. Sự thui chột kỹ năng cốt lõi (làm ngu đi) =))))

Đây là cái giá phải trả đắt nhất trong tương lai. Sự phụ thuộc vào AI hiện nay đang làm xói mòn khả năng tư duy và giải quyết vấn đề một cách độc lập.
Mất đi khả năng tư duy thuật toán: Các lập trình viên dẫn mất đi khả năng tư duy độc lập. Khi một vấn đề khó, trừu tượng phức tạp xuất hiện vượt ngoài khả năng xử lý của AI → Vibecoders bó tay chịu thua =))))

5. Cạm bẫy MVP, Prototype với doanh nghiệp

Vibecoding tạo ra các sản phẩm MVP tuyệt vời, nhưng lại là thảm họa khi triển khai thành production.
Chi phí triển khai đập đi xây lại quá tốn kém: Nợ kỹ thuật tích lũy theo cấp số nhân khiến việc bảo trì trở nên khó khăn. Cuối cùng doanh nghiệp phải bỏ ra số tiền lớn thuê người có chuyên môn viết lại toàn bộ mã nguồn hệ thống.
Khi có lỗ hổng khiến dữ liệu rò rỉ hay hệ thống sụp đổ khi dùng Vibecoding, ai là người chịu trách nhiệm? AI hay là Vibecoders????

→ Sử dụng AI một cách thông minh:

Thay đổi phương pháp tiếp cận từ lười biếng sang có kỷ luật.
Những Software Engineer thực thụ sử dụng AI vào các tác vụ lặp đi lặp lại, nhưng họ luôn là người kiểm soát AI theo System Architecture và Bussiness Logic của họ.
Thiết lập các ràng buộc như phải review code, check syntax error,... do AI generate.
Luôn xác định kiến trúc tổng thể dự án trước khi prompt cho AI bởi lập trình viên mới là những người có quyết định cao nhất về dự án.

Và lời cuối cùng tôi muốn truyền tải tới mọi người rằng:

Các lập trình viên sử dụng AI không sai, nhưng hãy sử dụng nó để tạo ra các sản phẩm có giá trị thực tế, bởi một sản phẩm được tạo ra từ AI có giá trị cao khi được điều khiển bởi bộ não trí tuệ thực sự của con người!!!

Cookie, Session và Token-based authentication

Đạt Trương Thành — Sun, 10 May 2026 04:29:12 +0000

1. Phân biệt Authentication và Authorization

Rất nhiều lập trình viên mới hay nhầm lẫn hai khái niệm này:

Authentication (Xác thực): Ví dụ: Hành động bạn nhập Username và Password để đăng nhập vào hệ thống.
Authorization (Phân quyền): Ví dụ: Sau khi đăng nhập thành công, hệ thống kiểm tra xem bạn là Admin hay User thường, bạn có quyền xóa bài viết hay chỉ được xem.

2. Giao thức HTTP và vấn đề "Stateless"

Giao thức HTTP bản chất là Stateless. Nghĩa là server xử lý xong một request là sẽ forget luôn client đó là ai.
Nếu không có cơ chế lưu trữ lại trạng thái, mỗi lần bạn bấm sang một trang mới trên website, hệ thống sẽ lại bắt bạn đăng nhập lại. Để giải quyết vấn đề này, người ta sinh ra Cookie, Session và Token.

3. Cơ chế Cookie và Session

Cookie:

Là một đoạn dữ liệu nhỏ (khoảng vài KB) được Server yêu cầu Client (browse) lưu trữ lại ở dưới máy của người dùng.
Mỗi khi Client gửi một request mới lên Server, nó sẽ tự động đính kèm các Cookie này theo. Nhờ đó, Server biết được request này đến từ ai.

Session:

Lưu toàn bộ thông tin nhạy cảm ở phía Client (bằng Cookie) là rất nguy hiểm (dễ bị hack). Do đó, người ta sinh ra Session.
Cách hoạt động: Khi bạn đăng nhập thành công, Server sẽ tạo ra một vùng nhớ chứa thông tin của bạn (gọi là Session) và sinh ra một Session ID. Server chỉ gửi cái Session ID này về cho Client để lưu vào Cookie.
Các lần request sau, Client chỉ gửi Session ID lên. Server lấy Session ID này dò trong bộ nhớ/DB Session của mình để biết bạn là ai.

4. Token-based Authentication

Nhược điểm của Session: Khi hệ thống scale lên nhiều Server, Server A lưu Session của bạn nhưng Server B thì không. Nếu request của bạn bị điều hướng sang Server B, bạn sẽ bị bắt đăng nhập lại.
Giải pháp Token (JWT - JSON Web Token):
- Thay vì lưu trạng thái ở Server, sau khi đăng nhập thành công, Server sẽ gom thông tin của bạn (như ID, Role), mã hóa và sign bằng một khóa bí mật, tạo thành một chuỗi gọi là Token.
- Server gửi Token này cho Client lưu lại (thường lưu ở Local Storage hoặc Cookie).
- Lần sau gửi request, Client đính kèm Token này vào Header (thường là Authorization: Bearer <token>).
- Server không cần tìm trong bộ nhớ nữa, chỉ cần dùng khóa bí mật để giải mã và kiểm tra chữ ký của Token là biết bạn là ai và có quyền gì.
Ưu điểm: Cực kỳ phù hợp cho Web API, các ứng dụng Mobile, và hệ thống Microservices vì nó hoàn toàn "Stateless" (Server không cần tốn RAM để nhớ người dùng).