Một lựa chọn thực tế cho n8n: khi nào nên chuyển từ Waha sang Evolution API

Trong các workflow n8n có WhatsApp, vấn đề thường không nằm ở việc “node nào chạy được demo”, mà là node nào chịu được vận hành thật: timeout, reconnect, mất session, cập nhật breaking change, và chi phí xử lý khi lỗi lặp lại.

Một thảo luận mới trên r/n8n nêu đúng nỗi đau này: dùng Waha nhưng gặp timeout liên tục, nhiều lần phải restart, thậm chí xóa sạch và dựng lại. Người đăng đang cân nhắc Evolution API vì có community node cho n8n, trong khi Meta Cloud API chính thức lại khó tiếp cận do giấy tờ pháp lý và chi phí.

Nếu anh em đang ở tình huống tương tự, mình nghĩ không nên quyết định theo cảm tính “tool A ổn hơn tool B”, mà nên nhìn như một bài toán vận hành.

Bản chất vấn đề: WhatsApp không chính thức luôn có rủi ro

Waha, Evolution API, WasenderAPI hay các giải pháp gateway không chính thức đều nằm trong vùng xám vận hành:

• Phụ thuộc vào cơ chế session và pairing của WhatsApp Web.
• Có thể lỗi khi WhatsApp thay đổi phía client.
• Dễ phát sinh timeout, disconnect, rate limit, hoặc block số nếu dùng mạnh tay.
• Khó có SLA rõ ràng như API chính thức.

Vì vậy câu hỏi đúng không phải là “Evolution API có hết lỗi không?”, mà là:

• Khi lỗi xảy ra, nó có tự hồi phục tốt hơn không?
• Có log đủ rõ để debug không?
• Có community node giúp giảm code glue trong n8n không?
• Có dễ backup, migrate, và dựng lại session không?
• Tổng chi phí vận hành có thấp hơn phương án hiện tại không?

Khi nào nên thử Evolution API

Evolution API đáng để thử nếu anh em đang gặp một trong các trường hợp sau:

• Waha timeout thường xuyên và không còn đoán được nguyên nhân.
• Workflow phụ thuộc nhiều vào WhatsApp, nhưng chưa đủ điều kiện dùng Meta API.
• Muốn có node/community integration sẵn cho n8n để giảm phần HTTP Request thủ công.
• Có thể chấp nhận chạy thử song song 1-2 tuần trước khi chuyển hẳn.

Điểm cộng lớn của Evolution API trong bối cảnh này là hệ sinh thái quanh n8n có vẻ thuận hơn: có community node, nhiều người dùng automation nhỏ lẻ quan tâm, và cách triển khai thường hợp với mô hình self-hosted.

Nhưng mình sẽ không chuyển thẳng toàn bộ production chỉ vì “nghe ổn hơn”. Với WhatsApp gateway, migration nên làm như thay một phần hạ tầng nhạy cảm.

Checklist test trước khi chuyển production

Nếu đang dùng n8n để gửi/nhận WhatsApp cho khách hàng, anh em nên tạo một workflow test riêng và đo tối thiểu các điểm này.

1. Độ ổn định session

Theo dõi trong vài ngày:

• Session có tự disconnect không?
• Khi mất kết nối, API báo lỗi rõ hay treo timeout?
• Có cần scan QR lại thường xuyên không?
• Restart container/service có giữ được state không?

Nếu mỗi lần lỗi đều cần thao tác tay, thì tool đó chưa đủ tốt cho workflow quan trọng.

2. Timeout và retry behavior

Trong n8n, nên bọc node gửi tin bằng retry có kiểm soát:

• Retry 2-3 lần với delay tăng dần.
• Nếu vẫn lỗi, đẩy sang nhánh cảnh báo nội bộ.
• Không retry vô hạn vì dễ gửi trùng hoặc làm số bị đánh dấu spam.

Một gateway tốt không chỉ “gửi được”, mà phải fail rõ ràng để n8n xử lý tiếp.

3. Webhook nhận tin

Test inbound message kỹ hơn outbound:

• Tin nhắn đến có bị miss không?
• Webhook có gửi duplicate event không?
• Event có đủ metadata để map về khách hàng/workflow không?
• Khi n8n downtime, có cơ chế replay hay mất luôn?

Nhiều hệ thống demo gửi tin rất mượt nhưng nhận tin lại là nơi phát sinh lỗi khó chịu.

4. Backup và khôi phục

Trước khi chuyển, cần biết chính xác state nằm ở đâu:

• Volume/container nào chứa session?
• Backup có khôi phục được sang máy khác không?
• Nếu số bị logout, quy trình dựng lại mất bao lâu?
• Có tài liệu nội bộ cho người khác thao tác không?

Nếu không trả lời được phần này, khi production hỏng sẽ rất mệt.

Gợi ý kiến trúc n8n an toàn hơn

Thay vì để mọi workflow gọi thẳng WhatsApp gateway, mình thích tách một lớp “message queue” đơn giản:

1. Workflow nghiệp vụ ghi yêu cầu gửi tin vào Google Sheet, Postgres, Redis, hoặc một queue phù hợp.
2. Một workflow riêng phụ trách gửi WhatsApp theo rate limit.
3. Kết quả gửi được ghi lại: sent, failed, retrying, blocked.
4. Khi gateway lỗi, chỉ workflow gửi tin bị ảnh hưởng; nghiệp vụ chính không sập dây chuyền.

Cách này hơi mất công hơn lúc đầu, nhưng giảm rủi ro rất nhiều. Nó cũng giúp anh em test Waha và Evolution API song song: cùng một queue, hai gateway khác nhau, so sánh tỷ lệ lỗi thật.

Có nên dùng Meta Cloud API không?

Nếu đủ điều kiện giấy tờ và chi phí chấp nhận được, Meta Cloud API vẫn là hướng sạch nhất cho hệ thống nghiêm túc: chính thức, ổn định hơn, ít rủi ro bị vỡ vì thay đổi WhatsApp Web.

Nhưng thực tế nhiều doanh nghiệp nhỏ ở thị trường đang phát triển không đi được đường đó ngay. Khi đó, dùng gateway như Evolution API hay Waha là quyết định thực dụng, miễn là mình không tự lừa rằng nó có độ tin cậy như API chính thức.

Kết luận thực tế

Nếu Waha đang khiến anh em phải reinstall nhiều lần, mình sẽ thử Evolution API, nhưng theo lộ trình:

• Không migrate toàn bộ ngay.
• Chạy song song với một số workflow ít rủi ro.
• Đo timeout, disconnect, duplicate, và thời gian khôi phục.
• Chuẩn hóa retry, logging, backup trước khi đưa vào production.

Trong automation, công cụ tốt không phải công cụ không bao giờ lỗi. Công cụ tốt là công cụ lỗi theo cách mình quan sát được, khôi phục được, và không kéo sập cả hệ thống khi nó gặp vấn đề.