Backend Tụt Sau Main: Phát Hiện Production Drift

TL;DR: Backend tụt sau main — tức backend chưa deploy kịp commit mới nhất trên main — là nguyên nhân phổ biến nhất gây ra production drift. Frontend deploy xong không có nghĩa backend đã theo kịp: hai bên chạy hai pipeline riêng trên hai nền tảng riêng, hoàn toàn có thể lệch pha nhau. Snapshot Production V2 phát hiện tình trạng này bằng cách so SHA backend, kiểm tra /health thật sự (không chỉ 200 OK), và phân biệt rõ cold-start Render với sự cố thật. Bài này giải thích vì sao drift nguy hiểm hơn cả sập hẳn, và cách xử lý khi thấy chỉ báo đỏ.

Có một lần mình ngồi xem lại log lỗi trên blog và phát hiện một thứ khá kỳ: giao diện load bình thường, mọi trang public đều mở được, nhưng phần bình luận lại im lặng không hiện gì cả — không lỗi to đùng, không trắng trang, chỉ là… không có gì xảy ra. Hoá ra frontend đã đổi sang gọi một route mới, còn backend tụt sau main — vẫn đang chạy bản cũ chưa kịp deploy. Hai bên nói chuyện với nhau bằng hai "ngôn ngữ" khác version, và đó chính là kiểu production drift mình muốn mổ xẻ trong bài này.

Đó chính là thứ mình muốn nói trong bài này: production drift. Nếu bạn chưa đọc bài mở đầu series, nên ghé qua Snapshot Production V2 theo dõi deploy status là gì trước, vì bài đó giải thích tổng quan công cụ và lý do mình xây nó ngay từ đầu.

Backend tụt sau main: vì sao production drift dễ xảy ra

Blog này chạy trên kiến trúc khá phổ biến với nhiều dự án hiện đại: phần frontend là một site tĩnh (Zola build ra HTML, deploy lên GitHub Pages), còn phần backend là một service FastAPI riêng biệt chạy trên Render, lo mấy việc như bình luận, đăng nhập, paywall, đo hiệu năng thực (RUM).

Hai mảnh này không hề biết đến sự tồn tại của nhau khi deploy:

• Frontend build xong, publish lên Pages — pipeline của GitHub Actions lo hết, xong là xong, không cần hỏi ý backend.
• Backend build image, khởi động lại service trên Render — pipeline riêng, thời gian riêng, có thể mất vài phút để service mới thật sự "sống".

Không có bước nào bắt hai pipeline này chờ nhau. Frontend có thể deploy xong trong 90 giây, trong khi backend đang giữa chừng rollout hoặc thậm chí đứng chờ trong hàng đợi build. Kết quả là tại một thời điểm bất kỳ, bạn hoàn toàn có thể có frontend mới nhất chạy song song với backend cũ hơn vài commit.

Điều quan trọng cần nhớ: "frontend deploy thành công" không nói lên bất kỳ điều gì về trạng thái backend. Đây là hai câu chuyện độc lập, và nếu chỉ nhìn dashboard deploy của một bên, bạn đang nhìn nửa bức tranh.

Drift trông như thế nào trong thực tế

Drift không ồn ào như một trang trắng 500. Nó âm thầm hơn nhiều, và đó mới là phần đáng sợ.

Vài kịch bản mình từng gặp hoặc hình dung ra rất dễ xảy ra:

• Frontend đã thêm nút bấm gọi tới một endpoint mới, nhưng backend production chưa có route đó → bấm vào, request trả về 404, người dùng chỉ thấy "không có gì xảy ra".
• Backend đổi shape của response (đổi tên field, đổi cấu trúc JSON), nhưng frontend cũ vẫn parse theo format cũ → dữ liệu hiện sai hoặc undefined, không throw lỗi rõ ràng nào cả.
• Frontend kỳ vọng một service cụ thể đã được mount trên backend (ví dụ module comment), nhưng bản backend đang chạy chưa bao gồm module đó → tính năng biến mất, không log lỗi nào bật lên vì về mặt kỹ thuật server vẫn "sống" và trả 200 cho các route khác.

So với việc site sập hẳn, drift nguy hiểm hơn theo một nghĩa cụ thể: nó cục bộ và dễ bị bỏ qua. Site vẫn load, trang chủ vẫn đẹp, Lighthouse vẫn xanh — chỉ có một tính năng nhỏ âm thầm hỏng. Nếu không có ai chủ động bấm thử đúng chỗ đó, drift có thể tồn tại nhiều giờ, thậm chí nhiều ngày, trước khi có người report.

Đây cũng là lý do tại sao chỉ đọc badge deploy tổng quát (kiểu đã nói ở bài đọc bảng deploy history D/B/A/F) là chưa đủ. Badge đó nói về lịch sử build, còn drift là câu hỏi về sự đồng bộ giữa hai hệ thống ngay lúc này.

Snapshot Production phát hiện drift bằng cách nào

Thay vì bắt mình phải mở terminal, gõ curl vào backend rồi tự đọc JSON, Snapshot Production V2 có riêng một card thông tin backend, làm ba việc:

1. Lấy SHA/version backend đang chạy và so với bản mà frontend hiện tại mong đợi. Nếu hai SHA không khớp nhau (backend chưa deploy commit mới nhất), card sẽ đánh dấu lệch.
2. Gọi /health, nhưng không dừng lại ở việc "trả về 200 là xong". Health check kiểu hời hợt như vậy dễ đánh lừa — process có thể sống nhưng router quan trọng lại chưa được mount đúng.
3. Xác nhận các service/route kỳ vọng thực sự tồn tại — ví dụ kiểm tra rằng module comment đã được mount, chứ không chỉ "server phản hồi một cái gì đó".

Cách tiếp cận health check "sâu" này khá gần với khuyến nghị chung của Render về health check — endpoint /health nên phản ánh đúng khả năng phục vụ của service, không chỉ việc process chưa crash (xem thêm tài liệu Render về health checks). Ba lớp kiểm tra trên gộp lại cho mình một tín hiệu rõ ràng: "hai bên đang đồng bộ" hay "có gì đó tụt lại phía sau", thay vì phải tự suy luận từ hai dashboard riêng biệt.

Cold-start vs sự cố thật — đừng hoảng khi thấy đỏ

Có một cái bẫy khác dễ gây hoang mang: Render ở các gói thấp (kể cả free tier) sẽ cho service "ngủ" sau một khoảng thời gian không có request. Request đầu tiên sau khi ngủ phải đánh thức lại container, việc này có thể mất khoảng 30 đến 60 giây.

Nếu đúng lúc đó bạn nhìn Snapshot Production và thấy backend báo lỗi, phản xạ đầu tiên rất dễ là nghĩ "chết rồi, backend down". Nhưng thường thì không phải vậy — đó chỉ là độ trễ khởi động, không phải sự cố.

Cách phân biệt khá đơn giản, mình tóm tắt lại thành bảng cho dễ nhớ:

Dấu hiệu	Cold-start (bình thường)	Sự cố thật
/health sau ~30-60s	Cuối cùng trả về OK	Vẫn lỗi hoặc timeout
Request tiếp theo	Nhanh trở lại bình thường	Vẫn chậm/lỗi liên tục
Tần suất xảy ra	Sau một khoảng dài không có traffic	Bất kể traffic, xảy ra ngẫu nhiên
SHA backend	Vẫn khớp với frontend	Có thể khớp hoặc không — không liên quan

Quy tắc mình tự đặt cho mình: nếu gọi lại /health vài lần trong vòng một phút mà cuối cùng nó trả về OK, đó là cold-start, không cần làm gì thêm. Nếu sau một phút vẫn không lên, lúc đó mới đáng để coi là sự cố cần xử lý.

Khi thực sự phát hiện drift — làm gì tiếp

Giả sử Snapshot Production báo rõ ràng: SHA backend cũ hơn commit frontend đang chạy, hoặc route kỳ vọng chưa xuất hiện. Đây là lúc cần một quy trình rõ ràng, không phải đoán mò:

1. Kích hoạt redeploy/sync backend thủ công trên Render — đừng chờ nó tự động bắt kịp, vì đôi khi pipeline backend cần một cú đẩy tay (do quota, do rate limit, hoặc do build queue).
2. Gọi lại /health sau khi redeploy hoàn tất, xác nhận nó trả về đúng trạng thái mong đợi — không chỉ 200 OK mà cả service/route cần thiết đã xuất hiện.
3. Quay lại Snapshot Production, kiểm tra chỉ báo drift đã chuyển xanh chưa. Đừng coi bước redeploy là xong việc — phải quay lại xác nhận bằng chính công cụ đã phát hiện ra vấn đề.

Nói cách khác, đây là một vòng lặp: phát hiện → xác nhận → sửa → xác nhận lại, không phải một hành động một lần rồi thôi. Bỏ qua bước xác nhận lại là cách phổ biến nhất khiến người ta tưởng đã fix nhưng thực ra drift vẫn còn đó dưới dạng khác.

Nguyên lý chung, không chỉ riêng blog này

Kiến trúc tách frontend/backend như blog này không phải chuyện hiếm — SPA gọi API riêng, site tĩnh dùng serverless function, mobile app gọi backend cloud... tất cả đều có cùng một rủi ro cấu trúc: hai (hoặc nhiều) service được deploy độc lập, mỗi bên tự báo "tôi thành công", nhưng không có gì đảm bảo chúng đang nói cùng một "ngôn ngữ" ở cùng một thời điểm.

Bài học ở đây không nằm ở công cụ cụ thể. Dù bạn dùng Snapshot Production, một dashboard tự viết, hay đơn giản là một script cron gọi health check định kỳ, nguyên tắc vẫn vậy: đừng coi "cả hai đều báo deploy OK" là bằng chứng cho việc chúng đồng bộ với nhau. Phải kiểm tra chéo — xác nhận version, xác nhận contract dữ liệu, xác nhận route/service thực sự tồn tại — như một bước riêng biệt, độc lập với việc từng service tự báo cáo trạng thái của chính nó.

Muốn xem toàn bộ các dấu hiệu deploy khác (không chỉ backend) và các bài liên quan trong series, bạn có thể ghé các bài Công nghệ khác trên blog.

Phát hiện được drift chỉ là nửa chặng đường — nửa còn lại là biến việc kiểm tra này thành thói quen sau mỗi lần merge, thay vì chỉ nhớ tới khi có sự cố. Phần tiếp theo và cũng là phần cuối của series, checklist theo dõi deploy sau khi merge đến khi production trả 200, sẽ gom tất cả những gì đã nói trong series này lại thành một danh sách thao tác cụ thể, dễ làm theo từng bước.