Timeout ও Retry: deadline, backoff ও jitter

এই পাঠে যা শিখবেন

• Connect timeout ও total deadline আলাদা করুন
• Bounded backoff এবং jitter দিন
• Retry amplification ঠেকান

সমস্যা দিয়ে শুরু

Checkout পাঁচ dependency ডাকে। প্রতিটিতে তিন retry আছে, upstream service-ও তিনবার চেষ্টা করে। একটি payment slowdown-এ request সংখ্যা বহুগুণ বাড়ে। Worker busy, connection pool পূর্ণ, healthy dependency-ও ধীর হয়ে যায়।

সহজ করে বুঝি

Timeout অপেক্ষার সীমা; connect timeout connection স্থাপনের অংশে প্রযোজ্য। End-to-end deadline পুরো request budget। Retry সাময়িক failure সামলায়, কিন্তু side effect-এর unknown outcome বিবেচনা করতে হয়। Exponential backoff চেষ্টা বাড়লে অপেক্ষা বাড়ায়; jitter client-দের একসঙ্গে retry করা কমায়।

পরিচিত একটি উপমা

ফোনে দোকান না ধরলে সবাই ঠিক এক মিনিট পরে আবার ফোন করলে লাইন আবার ব্যস্ত হয়। আলাদা সামান্য সময়ে চেষ্টা এবং সর্বোচ্চ কয়েকবারের সীমা চাপ কমায়। দোকানে order ইতিমধ্যে নথিভুক্ত হলে নতুন order না দিয়ে আগের reference জিজ্ঞাসা করতে হয়।

নকশাটি দেখুন

sequenceDiagram
 participant C as Checkout
 participant S as Stock API
 C->>S: Attempt 1 deadline budget
 S-->>C: Temporary unavailable
 C->>C: Bounded jitter delay
 C->>S: Attempt 2 same operation identity
 S-->>C: Result
 C->>C: Stop within overall deadline

প্রথম failure-এর পরে retryযোগ্য কি না দেখা হয়। Delay মোট deadline-এর মধ্যেই গণনা হয়। দ্বিতীয় attempt একই operation identity রাখে। Budget শেষ হলে request থামে; user cancellation বা timeout দূরের side effect rollback করে না।

PHP ও Laravel-এ প্রয়োগ

Laravel HTTP Client-এর read-only GET উদাহরণ; retry closure শুধু connection failure-এ অনুমতি দেয়। Production-এ response code policy আলাদা করুন। নিচের তিন attempt-এর সম্ভাব্য সময় user-facing total budget-এর সঙ্গে মিলতে হবে; timeout প্রতি attempt-এ প্রযোজ্য।

use Illuminate\Support\Facades\Http;
use Illuminate\Http\Client\ConnectionException;
use Illuminate\Http\Client\PendingRequest;

$response = Http::connectTimeout(1)
    ->timeout(2)
    ->retry(
        3,
        fn (int $attempt, Exception $exception) =>
            random_int(50, min(500, 100 * (2 ** ($attempt - 1)))),
        fn (Exception $exception, PendingRequest $request) =>
            $exception instanceof ConnectionException,
    )
    ->get(config('services.stock.url').'/availability', [
        'product_id' => $productId,
    ]);
$response->throw();

এটি PHP 8.3+ ও Laravel 12-এর শিক্ষামূলক fragment; সম্পূর্ণ application নয়। সংশ্লিষ্ট route-এ authentication ও resource authorization প্রয়োগ করতে হবে। নিচের অনুশীলনে failure ইচ্ছা করে তৈরি করুন; শুধু সফল response দেখে correctness ধরে নেবেন না।

সুবিধা, সীমাবদ্ধতা ও trade-off

Retry brief network fault লুকাতে পারে, কিন্তু load ও tail latency বাড়ায়। Fail-fast dependency outage দ্রুত expose করে, কিন্তু transient recovery-এর সুযোগ কমায়। Read retry তুলনামূলক সহজ; payment POST-এ provider idempotency ছাড়া blind retry নয়।

সাধারণ ভুল

• সব 4xx error retry করা।
• প্রতিটি layer-এ স্বাধীন retry দিয়ে multiplication তৈরি করা।
• প্রতি attempt timeout-কে পুরো user request deadline ভাবা।

আরও একটু গভীরে

Retry budget total traffic-এর একটি সীমা রাখতে পারে। Server Retry-After দিলে policy মেনে চলুন, কিন্তু নিজের deadline ছাড়িয়ে নয়। Deadline propagation-এ downstream শুধু অবশিষ্ট সময় পাবে; already-expired কাজ শুরু করবে না।

Dependency-কে প্রথমবার connection reject এবং পরে success করতে দিন। Attempt count ও elapsed time log করুন। পরে সব attempt slow করে client deadline পেরোয় কি না দেখুন। Numeric timeout settings বাস্তব p99 ও user SLO দিয়ে tune করতে হবে, আন্দাজকে benchmark বলবেন না।

মনে রাখুন

• Retry resource খরচ করে।
• একটি স্তরে coordinated policy রাখুন।
• Unknown write outcome আলাদা সামলান।

নিজে চেষ্টা করুন

দুই সেকেন্ডের endpoint budget-এ database, stock API এবং response rendering-এর সময় ভাগ করুন। একটি retry fit না হলে কোন fallback বেছে নেবেন লিখুন।

নিজের বোঝা যাচাই করুন

1. Connect আর total একই?

না। Connection establishment মোট operation-এর একটি অংশ; response wait ও transfer আলাদা সময় নেয়।

2. Jitter কেন?

অনেক caller একই মুহূর্তে আবার চাপ দেওয়া কমাতে।

3. তিন retry মানে তিন সেকেন্ড?

না। Attempts, per-attempt timeout এবং backoff যোগ হয়; library count semantics-ও যাচাই করুন।

4. Validation error retry?

সাধারণত নয়। একই invalid input আবার পাঠালে সাময়িক সমস্যার মতো সারে না।

5. Timeout payment ব্যর্থ?

নিশ্চিত নয়। Provider commit করে থাকতে পারে; একই identity দিয়ে query বা safe retry দরকার।

আরও পড়ুন

• Laravel retries and timeouts
• AWS backoff and jitter