সমস্যা: Race Condition

এগুলো concurrency bug — শুধু তখনই দেখা দেয় যখন একাধিক প্রসেস একসাথে একই কাজ করে, আর ডেভেলপমেন্টে প্রায় কখনো ধরা পড়ে না।

লারাভেলের উত্তর: atomic lock — “এই মুহূর্তে শুধু একটি প্রসেসই এটা করতে পারবে।” মজার ব্যাপার হলো, যে মেকানিজম Cache::lock() চালায়, সেটাই overlapping job আটকায়, scheduled task দুবার চলা বন্ধ করে, Artisan command আলাদা রাখে, আর session write সিরিয়ালাইজ করে।

Atomic Lock কী?

Atomic lock হলো একটি নামযুক্ত রিসোর্সের উপর ‘mutually exclusive claim’:

লারাভেলের lock তৈরি cache layer-এর উপর। Store atomic অপারেশন সাপোর্ট করলে (Redis, Memcached, DynamoDB ইত্যাদি) একাধিক সার্ভার ও প্রসেস জুড়ে আসল distributed lock পাবেন।

$lock = Cache::lock('import-users', 10); // TTL = ১০ সেকেন্ড

if ($lock->get()) {
    try {
        processUsers();
    } finally {
        $lock->release(); // এরর হলেও lock ছেড়ে দেওয়া হবে
    }
}

Docs: Atomic Locks

Lock ব্যবহারের ৩টি ধরন

১. Lock না পেলে ইউজারকে জানানো

$lock = Cache::lock('process-payment-' . $user->id, 10);

if ($lock->get()) {
    try {
        $user->deductBalance(100);
        $order->process();
    } finally {
        $lock->release();
    }
} else {
    // অন্য কোনো প্রসেস এখন কাজ করছে
    return response('Please wait, another transaction is in progress.', 429);
}

২. Closure দিয়ে — অটো release

Cache::lock('foo', 10)->get(function () {
    // lock পেলে চলবে, শেষে লারাভেল নিজেই release করবে
});

৩. Block — lock পাওয়া পর্যন্ত অপেক্ষা

// সর্বোচ্চ ৩ সেকেন্ড অপেক্ষা; না পেলে LockTimeoutException
Cache::lock('foo', 10)->block(3, function () {
    // Business logic
});

Overlapping Queue Job আটকানো

একাধিক worker একসাথে job চালাতে পারে। একই ইউজারের দুটি job দুটি worker একসাথে ধরলে — ডুপ্লিকেট ইমেইল, ডাবল বিলিং বা নষ্ট স্টেট। সমাধান WithoutOverlapping middleware:

use Illuminate\Queue\Middleware\WithoutOverlapping;

public function middleware(): array
{
    return [
        (new WithoutOverlapping($this->userId))->expireAfter(60),
    ];
}

$this->userId দিয়ে key তৈরি হয় — এই key-এর একটি job-ই এক সময়ে চলবে। ভেতরে এটা Redis-এ রাখা সেই একই Cache::lock(), শুধু job middleware-এ মোড়ানো।

Docs: Preventing Job Overlaps

Unique Jobs: Dispatch-এর সময় Lock

WithoutOverlapping একসাথে চলা আটকায়। Unique job আরও এক ধাপ এগিয়ে — ডুপ্লিকেট job queue-তে ঢুকতেই দেয় না।

use Illuminate\Contracts\Queue\ShouldBeUnique;
use Illuminate\Contracts\Queue\ShouldQueue;

class ProcessPodcast implements ShouldQueue, ShouldBeUnique
{
    public $uniqueFor = 3600; // (ঐচ্ছিক) lock কতক্ষণ থাকবে

    public function __construct(public Podcast $podcast) {}

    public function uniqueId(): string
    {
        return $this->podcast->id; // কোন key-তে unique
    }
}

1. Dispatch-এর আগে লারাভেল lock নেয়।
2. Lock আগে থেকেই থাকলে job নীরবে বাদ।
3. Lock ফ্রি থাকলে job queue-তে যায় এবং lock ধরে রাখে।

কখন দরকার? যে webhook বারবার retry হয়, যে বাটনে ইউজার ৩ বার ক্লিক করে, যে cron worker-এর চেয়ে দ্রুত dispatch করে।

Docs: Unique Jobs

Task Scheduling

Scheduled task প্রায়ই ক্লাস্টারের প্রতিটি সার্ভারে চলে। সমন্বয় না থাকলে ৩ সার্ভারে summary:generate ৩ বার চলবে।

Schedule::command('summary:generate')
    ->everyMinute()
    ->withoutOverlapping();

Command চালানোর আগে লারাভেল lock নেয়। আগের রান শেষ না হলে নতুনটা স্কিপ। একই মেকানিজম, ভিন্ন প্রেক্ষাপট।

Docs: Preventing Task Overlaps

Isolatable Commands ও Migrations

Isolatable Artisan Commands

Command-এ Isolatable interface যোগ করলে, এক সময়ে শুধু একটি instance চলবে:

use Illuminate\Console\Command;
use Illuminate\Contracts\Console\Isolatable;

class ImportUsers extends Command implements Isolatable
{
    protected $signature = 'users:import';
    // ...
}

php artisan users:import --isolated

লারাভেল command-এর নাম দিয়ে lock তৈরি করে। এতে প্যারালাল import একে অপরকে নষ্ট করে না, cleanup task overlap হয় না, ডুপ্লিকেট রিপোর্ট হয় না — লোকালি (দুটি টার্মিনালে) এবং ডিস্ট্রিবিউটেড পরিবেশে দুই জায়গাতেই।

আর্গুমেন্ট অনুযায়ী আলাদা lock চাইলে isolatableId() মেথড ডিফাইন করুন।

Docs: Isolatable Commands

Isolated Migrations

একাধিক সার্ভারে ডিপ্লয়ের সময় দুটি সার্ভার একসাথে migration চালাতে পারে:

php artisan migrate --isolated

একটি সার্ভার migration চালায়, বাকিরা অপেক্ষা বা স্কিপ করে। Schema স্টেট সামঞ্জস্যপূর্ণ থাকে।

Docs: Running Migrations

Session Blocking

Session blocking lock দিয়ে প্রতি session-এ রিকোয়েস্টগুলো সিরিয়ালাইজ করে:

Route::post('/order', function () {
    // ...
})->block($lockSeconds = 10, $waitSeconds = 10);

এক session, এক lock, এক সময়ে এক রিকোয়েস্ট। Cart আপডেট বাগ আর মাল্টি-ট্যাব কনফ্লিক্ট দূর হয়।

Docs: Session Blocking

Lock ব্যবহারের আগে ভাবুন

Lock coordination overhead আনে — উদ্দেশ্যমূলকভাবে ব্যবহার করুন।

পুরো লারাভেলে Lock

সারসংক্ষেপ ও যাচাই

• Lock মানে: এক সময়ে এক প্রসেস, বাকিরা অপেক্ষা করে, TTL-এ অটো এক্সপায়ার।
• সবসময় try/finally-তে release করুন, অথবা closure ফর্ম ব্যবহার করুন।
• WithoutOverlapping চলা আটকায়; ShouldBeUnique queue-তে ঢোকা আটকায়।
• মাল্টি-সার্ভারে Redis-এর মতো atomic store লাগবে।
• Idempotent হলে lock নাও লাগতে পারে; lock থাকলেও invariant যাচাই করুন।

নিজেকে যাচাই করুন