ওয়েব অ্যাপে ব্যাকগ্রাউন্ড জব কীভাবে চালাবেন: কিউ, শিডিউলার ও cron

ওয়েব অ্যাপে ব্যাকগ্রাউন্ড জব চালাতে প্রথমে কাজটিকে দুই ধরনে ভাগ করুন। ট্রিগারড জব (স্বাগত ইমেইল পাঠানো, আপলোড প্রক্রিয়া করা) একটি জব কিউ-তে রাখা যায়, প্রায়ই আপনার ডেটাবেসের একটি টেবিল, এবং একটি ওয়ার্কার রিট্রাই সহ সেটি চালায়। নির্ধারিত জব (রাতের রিপোর্ট, প্রতি ১৫ মিনিটের রিমাইন্ডার) এমন কিছু দরকার যা সময়সূচি অনুযায়ী চালু হয়: হোস্টের cron ফিচার, অথবা একটি বাইরের শিডিউলার যা আপনার অ্যাপের একটি সুরক্ষিত এন্ডপয়েন্ট ডাকে। সব সময় জবগুলো দুবার চললেও যেন নিরাপদ হয়, ব্যর্থতা রেকর্ড করুন, এবং এমন সার্ভারের ভেতরের টাইমারের ওপর কখনো নির্ভর করবেন না যা ঘুমাতে পারে বা রিস্টার্ট হতে পারে।

এই গাইড বিকল্পগুলো ব্যাখ্যা করে, কোনটি কখন মানায়, এবং শূন্যে নামা হোস্টসহ AI অ্যাপ বিল্ডার দিয়ে কীভাবে সেট আপ করবেন।

ব্যাকগ্রাউন্ড জব কী

যেকোনো ধীর, অনির্ভরযোগ্য বা ব্যবহারকারীর তাৎক্ষণিক সাড়ার জন্য দরকার নেই এমন কাজ:

• ইমেইল, বিজ্ঞপ্তি ও রসিদ পাঠানো
• ছবির আকার বদলানো, ভিডিও ট্রান্সকোড করা, PDF বানানো
• ধীর তৃতীয় পক্ষের API ডাকা, দীর্ঘ কাজের জন্য AI মডেলসহ
• অন্য সিস্টেম থেকে ডেটা আমদানি বা সিঙ্ক করা
• রাতের পরিষ্কার-পরিচ্ছন্নতা, রিপোর্ট ও রিমাইন্ডার

অনুরোধের ভেতরেই এগুলো করলে পেজ ধীর ও ভঙ্গুর হয়: ইমেইল প্রদানকারী বন্ধ থাকলে ব্যবহারকারীর সাইন-আপ ব্যর্থ হয়। ব্যাকগ্রাউন্ডে সরালে ব্যবহারকারী তাৎক্ষণিক সাড়া পান এবং জবটি আবার চেষ্টা করা যায়।

বিকল্পসমূহ

একটিমাত্র সঠিক উত্তর নেই। ছোট অ্যাপের প্রায়ই শুধু একটি ডেটাবেস কিউ ও একটি বাইরের শিডিউলার লাগে।

শূন্যে নামা হোস্ট কেন ছবিটি বদলায়

অনেক আধুনিক হোস্ট কেউ ব্যবহার না করলে আপনার অ্যাপকে ঘুম পাড়িয়ে দেয় এবং পরের অনুরোধে জাগায়। এটি টাকা বাঁচায়, কিন্তু একটি ঘুমন্ত সার্ভার কোনো কোড চালায় না: টাইমার চলে না, ওয়ার্কার পোল করে না। এসব হোস্টে নির্ধারিত কাজ একটি ইনকামিং অনুরোধ দিয়ে শুরু হতে হবে, আর সবচেয়ে সহজ উৎস একটি বাইরের শিডিউলার। প্রতিটি কল অ্যাপ (এবং প্রায়ই তার ডেটাবেস) জাগায়, তাই প্রতি মিনিটে ডাকলে প্রতি ১৫ মিনিটের চেয়ে বেশি খরচ হয়। প্রয়োজন পূরণ করে এমন সবচেয়ে ধীর সময়সূচি বেছে নিন।

প্যাটার্ন ১: একটি ডেটাবেস জব কিউ

ট্রিগারড জবের জন্য:

1. একটি jobs টেবিল বানান: টাইপ, পেলোড (JSON), অবস্থা (pending, running, done, failed), চেষ্টার সংখ্যা, run_after, last_error, সময়চিহ্ন।
2. কিছু ঘটলে, যে পরিবর্তন জবটি ট্রিগার করেছে তার একই ট্রানজেকশনে একটি জব সারি ঢোকান, যাতে দুটো একসঙ্গে সফল বা ব্যর্থ হয়।
3. একজন ওয়ার্কার সময়মতো জবগুলো নেয়, running চিহ্নিত করে, কাজ করে এবং done চিহ্নিত করে।
4. ব্যর্থ হলে attempts বাড়ান, run_after পরে সেট করুন (যেমন ১, ৫, তারপর ৩০ মিনিট) এবং ত্রুটি সংরক্ষণ করুন। সর্বোচ্চ সীমার পর জবটিকে failed চিহ্নিত করুন এবং কাউকে সতর্ক করুন।

একাধিক ওয়ার্কার একসঙ্গে চলতে পারলে জবগুলো নিরাপদে দখল (claim) করতে হবে। Postgres-এ SELECT ... FOR UPDATE SKIP LOCKED প্রতিটি ওয়ার্কারকে আলাদা সারি দখল করতে দেয়, একে অপরের সঙ্গে সংঘর্ষ না করে।

ওয়ার্কার চালায় কে? সবসময় চালু সার্ভারে, একটি আলাদা প্রসেসে একটি লুপ। শূন্যে নামা হোস্টে প্যাটার্ন ২-এর নির্ধারিত এন্ডপয়েন্ট প্রতিটি কলে সময়মতো জবের একটি ব্যাচ প্রক্রিয়া করতে পারে।

প্যাটার্ন ২: একটি বাইরের শিডিউলার যা আপনার অ্যাপ ডাকে

নির্ধারিত জবের জন্য:

1. একটি এন্ডপয়েন্ট যোগ করুন, যেমন POST /api/cron/send-reminders।
2. সুরক্ষিত রাখুন: একটি হেডারে গোপন টোকেন দাবি করুন, যা দুই পক্ষেই গোপন হিসেবে সংরক্ষিত, এবং অন্য সবকিছু প্রত্যাখ্যান করুন।
3. ইডেমপটেন্ট করুন: একই মিনিটে দুবার চললেও দুটি রিমাইন্ডার যেন না যায়। কী পাঠানো হয়েছে তা রেকর্ড করুন।
4. প্রতিটি কল ছোট রাখুন: একটি ব্যাচ (ধরুন ১০০টি আইটেম) প্রক্রিয়া করুন এবং বাকিগুলো পরের কল ধরবে।
5. একটি শিডিউলার সেটি লক্ষ্য করে দিন।

শিডিউলারের পছন্দ:

• GitHub Actions নির্ধারিত ওয়ার্কফ্লো। GitHub-এর ব্যবহারের সীমার মধ্যে বিনামূল্যে। GitHub-এর ডকুমেন্টেশন অনুযায়ী ২০২৬ সালের সেপ্টেম্বর পর্যন্ত সবচেয়ে ছোট ব্যবধান প্রতি ৫ মিনিটে একবার, ব্যস্ত সময়ে (বিশেষ করে প্রতি ঘণ্টার শুরুতে) রান বিলম্বিত হতে পারে, সময়সূচি ডিফল্টভাবে UTC-তে, এবং একটি পাবলিক রিপোজিটরির নির্ধারিত ওয়ার্কফ্লো রিপোজিটরিতে ৬০ দিন কার্যকলাপ না থাকলে বন্ধ হয়ে যায়।
• হোস্ট করা cron সার্ভিস। অনেক সার্ভিস আছে যাদের একমাত্র কাজ নির্ধারিত সময়ে একটি URL ডাকা। নির্ভর করার আগে নির্ভরযোগ্যতা, ন্যূনতম ব্যবধান ও সতর্কতা যাচাই করুন।
• আপনার ক্লাউড প্রদানকারীর শিডিউলার। আপনি যদি একটি বড় ক্লাউড প্রদানকারী ব্যবহার করেন, তার একটি ম্যানেজড শিডিউলার থাকবে যা একটি HTTPS এন্ডপয়েন্ট ডাকতে পারে।
• একটি হোস্ট করা জব বা ওয়ার্কফ্লো সার্ভিস। এগুলো শিডিউলিং, কিউ ও রিট্রাই একত্র করে এবং প্রতিটি ধাপে আপনার এন্ডপয়েন্ট ডাকে। প্রতিটি বিক্রেতার সাইটে দাম ও সীমা তুলনা করুন।

প্যাটার্ন ৩: প্রদানকারীকে দিয়ে করানো

কখনো সেরা ব্যাকগ্রাউন্ড জব কোনোটিই নয়:

• পেমেন্ট। Stripe ব্যর্থ সাবস্ক্রিপশন পেমেন্ট পুনরায় চেষ্টা করে এবং ওয়েবহুক পাঠায়; আপনি পোল করার বদলে প্রতিক্রিয়া দেখান। দেখুন ওয়েবহুক কী।
• ইমেইল। আপনি বার্তাটি দেওয়ার পর প্রদানকারীরা ডেলিভারি কিউতে রাখে এবং পুনরায় চেষ্টা করে।
• বড় AI কাজ। OpenAI ও Anthropic জরুরি নয় এমন অনুরোধের জন্য batch API দেয়, যা আপনি জমা দেন এবং পরে সংগ্রহ করেন।

আপনার AI বিল্ডারকে দেওয়ার প্রম্পট

কিউয়ের জন্য:

jobs টেবিল ব্যবহার করে আমাদের ডেটাবেসে একটি ব্যাকগ্রাউন্ড জব কিউ যোগ করো (টাইপ, পেলোড JSON, অবস্থা, চেষ্টার সংখ্যা, run_after, last_error)। কেউ সাইন-আপ করলে ইনলাইনে ইমেইল না পাঠিয়ে একই ট্রানজেকশনে একটি send_welcome_email জব ঢোকাও। একটি processJobs(limit) ফাংশন যোগ করো যা SELECT ... FOR UPDATE SKIP LOCKED দিয়ে দেয়-হওয়া জব দখল করে, চালায়, এবং ব্যর্থতা ১, ৫ ও ৩০ মিনিট পরে আবার চেষ্টা করে, চার বার চেষ্টার পর failed চিহ্নিত করে।

নির্ধারিত ট্রিগারের জন্য:

POST /api/cron/tick যোগ করো, যা CRON_SECRET গোপন থেকে নেওয়া একটি bearer টোকেন দিয়ে সুরক্ষিত; টোকেন ছাড়া সব অনুরোধ প্রত্যাখ্যান করো। প্রতিটি কল processJobs(100) চালাক এবং পরের ২৪ ঘণ্টায় দেয় এমন বুকিং রিমাইন্ডার পাঠাক যা এখনো পাঠানো হয়নি, পাঠানো রিমাইন্ডার রেকর্ড করে যাতে কিছু দুবার না যায়। চালানো কাজের একটি JSON সারাংশ ফেরত দাও। তারপর একটি GitHub Actions ওয়ার্কফ্লো লেখো যা প্রতি ১৫ মিনিটে এই এন্ডপয়েন্ট ডাকে, URL ও টোকেন রিপোজিটরির সিক্রেট থেকে পড়ে।

সাধারণ ভুল

• setInterval-এর ওপর নির্ভর। সার্ভার ঘুমালে বা রিস্টার্ট হলে নীরবে থেমে যায়, এবং দুটি কপি চললে দ্বিগুণ হয়।
• সুরক্ষাহীন cron এন্ডপয়েন্ট। যে কেউ এটি খুঁজে পেলে আপনার জব বা ইমেইল বিল চালাতে পারে।
• ইডেমপটেন্ট নয় এমন জব। রিট্রাই ও ডুপ্লিকেট শিডিউলার কল হবেই। সেভাবে ডিজাইন করুন।
• ব্যর্থতার কোনো দৃশ্যমানতা নেই। যে জব এক সপ্তাহ নীরবে ব্যর্থ হয় তা সশব্দে ব্যর্থ হওয়ার চেয়ে খারাপ। ত্রুটি লগ করুন এবং বারবার ব্যর্থতায় সতর্ক হোন।
• একটি একক অনুরোধে দীর্ঘ চালানো। অনুরোধের সময় শেষ হয়ে যায়। ব্যাচে প্রক্রিয়া করুন।
• খুব ঘন ঘন শিডিউল। শূন্যে নামা হোস্টে প্রতিটি কল অ্যাপ জাগায় ও বিল করে। ব্যবধান প্রকৃত প্রয়োজনের সঙ্গে মেলান।
• সময় অঞ্চল। “সকাল ৯টা” আপনার শিডিউলারের (প্রায়ই UTC) এবং আপনার ব্যবহারকারীদের কাছে আলাদা। সময় UTC-তে সংরক্ষণ করুন এবং প্রতি ব্যবহারকারীর জন্য রূপান্তর করুন।
• ওয়ার্কফ্লো ফাইলে গোপন তথ্য। টোকেন শিডিউলারের সিক্রেট স্টোরে রাখুন। দেখুন API key কীভাবে নিরাপদ রাখবেন।

চেকলিস্ট

• ধীর কাজ ব্যবহারকারীর অনুরোধ থেকে সরানো হয়েছে
• জবগুলো স্থায়ীভাবে সংরক্ষিত, শুধু মেমোরিতে নয়
• ক্রমবর্ধমান বিলম্ব ও সর্বোচ্চ সীমা সহ রিট্রাই
• প্রতিটি জব দুবার চললেও নিরাপদ
• নির্ধারিত এন্ডপয়েন্ট একটি গোপন টোকেন দিয়ে সুরক্ষিত
• প্রতিটি রান একটি সীমাবদ্ধ ব্যাচ প্রক্রিয়া করে
• ব্যর্থ জব দৃশ্যমান, সতর্কতা সহ
• হোস্টিং খরচ মাথায় রেখে শিডিউলের ব্যবধান বাছা হয়েছে
• সময় UTC-তে সংরক্ষিত

Mythex-এ ব্যাকগ্রাউন্ড জব

Mythex-এর ডকুমেন্টেশনে নির্ধারিত বা cron জবের কথা নেই, এবং প্রকাশিত অ্যাপ ও তার ডেটাবেস নিষ্ক্রিয় থাকলে ঘুমায় ও পরের অনুরোধে জাগে (দেখুন Hosting limits)। তাই অ্যাপের ভেতরের টাইমারের ওপর নির্ভর করবেন না। যে পদ্ধতি কাজ করে তা উপরে বলা হয়েছে: এজেন্টকে একটি জব টেবিল ও একটি টোকেন-সুরক্ষিত এন্ডপয়েন্ট বানাতে বলুন, তারপর একটি বাইরের শিডিউলার আপনার প্রকাশিত URL-এর দিকে নির্দেশ করুন। টোকেনটি প্রজেক্ট সিক্রেট হিসেবে সংরক্ষণ করুন, এবং মনে রাখবেন প্রতিটি জাগানোয় অ্যাপ ও ডেটাবেস জেগে থাকা সময়ের জন্য ক্রেডিট খরচ হয়, তাই যুক্তিসংগত ব্যবধান বেছে নিন। এর জন্য আপনার অ্যাপের একটি API ব্যাকএন্ড লাগলে, REST API backend রেসিপি একটি শুরুর বিন্দু, এবং এন্ডপয়েন্ট ডিজাইনের জন্য কীভাবে REST API বানাবেন দেখুন। যদি সবসময় চালু থাকা worker বা bot আপনার পণ্যের মূল হয়, তবে স্থায়ী প্রসেসের জন্য তৈরি হোস্ট বেশি উপযুক্ত হতে পারে।

প্রশ্নোত্তর