Vấn đề: chạy công việc theo lịch mà không thêm hạ tầng\n\nHầu hết ứng dụng cần có công việc xảy ra sau đó, hoặc theo lịch: gửi email nhắc, kiểm tra thanh toán hàng đêm, dọn bản ghi cũ, xây lại báo cáo, hoặc làm mới cache.\n\nBan đầu, dễ bị cám dỗ để thêm một hệ thống hàng đợi đầy đủ vì trông như cách “đúng” để làm tác vụ nền. Nhưng hàng đợi thêm nhiều thành phần phải vận hành: một dịch vụ khác để chạy, giám sát, triển khai và gỡ lỗi. Với một đội nhỏ (hoặc người sáng lập đơn lẻ), trọng lượng thêm này có thể làm chậm bạn.\n\nVậy câu hỏi thực sự là: làm sao chạy công việc theo lịch một cách đáng tin cậy mà không phải dựng thêm hạ tầng?\n\nMột cách thử đầu tiên phổ biến là đơn giản: thêm một cron gọi một endpoint, và endpoint đó làm công việc. Nó hoạt động cho đến khi không nữa. Khi bạn có nhiều hơn một server, deploy vào nhầm thời điểm, hoặc một job chạy lâu hơn dự kiến, bạn bắt đầu thấy lỗi khó hiểu.\n\nCông việc theo lịch thường hỏng theo vài cách có thể dự đoán:\n\n- Chạy đôi: hai server cả hai chạy cùng một task, dẫn đến hóa đơn tạo hai lần hoặc email gửi hai lần.\n- Bị mất: một lần gọi cron thất bại khi deploy và không ai để ý cho tới khi người dùng phàn nàn.\n- Lỗi im lặng: job lỗi một lần rồi không chạy lại vì không có kế hoạch thử lại.\n- Làm dở: job crash giữa chừng và để dữ liệu ở trạng thái lạ.\n- Không có dấu vết: bạn không thể trả lời “lần cuối chạy khi nào?” hoặc “đêm qua xảy ra gì?”.\n\nMô hình cron + database là con đường giữa. Bạn vẫn dùng cron để “đánh thức” theo lịch, nhưng bạn lưu ý định job và trạng thái job trong cơ sở dữ liệu để hệ thống có thể phối hợp, thử lại và ghi lại những gì đã xảy ra.\n\nNó phù hợp khi bạn đã có một cơ sở dữ liệu (thường là PostgreSQL), một số ít loại job, và bạn muốn hành vi dễ dự đoán với ít công việc vận hành. Nó cũng là lựa chọn tự nhiên cho ứng dụng xây nhanh trên stack hiện đại (ví dụ, React + Go + PostgreSQL).\n\nNó không phù hợp khi bạn cần thông lượng rất cao, job chạy lâu cần phát trực tiếp tiến độ, thứ tự nghiêm ngặt giữa nhiều loại job, hoặc fan-out nặng (hàng nghìn sub-task mỗi phút). Trong những trường hợp đó, một hàng đợi thực thụ và worker chuyên dụng thường đáng đầu tư hơn.\n\n## Ý tưởng cốt lõi bằng ngôn ngữ thông thường\n\nMô hình cron + database chạy công việc nền theo lịch mà không cần hệ thống hàng đợi đầy đủ. Bạn vẫn dùng cron (hoặc bất kỳ scheduler nào), nhưng cron không quyết định phải chạy gì. Nó chỉ đánh thức worker thường xuyên (một lần mỗi phút là phổ biến). Cơ sở dữ liệu quyết định công việc nào đến hạn và đảm bảo chỉ có một worker nhận mỗi job.\n\nHãy nghĩ nó như một bảng kiểm chung trên whiteboard. Cron là người vào phòng mỗi phút và hỏi: “Có ai cần làm gì không?” Cơ sở dữ liệu là whiteboard cho biết cái nào đến hạn, cái nào đã bị ai đó nhận, và cái nào đã xong.\n\nCác thành phần đơn giản:\n\n- Một trigger lịch chạy thường xuyên.\n- Một bảng jobs chứa “cái gì” và “khi nào” (thời điểm đến hạn), cùng trạng thái và số lần thử.\n- Một hoặc nhiều worker poll bảng, claim một job và thực hiện công việc.\n- Việc claim dùng khóa trong cơ sở dữ liệu để hai worker không lấy cùng một hàng.\n- Cơ sở dữ liệu là nguồn sự thật cho cái đã chạy, cái đã lỗi, và cái cần thử lại.\n\nVí dụ: bạn muốn gửi nhắc hóa đơn mỗi sáng, làm mới cache mỗi 10 phút, và dọn session cũ hàng đêm. Thay vì ba cron riêng (mỗi cron có nguy cơ chồng lấn và chế độ lỗi riêng), bạn lưu các entry job ở một chỗ. Cron khởi động cùng một quá trình worker. Worker hỏi Postgres: “Cái nào đến hạn bây giờ?” và Postgres trả lời bằng cách cho worker claim an toàn đúng một job tại một thời điểm.\n\nĐiều này mở rộng dần. Bạn có thể bắt đầu với một worker trên một server. Sau này, chạy năm worker trên nhiều server. Hợp đồng vẫn vậy: bảng là hợp đồng.\n\nSuy nghĩ thay đổi: cron chỉ là tiếng chuông đánh thức. Cơ sở dữ liệu là cảnh sát giao thông quyết định được phép chạy gì, ghi lại điều đã xảy ra, và cho bạn lịch sử rõ ràng khi có sự cố.\n\n## Thiết kế bảng jobs (một schema thực tế)\n\nMô hình này hiệu quả nhất khi cơ sở dữ liệu trở thành nguồn sự thật cho việc gì nên chạy, khi nào nên chạy, và lần gần nhất đã xảy ra điều gì. Schema không phức tạp, nhưng các chi tiết nhỏ (trường khóa và index phù hợp) tạo khác biệt khi tải tăng.\n\n### Một bảng hay hai?\n\nHai cách tiếp cận phổ biến:\n\n- Một bảng kết hợp khi bạn chỉ quan tâm trạng thái mới nhất của mỗi job (đơn giản, ít join).\n- Hai bảng khi bạn muốn tách rõ giữa “job này là gì” và “mỗi lần nó chạy” (lịch sử rõ ràng hơn, dễ debug hơn).\n\nNếu bạn dự đoán sẽ debug lỗi thường xuyên, giữ lịch sử. Nếu muốn thiết lập nhỏ nhất, bắt đầu với một bảng rồi thêm lịch sử sau.\n\n### Một schema thực tế (phiên bản hai bảng)\n\nDưới đây là bố cục thân thiện với PostgreSQL. Nếu bạn xây bằng Go với PostgreSQL, các cột này map tốt vào struct.\n\n\n\nMột vài chi tiết giúp đỡ sau này:\n\n- Giữ là một chuỗi ngắn để định tuyến (ví dụ ).\n- Lưu dưới dạng để dễ mở rộng mà không phải migrate.\n- là “thời điểm đến hạn tiếp theo”. Cron (hoặc script scheduler) đặt nó, worker tiêu thụ nó.\n- và cho phép worker claim job mà không đụng độ nhau.\n- nên ngắn và dễ đọc. Lưu stack trace ở nơi khác nếu cần.\n\n### Index bạn sẽ muốn\n\nKhông có index, worker sẽ phải scan quá nhiều. Bắt đầu với:\n\n- Index để tìm công việc đến hạn nhanh: \n- Index để giúp phát hiện lock hết hạn: \n- Tùy chọn: index phân mảnh cho công việc active (ví dụ status trong và )\n\nChúng giữ truy vấn “tìm job tiếp theo chạy được” nhanh ngay cả khi bảng lớn lên.\n\n## Khóa và claim job an toàn\n\nMục tiêu đơn giản: nhiều worker có thể chạy, nhưng chỉ một worker nên lấy một job cụ thể. Nếu hai worker xử lý cùng một hàng, bạn sẽ nhận email đôi, tính phí đôi, hoặc dữ liệu lộn xộn.\n\nCách an toàn là coi claim job như một “lease”. Worker đánh dấu job là locked trong cửa sổ thời gian ngắn. Nếu worker crash, lease hết hạn và worker khác có thể lấy nó. Đó là mục đích của .\n\n### Dùng lease để crash không chặn công việc mãi mãi\n\nNếu không có lease, worker có thể lock job và không bao giờ unlock (process bị kill, server reboot, deploy lỗi). Với , job lại có sẵn khi thời gian trôi qua.\n\nQuy tắc phổ biến: job có thể được claim khi là hoặc .\n\n### Claim job bằng một cập nhật nguyên tử\n\nĐiểm quan trọng là claim job trong một câu lệnh đơn (hoặc một transaction). Bạn muốn database làm trọng tài.\n\nĐây là pattern PostgreSQL phổ biến: chọn một job đến hạn, khóa nó, và trả nó về cho worker. (Ví dụ này dùng một bảng ; cùng ý áp dụng cho .)\n\n\n\nTại sao nó hoạt động:\n\n- cho phép nhiều worker cạnh tranh mà không chặn nhau.\n- Lease được đặt khi claim, nên worker khác bỏ qua cho đến khi lease hết hạn.\n- đưa hàng cho worker thắng cuộc.\n\n### Thời lượng lease nên là bao lâu, và làm sao gia hạn?\n\nĐặt lease dài hơn thời gian chạy bình thường, nhưng đủ ngắn để crash phục hồi nhanh. Nếu hầu hết job xong trong 10 giây, lease 2 phút là dư.\n\nVới task dài, gia hạn lease trong khi chạy (heartbeat). Cách đơn giản: mỗi 30 giây, kéo dài nếu bạn vẫn sở hữu job.\n\n- Độ dài lease: 5x đến 20x thời gian job điển hình\n- Khoảng heartbeat: 1/4 đến 1/2 lease\n- Cập nhật gia hạn nên có \n\nĐiều kiện cuối cùng quan trọng. Nó ngăn worker kéo dài lease của job mà nó không còn sở hữu.\n\n## Thử lại và backoff hoạt động có thể dự đoán\n\nThử lại là nơi mô hình này hoặc khiến bạn yên tâm hoặc biến thành mớ hỗn độn. Mục tiêu đơn giản: khi job lỗi, thử lại sau theo cách bạn có thể giải thích, đo lường và dừng.\n\nBắt đầu bằng cách làm trạng thái job rõ ràng và giới hạn: , , , , . Trong thực tế, hầu hết đội dùng để nghĩa là “thất bại nhưng sẽ thử lại” và nghĩa là “thất bại và bỏ cuộc”. Phân biệt này ngăn vòng lặp vô hạn.\n\nĐếm số lần thử là biện pháp bảo vệ thứ hai. Lưu (đã thử bao nhiêu lần) và (cho phép bao nhiêu lần). Khi worker bắt lỗi, nó nên:\n\n- tăng \n- đặt trạng thái thành nếu , nếu không thì \n- tính cho lần thử tiếp theo (chỉ cho )\n\nBackoff chỉ là quy tắc quyết định kế tiếp. Chọn một, ghi lại, và giữ nhất quán:\n\n- Delay cố định: luôn chờ 1 phút\n- Lũy thừa: 1m, 2m, 4m, 8m\n- Lũy thừa với giới hạn: lũy thừa nhưng không quá, ví dụ 30m\n- Thêm jitter: làm ngẫu nhiên một chút để các job không đồng loạt thử lại cùng giây\n\nJitter quan trọng khi một phụ thuộc sập rồi hồi. Không có nó, hàng trăm job có thể thử lại cùng lúc và lại fail.\n\nLưu đủ chi tiết lỗi để làm cho việc gỡ lỗi dễ thấy. Bạn không cần hệ thống logging đầy đủ, nhưng cần những cơ bản:\n\n- (thông điệp ngắn, an toàn để hiển thị trong admin)\n- hoặc (giúp nhóm lỗi)\n- và \n- tùy chọn (chỉ nếu bạn quản lý kích thước)\n\nQuy tắc cụ thể hoạt động tốt: đánh dấu job sau 10 lần thử, và backoff theo cấp số nhân với jitter. Điều này giữ cho lỗi tạm thời thử lại, nhưng ngăn job hỏng tiêu tốn CPU vô hạn.\n\n## Idempotency: ngăn trùng lặp ngay cả khi job lặp lại\n\nIdempotency nghĩa là job của bạn có thể chạy hai lần mà vẫn cho kết quả cuối cùng giống nhau. Trong mô hình này, nó quan trọng vì cùng một hàng có thể bị lấy lại sau crash, timeout, hoặc retry. Nếu job của bạn là “gửi email hóa đơn”, chạy hai lần không phải vô hại.\n\nCách thực tế suy nghĩ: tách mỗi job thành (1) thực hiện công việc và (2) áp dụng hiệu ứng. Bạn muốn phần hiệu ứng chỉ xảy ra một lần, ngay cả khi phần thực hiện được thử nhiều lần.\n\n### Dùng idempotency key gắn với sự kiện nghiệp vụ\n\nIdempotency key nên xuất phát từ cái job đại diện, không phải từ lần thử của worker. Key tốt là ổn định và dễ giải thích, như , , hoặc . Nếu hai lần thử job tham chiếu cùng một sự kiện thực tế, chúng nên chia sẻ cùng key.\n\nVí dụ: “Tạo báo cáo doanh số hàng ngày cho 2026-01-14” có thể dùng . “Thu tiền hóa đơn 812” có thể dùng .\n\n### Áp dụng "chỉ một lần" bằng ràng buộc database\n\nBiện pháp đơn giản nhất là để PostgreSQL từ chối bản sao. Lưu idempotency key ở nơi có thể index, rồi thêm ràng buộc unique.\n\n\n\nĐiều này ngăn hai hàng có cùng key tồn tại cùng lúc. Nếu thiết kế bạn cho phép nhiều hàng (để lưu lịch sử), đặt unique trên bảng “effects” thay vào đó, như hoặc .\n\nCác side effect phổ biến cần bảo vệ:\n\n- Email: tạo một hàng với key duy nhất trước khi gửi, hoặc ghi lại message id của provider khi gửi xong.\n- Webhook: lưu và bỏ qua nếu đã tồn tại.\n- Thanh toán: luôn dùng tính năng idempotency của nhà cung cấp thanh toán cộng với unique key trong DB của bạn.\n- Ghi file: ghi vào tên tạm, rồi rename, hoặc lưu bản ghi “file_generated” có key theo .\n\nNếu bạn xây trên stack Postgres-backed (ví dụ backend Go + PostgreSQL), các kiểm tra uniqueness này nhanh và dễ đặt gần dữ liệu. Ý tưởng chính: retry là bình thường, trùng lặp là thứ bạn kiểm soát.\n\n## Bước từng bước: xây worker và scheduler tối thiểu\n\nChọn một runtime nhàm chán và bám theo nó. Điểm của mô hình cron + database là ít thành phần, nên một process nhỏ bằng Go, Node, hoặc Python kết nối PostgreSQL thường là đủ.\n\n### Xây trong năm bước nhỏ\n\n1) Thêm bảng (và các bảng lookup bạn cần sau), rồi index , và thêm index giúp worker tìm job nhanh (ví dụ trên ).\n\n2) Ứng dụng của bạn chèn một hàng với là “now” hoặc thời điểm tương lai. Giữ payload nhỏ và dự đoán được (IDs và job type, không phải blob lớn).\n\n\n\n3) Chạy trong transaction. Chọn vài job đến hạn, khóa chúng để worker khác bỏ qua, và đánh dấu trong cùng transaction.\n\n\n\n4) Với mỗi job đã claim, thực hiện công việc, rồi cập nhật thành với . Nếu fail, ghi lỗi và chuyển nó về với mới (theo backoff). Giữ các cập nhật finalize nhỏ và luôn chạy chúng, ngay cả khi process sắp tắt.\n\n5) Dùng công thức đơn giản như , và dừng sau bằng cách đặt .\n\n### Thêm khả năng quan sát cơ bản\n\nBạn không cần dashboard đầy đủ ngày đầu, nhưng cần đủ để nhận ra vấn đề.\n\n- Log một dòng cho mỗi job: claimed, succeeded, failed, retried, dead.\n- Tạo query hoặc view đơn cho “dead jobs” và “running lâu”.\n- Alert khi số lượng lớn (ví dụ hơn N dead jobs trong giờ vừa qua).\n\nNếu bạn đã dùng stack Go + PostgreSQL, điều này map trực tiếp thành một binary worker duy nhất cộng cron.\n\n## Một ví dụ thực tế để bạn sao chép\n\nTưởng tượng một app SaaS nhỏ với hai việc theo lịch:\n\n- Dọn dẹp nightly xóa session hết hạn và file tạm.\n- Email "báo cáo hoạt động của bạn" hàng tuần gửi đến mỗi user vào sáng thứ Hai.\n\nGiữ đơn giản: một bảng PostgreSQL chứa jobs, và một worker chạy mỗi phút (được cron kích hoạt). Worker claim job đến hạn, chạy, và ghi lại thành công hoặc lỗi.\n\n### Cái gì được enqueue, và khi nào\n\nBạn có thể enqueue jobs từ vài nơi:\n\n- Hàng ngày lúc 02:00: enqueue một job cho “hôm nay”.\n- Khi signup: enqueue một job cho Monday tiếp theo của user.\n- Sau một sự kiện (ví dụ “user bấm Export report”): enqueue chạy ngay cho khoảng ngày cụ thể.\n\nPayload chỉ là tối thiểu worker cần. Giữ nhỏ để dễ retry.\n\n\n\n### Idempotency ngăn gửi đôi như thế nào\n\nWorker có thể crash ở thời điểm tệ nhất: ngay sau khi gửi email nhưng trước khi đánh dấu job là “done”. Khi nó khởi động lại, nó có thể lấy lại cùng job.\n\nĐể ngăn gửi đôi, cho công việc một khóa dedupe tự nhiên và lưu nó nơi database có thể bắt buộc. Với báo cáo hàng tuần, key tốt là . Trước khi gửi, worker ghi “tôi sắp gửi báo cáo X”. Nếu bản ghi đó đã tồn tại, worker bỏ qua gửi.\n\nViệc này có thể đơn giản như một bảng với ràng buộc unique trên , hoặc một duy nhất trên chính job.\n\n### Một lỗi trông như thế nào (và cách phục hồi)\n\nVí dụ nhà cung cấp email timeout. Job fail, nên worker:\n\n- tăng \n- lưu thông điệp lỗi để debug\n- lên lịch thử lại theo backoff (ví dụ: +1 min, +5 min, +30 min, +2 hours)\n\nNếu tiếp tục fail quá giới hạn (ví dụ 10 attempts), đánh dấu và dừng retry. Job hoặc sẽ thành công một lần, hoặc sẽ thử lại theo lịch rõ ràng, và idempotency làm cho retry an toàn.\n\n## Sai lầm phổ biến và bẫy\n\nMô hình cron + database đơn giản, nhưng sai nhỏ có thể biến nó thành trùng lặp, công việc kẹt, hoặc tải bất ngờ. Phần lớn vấn đề xuất hiện sau crash, deploy, hoặc spike traffic đầu tiên.\n\n### Sai lầm gây trùng lặp hoặc job kẹt\n\nHầu hết sự cố thực tế đến từ vài bẫy sau:\n\n- Chạy cùng job từ nhiều cron entry mà không có lease. Nếu hai server tick cùng phút, cả hai có thể claim cùng công việc trừ khi bước claim là nguyên tử và đặt lock (hoặc lease) trong cùng transaction.\n- Bỏ qua . Nếu worker crash sau khi claim job, hàng đó có thể ở trạng thái “in progress” mãi mãi. Timestamp lease cho phép worker khác lấy lại sau.\n- Thử lại ngay lập tức khi lỗi. Khi một API xuống, retry tức thì tạo spike, cháy rate limit, và lại fail. Luôn lên lịch thử lại vào tương lai.\n- Xem “ít nhất một lần” (at least once) như “chính xác một lần” (exactly once). Job có thể chạy hai lần (timeout, restart, network). Nếu lặp lại gây hại, làm cho side effects an toàn khi lặp lại.\n- Lưu payload lớn trong hàng job. JSON lớn làm phình bảng, làm chậm index, và khiến việc khóa nặng hơn. Lưu tham chiếu (ví dụ , , hoặc khoá file) rồi fetch khi chạy.\n\nVí dụ: gửi email hóa đơn hàng tuần. Nếu worker timeout sau khi gửi nhưng trước khi đánh dấu job xong, cùng job có thể retry và gửi trùng. Đó là bình thường cho mô hình này trừ khi bạn thêm biện pháp bảo vệ (ví dụ, ghi event "email sent" duy nhất theo invoice id).\n\n### Những bẫy ít rõ ràng hơn\n\nTránh trộn scheduling và thực thi trong cùng transaction dài. Nếu bạn giữ transaction mở trong khi gọi network, bạn giữ khóa lâu hơn cần thiết và chặn worker khác.\n\nChú ý lệch đồng hồ giữa máy. Dùng thời gian database ( trong PostgreSQL) làm nguồn sự thật cho và , không phải đồng hồ server app.\n\nĐặt thời gian chạy tối đa rõ ràng. Nếu job có thể chạy 30 phút, làm lease dài hơn và gia hạn nếu cần. Nếu không, worker khác có thể lấy giữa chừng.\n\nGiữ bảng job khỏe mạnh. Nếu job đã hoàn thành chất đống mãi, truy vấn chậm và tranh chấp khóa tăng. Chọn quy tắc giữ liệu đơn giản (archive hoặc xóa các hàng cũ) trước khi bảng quá lớn.\n\n## Checklist nhanh và bước tiếp theo\n\n### Checklist nhanh\n\nTrước khi đưa mô hình này vào dùng, kiểm tra những điều cơ bản. Bỏ quên nhỏ thường biến thành job kẹt, trùng lặp bất ngờ, hoặc worker dội database.\n\n- Bảng jobs có các trường thiết yếu: , , , , và (cùng hoặc tương tự để thấy chuyện gì đã xảy ra).\n- Mỗi job có thể chạy hai lần mà không gây hại. Nếu không chắc, thêm idempotency key hoặc ràng buộc duy nhất quanh side effect (ví dụ, một hóa đơn cho ).\n- Có nơi rõ để quan sát lỗi và quyết định: xem job thất bại, chạy lại một job, hoặc đánh dấu dead khi nên dừng.\n- Thời gian lease hợp lý cho công việc. Nó nên đủ dài cho chạy bình thường, nhưng đủ ngắn để worker crash không chặn tiến trình vài giờ.\n- Retry backoff có thể dự đoán. Nó nên làm chậm các lỗi lặp lại và dừng sau .\n\nNếu các điều này đúng, mô hình cron + database thường ổn cho workloads thực tế.\n\n### Bước tiếp theo\n\nKhi checklist ổn, tập trung vào vận hành hằng ngày.\n\n- Thêm hai hành động quản trị nhỏ: “retry now” (đặt và xóa lock) và “cancel” (chuyển sang trạng thái terminal). Chúng cứu thời gian khi xử lý sự cố.\n- Worker log một dòng mỗi job: job type, job id, attempt number, và kết quả. Thêm alert khi số lỗi tăng.\n- Load test với spike thực tế: nhiều job cho cùng một phút. Nếu việc claim job chậm, thêm index phù hợp (thường là ).\n\nNếu bạn muốn dựng nhanh kiểu này, Koder.ai (koder.ai) có thể giúp bạn đi từ schema đến một app Go + PostgreSQL triển khai được với ít công việc nối dây hơn, để bạn tập trung vào khóa, retry, và quy tắc idempotency.\n\nNếu sau này bạn vượt quá giới hạn của thiết lập này, bạn vẫn hiểu rõ vòng đời job, và các ý tưởng này dễ chuyển sang một hệ thống hàng đợi đầy đủ hơn.
