AbortController, retry, debounce আর throttle — বাস্তব অ্যাপের async নকশা

১ · কেন “একটি await” যথেষ্ট নয় — বাস্তব অ্যাপের পাঁচটি সমস্যা

পর্ব ৩৩ থেকে ৩৫-এ আপনি Promise, async/await আর fetch শিখেছেন। টিউটোরিয়ালের উদাহরণে সবকিছু সুন্দর: একটি বোতাম, একটি request, একটি await, তারপর ফল দেখানো। কিন্তু একটি সত্যিকারের ই-কমার্স অ্যাপ চালু করলে প্রথম সপ্তাহেই পাঁচটি সমস্যা চোখে পড়বে।

এই পর্বের নকশাগুলো (pattern) কোনো লাইব্রেরি নয় — কয়েক লাইনের ধারণা। প্রায় সবগুলোই দাঁড়িয়ে আছে তিনটি জিনিসের ওপর, যা আপনি আগেই জানেন: closure (পর্ব ২২ — অবস্থা মনে রাখা), timer আর event loop (পর্ব ৩১–৩২), আর Promise (পর্ব ৩৩). নতুন একটিই মূল উপাদান লাগবে — বাতিল করার একটি সাধারণ ভাষা।

২ · AbortController আর AbortSignal — বাতিল করার সাধারণ ভাষা

Promise-এর একটি সীমাবদ্ধতা পর্ব ৩৩-এ হয়তো খেয়াল করেছেন: একবার তৈরি হলে বাইরে থেকে তাকে থামানোর কোনো method নেই। Promise শুধু একটি ভবিষ্যৎ ফলের প্রতিনিধি; যে কাজটি সেই ফল তৈরি করছে, তার নিয়ন্ত্রণ promise-এর হাতে নেই। তাই বাতিলের জন্য ওয়েব প্ল্যাটফর্ম একটি আলাদা, দুই-অংশের ব্যবস্থা দিয়েছে।

ভাগটি ইচ্ছাকৃত। Signal পাওয়া কোড শুধু শুনতে পারে, নিজে বাতিল করতে পারে না; বাতিলের ক্ষমতা থাকে যে controller তৈরি করেছে তার কাছে। একটি signal একাধিক কাজে দেওয়া যায় — একবার abort() করলে সবগুলো একসাথে থামে (যেমন একটি পাতা ছেড়ে যাওয়ার সময় সেই পাতার সব request). আর মনে রাখুন, বাতিল একমুখী: একবার aborted হলে signal আর কখনো আগের অবস্থায় ফেরে না। নতুন কাজের জন্য নতুন controller বানাতে হয়।

fetch-এ signal দেওয়া

const controller = new AbortController();
cancelBtn.onclick = () => controller.abort();      // ব্যবহারকারী “বাতিল” চাপলেন

try {
  const res = await fetch("/api/products?q=saree", { signal: controller.signal });
  showProducts(await res.json());
} catch (err) {
  if (err.name === "AbortError") return;          // নিজেরাই বাতিল করেছি — ভুল নয়
  showError(err);                                 // আসল নেটওয়ার্ক ভুল
}

নিজের async function-কে বাতিলযোগ্য করা

Signal কোনো জাদু নয় — এটি একটি সাধারণ EventTarget. যে function signal গ্রহণ করে, তাকে নিজেই তিনটি কাজ করতে হয়: শুরুতে দেখা আগেই বাতিল কি না, 'abort' event শোনা, আর বাতিল হলে নিজের সম্পদ (timer, listener, সংযোগ) পরিষ্কার করে reject করা। একটি বাতিলযোগ্য delay দেখুন — এটিই নিচের retry-এর ভিত্তি:

function delay(ms, signal) {
  return new Promise((resolve, reject) => {
    signal?.throwIfAborted();                  // আগেই বাতিল? তখনই reject
    const id = setTimeout(resolve, ms);
    signal?.addEventListener("abort", () => {
      clearTimeout(id);                        // timer-ও বন্ধ — নইলে বৃথা চলবে
      reject(signal.reason);                   // সাধারণত DOMException "AbortError"
    }, { once: true });
  });
}

এই নিয়মটিকে বলা হয় cooperative cancellation — বাতিল জোর করে চাপানো হয় না, কাজটি নিজে signal দেখে থামতে রাজি হয়। একটি লম্বা লুপ যদি signal কখনো না দেখে, abort() তাকে থামাতে পারবে না। তাই নিজের লম্বা async কাজে মাঝে মাঝে signal.throwIfAborted() ডাকুন — প্রতিটি await-এর পরে বা প্রতিটি ব্যাচের শুরুতে।

AbortSignal.timeout আর AbortSignal.any

দুটি তৈরি-করা static method কাজ অনেক সহজ করে। AbortSignal.timeout(5000) এমন একটি signal দেয়, যা ৫ সেকেন্ড পরে নিজেই বাতিল হয় — এবার reason-এর name হলো "TimeoutError", "AbortError" নয়। এতে আপনি আলাদা করতে পারেন: ব্যবহারকারী বাতিল করেছেন, না সময় শেষ হয়েছে। AbortSignal.any([a, b]) কয়েকটি signal জুড়ে একটি signal বানায়, যা যেকোনো একটি বাতিল হলেই বাতিল হয়:

const userCancel = new AbortController();
const signal = AbortSignal.any([userCancel.signal, AbortSignal.timeout(8000)]);
const res = await fetch("/api/order-status", { signal });
// বাতিল চাপলে → AbortError;  ৮ সেকেন্ড পেরোলে → TimeoutError

AbortSignal.timeout সব আধুনিক ব্রাউজার আর Node.js 18-এর পর থেকে নিশ্চিতভাবে আছে। AbortSignal.any নতুন — Chrome/Edge 116, Node.js 20.3 থেকে; পুরোনো ব্রাউজার সমর্থন করতে হলে দুটি signal-এর 'abort' event শুনে হাতে একটি নতুন controller বাতিল করুন।

একই signal আজ প্রায় সবখানে চলে: addEventListener(type, fn, { signal }) — signal বাতিল হলে listener নিজেই সরে যায় — থেকে Node.js-এর fs আর timers/promises পর্যন্ত। কেন বাতিল Promise-এর ভেতরে না রেখে আলাদা বস্তু বানানো হলো, সেই গল্প ভাবনার প্রশ্ন ৪-এ।

৩ · Timeout আর race condition — দেরিতে আসা পুরোনো উত্তর

Promise.race দিয়ে timeout — আর তার লুকানো দাম

AbortSignal.timeout আসার আগে timeout দেওয়ার প্রচলিত উপায় ছিল Promise.race (পর্ব ৩৩): আসল কাজ আর একটি টাইমার — যে আগে শেষ হয়, সেটিই জেতে।

function withTimeout(promise, ms) {
  let id;
  const timer = new Promise((_, reject) => {
    id = setTimeout(() => reject(new Error(`${ms}ms পেরিয়ে গেছে`)), ms);
  });
  return Promise.race([promise, timer]).finally(() => clearTimeout(id));
}
await withTimeout(loadReport(), 3000);   // ৩ সেকেন্ডে না এলে reject

Search-as-you-type: উত্তর আসে ভুল ক্রমে

এবার এই পর্বের সবচেয়ে বাস্তব বাগ। একটি পণ্য খোঁজার বক্সে প্রতিটি টাইপে একটি request যায়। ব্যবহারকারী লিখলেন “pa”, তারপর দ্রুত “panjabi”. দুটি request বেরোল। কিন্তু নেটওয়ার্ক ক্রম মানে না — “pa”-র ফলাফল বড় (হাজার পণ্য), তাই ধীরে এল; “panjabi”-র ফল ছোট, আগে এল। কোড প্রতিটি উত্তর আসামাত্র তালিকা আঁকে। ফল: ব্যবহারকারীর বক্সে লেখা “panjabi”, অথচ পর্দায় “pa”-র ফলাফল — কারণ পুরোনো উত্তরটি শেষে এসে নতুনটিকে মুছে দিয়েছে। একাধিক async কাজের শেষ হওয়ার ক্রমের ওপর ফল নির্ভর করলে, তাকে বলে race condition.

সমাধান দুটি, আর দুটিই কয়েক লাইনের। ১. আগেরটি বাতিল করুন — নতুন টাইপ এলে পুরোনো request abort করুন। এতে নেটওয়ার্কও বাঁচে:

let controller = null;
async function searchProducts(q) {
  controller?.abort();                       // আগের request বাতিল
  controller = new AbortController();
  try {
    const res = await fetch(`/api/search?q=${encodeURIComponent(q)}`,
                            { signal: controller.signal });
    renderList(await res.json());
  } catch (err) {
    if (err.name !== "AbortError") showError(err);
  }
}

২. পুরোনো উত্তর উপেক্ষা করুন — যেখানে কাজটি বাতিল করা যায় না (যেমন একটি তৃতীয় পক্ষের SDK), সেখানে প্রতিটি request-কে একটি ক্রমিক নম্বর দিন, আর উত্তর এলে দেখুন সেটি এখনো সবশেষ কি না:

let latest = 0;
async function searchProducts(q) {
  const id = ++latest;                       // এই request-এর নম্বর
  const items = await searchSdk(q);
  if (id !== latest) return;                 // ইতিমধ্যে নতুন request গেছে — ফেলে দিন
  renderList(items);
}

দুটি একসাথেও চলে, আর প্রায় সবসময় সাথে থাকে debounce (অংশ ৬) — যাতে প্রতিটি অক্ষরে request-ই না যায়।

৪ · Retry, exponential backoff আর jitter — বুঝে আবার চেষ্টা

অনেক ভুল ক্ষণস্থায়ী: মোবাইল টাওয়ার বদলের মুহূর্তে সংযোগ কেটে গেল, সার্ভার কয়েক সেকেন্ডের জন্য ব্যস্ত (503 Service Unavailable), বা আপনি সীমার বেশি অনুরোধ পাঠিয়েছেন (429 Too Many Requests). এমন transient error-এ একটু থেমে আবার চেষ্টা করলে প্রায়ই সফল হয়। কিন্তু retry ভুলভাবে করলে সমস্যা সারানোর বদলে বাড়ায়। তিনটি প্রশ্নের উত্তর আগে ঠিক করুন।

1. কোন ভুলে? নেটওয়ার্ক ভুল, 408, 429, 500, 502, 503, 504 — হ্যাঁ। 400 (ভুল ডেটা), 401/403 (অনুমতি নেই), 404 (নেই) — না; একশোবার পাঠালেও একই উত্তর আসবে। আর AbortError — কখনোই না, ব্যবহারকারী নিজে বাতিল করেছেন।
2. কোন কাজে? শুধু idempotent কাজে — যা একবার বা দশবার করলে ফল একই। GET (পড়া), PUT (একটি নির্দিষ্ট মান বসানো), DELETE idempotent; POST /orders নয়। প্রথম POST হয়তো সার্ভারে পৌঁছে অর্ডার তৈরিও করেছে, শুধু উত্তরটি পথে হারিয়েছে — আবার পাঠালে দুটি অর্ডার, দুবার টাকা কাটা। POST নিরাপদে retry করতে চাইলে সার্ভারকে একটি idempotency key দিন (একটি অনন্য id, যা দেখে সার্ভার একই অনুরোধ দ্বিতীয়বার করে না) — অনেক পেমেন্ট API এভাবেই কাজ করে।
3. কতক্ষণ পরে, কতবার? সাথে সাথে নয়, আর অসীমবার নয় — এখানেই backoff আর jitter.

Exponential backoff — প্রতিবার অপেক্ষা দ্বিগুণ

সার্ভার ব্যস্ত থাকলে সাথে সাথে আবার পাঠানো মানে তার ভার আরও বাড়ানো। তাই প্রতিটি ব্যর্থতার পরে অপেক্ষা বাড়াতে থাকুন: ১০০ ms, ২০০, ৪০০, ৮০০… — সূত্র base × 2^(n−1), সাথে একটি সর্বোচ্চ সীমা (cap) আর মোট চেষ্টার সীমা। একে বলে exponential backoff. একটি পেমেন্টের অবস্থা যাচাইয়ের নকল API ধরুন, যা প্রথম দুবার 503 দেয়, তৃতীয়বার সফল হয়:

1async function retry(task, tries = 3, base = 100) {2  for (let n = 1; ; n++) {3    try { return await task(n); }4    catch (err) {5      if (n === tries) throw err;6      const wait = base * 2 ** (n - 1);7      await delay(wait);8    }9  }10}

Jitter — সবাই একসাথে ফিরে আসবেন না

শুধু backoff-এ একটি গোপন সমস্যা আছে। ধরুন সার্ভার এক সেকেন্ডের জন্য পড়ে গেল, আর ঠিক তখন দশ হাজার ব্যবহারকারীর request ব্যর্থ হলো। সবার কোড একই নিয়মে ১০০ ms পরে আবার পাঠাবে — দশ হাজার request একই মুহূর্তে! তারপর ২০০ ms পরে আবার একসাথে। ঢেউয়ের মতো আঘাত সার্ভারকে সেরে উঠতে দেয় না — একে বলে thundering herd. সমাধান jitter: অপেক্ষার সময়ে এলোমেলোতা মেশানো। জনপ্রিয় “full jitter” রূপে অপেক্ষা = ০ থেকে min(cap, base × 2^(n−1))-এর মধ্যে একটি random সংখ্যা। এতে request-গুলো সময়ের ওপর ছড়িয়ে পড়ে।

সার্ভার নিজে বলে দিলে আরও ভালো: 429 বা 503 উত্তরের সাথে Retry-After header আসতে পারে — কত সেকেন্ড পরে (বা কোন তারিখ-সময়ে) আবার আসতে হবে। থাকলে নিজের হিসাবের বদলে সেটিই মানুন। এবার সব নিয়ম একসাথে, একটি বাস্তবধর্মী fetchWithRetry-এ (চালানো যায় না — নেটওয়ার্ক লাগে):

const RETRYABLE = new Set([408, 429, 500, 502, 503, 504]);

async function fetchWithRetry(url, options = {}, tries = 4) {
  for (let n = 1; ; n++) {
    let res;
    try {
      res = await fetch(url, options);
      if (!RETRYABLE.has(res.status) || n === tries) return res;   // সফল বা স্থায়ী ভুল
    } catch (err) {
      if (err.name === "AbortError" || n === tries) throw err;     // বাতিল কখনো retry নয়
    }
    const retryAfter = Number(res?.headers.get("Retry-After"));    // সেকেন্ডে, থাকলে
    const cap = Math.min(10_000, 200 * 2 ** (n - 1));
    const wait = retryAfter > 0 ? retryAfter * 1000 : Math.random() * cap;  // full jitter
    await delay(wait, options.signal);                              // অপেক্ষাও বাতিলযোগ্য
  }
}
// ব্যবহার: শুধু GET-এ, বা idempotency key থাকা POST-এ

এবার মূল ধারণাগুলো নিজে চালিয়ে দেখুন — বাতিলযোগ্য delay, দুবার ব্যর্থ হয়ে তৃতীয়বার সফল হওয়া নকল পেমেন্ট API, ব্যবহারকারীর বাতিল আর AbortSignal.timeout. আউটপুট যাতে প্রতিবার একই আসে, তাই এখানে jitter বন্ধ রাখা হয়েছে:

function delay(ms, signal) {
  return new Promise((resolve, reject) => {
    signal?.throwIfAborted();                       // আগেই বাতিল? তখনই reject
    const id = setTimeout(resolve, ms);
    signal?.addEventListener("abort", () => { clearTimeout(id); reject(signal.reason); }, { once: true });
  });
}
async function retry(task, tries = 3, base = 100) {
  for (let n = 1; ; n++) {
    try { return await task(n); } catch (err) {
      if (n === tries) throw err;                   // আর নয় — ভুল ওপরে যাক
      const wait = base * 2 ** (n - 1);             // 100, 200, 400 ...
      console.log(`চেষ্টা ${n}: ${err.message} — ${wait}ms পরে আবার`);
      await delay(wait);
    }
  }
}
const checkPayment = async (n) => {                 // নকল API: দুবার ব্যর্থ
  await delay(50);
  if (n < 3) throw new Error("503 Service Unavailable");
  return `চেষ্টা ${n}: পেমেন্ট সফল`;
};
retry(checkPayment).then(console.log);
const ac = new AbortController();
delay(5000, ac.signal).catch((e) => console.log("বাতিল:", e.name, ac.signal.aborted));
ac.abort();                                         // ব্যবহারকারী “বাতিল” চাপলেন
delay(5000, AbortSignal.timeout(120)).catch((e) => console.log("সময় শেষ:", e.name));

Circuit breaker — বারবার ব্যর্থ হলে কিছুক্ষণ চেষ্টাই নয়

Retry একটি request-এর জন্য ভালো। কিন্তু একটি সার্ভিস যদি পুরোপুরি মৃত হয়, প্রতিটি নতুন request তবুও তিনবার চেষ্টা করবে, প্রতিবার timeout পর্যন্ত অপেক্ষা করবে — ব্যবহারকারী বসে থাকবেন, মৃত সার্ভিস আরও চাপ খাবে। Circuit breaker বাড়ির বিদ্যুতের সার্কিট ব্রেকারের মতো: পরপর কয়েকটি ব্যর্থতা হলে সে “খুলে যায়” (open) — কিছুক্ষণ কোনো request পাঠানোই হয় না, সাথে সাথে ভুল বা cache-এর পুরোনো ডেটা ফেরত দেওয়া হয়। কিছুক্ষণ পরে সে “আধখোলা” (half-open) হয়ে একটি পরীক্ষামূলক request পাঠায়; সফল হলে আবার “বন্ধ” (closed). এটি মূলত সার্ভারের জগতের নকশা — বিস্তারিত ভাবনার প্রশ্ন ৩-এ।

৫ · একসাথে কয়টি — concurrency limit, batching আর dedupe

পর্ব ৩৩-এর Promise.all দিয়ে অনেক কাজ একসাথে চালানো যায়। কিন্তু Promise.all(images.map(upload)) লেখার মুহূর্তে সবগুলো upload একসাথে শুরু হয়ে যায় — map সবগুলো function ডেকে ফেলে, Promise.all শুধু অপেক্ষা করে। ১০টি ছবিতে হয়তো চলে যায়; ১০,০০০টি ফাইলে ব্রাউজার বা সার্ভার হাঁপিয়ে ওঠে, অনেক request 429 খায়, মেমরি ভরে যায়। দরকার একটি concurrency limit: একসাথে বড়জোর N টি কাজ, একটি শেষ হলে তবেই পরেরটি।

সবচেয়ে সহজ বাস্তবায়ন হলো “worker pool”: N জন কর্মী, আর একটি ভাগ করা কাজের তালিকা। প্রতিটি কর্মী একটি লুপে তালিকা থেকে পরের কাজ তুলে নেয়, শেষ করে, আবার তোলে — তালিকা ফুরোলে থামে। next++ নিয়ে দুই কর্মীর কাড়াকাড়ির ভয় নেই, কারণ JavaScript-এর কোড একটি thread-এ চলে আর await-এর মাঝখানে কেউ ঢুকতে পারে না (পর্ব ৩১)। ৩টি স্লটে ৬টি কাজ ধাপে ধাপে দেখুন — কাজগুলোর সময় আলাদা (A ৩০০ ms, B ১০০, C ২০০, D ১০০, E ২০০, F ১০০):

1async function mapWithConcurrency(items, limit, fn) {2  const results = new Array(items.length);3  let next = 0;4  async function worker() {5    while (next < items.length) {6      const i = next++;7      results[i] = await fn(items[i], i);8    }9  }10  await Promise.all(Array.from({ length: limit }, worker));11  return results;12}

বিক্রেতার ১০টি ছবি এক লাইনে: await mapWithConcurrency(files, 3, uploadImage) — একসাথে ৩টি upload, একটি শেষ হলে পরেরটি। বাস্তবে আরও দুটি জিনিস যোগ করুন: প্রতিটি কাজের ভুল try/catch-এ ধরে { ok: false, error } হিসেবে রাখুন (নইলে একটি ব্যর্থতা পুরো Promise.all ভেঙে দেয় — পর্ব ৩৩-এর allSettled-এর মতো আচরণ চান), আর একটি signal নিন যাতে “আপলোড বাতিল” চাপলে বাকি কাজ আর শুরু না হয়। npm-এর p-limit প্যাকেজ একই ধারণার একটি জনপ্রিয় রূপ।

Batching আর request deduplication

কখনো কখনো সমস্যা উল্টো: কাজ অনেক, কিন্তু প্রতিটি খুব ছোট। একটি পাতায় ৫০টি পণ্যের কার্ড, প্রত্যেকে আলাদাভাবে নিজের দাম চাইছে — ৫০টি request. Batching-এ কয়েক মিলিসেকেন্ড ধরে অনুরোধগুলো জমিয়ে একটিতে পাঠানো হয়: /api/prices?ids=1,2,3,…. GraphQL জগতের DataLoader লাইব্রেরি ঠিক এই কাজ করে।

আরেকটি সাধারণ অপচয়: একই পণ্যের জন্য একসাথে কয়েকটি অনুরোধ। পাতার হেডার, কার্ট আর “আপনার জন্য” অংশ — তিনটি component একই মুহূর্তে পণ্য ৪২-এর তথ্য চায়। তিনটি request পাঠানোর দরকার নেই; প্রথমটির promise-টিই বাকি দুজনকে দিয়ে দিন। একে বলে request deduplication — এটি আসলে পর্ব ২২-এর memoization, শুধু ফলের বদলে চলমান promise জমানো হচ্ছে:

const inFlight = new Map();                       // id → চলমান promise

function getProduct(id) {
  if (inFlight.has(id)) return inFlight.get(id);  // একই id-র request চলছে — সেটিই দিন
  const p = fetchProduct(id).finally(() => inFlight.delete(id));
  inFlight.set(id, p);
  return p;
}
// একসাথে getProduct(42) তিনবার → নেটওয়ার্কে একটিই request, তিনজন একই ফল পান

৬ · Debounce — ব্যবহারকারী থামা পর্যন্ত অপেক্ষা

এবার উল্টো দিকের সমস্যা: কাজ ধীর নয়, event খুব দ্রুত। একজন মানুষ সেকেন্ডে ৫–১০টি অক্ষর টাইপ করেন; input event প্রতিটি অক্ষরে আসে। “ঢাকা” লিখতে চারটি event — প্রতিটিতে একটি search request পাঠালে চারটির মধ্যে তিনটির উত্তর কেউ দেখবে না। Debounce-এর নিয়ম: event আসতে থাকলে অপেক্ষা করুন; শেষ event-এর পরে নির্দিষ্ট সময় (যেমন ৩০০ ms) চুপচাপ গেলে তবেই একবার চালান। প্রতিটি নতুন event ঘড়িটি আবার শূন্য থেকে শুরু করায়।

বাস্তবায়ন একটি closure-এ রাখা একটি timer id: প্রতিটি কলে আগের timer বাতিল, নতুন timer বসানো। চারটি কী-প্রেস — ০, ১০০, ২০০ আর ৬০০ ms-এ — আর ৩০০ ms অপেক্ষা দিয়ে ধাপে ধাপে দেখুন:

1function debounce(fn, wait) {2  let timer;3  return (...args) => {4    clearTimeout(timer);5    timer = setTimeout(() => fn(...args), wait);6  };7}8const search = debounce(callApi, 300);

Leading বনাম trailing: কখনো কখনো প্রথম event-এই সাথে সাথে চালানো দরকার, তারপর ভিড় থামা পর্যন্ত চুপ — যেমন একটি বোতামে দ্রুত দুবার ক্লিক: প্রথম ক্লিকেই কাজ হোক, পরেরগুলো উপেক্ষিত হোক। এটি leading debounce. Lodash-এর debounce(fn, wait, { leading, trailing, maxWait }) দুটোই দেয়; maxWait নিশ্চিত করে যে টানা event আসতে থাকলেও কাজটি একটি নির্দিষ্ট সময়ের বেশি আটকে থাকবে না। সাধারণ ব্যবহার: search box, autosave, resize শেষে layout হিসাব, আর “এই username পাওয়া যাবে কি না” যাচাই।

৭ · Throttle আর requestAnimationFrame — নির্দিষ্ট সময়ে বড়জোর একবার

Scroll করার সময় scroll event সেকেন্ডে কয়েক ডজন বার আসে, আর ব্যবহারকারী হয়তো কয়েক সেকেন্ড ধরে থামেনই না। এখানে debounce খারাপ: “স্ক্রল থামলে তবেই” মানে পুরো স্ক্রলের সময় পাতার উপরের অগ্রগতি-বার নড়বেই না। দরকার নিয়মিত হালনাগাদ, তবে প্রতিটি event-এ নয়। Throttle-এর নিয়ম: নির্দিষ্ট সময়ের জানালায় বড়জোর একবার চালান; মাঝের event বাদ। প্রতি ১০০ ms-এ একটি event আর ৩০০ ms সীমা দিয়ে দেখুন:

1function throttle(fn, limit) {2  let last = -Infinity;3  return (...args) => {4    const now = Date.now();5    if (now - last < limit) return;   // বাদ6    last = now;7    fn(...args);8  };9}

এবার দুটো একসাথে চালিয়ে দেখুন। টাইপিং আর scroll — দুটোই timer দিয়ে নকল করা হয়েছে, যাতে প্রতিবার একই আউটপুট আসে। এখানে throttle-টি timestamp-এর বদলে একটি “তালা” আর timer দিয়ে লেখা — এটিও খুব প্রচলিত রূপ:

function debounce(fn, wait) {
  let timer;
  return (...args) => {
    clearTimeout(timer);                          // আগের অপেক্ষা বাতিল
    timer = setTimeout(() => fn(...args), wait);  // নতুন করে গোনা শুরু
  };
}
function throttle(fn, limit) {
  let locked = false;
  return (...args) => {
    if (locked) return;                           // সময় হয়নি — বাদ
    locked = true;
    fn(...args);
    setTimeout(() => (locked = false), limit);
  };
}
const search = debounce((q) => console.log("সার্চ API:", q), 300);
[[0, "d"], [100, "dh"], [200, "dha"], [600, "dhaka"]]
  .forEach(([t, q]) => setTimeout(() => search(q), t));   // নকল টাইপিং

const onScroll = throttle((i) => console.log("scroll হ্যান্ডলার, ইভেন্ট", i), 350);
for (let i = 0; i < 10; i++) setTimeout(() => onScroll(i), i * 100);

“অর্ডার দিন” বোতাম — double-click থেকে বাঁচানো

অধৈর্য ব্যবহারকারী পেমেন্ট বোতামে দুবার চাপলে দুটি অর্ডার — এটি throttle-এর একটি বিশেষ রূপ, যেখানে “জানালা” হলো request শেষ হওয়া পর্যন্ত। সবচেয়ে পরিষ্কার সমাধান হলো request চলার সময় বোতামটিই নিষ্ক্রিয় রাখা, আর সার্ভারের জন্য একটি idempotency key পাঠানো:

const checkoutKey = crypto.randomUUID();        // এই চেকআউটের জন্য একটিই key
orderBtn.addEventListener("click", async () => {
  if (orderBtn.disabled) return;
  orderBtn.disabled = true;                       // দ্বিতীয় ক্লিক আর কাজ করবে না
  try {
    await placeOrder(cart, { idempotencyKey: checkoutKey });
    showSuccess();
  } finally {
    orderBtn.disabled = false;                    // ভুল হলেও বোতাম ফিরে আসে
  }
});

ব্রাউজারের এই সুরক্ষা ভালো অভিজ্ঞতার জন্য; আসল নিশ্চয়তা সার্ভারের, যে একই key দ্বিতীয়বার দেখলে নতুন অর্ডার না বানিয়ে আগের ফলটিই ফেরত দেয়। পর্ব ২২-এর once আর এখানের key — দুটো একসাথে থাকলে দুই স্তরের পাহারা।

requestAnimationFrame — পর্দা আঁকার তালে throttle

শুধু দৃশ্যমান কিছু হালনাগাদ করতে হলে (অগ্রগতি-বার, sticky header, টেনে আনা জিনিসের অবস্থান) মিলিসেকেন্ডের সীমার চেয়ে ভালো সঙ্গী হলো requestAnimationFrame. এটি callback চালায় ব্রাউজারের পরের ছবি আঁকার ঠিক আগে — সাধারণত পর্দার refresh rate-এর তালে (৬০ Hz পর্দায় প্রায় ১৬.৭ ms পরপর), আর লুকানো ট্যাবে থেমে যায়। একটি ফ্রেমে একবারের বেশি আঁকার কোনো মানে নেই, কারণ মানুষ তা দেখতেই পাবে না:

let scheduled = false;
window.addEventListener("scroll", () => {
  if (scheduled) return;                          // এই ফ্রেমের কাজ আগেই নির্ধারিত
  scheduled = true;
  requestAnimationFrame(() => {
    const max = document.body.scrollHeight - innerHeight;
    bar.style.width = (scrollY / max) * 100 + "%";  // পরের ফ্রেমের ঠিক আগে একবার
    scheduled = false;
  });
}, { passive: true });

৮ · Polling থেকে push, optimistic UI আর অফলাইন queue

সার্ভারের খবর কীভাবে পাবেন

ডেলিভারি রাইডার কোথায়, পেমেন্ট নিশ্চিত হলো কি না, নতুন মেসেজ এল কি না — এসব খবর সার্ভারে তৈরি হয়, কিন্তু HTTP-তে কথা শুরু করে সবসময় ব্রাউজার। চারটি প্রচলিত পথ:

Polling-এ এই পর্বের সব নকশা লাগে: setInterval-এর বদলে আগের উত্তরের পরে await delay(ms, signal) (ধীর সার্ভারে request জমে না), ব্যর্থতায় backoff, পাতা ছাড়লে বাতিল। SSE আর WebSocket বিস্তারিত পর্ব ৫১-এ।

Optimistic UI — আগে দেখান, পরে নিশ্চিত করুন

Facebook-এ লাইক চাপলে হৃদয়টি সাথে সাথে লাল হয় — সার্ভারের উত্তরের অপেক্ষা করে না। একে বলে optimistic update: সফল হবে ধরে নিয়ে UI আগেই বদলান, request পেছনে যাক; ব্যর্থ হলে আগের অবস্থায় ফিরিয়ে আনুন (rollback) আর জানান।

async function toggleLike(post) {
  const before = { liked: post.liked, count: post.count };
  post.liked = !post.liked;                       // ১. সাথে সাথে UI বদল
  post.count += post.liked ? 1 : -1;
  render(post);
  try {
    await api.setLike(post.id, post.liked);       // ২. পেছনে request (PUT — idempotent)
  } catch {
    Object.assign(post, before);                  // ৩. ব্যর্থ — আগের অবস্থায় ফেরত
    render(post);
    showToast("লাইক সেভ হয়নি, আবার চেষ্টা করুন");
  }
}

লক্ষ করুন, request-টি “লাইক টগল করা” নয়, বরং “liked = true বসানো” — idempotent; দ্রুত দুবার চাপলেও শেষ অবস্থাই জেতে। Optimistic UI তখনই মানায় যখন সফলতার সম্ভাবনা বেশি আর ভুল হলে ক্ষতি কম (লাইক, বুকমার্ক, তালিকা সাজানো)। টাকা পাঠানো বা অর্ডারে নয় — সেখানে সার্ভারের নিশ্চিতকরণের জন্য অপেক্ষা করুন।

অফলাইন হলে — কাজ জমিয়ে রাখার queue

নেটওয়ার্কহীন গ্রামে একজন মাঠকর্মী সার্ভের ফর্ম জমা দিচ্ছেন — কাজটি হারানো চলবে না। সমাধান একটি queue: কাজগুলো স্থানীয়ভাবে জমা রাখুন (পর্ব ৪০-এর IndexedDB), আর সংযোগ ফিরলে (online event) ক্রম মেনে একটি একটি করে retry-সহ পাঠান, প্রতিটির সাথে idempotency key. পাতা বন্ধ থাকলেও এটি করার উপায় — service worker — পর্ব ৪৪-এ।

// ইন্টারভিউ সংস্করণ — this আর argument দুটোই রক্ষা করে
function debounce(fn, wait, { leading = false } = {}) {
  let timer = null;
  return function (...args) {
    const callNow = leading && timer === null;
    clearTimeout(timer);
    timer = setTimeout(() => {
      timer = null;
      if (!leading) fn.apply(this, args);
    }, wait);
    if (callNow) fn.apply(this, args);
  };
}

function throttle(fn, limit) {
  let last = -Infinity;
  return function (...args) {
    const now = Date.now();
    if (now - last >= limit) { last = now; fn.apply(this, args); }
  };
}

৯ · AI-এর যুগে — AI-এর লেখা async নকশা যাচাই করা

“একটি retry function লিখে দাও” বললে AI কয়েক সেকেন্ডে চলার মতো কোড দেয়। কিন্তু এই নকশাগুলোর ভুল ডেমোতে ধরা পড়ে না; ধরা পড়ে হাজার ব্যবহারকারী আর ধীর সার্ভার একসাথে এলে। পাঁচটি ভুল বিশেষভাবে দেখুন।

AI-এর লেখা async নকশা হাতে পেলে — যাচাইয়ের চেকলিস্ট

• Retry শুধু ক্ষণস্থায়ী ভুলে; AbortError আর 4xx (429 ছাড়া) কখনো retry হয় না
• Retry হওয়া প্রতিটি কাজ idempotent, বা একটি idempotency key পাঠায়
• Backoff-এ jitter, cap আর সর্বোচ্চ চেষ্টার সংখ্যা আছে; Retry-After মানা হয়
• প্রতিটি দীর্ঘ কাজ একটি signal নেয়, আর বাতিল হলে timer ও listener পরিষ্কার করে
• Search বা পাতা বদলে আগের request বাতিল হয়, বা পুরোনো উত্তর উপেক্ষা করা হয় (race condition নেই)
• Debounce/throttle একবারই তৈরি হয় (প্রতি render-এ নয়), আর component সরানোর সময় বাতিল হয়
• অনেক কাজে concurrency-র সীমা আছে; Promise.race-এর timeout-এ হেরে যাওয়া কাজটিও থামানো হয়