Nên chọn ngôn ngữ backend nào cho hệ thống?

Question

IT Interview Practice · Accepted Answer

Nếu chưa biết dự án cần làm gì, hãy bắt đầu bằng câu hỏi:

> **Hệ thống này cần tối ưu điều gì, và đội ngũ hiện tại có thể làm tốt với công nghệ nào?**

Câu trả lời sẽ giúp thu hẹp lựa chọn. Một backend ra mắt sớm, một dịch vụ xử lý ảnh và một hệ thống đặt hàng có thể cần những ưu tiên khác nhau.

## 1. Hiểu backend chủ yếu làm việc gì

**Workload là loại công việc hệ thống phải xử lý.** Trước tiên, phân biệt hai trường hợp:

- **Chờ I/O:** phần lớn thời gian chờ database, đọc file hoặc gọi API bên ngoài.
- **Tính toán nhiều:** phần lớn thời gian dùng CPU để xử lý, chẳng hạn biến đổi ảnh hoặc chạy thuật toán.

Ví dụ một API đặt hàng có thể đi qua luồng:

```text
Request
   ↓
Validate input
   ↓
Database
   ↓
Payment API
   ↓
Response
```

Nếu thời gian chủ yếu nằm ở database và dịch vụ thanh toán, đổi ngôn ngữ có thể không cải thiện nhiều tổng thời gian phản hồi. Cần đo từng bước để biết nên tối ưu ở đâu.

Với Node.js, công việc JavaScript tính toán lâu trên event loop có thể làm các request khác phải chờ. Nếu có loại công việc này, cần xem xét worker hoặc cách tách xử lý phù hợp. [Tài liệu Node.js](https://nodejs.org/en/learn/asynchronous-work/dont-block-the-event-loop).

**Bước này giúp xác định yêu cầu kỹ thuật trước khi chọn công nghệ.**

## 2. Chọn ưu tiên quan trọng nhất

Hai công nghệ có thể cùng xây được API, nhưng chi phí để đạt mục tiêu khác nhau.

| Ưu tiên | Cần kiểm tra | Vì sao quan trọng? |
| --- | --- | --- |
| Ra sản phẩm đúng hạn | Team thành thạo gì, có sẵn thư viện nào? | Học công nghệ và tự viết lại chức năng làm tăng thời gian. |
| Đáp ứng tải | Độ trễ, tỷ lệ lỗi và tài nguyên trên tải dự kiến | Xác nhận hệ thống đáp ứng nhu cầu thật. |
| Duy trì lâu dài | Khả năng kiểm thử, nâng cấp và tuyển người | Sản phẩm còn cần được sửa và phát triển sau khi ra mắt. |
| Vận hành trong ngân sách | Chi phí hạ tầng và nhân lực vận hành | Tiết kiệm máy chủ có thể không bù được công sức phát sinh. |

Chọn một vài ưu tiên chính và biến chúng thành điều kiện có thể kiểm tra. Ví dụ: phải ra mắt trước thời điểm nào, chịu được tải nào và nằm trong ngân sách nào.

## 3. Lập danh sách công nghệ đáng cân nhắc

Sau khi có yêu cầu, dùng bảng dưới đây để tạo danh sách ban đầu. Đây là cách cân nhắc, không phải giới hạn ứng dụng của từng ngôn ngữ.

| Lựa chọn | Khi đáng cân nhắc | Điều cần kiểm tra thêm |
| --- | --- | --- |
| TypeScript chạy trên Node.js | Team quen TypeScript và đang xây sản phẩm web | Cách xử lý công việc tính toán nặng và kinh nghiệm vận hành backend. |
| Java hoặc C# | Team đã dùng hệ sinh thái này cho ứng dụng nghiệp vụ | Những tích hợp cần thiết và chi phí vận hành thực tế. |
| Go | Xây dịch vụ mạng, API hoặc worker với nhiều tác vụ đồng thời | Kinh nghiệm của team, thư viện và kết quả đo trên tải thật. |
| Python | Công việc gắn với xử lý dữ liệu hoặc tính toán khoa học | Thư viện cần dùng, cách thực thi phần tính toán và yêu cầu của API. |
| Rust | Có yêu cầu rõ về tài nguyên và kiểm soát bộ nhớ | Lợi ích đo được có xứng với thời gian học và phát triển của team không. |

Các hệ sinh thái có hỗ trợ tương ứng: [Spring](https://spring.io/projects/), [ASP.NET Core](https://dotnet.microsoft.com/en-us/apps/aspnet), [Go cho dịch vụ mạng](https://go.dev/solutions/cloud), [ứng dụng Python](https://www.python.org/about/apps/) và [Rust](https://rust-lang.org/). Bảng trên là hướng đánh giá từ những khả năng đó, không phải bảng xếp hạng hiệu năng.

Danh sách này chưa phải kết luận. Bước tiếp theo là đưa đội ngũ thực tế vào quyết định.

## 4. Xem team có thể xây và vận hành tốt lựa chọn nào

**Ví dụ giả định:** cần xây hệ thống đặt hàng; team có tám lập trình viên Java và chưa ai vận hành Go.

Nếu giải pháp Java đáp ứng được tải và ngân sách, tôi sẽ ưu tiên Java. Team có thể tận dụng kinh nghiệm để phát triển, review và xử lý sự cố.

Chuyển sang Go cần tính thêm:

- Thời gian học và xây quy ước code.
- Khả năng review, debug và hỗ trợ thành viên mới.
- Người chịu trách nhiệm khi có sự cố production.

Nếu phép đo cho thấy giải pháp hiện tại không đáp ứng yêu cầu, cần tìm nguyên nhân. Khi giới hạn thực sự nằm ở phần triển khai bằng ngôn ngữ/runtime và phương án khác cải thiện đủ lớn, việc đổi mới có cơ sở.

**Kinh nghiệm của team là một phần của chi phí và độ tin cậy của hệ thống.**

## 5. Kiểm tra hệ sinh thái và vận hành trước khi chốt

Với ví dụ đặt hàng, hãy thử các tích hợp thực sự cần: database, thanh toán, xác thực và hàng đợi nếu có.

Đừng chỉ kiểm tra “có thư viện”. Cần xem thư viện có đáp ứng chức năng, được duy trì và có thể theo dõi lỗi trong môi trường của team hay không.

Tiếp theo, thử cách đóng gói, triển khai, ghi log và khôi phục phiên bản cũ. Đo CPU, RAM và thời gian khởi động nếu chúng ảnh hưởng đến mục tiêu dự án.

Một lựa chọn có thể viết API thuận tiện nhưng làm tích hợp hoặc vận hành khó hơn. Chi phí đó cần được tính trước khi chọn.

## 6. Dùng thử nghiệm nhỏ để xác nhận quyết định

Làm thử một luồng đại diện, chẳng hạn tạo đơn có ghi database và gọi dịch vụ thanh toán thử nghiệm.

Kiểm tra cùng điều kiện về tài nguyên, dữ liệu và mức đồng thời:

- Độ trễ, tỷ lệ lỗi và lượng tài nguyên sử dụng.
- Hành vi khi dịch vụ phụ thuộc chậm hoặc không phản hồi.
- Mức dễ phát triển, tìm lỗi và vận hành của team.

Chỉ cần so sánh nhiều phương án khi còn một điểm chưa chắc chắn có thể làm thay đổi quyết định. Một benchmark HTTP đơn giản không đại diện đầy đủ cho luồng đặt hàng.

Với ví dụ trên, nếu Java vượt qua các kiểm tra, có thể chốt Java. Nếu chưa đạt, kết quả đo phải chỉ ra vấn đề cần giải quyết và lý do thử phương án khác.

**Cách nhớ:** hiểu workload → xác định ưu tiên → lập danh sách → xét team và vận hành → đo để chốt.

Ngôn ngữ phù hợp là ngôn ngữ giúp đội ngũ đáp ứng yêu cầu với chi phí phát triển và vận hành chấp nhận được.

Ưu tiên	Cần kiểm tra	Vì sao quan trọng?
Ra sản phẩm đúng hạn	Team thành thạo gì, có sẵn thư viện nào?	Học công nghệ và tự viết lại chức năng làm tăng thời gian.
Đáp ứng tải	Độ trễ, tỷ lệ lỗi và tài nguyên trên tải dự kiến	Xác nhận hệ thống đáp ứng nhu cầu thật.
Duy trì lâu dài	Khả năng kiểm thử, nâng cấp và tuyển người	Sản phẩm còn cần được sửa và phát triển sau khi ra mắt.
Vận hành trong ngân sách	Chi phí hạ tầng và nhân lực vận hành	Tiết kiệm máy chủ có thể không bù được công sức phát sinh.

Lựa chọn	Khi đáng cân nhắc	Điều cần kiểm tra thêm
TypeScript chạy trên Node.js	Team quen TypeScript và đang xây sản phẩm web	Cách xử lý công việc tính toán nặng và kinh nghiệm vận hành backend.
Java hoặc C#	Team đã dùng hệ sinh thái này cho ứng dụng nghiệp vụ	Những tích hợp cần thiết và chi phí vận hành thực tế.
Go	Xây dịch vụ mạng, API hoặc worker với nhiều tác vụ đồng thời	Kinh nghiệm của team, thư viện và kết quả đo trên tải thật.
Python	Công việc gắn với xử lý dữ liệu hoặc tính toán khoa học	Thư viện cần dùng, cách thực thi phần tính toán và yêu cầu của API.
Rust	Có yêu cầu rõ về tài nguyên và kiểm soát bộ nhớ	Lợi ích đo được có xứng với thời gian học và phát triển của team không.

1. Hiểu backend chủ yếu làm việc gì

2. Chọn ưu tiên quan trọng nhất

3. Lập danh sách công nghệ đáng cân nhắc

4. Xem team có thể xây và vận hành tốt lựa chọn nào

5. Kiểm tra hệ sinh thái và vận hành trước khi chốt

6. Dùng thử nghiệm nhỏ để xác nhận quyết định

Câu hỏi liên quan