WebSocket / real-time

WebSocket / real-time là gì?

Real-time nghĩa là màn hình tự đổi mà người dùng không phải làm gì cả. Để làm được điều đó, cần một kết nối mở sẵn giữa máy chủ và từng người dùng — cơ chế phổ biến nhất tên là WebSocket. Kết nối mở từ lúc người dùng vào màn hình và giữ nguyên, nên máy chủ có thể đẩy tin xuống bất cứ lúc nào.

Cách thông thường thì ngược lại: trình duyệt hỏi, máy chủ trả lời, kết nối đóng. Muốn dữ liệu mới thì phải hỏi lại — hoặc do người dùng kéo màn hình để làm mới, hoặc do app tự hỏi theo chu kỳ.

Hệ quả quan trọng nhất với BA/PO: mỗi người đang mở màn hình là một kết nối máy chủ phải giữ. 10.000 người xem cùng lúc là 10.000 kết nối, kể cả khi cả tiếng không có gì thay đổi. Đó là chi phí hạ tầng thật, và là lý do real-time phải được chọn có lý do chứ không phải bật mặc định cho mọi màn hình.

Baseline — bạn hiểu

• Real-time (giá đang đổi, trạng thái live) cần một kết nối luôn mở cho mỗi người dùng — tốn kém, nên là lựa chọn chứ không phải mặc định.
• Có ba mức khác nhau: đẩy real-time, tự làm mới theo chu kỳ, và chỉ làm mới khi người dùng yêu cầu.
• Kết nối có thể đứt bất cứ lúc nào, và khi đứt thì màn hình vẫn hiện số cũ nếu không ai spec chuyện đó.

Working — bạn làm được

• Phân biệt feature nào thật sự cần real-time so với refresh định kỳ, và nói được cái giá của mỗi lựa chọn.
• Spec trạng thái mất kết nối: người dùng có biết không, dữ liệu có tự đồng bộ lại không.
• Quy yêu cầu "phải thấy ngay" của stakeholder thành một con số giây trong acceptance criteria.

Cơ chế hoạt động

Ví dụ theo cấp độ

Cơ bản — Hai màn hình theo dõi đơn hàng, khác nhau ở đâu?

Tình huống: bạn mở hai app giao hàng, cả hai đều có màn hình theo dõi đơn. Bạn muốn biết màn hình nào đang chạy real-time.

Quan sát thật, không cần hỏi dev:

• Màn hình A: bạn để yên, không chạm gì. Sau khoảng 8 giây, dòng trạng thái tự đổi từ "Đang lấy hàng" sang "Đang giao", và ở góc có một chấm xanh kèm chữ "đang cập nhật".
• Màn hình B: bạn để yên 10 phút, không có gì đổi. Kéo màn hình xuống để làm mới, lúc đó mới thấy "Đang giao" — trạng thái này đã đổi từ 9 phút trước.

Bài kiểm tra 60 giây bạn tự làm được: mở màn hình, để yên, tuyệt đối không chạm vào. Nếu sau một phút nội dung tự đổi thì màn hình có cơ chế tự cập nhật; nếu không đổi cho tới khi bạn kéo làm mới thì không có. Sau đó hỏi dev đúng một câu để biết là loại nào: "màn này đang đẩy real-time hay tự hỏi lại theo chu kỳ?"

Học được: "real-time" không phải một từ khen, nó là một hành vi quan sát được. Trước khi viết nó vào spec, hãy nói được màn hình hiện tại đang thuộc loại nào — vì rất nhiều yêu cầu "làm real-time đi" thực ra chỉ cần đổi từ loại B sang tự làm mới.

Trung bình — "Có đơn mới là tôi phải biết ngay"

Tình huống: chủ cửa hàng yêu cầu màn hình quản lý đơn phải báo ngay khi có đơn mới. Bạn phải chọn giữa real-time và tự làm mới mỗi 30 giây, và giải thích được lựa chọn đó.

Câu hỏi tách được vấn đề: "Chậm 30 giây thì cửa hàng mất gì?" Một shop 20 đơn mỗi ngày thì không mất gì — chuông báo cộng làm mới 30 giây là quá đủ. Một bếp quán ăn giờ cao điểm thì 30 giây làm lệch cả dây chuyền, và real-time xứng đáng với chi phí của nó.

Các dòng viết vào ticket khi chọn phương án 30 giây:

• "Danh sách đơn tự làm mới mỗi 30 giây khi tab đang hiển thị. Tab chạy nền thì dừng làm mới để đỡ pin và đỡ tải."
• "Có đơn mới: phát âm thanh một lần và hiện chấm đỏ kèm số đơn chưa xem trên tiêu đề."
• "Acceptance criteria: đơn mới xuất hiện trên màn hình chậm nhất 30 giây kể từ khi khách đặt." — không viết "ngay lập tức".
• "Ba lần làm mới liên tiếp thất bại: hiện dải cảnh báo 'Mất kết nối — số liệu có thể chưa mới', giữ nguyên danh sách đang có, không xoá trắng màn hình."

Học được: real-time không phải phiên bản "tốt hơn" của làm mới định kỳ; nó là một lựa chọn đắt hơn để đổi lấy vài chục giây. Việc của BA là quy chữ "ngay" thành một con số giây mà nghiệp vụ chịu được, rồi mới chọn cơ chế.

Nâng cao — Người dùng mất mạng giữa chừng

Tình huống: màn hình tồn kho thời gian thực cho nhân viên kho, chạy trên điện thoại, dùng ngay trong kho — nơi sóng chập chờn. Nhân viên đi vào khu vực không có sóng 4 phút rồi quay ra.

Cái bẫy: kết nối đứt lặng lẽ. Màn hình không báo lỗi, không quay vòng, không có gì khác thường — nó vẫn hiện số tồn kho của 4 phút trước, trông y hệt dữ liệu đang sống. Nhân viên đọc "còn 12 cái" và nhận đơn, trong khi thực tế đã hết từ ba phút trước. Đây là loại lỗi tệ nhất trong nhóm này: không ai biết là đang sai, kể cả người dùng lẫn hệ thống.

Ba câu hỏi bắt buộc phải trả lời trong spec:

1. Người dùng có biết mình đang mất kết nối không? "Sau 10 giây không nhận được tín hiệu từ máy chủ, hiện dải màu vàng ở đầu màn hình: 'Mất kết nối. Số liệu cập nhật lần cuối 10:42'. Các con số vẫn hiện nhưng được làm mờ để phân biệt với dữ liệu sống."
2. Nối lại rồi thì phần bị lỡ có tự tới không? "Khi nối lại, app phải tải lại toàn bộ danh sách một lần, không chỉ nghe tiếp các thay đổi mới." Đây là chỗ hay bị bỏ sót nhất: nếu chỉ nghe tiếp, mọi thay đổi xảy ra trong 4 phút mất sóng sẽ không bao giờ tới, và màn hình sai vĩnh viễn cho tới lần tải lại sau.
3. Nối lại bao lâu một lần, và bao giờ thì dừng? "Thử nối lại sau 1 giây, 2 giây, 5 giây, 15 giây, rồi mỗi 30 giây. Quá 5 phút vẫn không được: thay dải cảnh báo bằng nút 'Tải lại' để người dùng chủ động."

Một dòng nữa mà chỉ BA nghĩ ra được: "Trong lúc mất kết nối, nút 'Nhận đơn' bị khoá kèm dòng giải thích, vì quyết định này dựa trên số tồn kho có thể đã cũ." Dev sẽ không tự viết dòng này — nó là một quyết định nghiệp vụ về việc chấp nhận rủi ro nào.

Học được: phần khó của real-time không nằm ở lúc nó chạy mà ở lúc nó ngừng chạy. Một màn hình real-time không có trạng thái mất kết nối còn tệ hơn một màn hình phải kéo để làm mới — vì màn hình kéo-làm-mới không bao giờ nói dối người dùng rằng số đang sống.

Áp dụng khi viết spec

Với mỗi màn hình có dữ liệu thay đổi theo thời gian, ticket của bạn phải trả lời được bốn câu:

1. Yêu cầu "ngay" ở đây là bao nhiêu giây? Chậm hơn ngưỡng đó thì nghiệp vụ mất gì?
2. Màn hình này cần đẩy real-time, tự làm mới định kỳ, hay chỉ làm mới khi người dùng yêu cầu?
3. Khi mất kết nối, người dùng thấy gì, và hành động nào bị khoá lại?
4. Khi nối lại, dữ liệu bị lỡ được lấy bù bằng cách nào?

Câu hỏi nên hỏi dev

• "Màn hình này đang đẩy real-time hay tự hỏi lại theo chu kỳ? Chu kỳ bao nhiêu?"
• "Nếu bật real-time, mình chịu được tối đa bao nhiêu kết nối đồng thời?"
• "App phát hiện mất kết nối sau bao lâu, hay chỉ biết khi người dùng thao tác?"
• "Sau khi nối lại, app có tải lại toàn bộ dữ liệu không, hay chỉ nghe tiếp thay đổi mới?"
• "Các bản tin đẩy xuống có đảm bảo đúng thứ tự không, hay có thể tới lộn xộn?"

Sai lầm thường gặp

• Viết "cập nhật real-time" cho mọi dashboard vì nghe hiện đại, trong khi không ai hành động trong vòng một phút.
• Chỉ spec lúc kết nối tốt; không có trạng thái mất kết nối và không có bước nối lại.
• Cho rằng nối lại là đủ, quên rằng những thay đổi xảy ra lúc đứt sẽ không tự tới.
• Để màn hình hiện số cũ y như số sống, không có mốc "cập nhật lúc".
• Đo "ngay lập tức" bằng cảm giác thay vì bằng số giây trong acceptance criteria.
• Bật real-time cho danh sách hàng nghìn dòng, mỗi thay đổi lại vẽ lại cả danh sách — máy người dùng nóng và hết pin.

Definition of done — dấu hiệu bạn đã đạt

• Với mỗi màn hình bạn spec, bạn nói được nó cập nhật bằng cơ chế nào và độ trễ tối đa là bao nhiêu.
• Mọi màn hình tự cập nhật trong khu vực của bạn đều có trạng thái mất kết nối và mốc "cập nhật lúc".
• Bạn quy được yêu cầu "phải thấy ngay" thành một con số giây trước khi vào buổi refinement.

Đi sâu hơn

• Webhook vs polling — khi độ trễ đến từ cách hai hệ thống báo tin cho nhau.