System Design Trainer کے ساتھ سسٹم ڈیزائن انٹرویوز کی مشق کریں

System Design Trainer کیا ہے؟

System Design Trainer سسٹم ڈیزائن انٹرویوز کی مشق کے لیے ایک انٹرایکٹو وائٹ بورڈ ہے۔ آپ ایک منظرنامہ منتخب کرتے ہیں، AWS یا Azure کے اجزا کینوس پر گھسیٹ کر لاتے ہیں، انہیں آپس میں جوڑ کر ایک آرکیٹیکچر بناتے ہیں، اور ایک متعین گنجائش کی simulation چلاتے ہیں۔

سمیلیٹر اندازہ لگاتا ہے کہ ہر جزو کتنے ٹریفک کو سنبھال سکتا ہے، سسٹم کی رکاوٹ کی نشاندہی کرتا ہے، اور آرکیٹیکچر کے خطرات نمایاں کرتا ہے۔ ڈیزائن مکمل ہونے پر Jev ان انتخاب کا جائزہ لے سکتا ہے جنہیں صرف گنجائش کے حساب سے پرکھا نہیں جا سکتا، جن میں اسکیل ایبلٹی، قابلِ اعتماد ہونا، ڈیٹا ڈیزائن، اور آپ کی تحریری وضاحت شامل ہیں۔

اہم خصوصیات

• انٹرایکٹو آرکیٹیکچر کینوس: وائٹ بورڈ React Flow کو @xyflow/react کے ذریعے استعمال کرتے ہوئے بنایا گیا ہے۔
• منظم مشق: پروجیکٹ میں چار ابواب پر مشتمل 15 لیولز شامل ہیں۔
• براہِ راست گنجائش کی ماڈلنگ: ہر نوڈ استعمال کی شرح اور اس بات کا تخمینہ دکھاتا ہے کہ وہ کتنے صارفین کو سپورٹ کر سکتا ہے۔
• آرکیٹیکچر کی تشخیص: سمیلیٹر ناکامی کے واحد نقاط، غائب لوڈ بیلنسرز، اور ڈیٹا بیسز سے براہِ راست جڑے کلائنٹس کی نشاندہی کرتا ہے۔
• لاگت اور دستیابی کے تخمینے: سسٹم تھروپٹ کے حساب کے ساتھ اضافی اشاریے بھی فراہم کرتا ہے۔
• انٹرویو لینے والے جیسا جائزہ: Jev اسکیل ایبلٹی، قابلِ اعتماد ہونا، ڈیٹا ڈیزائن، اور تحریری وضاحتوں کے اسکور دیتا ہے، پھر اگلی بہتری کے لیے سفارش کرتا ہے۔
• حسبِ ضرورت ٹیکنالوجیز: آپ Kafka، MongoDB، یا NGINX جیسی ٹیکنالوجیز درج کر سکتے ہیں۔ Jev ان کے آرکیٹیکچرل کردار کی درجہ بندی کرتا ہے تاکہ ایپلیکیشن گنجائش کا پروفائل مقرر کر سکے۔
• مقامی پیش رفت: ڈیزائنز اور منظرنامے کی پیش رفت براؤزر میں محفوظ کی جاتی ہے۔
• آزادانہ مشق: منظم لیولز کے علاوہ ایک کھلا وائٹ بورڈ بھی دستیاب ہے۔

پروجیکٹ انسٹال اور چلائیں

1. انحصارات انسٹال کریں

ریپوزٹری کو کلون یا ڈاؤن لوڈ کریں، ٹرمینل میں اس کی ڈائریکٹری کھولیں، اور npm کے انحصارات انسٹال کریں:

npm install

2. مقامی ماحول کی فائل بنائیں

شامل کردہ ماحول کے ٹیمپلیٹ کو .env.local میں کاپی کریں:

cp .env.example .env.local

3. Jev ترتیب دیں

حقیقی Jev جوابات حاصل کرنے کے لیے .env.local میں TYPESAFE_API_KEY کی قدر شامل کریں۔ Jev کو lib/server/jev.ts میں @typesafe-ai/sdk استعمال کرتے ہوئے نافذ کیا گیا ہے۔

ایپلیکیشن API key کے بغیر بھی چل سکتی ہے۔ ایسی صورت میں Jev کے جوابات واضح طور پر لیبل کیے گئے mock پر منتقل ہو جاتے ہیں، جس سے آپ بیرونی جائزے کے بغیر باقی ورک فلو کو دریافت کر سکتے ہیں۔

4. ڈیولپمنٹ سرور شروع کریں

npm run dev

ٹرینر استعمال کرنا شروع کرنے کے لیے ڈیولپمنٹ سرور کی جانب سے بتائے گئے مقامی پتے کو کھولیں۔

اپنی پہلی سسٹم ڈیزائن مشق مکمل کریں

1. پرامپٹ منتخب کریں۔ ایسا منظرنامہ منتخب کریں جس میں دس لاکھ صارفین کے لیے انفراسٹرکچر ڈیزائن کرنا شامل ہو۔ ہر منظرنامہ صارفین کی مقررہ تعداد اور تقاضے فراہم کرتا ہے۔
2. مقاصد پڑھیں۔ لیولز میں مطلوبہ مقاصد اور اختیاری اضافی مقاصد شامل ہوتے ہیں، جنہیں ڈیزائن چلانے پر جانچا جاتا ہے۔
3. کلاؤڈ اجزا شامل کریں۔ مناسب AWS یا Azure اجزا وائٹ بورڈ پر گھسیٹ کر لائیں۔
4. آرکیٹیکچر کو جوڑیں۔ منظرنامے کے مطابق کلائنٹس، نیٹ ورکنگ اجزا، ایپلیکیشن سروسز، کیشز، قطاروں، اور ڈیٹا بیسز کے درمیان درخواست اور ڈیٹا کے راستے بنائیں۔
5. ڈیزائن چلائیں۔ استعمال کی شرح، معاونت یافتہ صارفین کے تخمینے، دستیابی، لاگت، اور آرکیٹیکچر کی تنبیہات کا جائزہ لیں۔
6. رکاوٹ دور کریں۔ اوور لوڈ شدہ اجزا یا ساختی تنبیہات کی بنیاد پر ڈیزائن اپ ڈیٹ کریں، پھر اسے دوبارہ چلائیں۔
7. Jev سے رائے طلب کریں۔ تیار ہونے پر ڈیزائن اور تحریری وضاحت جائزے کے لیے جمع کریں۔

لیول اسکورنگ کیسے کام کرتی ہے

ہر مطلوبہ مقصد مکمل کرنے پر ایک ستارہ ملتا ہے۔ ہر اضافی مقصد ایک اور ستارہ دیتا ہے۔ ستارے XP فراہم کرتے ہیں اور آپ کے رینک میں شامل ہوتے ہیں، جبکہ پیش رفت براؤزر میں برقرار رہتی ہے۔

باب 4 میں آپ سے Azure Architecture Center کے حوالہ جاتی آرکیٹیکچرز دوبارہ بنانے کو کہا جاتا ہے۔ ان میں سے کوئی لیول مکمل کرنے کے بعد ٹرینر اصل آرکیٹیکچر کا لنک فراہم کرتا ہے۔

گنجائش کے ماڈل کو سمجھیں

گنجائش کا انجن lib/simulate.ts میں موجود ہے۔ یہ متعین ہے اور AI استعمال نہیں کرتا۔ چوٹی کا لوڈ منظرنامے سے درج ذیل تعلق کے ذریعے اخذ کیا جاتا ہے:

DAU × requests per day ÷ 86,400 × peak factor

ماڈل اس لوڈ کو ریڈز اور رائٹس میں تقسیم کرتا ہے، پھر اسے Users نوڈ سے جڑے ہوئے گراف میں آگے منتقل کرتا ہے۔

عام اجزا ٹریفک کو کیسے متاثر کرتے ہیں

• CDNs: اس ٹریفک کے حصے کو جذب کرتے ہیں جسے منظرنامہ ایج پر کیش کے قابل قرار دیتا ہے۔
• کیشز: اپنی ہٹ ریٹ کے مطابق ریڈز جذب کرتے ہیں۔ ماڈل cache-aside sibling placement اور inline placement دونوں کو سپورٹ کرتا ہے۔
• قطاریں: رائٹس کو ہم وقت راستے سے ہٹا کر اوسط درخواست کی شرح کے مطابق ہموار کرتی ہیں۔
• ہم مرتبہ اجزا: ایک ہی قسم کے اجزا لوڈ کو برابر تقسیم کرتے ہیں۔ مثال کے طور پر، دو ایپلیکیشن گروپس سے جڑا لوڈ بیلنسر ٹریفک کو ان کے درمیان تقسیم کرتا ہے۔
• SQL ڈیٹا بیسز: رائٹ کی گنجائش ایک پرائمری تک محدود ہوتی ہے۔
• NoSQL ڈیٹا بیسز: رائٹ کی گنجائش پارٹیشنز کے ساتھ اسکیل ہوتی ہے۔

ہر نوڈ استعمال کی شرح اور supports ~N users کا تخمینہ رپورٹ کرتا ہے، جو منظرنامے میں صارفین کی تعداد کو استعمال کی شرح سے تقسیم کر کے شمار کیا جاتا ہے۔ پورے نظام کی گنجائش کا تعین اس رکاوٹ سے ہوتا ہے جس کا معاون صارفین کا تخمینہ سب سے کم ہو۔

ڈیزائن کی تکراری مثال

فرض کریں کہ ایک ڈیزائن کلائنٹ کا تمام ٹریفک براہِ راست ایک ایپلیکیشن جزو اور پھر ڈیٹابیس کو بھیجتا ہے۔ سمیولیشن چلانے سے ایپلیکیشن یا ڈیٹابیس رکاوٹ کے طور پر سامنے آ سکتا ہے، اور قابلِ اعتمادیت سے متعلق انتباہات بھی ظاہر ہو سکتے ہیں۔

اس کے بعد آپ موزوں تقسیم، کیشنگ، غیر ہم وقت پروسیسنگ، یا ڈیٹا کے اجزا شامل کر کے فن تعمیر میں ترمیم کر سکتے ہیں۔ مثال کے طور پر، لوڈ بیلینسر کے پیچھے موجود ہم سطح ایپلیکیشن گروپس ایپلیکیشن ٹریفک تقسیم کر سکتے ہیں، کیش اپنی ہٹ ریٹ کے مطابق ڈیٹابیس ریڈز کم کر سکتی ہے، اور قطار رائٹس کو ہم وقت راستے سے منتقل کر سکتی ہے۔ ہر تبدیلی کے بعد ماڈل دوبارہ چلائیں تاکہ معلوم ہو سکے کہ رکاوٹ کہیں اور منتقل ہوئی ہے یا نہیں۔

زیادہ گنجائش کا تخمینہ خود بخود کسی ڈیزائن کو درست نہیں بناتا۔ قابلِ اعتمادیت، ڈیٹا ڈیزائن، اسکیل ایبلٹی، اور اپنے انتخاب کے پیچھے موجود استدلال میں توازن جانچنے کے لیے Jev استعمال کریں۔

Jev کو مؤثر طریقے سے استعمال کریں

متعین سمیولیٹر اپنے حساب کردہ اعداد Jev کو حقائق کے طور پر فراہم کرتا ہے۔ اس کے بعد Jev ان فیصلوں کو سنبھالتا ہے جنہیں تھروپٹ فارمولوں تک محدود نہیں کیا جا سکتا۔

• جائزے کے اسکور: اسکیل ایبلٹی، قابلِ اعتمادیت، ڈیٹا ڈیزائن، اور تحریری وضاحت کا جائزہ لیتا ہے۔
• بہتری کا انتخاب: طے کرتا ہے کہ اگلی بہتری کس حصے میں ہونی چاہیے۔
• چیک لسٹ کے فیصلے: منظرنامے کے چیک لسٹ آئٹمز میں سے ہر ایک کے لیے ایک Noul تیار کرتا ہے۔
• حسبِ ضرورت جزو کی درجہ بندی: آپ کی درج کردہ ٹیکنالوجی کو ایک فن تعمیراتی کردار تفویض کرتا ہے، جس سے ٹرینر متعلقہ گنجائش پروفائل لاگو کر سکتا ہے۔

زیادہ مؤثر رائے کے لیے تحریری وضاحت کو واضح بنائیں۔ ٹریفک کا بہاؤ، اسکیلنگ کے مفروضے، ناکامی سے نمٹنے کا طریقہ، ریڈ اور رائٹ کے پیٹرنز، اور ہر بڑے جزو کی موجودگی کی وجہ بیان کریں۔

اعلیٰ درجے کی تجاویز

ہر جزو کو نہیں، رکاوٹ کو بہتر بنائیں

نظام اتنے ہی صارفین کو معاونت فراہم کرتا ہے جتنے اس کے محدود ترین جزو کی گنجائش ہو۔ اس نوڈ سے آغاز کریں جس کا معاون صارفین کا تخمینہ سب سے کم ہے۔ ڈیزائن تبدیل کرنے کے بعد سمیولیشن دوبارہ چلائیں، کیونکہ ایک رکاوٹ دور کرنے سے دوسری رکاوٹ ظاہر ہو سکتی ہے۔

ہم وقت اور غیر ہم وقت راستوں کا موازنہ کریں

قطاریں رائٹس کو ہم وقت درخواست کے راستے سے ہٹا کر اوسط لوڈ کے مطابق ہموار کرتی ہیں۔ جب منظرنامہ غیر ہم وقت پروسیسنگ کی اجازت دے، تو براہِ راست رائٹ راستے اور قطار پر مبنی فن تعمیر کا موازنہ کرنے کے لیے ماڈل استعمال کریں۔

کیش کی جگہ کا تجربہ کریں

سمیولیٹر کیش-ایسائیڈ پیٹرن میں ہم سطح کے طور پر استعمال ہونے والی کیشز اور راستے میں براہِ راست رکھی گئی کیشز کو پہچانتا ہے۔ دیکھیں کہ جگہ اور ہٹ ریٹ بعد کے ریڈ ٹریفک کو کیسے متاثر کرتے ہیں۔

ساختی انتباہات پر نظر رکھیں

صرف استعمال کی شرح پر توجہ نہ دیں۔ ناکامی کے واحد مقامات، غائب لوڈ بیلینسرز، اور کلائنٹ سے ڈیٹابیس کے براہِ راست کنکشنز کی جانچ کریں۔ یہ انتباہات قابلِ اعتمادیت یا سکیورٹی سے متعلق ڈیزائن کی کمزوریاں ظاہر کر سکتے ہیں، چاہے خام گنجائش کافی ہی کیوں نہ ہو۔

کیٹلاگ کے اعداد کے پیچھے موجود ماخذ دیکھیں

گنجائش، دستیابی، اور لاگت کا ڈیٹا lib/catalog.ts میں متعین ہے۔ ہر عدد کے ساتھ ایک ماخذ شامل ہے جو جزو کی خصوصیات کے کارڈ میں دکھایا جاتا ہے۔ اقدار کو سرکاری حدود، سرکاری SLAs، وینڈر بینچ مارکس، مفروضوں، یا ایسی سروسز کے طور پر درجہ بند کیا گیا ہے جن کی کوئی شائع شدہ حد نہیں۔

• سرکاری حد: AWS یا Azure کا شائع شدہ کوٹا، جیسے اکاؤنٹ کی سطح پر درخواستوں کی تھروٹل حد۔
• سرکاری SLA: وینڈر کی ماہانہ اپ ٹائم وابستگی۔
• وینڈر بینچ مارک: کارکردگی کا شائع شدہ عدد جس کی ضمانت نہیں دی گئی۔
• مفروضہ: ایسی ماڈل کردہ قدر جس کے لیے وینڈر کا کوئی عدد دستیاب نہ ہو۔ پروجیکٹ تمام لاگتوں کو بھی مفروضے تصور کرتا ہے۔
• کوئی شائع شدہ حد نہیں: ایسی سروس جسے آزادانہ طور پر اسکیل ہونے کے طور پر ماڈل کیا گیا ہو، اس لیے وہ رکاوٹ نہیں بنتی۔

README کے مطابق ان ماخذوں کی آخری جانچ ستمبر 2026 میں کی گئی تھی۔ کلاؤڈ کوٹے تبدیل ہو سکتے ہیں، اور کئی کو بڑھایا بھی جا سکتا ہے، اس لیے سمیولیشن کے نتائج کو ضمانت کے بجائے تخمینے سمجھنا چاہیے۔

منظرنامے دریافت کریں یا ان میں توسیع کریں

منظرنامے کی تعریفیں lib/scenarios.ts میں محفوظ ہیں، جبکہ 15 ساختہ لیولز lib/levels.ts میں متعین ہیں۔ دستیاب مشقی سوالات میں توسیع کرتے وقت منظرنامے lib/scenarios.ts میں شامل کریں۔

براؤزر میں محفوظ ہونے والے ڈیٹا کو سمجھیں

کینوس ڈیزائن ہر منظرنامے کے لیے localStorage میں محفوظ کیے جاتے ہیں، اور پیش رفت بھی براؤزر میں رکھی جاتی ہے۔ یاد رکھیں کہ براؤزر اسٹوریج موجودہ براؤزر پروفائل اور ماحول تک محدود ہوتی ہے۔

نتیجہ

System Design Trainer ایک انٹرایکٹو کلاؤڈ فنِ تعمیر کینوس، متعین گنجائش ماڈلنگ، ساختہ مقاصد، اور Jev پر مبنی ڈیزائن جائزے کو یکجا کرتا ہے۔ قابلِ پیمائش رویے کو جانچنے کے لیے سمیولیٹر استعمال کریں، ساختی مسائل پکڑنے کے لیے انتباہات سے فائدہ اٹھائیں، اور سسٹم ڈیزائن انٹرویو میں متوقع استدلال اور توازن کے تجزیے کو بہتر بنانے کے لیے Jev استعمال کریں۔