পাঠ্যক্রম খুলুন

অগ্রসর পর্যায়

Tenant-Aware Operations: cache, queue, quota ও migration

Tenant-Aware Cache, Queues, Quotas, and Migrations

এই পাঠের কুইজ ↓৫ মিনিট পড়াPHP 8.3+ · Laravel 12

আগে পড়ে নিনMulti-Tenant SaaS: এক product-এ tenant data isolation ↗

এই পাঠের সূচিপত্র

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

Cache queue ও quota-তে tenant context রাখুন
Noisy neighbor আলাদা করুন
Tenant migrations পর্যবেক্ষণ করুন

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

বড় customer দশ লাখ report job queue-তে দিল। ছোট customer-এর password email আটকে গেল। আর tenant A-এর dashboard cache tenant B-তেও দেখা যাচ্ছে, কারণ key শুধু dashboard। Database isolation থাকলেও operational resource shared হওয়ায় নতুন সমস্যা এসেছে।

সহজ করে বুঝি

Tenant-aware operations data boundary-এর পাশাপাশি compute, queue, cache ও rate budget আলাদা করে। Job payload tenant identity বহন করে, handler scoped query চালায়। Quota workload সীমিত করে; fairness ছোট tenant-এর starvation কমায়। Cache key এবং lock key-তেও tenant scope থাকে।

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

এক apartment-এর বাসিন্দা সব lift সারাদিন আটকে রাখলে অন্যরা ব্যবহার করতে পারে না। Shared resource আছে বলেই usage policy দরকার। চিঠির বাক্সে flat number না দিলে ঠিকানা ভুল হয়; queue job এবং cache key-তেও একই পরিচয় জরুরি।

নকশাটি দেখুন

Diagram লোড হচ্ছে…

Cache queue ও quota-তে tenant context রাখুন

Diagram-এর text flow দেখুন

flowchart LR
 R[Tenant Request] --> Q[Per Tenant Quota]
 Q --> J[Job with Tenant ID]
 J --> P[Fair Worker Pools]
 P --> D[(Tenant Scoped Database)]
 P --> C[Cache tenant:id:version]

Request-এর আগে verified tenant quota প্রযোজ্য। Job explicit tenant ID বহন করে। Worker tenant context যাচাই করে এবং কাজ শেষে reset করে, বিশেষত long-lived process-এ। Cache key version schema change-এ পুরোনো representation এড়াতে সাহায্য করে।

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

Laravel job handle fragment; tenantId constructor-এর serialized trusted field এবং user membership rechecked where required। Query tenant-scoped। Cache configured shared Redis store। Report data authorization-sensitive হলে cache payload-এ user permission scope-ও যুক্ত করতে হবে।

use Illuminate\Support\Facades\Cache;
use Illuminate\Support\Facades\DB;

$key = 'tenant:'.$tenantId.':sales-summary:v2';
$summary = Cache::remember($key, 60, function () use ($tenantId) {
    return DB::table('orders')
        ->where('tenant_id', $tenantId)
        ->where('status', 'paid')
        ->selectRaw('COUNT(*) AS orders_count, SUM(total_minor) AS total_minor')
        ->first();
});
logger()->info('tenant.summary.generated', [
    'tenant_id' => $tenantId,
    'cache_key_version' => 2,
]);
// Quotas and worker-pool fairness are additional, separately configured controls.

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

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

Isolation বেশি করলে fairness ও incident containment বাড়ে, কিন্তু প্রতি tenant worker চালালে idle resource খরচ হতে পারে। Shared pools সঙ্গে per-tenant admission control মধ্যপথ। High-cardinality tenant metrics monitoring cost বাড়ায়; aggregate tiers ও sampled detail ভাবুন।

সাধারণ ভুল

Tenant ID বাদ দিয়ে cache ও lock key তৈরি করা।
Long-lived worker-এর static tenant context পরের job-এ রেখে দেওয়া।
এক tenant migration failure-এ সব tenant upgrade বন্ধ করা।

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

Database-per-tenant migrations resumable registry দিয়ে চালান: pending, running, succeeded, failed। Expand-contract schema change compatibility window রাখে। Partial rollout-এ app-কে পুরোনো ও নতুন schema-এর সঙ্গে কিছু সময় চলতে হতে পারে।

এক tenant-এর heavy export backlog দিন, অন্য tenant-এর ছোট job latency মাপুন। Separate queue priority একা starvation সমাধান করে কি না দেখুন। Migration মাঝপথে বন্ধ করে restart দিন; completed tenant পুনরায় ক্ষতিগ্রস্ত না হয়ে বাকি tenant এগোতে হবে।

মনে রাখুন

Tenant context সব operational path-এ।
Quota এবং fairness একসঙ্গে দরকার।
Migration progress durable ও resumable।

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

তিন SaaS plan-এর export quota, worker concurrency এবং maximum queue age লিখুন। SLA ভাঙলে downgrade নয়, কী admission response দেবেন ঠিক করুন।

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

1. DB scoped হলেই নিরাপদ?

না। Cache, search, files ও queued jobs থেকেও অন্য tenant-এর data leak হতে পারে।

2. Job-এর tenant কোথা থেকে?

Verified request বা durable business record থেকে; caller-এর arbitrary body value নয়।

3. Noisy neighbor কী?

এক tenant shared resource saturate করে অন্য tenant-এর latency বা availability নষ্ট করে।

4. সব tenant আলাদা worker?

দরকার নেই। Cost ও fairness দেখে shared pools, quotas এবং premium isolation বেছে নিন।

5. Migration restart?

Per-tenant progress ও idempotent steps থাকলে failed tenant resume করা যায়; blind global rerun ঝুঁকিপূর্ণ।

এই পাঠের কুইজ

এই পাঠ থেকে ২টি প্রশ্ন। উত্তর দিয়ে ব্যাখ্যা দেখুন; অধ্যায়ের কুইজ আলাদাভাবে দিতে হবে।

এই পাঠের ২টি প্রশ্নের উত্তর দিন। পাস করতে দুটিই সঠিক হতে হবে।

জমা দেওয়ার পর সঠিক উত্তর ও ব্যাখ্যা দেখবেন। ফলাফল এই ব্রাউজারে সংরক্ষিত থাকবে। অনুশীলনের ফল অধ্যায় সম্পন্নের হিসাবে যোগ হয় না।

সব বিষয় মিলিয়ে অনুশীলন করুন →

অগ্রগতি এই ব্রাউজারে সংরক্ষিত থাকে। শুধু পাঠ খুললে সম্পন্ন হয় না।