# کلاؤڈ کمپیوٹنگ کی وضاحت: 11 آرکیٹیکچر کے تصورات جو آپ کو ضرور جاننے چاہئیں (4K ماسٹرکلاس)۔

Published: 2026-09-15

زیادہ تر سافٹ ویئر انجینئرز AWS، GCP، اور Azure میں سینکڑوں وینڈر پروڈکٹ کے مخففات کو حفظ کر کے کلاؤڈ آرکیٹیکچر سیکھنے کی کوشش کرتے ہیں۔ لیکن حقیقی دنیا کی کلاؤڈ انجینئرنگ گیارہ بنیادی آرکیٹیکچرل پرائمیٹیو پر مبنی ہے۔ اس 4K ریمسٹر ماسٹرکلاس میں، نیکو نے مکمل انٹرپرائز بلیو پرنٹ کی وضاحت کی ہے: عمودی بمقابلہ افقی اسکیلنگ اور لیئر 7 لوڈ بیلنسنگ سے لے کر ڈائنامک آٹو اسکیلنگ، سرور لیس مائیکرو VM ایگزیکیوشن، غیر مطابقت پذیر ایونٹ پر مبنی ڈیکوپلنگ، کنٹینر آرکیسٹریشن، چار ستونی اسٹوریج کی درجہ بندی، ہائی اویلیبلٹی اور 11 نائنز کی ڈیورایبلٹی کے درمیان اہم فرق، ڈیکلیریٹیو انفراسٹرکچر بطور کوڈ، اور ورچوئل پرائیویٹ کلاؤڈ نیٹ ورکنگ۔ ان گیارہ تصورات پر عبور حاصل کریں، اور آپ پروڈکشن میں کسی بھی بیک اینڈ کو آرکیٹیکٹ کر سکتے ہیں۔ فیصلہ: SHIP IT۔

Canonical: https://thedailydiff.dev/ur/video/2026-09-14-cloud-computing-explained-4k/

## اس ویڈیو میں کیا شامل ہے

- - آرکیٹیکچر وال اور ماسٹر بلیو پرنٹ
- - 01. عمودی بمقابلہ افقی اسکیلنگ
- - 02. لوڈ بیلنسنگ آرکیٹیکچر (L4 بمقابلہ L7 اور ہیلتھ چیکس)
- - 03. آٹو اسکیلنگ اور لچک
- - 04. سرور لیس (FaaS اور فائر کریکر مائیکرو VM)

## ابواب

- 0:00 - آرکیٹیکچر وال اور ماسٹر بلیو پرنٹ
- 0:57 - 01. عمودی بمقابلہ افقی اسکیلنگ
- 2:17 - 02. لوڈ بیلنسنگ آرکیٹیکچر (L4 بمقابلہ L7 اور ہیلتھ چیکس)
- 3:45 - 03. آٹو اسکیلنگ اور لچک
- 4:50 - 04. سرور لیس (FaaS اور فائر کریکر مائیکرو VM)
- 6:05 - 05. ایونٹ پر مبنی آرکیٹیکچر (EDA اور ڈیکوپلنگ)
- 7:13 - 06. کنٹینر آرکیسٹریشن (ڈاکر اور کیوبرنیٹیز)
- 8:16 - 07. 4 کلاؤڈ اسٹوریج پلرز (S3، EBS، DBs اور Redis)
- 9:44 - 08. ہائی اویلیبلٹی اور نائنز (ملٹی-AZ فیل اوور)
- 10:53 - 09. ڈیورایبلٹی بمقابلہ اویلیبلٹی (11 نائنز کیوں اپ ٹائم نہیں ہے)
- 12:14 - 10. انفراسٹرکچر بطور کوڈ (Terraform بمقابلہ کنسول ڈرفٹ)
- 13:20 - 11. کلاؤڈ نیٹ ورکنگ (VPC، سب نیٹس، NAT اور سیکیورٹی گروپس)
- 14:26 - 12. مکمل انٹرپرائز بلیو پرنٹ اور فیصلہ

## ترجمہ شدہ ٹرانسکرپٹ

اصل انگریزی بیان سے ترجمہ کیا گیا۔ دستیاب آڈیو اور کیپشنز یوٹیوب کے زیر انتظام ہیں۔

### - آرکیٹیکچر وال اور ماسٹر بلیو پرنٹ

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

0:34 اس ماسٹرکلاس میں، ہم پورے انٹرپرائز بلیو پرنٹ پر چلیں گے: اسکیلنگ سے اور لوڈ بیلنسنگ سے سرور لیس، ایونٹ پر مبنی ڈیکوپلنگ تک، اسٹوریج کی درجہ بندی، اور کلاؤڈ نیٹ ورکنگ۔ ان گیارہ تصورات پر عبور حاصل کریں، اور آپ AWS پر کوئی بھی بیک اینڈ ڈیزائن کر سکتے ہیں، GCP، یا Azure۔ یہ The Daily Diff ہے، اندرونی طور پر۔

### - 01. عمودی بمقابلہ افقی اسکیلنگ

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

1:28 اور ڈیٹا بیس بالکل وہی رہتے ہیں۔ لیکن یہ ایک سخت ہارڈ ویئر کی حد کو چھوتا ہے۔ دنیا میں کسی بھی ایک مشین میں دس ہزار CPU کور نہیں ہیں، اور اعلی درجے کے مثالوں پر ایک اضافی قیمت کا پریمیم ہوتا ہے۔ افقی اسکیلنگ، یا اسکیلنگ آؤٹ، کا مطلب ہے اپنے سرورز کو چھوٹے اور سستے رکھنا، لیکن ایک راؤٹر کے پیچھے متوازی طور پر متعدد مثالیں چلانا۔ اگر ایک مثال کریش ہو جاتی ہے، تو بقیہ نوڈز بغیر کسی ڈاؤن ٹائم کے ٹریفک کو جذب کر لیتے ہیں۔ افقی اسکیلنگ کا سنہری اصول

2:01 اسٹیٹ لیسنس ہے: آپ کے ایپلیکیشن سرورز صارف کے سیشنز، اپ لوڈ کردہ فائلیں، یا اسٹیٹ کو اپنی مقامی ڈسکس پر محفوظ نہیں کر سکتے۔ اسٹیٹ کو ایک بیرونی ڈیٹا بیس یا کیش میں رہنا چاہیے، کسی بھی نوڈ کو کسی بھی صارف کی درخواست کو ہینڈل کرنے کی اجازت دیتا ہے۔

### - 02. لوڈ بیلنسنگ آرکیٹیکچر (L4 بمقابلہ L7 اور ہیلتھ چیکس)

2:17 تصور نمبر دو: لوڈ بیلنسنگ۔ افقی اسکیلنگ کاغذ پر بہت اچھی لگتی ہے، لیکن یہ ایک فوری مسئلہ پیش کرتی ہے: جب دس ہزار صارفین آپ کے ڈومین نام پر آتے ہیں، تو کون سا مخصوص سرور ان کی ٹریفک وصول کرتا ہے؟ ایک لوڈ بیلنسر ایک ریورس پراکسی کے طور پر کام کرتا ہے جو عوامی انٹرنیٹ اور آپ کے نجی بیک اینڈ کلسٹر کے درمیان بیٹھا ہوتا ہے۔ یہ آنے والے TCP یا HTTP کنکشنز کو قبول کرتا ہے اور آپ کے صحت مند مثالوں میں درخواستوں کو تقسیم کرتا ہے۔

2:47 لوڈ بیلنسرز دو بنیادی نیٹ ورک تہوں پر کام کرتے ہیں۔ لیئر 4 نیٹ ورک لوڈ بیلنسرز ٹرانسپورٹ لیئر پر کام کرتے ہیں، IP ایڈریس اور پورٹ کی بنیاد پر خام TCP اور UDP پیکٹ کو روٹ کرتے ہیں مائیکرو سیکنڈ لیٹنسی اور ہر سیکنڈ میں لاکھوں درخواستوں کے ساتھ۔ لیئر 7 ایپلیکیشن لوڈ بیلنسرز HTTP پروٹوکول خود کا معائنہ کرتے ہیں: URL پاتھ، درخواست کے ہیڈرز، کوکیز، اور HTTP طریقوں کو پڑھنا۔ یہ پاتھ پر مبنی روٹنگ کو ممکن بناتا ہے: سلیش-api درخواستوں کو آپ کے بیک اینڈ کلسٹر پر بھیجنا اور سلیش-اسٹیٹک درخواستوں کو ایک

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

### - 03. آٹو اسکیلنگ اور لچک

3:45 تصور نمبر تین: آٹو اسکیلنگ۔ اگر آپ کی ویب ایپ کو صبح تین بجے دو سرورز کی ضرورت ہے، لیکن دوپہر کے لانچ کے دوران بیس سرورز کی، تو کلاؤڈ کنسول میں دستی طور پر بٹن پر کلک کرنا ڈاؤن ٹائم اور دیوالیہ پن کی ضمانت شدہ راہ ہے۔ آٹو اسکیلنگ افقی سرور پولز میں متحرک لچک لاتی ہے۔ ایک آٹو اسکیلنگ گروپ اوسط CPU یوٹیلائزیشن، نیٹ ورک I-O، یا قطار کے بیک لاگ کی گہرائی جیسے کارکردگی کے میٹرکس کی نگرانی کرتا ہے۔ جب اوسط CPU ایک مقررہ حد سے تجاوز کر جاتا ہے — مثلاً،

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

### - 04. سرور لیس (FaaS اور فائر کریکر مائیکرو VM)

4:53 سالوں تک، مارکیٹنگ ٹیموں نے سرور لیس کو جادوئی کوڈ کے طور پر پیش کیا جو آسمان میں چلتا ہے۔ حقیقت میں، سرور لیس اب بھی سرورز کا استعمال کرتا ہے — لیکن آپ ان کے مالک نہیں ہیں، پیچ نہیں کرتے، یا ان کی ادائیگی نہیں کرتے جب کوئی کوڈ نہیں چل رہا ہوتا ہے۔ Function-as-a-Service جیسے AWS Lambda یا Google Cloud Functions کے ساتھ، آپ ایک اسٹینڈ اکیلے ہینڈلر فنکشن لکھتے ہیں۔ جب کوئی HTTP درخواست، S3 فائل اپ لوڈ، یا ڈیٹا بیس میں تبدیلی واقع ہوتی ہے، تو کلاؤڈ رن ٹائم ایک عارضی

5:23 مائیکرو-ورچوئل-مشین جیسے Firecracker کو پانچ ملی سیکنڈ سے بھی کم وقت میں بوٹ کرتا ہے۔ آپ کا کوڈ چلتا ہے، ایک جواب لوٹاتا ہے، اور بند ہو جاتا ہے۔ اگر تین ماہ تک کوئی آپ کی ویب سائٹ پر نہیں جاتا ہے، تو آپ کا کمپیوٹ بل بالکل صفر ڈالر اور صفر سینٹ ہوتا ہے۔ اگر ایک ملین صارفین بیک وقت اس پر آتے ہیں، تو فراہم کنندہ ایک ملین بیک وقت مائیکرو VMs کو گھماتا ہے۔ انجینئرنگ کے متبادل حقیقی ہیں: تازہ رن ٹائمز کو اسپن کرنے پر کولڈ اسٹارٹ لیٹنسی، Lambda پر پندرہ منٹ کی سخت ایگزیکیوشن حد، اور سخت اسٹیٹ لیسنس۔

5:55 سرور لیس ایونٹ پائپ لائنز اور وقفے وقفے سے APIs کے لیے ناقابل شکست ہے، لیکن مستقل ویب ساکٹس یا کئی گھنٹے کی تربیتی کارروائیوں کے لیے خراب ہے۔

### - 05. ایونٹ پر مبنی آرکیٹیکچر (EDA اور ڈیکوپلنگ)

6:05 تصور نمبر پانچ: ایونٹ پر مبنی آرکیٹیکچر، یا EDA۔ روایتی آرکیٹیکچرز میں، خدمات ہم وقت ساز طریقے سے بات چیت کرتی ہیں۔ آپ کی چیک آؤٹ سروس پیمنٹ کو کال کرتی ہے، پیمنٹ انوینٹری کو کال کرتی ہے، انوینٹری فراڈ کو کال کرتی ہے، اور فراڈ ای میل کو کال کرتی ہے۔ یہ تباہی کی ہم وقت ساز آبشار پیدا کرتا ہے۔ اگر تھرڈ پارٹی ای میل فراہم کنندہ کو نیٹ ورک میں کوئی ہچکی محسوس ہوتی ہے اور جواب دینے میں دس سیکنڈ لگتے ہیں، تو آپ کے گاہک کی پوری چیک آؤٹ درخواست ایک غلطی کے ساتھ ٹائم آؤٹ ہو جاتی ہے۔ ایک ایونٹ پر مبنی آرکیٹیکچر میں، خدمات مکمل طور پر الگ ہو جاتی ہیں۔

6:37 جب کوئی گاہک خرید پر کلک کرتا ہے، تو چیک آؤٹ سروس ڈاؤن اسٹریم خدمات کو کال نہیں کرتی۔ یہ صرف ایک مرکزی ایونٹ بس جیسے ایمیزون ایونٹ برج یا ایک SNS ٹاپک پر آرڈر پلیسڈ نامی ایک ایونٹ شائع کرتی ہے۔ چیک آؤٹ پچاس ملی سیکنڈ میں مکمل ہو جاتا ہے۔ پیمنٹ، انوینٹری کی کٹوتی، اور ای میل کی رسیدوں کے لیے ڈاؤن اسٹریم ورکرز اپنے مخصوص SQS قطاروں سے آزادانہ طور پر پیغامات کھینچتے ہیں۔ اگر ای میل سروس ایک گھنٹے کے لیے بند ہو جاتی ہے، تو پیغامات محفوظ طریقے سے قطار میں بفرڈ رہتے ہیں بغیر کسی بھی آرڈر کے ضائع ہونے کے۔

### - 06. کنٹینر آرکیسٹریشن (ڈاکر اور کیوبرنیٹیز)

7:13 تصور نمبر چھ: کنٹینر آرکیسٹریشن۔ ڈاکر نے پیکیجنگ کا مسئلہ حل کیا: یہ آپ کے ایپلیکیشن کوڈ، سسٹم لائبریریوں، کنفیگریشن، اور رن ٹائم کو ایک غیر متغیر تصویر میں لپیٹتا ہے جو آپ کے میک بک پر اور کلاؤڈ میں یکساں طور پر چلتا ہے۔ لیکن ایک کنٹینر کو پیک کرنا آسان ہے۔ پچاس جسمانی ورچوئل مشینوں میں پانچ سو کنٹینرز چلانا وہیں ہے جہاں انجینئرنگ ٹوٹ جاتی ہے۔ اسی لیے کیوبرنیٹیز اور AWS ECS جیسے کنٹینر آرکیسٹریٹرز

7:41 موجود ہیں۔ ایک آرکیسٹریٹر ایک کنٹرول پلین فراہم کرتا ہے: ایک API سرور، ایک etcd اسٹیٹ اسٹور، اور ایک ذہین شیڈیولر۔ آپ اپنی مطلوبہ حالت کا اعلان کرتے ہیں: مجھے اپنی auth سروس کی دس ریپلیکا چاہیے جن میں سے ہر ایک میں دو گیگا بائٹس RAM ہو۔ شیڈیولر کلسٹر کا معائنہ کرتا ہے، خالی میموری والے نوڈز پر پوڈز رکھتا ہے، اندرونی نیٹ ورکنگ کو کنفیگر کرتا ہے، اور حقیقت کو مسلسل ہم آہنگ کرتا ہے۔ اگر ایک نوڈ ہارڈ ویئر کی خرابی کا شکار ہوتا ہے، تو کیوبرنیٹیز نقصان کا پتہ لگاتا ہے اور فوری طور پر تمام بے گھر پوڈز کو صحت مند

### - 07. 4 کلاؤڈ اسٹوریج پلرز (S3، EBS، DBs اور Redis)

8:16 نوڈز پر دوبارہ شیڈیول کرتا ہے۔ تصور نمبر سات: کلاؤڈ اسٹوریج کی درجہ بندی۔ ابتدائی اکثر کلاؤڈ اسٹوریج کو ایک ہی بالٹی سمجھتے ہیں جہاں آپ فائلیں پھینکتے ہیں۔ پروڈکشن آرکیٹیکچر میں، اسٹوریج کو رسائی کے پیٹرن اور لیٹنسی کی بنیاد پر چار الگ ستونوں میں تقسیم کیا جاتا ہے۔ پہلا آبجیکٹ اسٹوریج ہے، جیسے ایمیزون S3 یا گوگل کلاؤڈ اسٹوریج۔ آپ HTTP REST APIs کے ذریعے فائلوں تک رسائی حاصل کرتے ہیں سادہ PUT اور GET کالز کا استعمال کرتے ہوئے۔ یہ ہر ماہ فی گیگا بائٹ دو سینٹ پر لامحدود افقی صلاحیت فراہم کرتا ہے،

8:49 جس سے یہ ویڈیو، صارف کے اپ لوڈز، لاگز، اور بیک اپس کے لیے مثالی بنتا ہے۔ دوسرا بلاک اسٹوریج ہے، جیسے ایمیزون EBS۔ یہ ورچوئل ہارڈ ڈرائیوز ہیں جو براہ راست ایک مخصوص ورچوئل مشین سے ہائی سپیڈ انٹرکنیکٹس پر ماؤنٹ ہوتی ہیں۔ وہ معیاری فائل سسٹم جیسے ext4 میں فارمیٹ ہوتے ہیں، جو ڈیٹا بیس انجنوں کے لیے ضروری تیز رفتار رینڈم ریڈ اور رائٹ رسائی کی حمایت کرتے ہیں۔ تیسرا منظم ڈیٹا بیس ہیں: ریلیشنل انجن جیسے RDS پر PostgreSQL جو ACID ٹرانزیکشنز اور پیچیدہ جوائنز فراہم کرتے ہیں،

9:21 اور NoSQL انجن جیسے DynamoDB جو بڑے پیمانے پر سنگل ہندسوں کی ملی سیکنڈ لیٹنسی فراہم کرتے ہیں۔ اور چوتھے ان-میموری کیشز ہیں جیسے Redis۔ RAM سے ڈیٹا پڑھنے میں ملی سیکنڈز کے بجائے مائیکرو سیکنڈز لگتے ہیں۔ کیشز آپ کے ڈیٹا بیس کے سامنے بیٹھتے ہیں، اسے بار بار کی ریڈ ٹریفک سے بچاتے ہیں اور غیر مستحکم صارف سیشن ٹوکنز کا انتظام کرتے ہیں۔

### - 08. ہائی اویلیبلٹی اور نائنز (ملٹی-AZ فیل اوور)

9:44 تصور نمبر آٹھ: ہائی اویلیبلٹی، یا HA۔ اویلیبلٹی ایک سوال کا جواب دیتی ہے: آپ کی ایپلیکیشن کتنے فیصد وقت کارآمد اور صارفین کے لیے قابل رسائی ہے؟ انٹرپرائز معاہدوں میں، اویلیبلٹی کو نائنز میں ماپا جاتا ہے۔ دو نائنز، یا ننانوے فیصد اویلیبلٹی، ہر سال ساڑھے تین دن سے زیادہ ڈاؤن ٹائم کی اجازت دیتی ہے۔ چار نائنز ڈاؤن ٹائم کو باون منٹ تک کم کر دیتی ہے، اور پانچ نائنز فی سال کل پانچ منٹ کے ڈاؤن ٹائم کی بمشکل اجازت دیتی ہے۔

10:15 ہائی اویلیبلٹی حاصل کرنے کے لیے، آپ کو فالٹ ڈومینز میں ناکامی کے واحد پوائنٹس کو ختم کرنا ہوگا۔ کلاؤڈ میں، اس کا مطلب ہے متعدد اویلیبلٹی زونز میں تعینات کرنا۔ ایک اویلیبلٹی زون ایک ہی ریک نہیں ہے: یہ ایک یا زیادہ الگ جسمانی ڈیٹا سینٹرز ہیں جو میلوں دور ہیں اور آزادانہ بجلی اور کولنگ رکھتے ہیں۔ زون A اور زون B میں ہم وقت ساز ڈیٹا بیس ریپلیکیشن کے ساتھ فعال مثالیں چلا کر، ایک بجلی کا کڑکا یا فائبر کٹ جو ایک پوری جسمانی سہولت کو بند کر دیتا ہے، خودکار فیل اوور کا نتیجہ دیتا ہے۔

10:50 تیس سیکنڈ میں بغیر کسی انسانی مداخلت کے۔

### - 09. ڈیورایبلٹی بمقابلہ اویلیبلٹی (11 نائنز کیوں اپ ٹائم نہیں ہے)

10:53 تصور نمبر نو: استحکام بمقابلہ دستیابی۔ یہ کلاؤڈ آرکیٹیکچر کے انٹرویوز میں سب سے عام نظریاتی جال ہے۔ انجینئرز اکثر الفاظ کو ایک دوسرے کے بدلے استعمال کرتے ہیں، لیکن وہ مکمل طور پر مختلف خصوصیات کی پیمائش کرتے ہیں۔ دستیابی اپ ٹائم کی پیمائش کرتی ہے: کیا میں ابھی اپنے ڈیٹا کو پڑھنے یا لکھنے کے لیے API کال کر سکتا ہوں؟ دستیابی اپ ٹائم کی پیمائش کرتی ہے: کیا میں ابھی اپنے ڈیٹا کو پڑھنے یا لکھنے کے لیے API کال کر سکتا ہوں؟ استحکام تحفظ کی پیمائش کرتا ہے: کیا میرا ڈیٹا مستقل بِٹ رَوٹ، کرپشن، یا دس سال سے زیادہ کی تباہی کے بغیر زندہ رہے گا؟ استحکام تحفظ کی پیمائش کرتا ہے: کیا میرا ڈیٹا مستقل بِٹ رَوٹ، کرپشن، یا دس سال سے زیادہ کی تباہی کے بغیر زندہ رہے گا؟

11:24 ایمیزون S3 اسٹینڈرڈ کو دیکھیں۔ اس کا سروس لیول ایگریمنٹ ننانوے اعشاریہ نو فیصد دستیابی پیش کرتا ہے، جو ہر ماہ تقریباً تینتالیس منٹ کا ڈاؤن ٹائم فراہم کرتا ہے جہاں ایک API درخواست پانچ سو کی خامی واپس کر سکتی ہے۔ لیکن S3 گیارہ نائنز کی ڈیوریبلٹی کا وعدہ کرتا ہے: ننانوے اعشاریہ نو نو نو نو نو نو نو نو نو فیصد۔ اگر آپ S3 میں دس ملین فائلیں ذخیرہ کرتے ہیں، تو آپ شماریاتی طور پر ہر دس ہزار سال میں اوسطاً ایک فائل کھونے کی توقع کر سکتے ہیں۔

11:56 اگر آپ S3 میں دس ملین فائلیں ذخیرہ کرتے ہیں، تو آپ شماریاتی طور پر ہر دس ہزار سال میں اوسطاً ایک فائل کھونے کی توقع کر سکتے ہیں۔ S3 یہ آبجیکٹس کو ایرژر-کوڈنگ کرکے اور کم از کم تین جغرافیائی طور پر الگ الگ ڈیٹا سہولیات میں چنکس کو نقل کرکے حاصل کرتا ہے۔ S3 یہ آبجیکٹس کو ایرژر-کوڈنگ کرکے اور کم از کم تین جغرافیائی طور پر الگ الگ ڈیٹا سہولیات میں چنکس کو نقل کرکے حاصل کرتا ہے۔ ایک بڑے علاقائی نیٹ ورک کی بندش کے دوران، S3 عارضی طور پر دستیاب نہیں ہو سکتا ہے، لیکن آپ کا ڈیٹا کبھی تباہ نہیں ہوتا ہے۔

### - 10. انفراسٹرکچر بطور کوڈ (Terraform بمقابلہ کنسول ڈرفٹ)

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

12:48 کوڈ کے بطور ٹولز جیسے ٹیرافارم، OpenTofu، Pulumi، یا AWS CDK کے ساتھ، آپ اپنی پوری کلاؤڈ آرکیٹیکچر کو Git میں ذخیرہ شدہ اعلانیہ کنفیگریشن فائلوں میں بیان کرتے ہیں۔ OpenTofu، Pulumi، یا AWS CDK کے ساتھ، آپ اپنی پوری کلاؤڈ آرکیٹیکچر کو Git میں ذخیرہ شدہ اعلانیہ کنفیگریشن فائلوں میں بیان کرتے ہیں۔ کھلی پورٹ یا ڈیٹا بیس ریپلیکا میں ہر تبدیلی پل ریکویسٹ اور پیر ریویو سے گزرتی ہے۔ کھلی پورٹ یا ڈیٹا بیس ریپلیکا میں ہر تبدیلی پل ریکویسٹ اور پیر ریویو سے گزرتی ہے۔ terraform plan چلانا کسی بھی چیز کو چھونے سے پہلے API کے بالکل درست فرق کا پیش نظارہ کرتا ہے، اور آپ کے پروڈکشن اسٹیک کی ایک جیسی نقل بنانا چار ہفتوں کی بجائے چار منٹ لیتا ہے۔ اور آپ کے پروڈکشن اسٹیک کی ایک جیسی نقل بنانا چار ہفتوں کی بجائے چار منٹ لیتا ہے۔

### - 11. کلاؤڈ نیٹ ورکنگ (VPC، سب نیٹس، NAT اور سیکیورٹی گروپس)

13:20 تصور نمبر گیارہ: کلاؤڈ نیٹ ورکنگ اور ورچوئل پرائیویٹ کلاؤڈز۔ جب آپ سرورز کو کلاؤڈ پر تعینات کرتے ہیں، تو وہ کچی عوامی انٹرنیٹ پر بے نقاب نہیں بیٹھتے۔ وہ ایک سافٹ ویئر-تعریف شدہ الگ تھلگ حد کے اندر رہتے ہیں جسے VPC کہتے ہیں۔ اپنی VPC کے اندر، آپ ایک نجی IP ایڈریس کی جگہ مختص کرتے ہیں جیسے دس-ڈاٹ-زیرو-ڈاٹ-زیرو-ڈاٹ-زیرو سلیش سولہ، اور اسے عوامی اور نجی سب نیٹ میں تقسیم کرتے ہیں۔ دس-ڈاٹ-زیرو-ڈاٹ-زیرو-ڈاٹ-زیرو سلیش سولہ، اور اسے عوامی اور نجی سب نیٹ میں تقسیم کرتے ہیں۔ ایک عوامی سب نیٹ کا انٹرنیٹ گیٹ وے تک براہ راست راستہ ہوتا ہے۔

13:51 اس میں آپ کے ایپلیکیشن لوڈ بیلنسرز اور NAT گیٹ ویز جیسے عوامی اثاثے شامل ہوتے ہیں۔ یہ آپ کے نیٹ ورک کا واحد حصہ ہے جس میں عوامی IP پتے ہوتے ہیں۔ آپ کے ایپلیکیشن سرورز اور پروڈکشن ڈیٹا بیس سختی سے نجی سب نیٹ میں رہتے ہیں جن میں کوئی عوامی IP اور انٹرنیٹ سے صفر ان باؤنڈ راستے نہیں ہوتے۔ آپ کے ایپلیکیشن سرورز اور پروڈکشن ڈیٹا بیس سختی سے نجی سب نیٹ میں رہتے ہیں جن میں کوئی عوامی IP اور انٹرنیٹ سے صفر ان باؤنڈ راستے نہیں ہوتے۔ جب آپ کے بیک اینڈ سرورز کو سیکیورٹی اپ ڈیٹس ڈاؤن لوڈ کرنے کی ضرورت ہوتی ہے، ان کی آؤٹ باؤنڈ ٹریفک عوامی سب نیٹ میں NAT گیٹ وے کے ذریعے روٹ ہوتی ہے۔ ہر انسٹنس کے ارد گرد سیکیورٹی گروپس ہوتے ہیں: اسٹیٹ فل ورچوئل فائر والز جو کم از کم استحقاق کے اصول کو نافذ کرتے ہیں۔ ہر انسٹنس کے ارد گرد سیکیورٹی گروپس ہوتے ہیں: اسٹیٹ فل ورچوئل فائر والز جو کم از کم استحقاق کے اصول کو نافذ کرتے ہیں۔

### - 12. مکمل انٹرپرائز بلیو پرنٹ اور فیصلہ

14:28 آپ کا ڈیٹا بیس سیکیورٹی گروپ صرف پورٹ 5432 پر آپ کے ایپلیکیشن سرورز کے سیکیورٹی گروپ سے کنکشن قبول کرتا ہے، آپ کا ڈیٹا بیس سیکیورٹی گروپ صرف پورٹ 5432 پر آپ کے ایپلیکیشن سرورز کے سیکیورٹی گروپ سے کنکشن قبول کرتا ہے، بیرونی رسائی کو ریاضیاتی طور پر ناممکن بناتا ہے۔ جب آپ زوم آؤٹ کرتے ہیں، تو یہ گیارہ پرانی چیزیں ایک ہم آہنگ نظام میں جڑ جاتی ہیں۔ آپ کا DNS عوامی سب نیٹ میں ایک لوڈ بیلنسر پر روٹ کرتا ہے، آٹو اسکیلنگ گروپس متعدد دستیابی زونز میں ٹریفک کے اضافے کو سنبھالتے ہیں، ایونٹ بسیں بیک اینڈ ورکرز کو ڈی کپل کرتی ہیں، اور آپ کا پورا اسٹیک کوڈ کے بطور انفراسٹرکچر کا استعمال کرتے ہوئے Git سے تعینات کیا جاتا ہے۔ ایونٹ بسیں بیک اینڈ ورکرز کو ڈی کپل کرتی ہیں، اور آپ کا پورا اسٹیک کوڈ کے بطور انفراسٹرکچر کا استعمال کرتے ہوئے Git سے تعینات کیا جاتا ہے۔

15:02 آج کے ماسٹر کلاس کا فیصلہ: SHIP IT۔ سینکڑوں کلاؤڈ مارکیٹنگ کے مخففات کو یاد کرنا بند کریں۔ ان گیارہ آرکیٹیکچر پیٹرنز میں مہارت حاصل کریں، اپنی حالت کو ڈی کپل کریں، اور ایسے سسٹم بنائیں جو ناکام نہ ہو سکیں۔ مجھے بتائیں کہ جب آپ نے پہلی بار تعمیر شروع کی تو آپ کو کس کلاؤڈ تصور نے سب سے زیادہ سر درد دیا تبصروں میں۔ اور مکمل آرکیٹیکچر چیٹ شیٹ حاصل کرنے کے لیے، روزانہ diff.dev پر نیوز لیٹر کو سبسکرائب کریں،

15:28 لنک نیچے ہے۔ اور یہ آج کا diff ہے۔ میں Axrisi سے نیکو ہوں۔ ذمہ داری سے ضم کریں۔

## ذرائع

- [AWS Well-Architected Framework (Reliability & Performance Pillars)](https://aws.amazon.com/architecture/well-architected/) — aws.amazon.com
- [Kubernetes Architecture & Control Plane Concepts](https://kubernetes.io/docs/concepts/architecture/) — kubernetes.io
- [Martin Fowler: What is Event-Driven Architecture?](https://martinfowler.com/articles/201701-event-driven.html) — martinfowler.com
- [Amazon S3 Data Durability & Availability Technical Whitepaper](https://aws.amazon.com/s3/features/) — aws.amazon.com
- [HashiCorp: Declarative Infrastructure as Code with Terraform](https://www.terraform.io/) — www.terraform.io