পাঠ্যক্রম খুলুন
মধ্যবর্তী পর্যায়

Distributed ID: UUID, ULID ও Snowflake

Distributed ID Generation: UUID, ULID, and Snowflake

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

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

  • UUID ULID এবং Snowflake তুলনা করুন
  • Clock rollback ও worker identity-এর failure বুঝুন
  • Identifier-কে authorization থেকে আলাদা রাখুন

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

দুটি region স্বাধীনভাবে order বানায়, উভয়ের auto-increment ID 1001 হয়ে গেল। পরে merge করতে collision। Team timestamp দিয়ে ID বানাল, কিন্তু একই millisecond-এ দুই request একই value পেল। Unique identity এবং chronological order এক প্রশ্ন নয়।

সহজ করে বুঝি

UUID 128-bit identifier family; v4 randomness-ভিত্তিক, v7 time-ordered layout ব্যবহার করে। ULID timestamp ও randomness মিলিয়ে sortable textual representation দেয়। Snowflake-style generator timestamp, worker identity এবং sequence মিলিয়ে compact numeric ID বানায়। প্রতিটি পদ্ধতির uniqueness assumptions, clock behavior ও storage trade-off আছে।

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

আলাদা শাখা শুধু receipt 1,2,3 দিলে একত্রে মিলে যায়। Branch prefix ও local sequence যোগ করলে পরিচয় আলাদা হয়, কিন্তু prefix একই শাখাকে ভুলভাবে দিলে collision আবার আসে। Random দীর্ঘ code coordination কমায়, তবে order বোঝার আলাদা field দরকার হতে পারে।

নকশাটি দেখুন

Diagram লোড হচ্ছে…

UUID ULID এবং Snowflake তুলনা করুন
Diagram-এর text flow দেখুন
flowchart LR
 A[Region A Generator] --> U[ULID or UUID]
 B[Region B Generator] --> U
 U --> D[(Unique Database Constraint)]
 S[Snowflake Alternative] --> T[Timestamp Worker Sequence]
 T --> W[Worker ID Coordination and Clock Policy]

দুই region local generator ব্যবহার করে, কিন্তু shared data store unique constraint শেষ প্রতিরক্ষা রাখে। Snowflake-এর অন্য path-এ worker identity আলাদা হতে হবে এবং sequence limit সামলাতে হবে। Clock পিছোলে generator wait, fail বা documented safe policy নেবে; পুরোনো timestamp-এ sequence reset করলে collision হতে পারে।

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

Laravel migration এবং ID creation fragment। orders table-এ public_id ULID unique; internal numeric key রাখা যায়। ULID থেকে timestamp আংশিক অনুমান করা সম্ভব, তাই secret token হিসেবে নয়। URL-এ public ID থাকলেও Policy দিয়ে order owner যাচাই করতে হবে।

php
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;
use Illuminate\Support\Str;

Schema::table('orders', function (Blueprint $table) {
    $table->ulid('public_id')->nullable()->unique();
});

$publicId = (string) Str::ulid();
$order = new App\Models\Order();
$order->public_id = $publicId;
$order->user_id = $userId;
$order->status = 'pending';
$order->save();
// Existing rows need a backfill before changing nullable to non-null.
// Collision retry should be bounded and limited to the unique-ID violation.

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

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

Random UUID decentralized generation সহজ করে, কিন্তু ordered key-এর তুলনায় B-tree locality কম হতে পারে। ULID/UUIDv7 temporal locality সাহায্য করে, কিন্তু timestamp privacy ও strict global order guarantee নয়। Snowflake compact হলেও worker registry ও clock policy operations বাড়ায়।

সাধারণ ভুল

  • ID গোপন বা কঠিন guess মানেই access authorized ধরা।
  • দুটি worker-এ একই Snowflake identity configure করা।
  • Sortable ID-কে causal order বা transaction commit order বলা।

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

একই millisecond-এর ULID monotonicity implementation ও local generator state-এর বিষয়; independent machine-এর strict global sequence নয়। JavaScript client-এ বড় numeric ID precision হারাতে পারে, তাই serialized decimal string ব্যবহার করুন। UUID database native type ও text storage-এর খরচ আলাদা।

দুটি simulated worker দিয়ে একই worker identity ও frozen timestamp ব্যবহার করে Snowflake collision কেন হবে দেখান। ULID দিয়ে হাজার ID বানিয়ে unique constraint test করুন, কিন্তু ছোট test collision অসম্ভব প্রমাণ করে না। Separate created_at এবং aggregate version দিয়ে business order রাখুন।

মনে রাখুন

  • Uniqueness assumptions লিখুন।
  • Clock ও worker identity operational input।
  • ID permission নয়।

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

Multi-region invoice service-এর ID strategy বেছে নিন। Offline generation, database index, public exposure ও client precision তুলনা করুন।

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

1. Timestamp একাই unique?

না। একই সময়ে বহু request বা clock rollback একই value তৈরি করতে পারে।

2. UUID সব একই?

না। Version অনুযায়ী randomness, timestamp ও ordering layout আলাদা।

3. ULID global sequence?

না। Sortability strict causality বা independent node-এর total commit order নিশ্চিত করে না।

4. Snowflake risk কী?

Worker identity collision, sequence exhaustion এবং clock rollback policy ভুল হলে duplicate হতে পারে।

5. Unique constraint কেন?

Generator configuration defect বা collision database-এ invalid duplicate ঢোকা ঠেকাতে শেষ invariant guard।

আরও পড়ুন

এই পাঠের কুইজ

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

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

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

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

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