Backend và API cho app iOS đặt tại Việt Nam

Trả lời nhanh: Với ứng dụng phục vụ người Việt, đặt backend cho app trong nước tiết kiệm khoảng vài chục tới hơn một trăm mili giây cho mỗi lượt gọi so với đặt ở nước ngoài. Nghe nhỏ, nhưng một màn hình gọi năm lượt API là chênh lệch nửa giây, và người dùng cảm nhận rõ điều đó. Ngoại lệ đáng cân nhắc: ứng dụng có người dùng phân bố toàn cầu, hoặc phụ thuộc nặng vào dịch vụ chỉ có ở nước ngoài. Cách giải quyết chung là đặt phần chính trong nước và tách phần phụ thuộc ra riêng.

Câu hỏi đặt máy chủ ở đâu thường bị trả lời bằng cảm tính hoặc bằng thói quen. Với ứng dụng di động thì nó có ảnh hưởng đo được và người dùng cảm nhận được, nên đáng để tính bằng số. Bài này chỉ cách đo và cách bố trí theo từng tình huống.

Chênh lệch thật là bao nhiêu

Đường truyền từ Việt Nam ra các trung tâm dữ liệu trong khu vực thường thêm vài chục mili giây, còn ra xa hơn thì thêm hơn một trăm. Con số cụ thể thay đổi theo nhà mạng và theo thời điểm, nhất là khi có sự cố tuyến cáp biển.

Vì sao ứng dụng di động chịu ảnh hưởng nặng hơn trang web:

• Nhiều lượt gọi cho một màn hình. Trang web tải một lần rồi thôi, ứng dụng gọi API liên tục theo thao tác của người dùng.
• Mạng di động vốn đã có độ trễ cao hơn mạng có dây, nên phần cộng thêm càng đáng kể.
• Người dùng mong ứng dụng phản hồi tức thì, khác với kỳ vọng khi mở một trang web.

Đây cũng là lý do nên thiết kế màn hình lấy dữ liệu bằng ít lượt gọi nhất có thể, như đã nói ở bài về kiến trúc backend.

Đo cho đúng cách

# Do do tre co ban toi may chuping -c 20 api.trangcuaban.vn # Do thoi gian mot luot goi API day ducurl -w "ket noi: %{time_connect}s | bat tay TLS: %{time_appconnect}s | tong: %{time_total}s\n" \     -o /dev/null -s https://api.trangcuaban.vn/v1/san-pham

Ba lưu ý để con số có ý nghĩa:

• Đo từ mạng của người dùng thật, tức mạng di động của các nhà mạng phổ biến, không phải mạng văn phòng có đường truyền quốc tế tốt.
• Đo vào giờ cao điểm buổi tối, khi đường truyền quốc tế chật nhất.
• Đo cả thời gian bắt tay mã hóa, vì lần kết nối đầu tiên tốn nhiều lượt đi về và đó là lúc khoảng cách địa lý thể hiện rõ nhất.

Cách chắc chắn nhất là ghi lại thời gian gọi API ngay trong ứng dụng thật và gom về máy chủ. Khi đó bạn có số liệu từ chính người dùng của mình thay vì từ máy của bạn.

Khi nào nên đặt ở nước ngoài

Ba trường hợp:

• Người dùng phân bố toàn cầu. Khi đó đặt ở một trung tâm khu vực hoặc dùng nhiều điểm là hợp lý hơn.
• Phụ thuộc nặng vào dịch vụ chỉ có ở nước ngoài. Ví dụ ứng dụng gọi liên tục tới một API bên thứ ba đặt ở nước ngoài, khi đó máy chủ của bạn nằm gần dịch vụ đó có thể tổng thời gian lại thấp hơn.
• Cần dịch vụ hạ tầng đặc thù chưa phổ biến trong nước.

Với trường hợp thứ hai, có một cách bố trí thường bị bỏ qua: đặt phần phục vụ người dùng trong nước, và tách riêng phần gọi dịch vụ ngoài thành các tác vụ chạy nền. Người dùng nhận phản hồi nhanh, còn việc gọi ra nước ngoài chạy trong hàng đợi mà họ không phải chờ.

Bố trí kết hợp cho ứng dụng có người dùng cả trong lẫn ngoài nước

Mô hình thực dụng cho phần lớn trường hợp:

1. Máy chủ chính đặt trong nước, phục vụ phần lớn người dùng và chứa database.
2. Nội dung tĩnh và ảnh phân phối qua mạng phân phối nội dung, để người dùng ở đâu cũng tải nhanh. Đây là phần dễ và rẻ nhất trong toàn bộ bài toán.
3. Nếu có thị trường thứ hai đáng kể, cân nhắc một điểm đọc gần thị trường đó, còn phần ghi vẫn về máy chính.

Đừng vội làm bước ba khi chưa có số liệu. Rất nhiều đội dựng hạ tầng nhiều vùng từ đầu rồi phát hiện chín mươi phần trăm người dùng ở một nước, và họ chỉ chuốc thêm phức tạp.

Ngoài độ trễ còn hai lý do khác

Giải trình với khách hàng. Với khách doanh nghiệp và cơ quan nhà nước, câu hỏi dữ liệu người dùng đặt ở đâu là câu hỏi bắt buộc trong hồ sơ. Trả lời rằng dữ liệu nằm tại trung tâm dữ liệu ở Việt Nam đơn giản hơn nhiều so với việc giải thích một chuỗi nhà cung cấp ở nước ngoài.

Hỗ trợ khi có sự cố. Nhà cung cấp trong nước hỗ trợ bằng tiếng Việt và cùng múi giờ. Lúc hai giờ sáng hệ thống có vấn đề, đây là khác biệt rất thật.

Về cấu hình, backend cho ứng dụng di động thường không cần nhiều nhân xử lý mà cần độ trễ thấp và ổ đĩa nhanh, vì phần lớn thời gian là đọc database cho những lượt gọi nhỏ. Bắt đầu từ 2 vCPU và 4GB cho ứng dụng mới, nâng theo số liệu thật thay vì mua dư ngay từ đầu.

Bảng độ trễ theo vị trí đặt máy chủ

Con số ở cột cuối mới là thứ người dùng cảm nhận: một màn hình ứng dụng thường gọi nhiều lượt, và độ trễ nhân lên. Chênh lệch giữa dòng đầu và dòng cuối là khác biệt giữa mượt và ì.

Đo từ mạng người dùng, không đo từ máy chủ

# Do tu mang cua nguoi dung that, khong do tu may chuping -c 30 api.tenmien.vnmtr -rwc 30 api.tenmien.vn # Do thoi gian may chu tra byte dau tiencurl -o /dev/null -s -w "ket noi %{time_connect}s | byte dau %{time_starttransfer}s\n" \  https://api.tenmien.vn/health # Do 20 lan, xem trung vi va truong hop cham nhatfor i in $(seq 1 20); do  curl -o /dev/null -s -w "%{time_starttransfer}\n" https://api.tenmien.vn/healthdone | sort -n | awk '{a[NR]=$1} END {print "trung vi", a[int(NR/2)], "cham nhat", a[NR]}' # Do tren MANG DI DONG, khong chi tren wifi van phong# Nguoi dung ung dung di dong phan lon dung mang di dong

Vị trí dữ liệu và ràng buộc pháp lý

• Vị trí dữ liệu: nếu ứng dụng xử lý dữ liệu cá nhân của người dùng Việt Nam, khung áp dụng là Luật Bảo vệ dữ liệu cá nhân số 91/2025/QH15, hiệu lực từ 01/01/2026. Đặt dữ liệu trong nước làm hồ sơ tuân thủ đơn giản hơn.
• Thanh toán và hóa đơn: mua dịch vụ trong nước có hóa đơn giá trị gia tăng, thuận tiện cho hạch toán chi phí.
• Hỗ trợ cùng múi giờ, quan trọng khi có sự cố lúc nửa đêm.

Trường hợp đặt máy ở nước ngoài là hợp lý

Khi người dùng chủ yếu ở nước ngoài, hoặc khi bạn cần một dịch vụ quản lý sẵn chỉ có ở nhà cung cấp quốc tế. Với ứng dụng có người dùng cả trong lẫn ngoài nước, bố trí thường hiệu quả là máy chính trong nước phục vụ phần đông người dùng, và dùng mạng phân phối cho tệp tĩnh và ảnh. Xem VPS Việt Nam.