ایک Nutshell میں نظام ڈیزائن

ہم شروع کریں. میں نے اس مضمون کو اپنے دماغ میں 2 سال کے لئے رکھ دیا اور اسے کبھی نہیں لکھا، اس بات سے ڈر لگتا ہے کہ یہ کامل نہیں ہو گا. ٹیکنالوجی کے ماحول ہمیشہ بدل رہا ہے اور ترقی کر رہا ہے، اور آپ آج استعمال کرتے ہوئے آلات 5 سال بعد پرانے ہوسکتے ہیں. اس وجہ سے میں اس نظام کے ڈیزائن کے بنیادی نظریات کو یہاں لکھ رہا ہوں. ہم ہمیشہ اس کی بنیاد پر ہماری انٹرفیس اور ضروریات کو بہتر بنانے کے قابل ہیں. اگر میں ایک اور فریم ورک پر آتا ہوں تو، میں اسے اس موازنہ کے ایک پیروی کے طور پر لکھوں گا. سسٹم ڈیزائن سافٹ ویئر کی ترقی کا ایک ضروری حصہ ہے. آپ کو خصوصیات میں گراف کرنے سے پہلے 30،000 فٹ نقطہ نظر ہونا چاہئے. عام مقصد پروگرامنگ زبانوں کو ہر جگہ استعمال کیا جا سکتا ہے، لیکن آپ کو سب سے پہلے یہ جاننے کی ضرورت ہے کہ اسے استعمال کرنے کے لئے کہاں اور اس کا استعمال کرنے کے لئے کس طرح. مندرجہ ذیل اہم اقدامات ہیں جو میں نے اپنے تحقیق کے دوران پایا (کچھ موضوعات کو تفصیلی طور پر بیان نہیں کیا جائے گا کیونکہ وہ ان کے اپنے مضامین کے قابل ہیں): UX ڈیزائن & اجزاء کیونکہ آپ سب سے زیادہ ممکنہ طور پر CLI کی ترقی نہیں کریں گے، اچھی UX-UI ہونا ضروری ہے. آپ کو اہم اجزاء کو جاننے کی ضرورت ہے اور اس کے بعد آپ آگے بڑھتے ہوئے ان پر بہتر بنانا ہے. صرف اہم چیزیں کافی ہیں. ایک ٹویٹر کلون کو ایک اجزاء ہوگا جہاں ٹویٹس تیار کیے جائیں گے۔ اس میں صارف پروفائلز، پیروکار، رازداری کی ترتیبات وغیرہ ہوں گے۔ ایک Uber کلون نقشے انضمام کرے گا. چیٹ پیغامات جیسے WhatsApp میں شخص سے شخص کے پیغامات اور گروپ پیغامات، پیغامات اور اشتراک کے اختیارات، وغیرہ ہوں گے. آپ ڈیزائن کر رہے ہیں کہ ایپز کی قسم کی کوشش کریں اور ان کے ڈیزائن پر نظر ڈالیں. تمام سوشل میڈیا ایپز ایک چھت کے تحت ہوں گے، تمام ویڈیو سٹریمنگ پلیٹ فارمز / OTT دوسرے میں ہوں گے، اور تمام فلم بکنگ / بکنگ ایپز ایک دوسرے کے تحت ہوں گے. ╔═════════════════════════════════════╗ ║ TWITTER CLONE UI COMPONENTS ║ ╠═════════════════════════════════════╣ │ APPLICATION UI │ ├─────────────────────────────────────┤ │ ┌──────────┐ ┌──────────┐ │ │ │ Profile │ │ Tweet │ │ │ │Component │ │Component │ │ │ └──────────┘ └──────────┘ │ │ ┌──────────┐ ┌──────────┐ │ │ │ Settings │ │ Messages │ │ │ │Component │ │Component │ │ │ └──────────┘ └──────────┘ │ └─────────────────────────────────────┘ کلاسیں / Subclasses اگر آپ ایک اشیاء کی طرف متوجہ ڈیزائن کے بارے میں سوچ رہے ہیں، تو یہ آسان ہے اگر آپ اپنے نظام کے ڈیزائن میں آپ کی ضرورت ہوسکتی ہے کہ تمام مختلف کلاسوں کی فہرست کریں. یہ تمام اشیاء کو چالو کرنے میں مدد ملتی ہے، اور پھر آپ ان کلاسوں سے متعلق طریقوں کی وضاحت کرنے کے لئے آگے بڑھ سکتے ہیں. ╔═════════════════════════════════════╗ ║ OBJECT-ORIENTED CLASS DESIGN ║ ╚═════════════════════════════════════╝ ┌─────────────────┐ │ User │ ├─────────────────┤ │ - name │ │ - location │ │ - email │ ├─────────────────┤ │ + post() │ │ + follow() │ └────────┬────────┘ │ ┌────────┴────────┐ │ │ ┌───▼────┐ ┌─────▼───┐ │Premium │ │ Basic │ │ User │ │ User │ └────────┘ └─────────┘ ڈیزائن Patterns ایک بار جب آپ کلاس ڈیزائن حاصل کرسکتے ہیں تو، آپ اپنی ضروریات کو پورا کرنے کے لئے ایک مناسب ڈیزائن ماڈل منتخب کرسکتے ہیں. مثال کے طور پر، اگر آپ کے ایپلی کیشن میں ایک نیوز فائی ہے تو، آپ Publisher-Subscriber ڈیزائن ماڈل پر غور کرسکتے ہیں. ╔═════════════════════════════════════╗ ║ PUBLISHER-SUBSCRIBER PATTERN ║ ╚═════════════════════════════════════╝ ┌──────────────┐ │ Publisher │ │ (News Feed) │ └──────┬───────┘ │ │ publish() │ ┌───▼────────────────┐ │ Message Broker │ └───┬────────────────┘ │ │ notify() │ ┌───┴───┬───────┬────────┐ │ │ │ │ ┌──▼──┐ ┌──▼──┐ ┌──▼──┐ ┌───▼─┐ │Sub1 │ │Sub2 │ │Sub3 │ │Sub4 │ └─────┘ └─────┘ └─────┘ └─────┘ CDN / Serverless / API / کیش CDN is used to host static HTML content with lower latency. You can incorporate it in your infrastructure to reduce response time. You can reduce costs by using serverless architecture for simple grunt work, automation, or cron jobs. APIs help a lot in connecting disconnected systems and enabling segregation of concerns. Cache helps store temporary data, but the catch is that cache memory is the most expensive type of memory. So, you must have an optimized cache strategy. ╔═════════════════════════════════════╗ ║ CDN/SERVERLESS/API/CACHE STACK ║ ╚═════════════════════════════════════╝ ┌─────────┐ │ Client │ └────┬────┘ │ ▼ ┌─────────────┐ ┌──────────┐ │ CDN │◄───│ Static │ │ (Static) │ │ Content │ └────┬────────┘ └──────────┘ │ ▼ ┌─────────────┐ ┌──────────┐ │ Cache │◄───│ Hot │ │ │ │ Data │ └────┬────────┘ └──────────┘ │ ▼ ┌─────────────┐ ┌──────────┐ │ API │◄───│Serverless│ │ Gateway │ │Functions │ └────┬────────┘ └──────────┘ │ ▼ ┌─────────────┐ │ Backend │ │ Server │ └─────────────┘ ممکنہ مطابقت vs. تجارتی مطابقت In eventual consistency, you can expect some delay in the transaction being considered "written." This is used in applications where a little delay may not affect the overall application. For example, a WhatsApp message may be delivered with a delay of 2-3 seconds, and that should not impact the overall user experience. You can use a NoSQL database to achieve this. In transactional consistency, you want the transaction to be committed instantly. For example, in a money transfer application, you want the money transferred immediately to reduce the risks of double spending. You can use a relational database to achieve this. ╔═════════════════════════════════════════════════════════════╗ ║ EVENTUAL vs TRANSACTIONAL CONSISTENCY ║ ╚═════════════════════════════════════════════════════════════╝ EVENTUAL CONSISTENCY TRANSACTIONAL CONSISTENCY ┌──────────────────┐ ┌──────────────────┐ │ Write Request │ │ Write Request │ └────────┬─────────┘ └────────┬─────────┘ │ │ ▼ ▼ ┌─────────┐ ┌─────────┐ │ NoSQL │ │ SQL │ │ DB │ │ DB │ └────┬────┘ └────┬────┘ │ │ ┌────▼────┐ ┌────▼────┐ │ Delay │ │Immediate│ │ 2-3 sec │ │ Commit │ └────┬────┘ └────┬────┘ │ │ ▼ ▼ [Eventually [Immediately Consistent] Consistent] واقعات کا عمل واقعات کا انتظام ضروری ہے جب آپ کے پاس مختلف اجزاء ہیں جو ایک دوسرے سے بات چیت کرنے کی کوشش کرتے ہیں. درخواست کے آغاز سے جواب کی تکمیل تک، آپ کو واضح طور پر جاننا چاہئے کہ ڈیٹا پیکیجوں کے راستے کیا کریں گے. ╔═════════════════════════════════════╗ ║ EVENT HANDLING FLOW ║ ╚═════════════════════════════════════╝ ┌──────────┐ Event ┌──────────┐ │Component │─────────────►│ Event │ │ A │ Fired │ Queue │ └──────────┘ └─────┬────┘ │ ┌─────▼─────┐ │ Handler │ └─────┬─────┘ │ ┌───────────┼───────────┐ │ │ │ ┌───▼───┐ ┌───▼───┐ ┌───▼───┐ │Comp B │ │Comp C │ │Comp D │ └───────┘ └───────┘ └───────┘ SQL / NoSQL / Polyglot پائیدار SQL ڈیٹا بیسوں کو ساختہ ڈیٹا کو ذخیرہ کرنے کے لئے استعمال کیا جاتا ہے.In distributed SQL systems, during network partitions, you typically prioritize consistency over availability. NoSQL ڈیٹا بیسوں کو نصف ساختہ ڈیٹا، کلید کے اجزاء جوڑوں، تصاویر، اور ویڈیوز کو ذخیرہ کرنے کے لئے استعمال کیا جا سکتا ہے. Graph ڈیٹا بیسز اور تلاش کے انجن ڈیٹا بیسز بھی NoSQL ڈیٹا بیسز کے تحت آتے ہیں. CAP نظریہ کے مطابق، ایک تقسیم شدہ نظام میں نیٹ ورک کے حصوں کا تجربہ کرتے ہوئے، آپ کو مطابقت اور دستیابیت کے درمیان منتخب کرنا پڑتا ہے. اگر آپ کو SQL اور NoSQL ڈیٹا بیسوں کی ایک مجموعہ کی ضرورت ہے تو، ہم اسے polyglot persistence کہتے ہیں. ╔═════════════════════════════════════╗ ║ SQL/NoSQL/POLYGLOT PERSISTENCE ║ ╚═════════════════════════════════════╝ ┌─────────────────────────────────────┐ │ Application Layer │ └──────────────┬──────────────────────┘ │ ┌───────┴────────┐ │ │ ┌──────▼──────┐ ┌─────▼────────────┐ │ SQL │ │ NoSQL │ │ Database │ │ Database │ ├─────────────┤ ├──────────────────┤ │ - ACID │ │ - Key-Value │ │ - Structured│ │ - Document │ │ - CA (CP) │ │ - Graph │ │ │ │ - AP │ └─────────────┘ └──────────────────┘ └────────┬────────┘ │ POLYGLOT PERSISTENCE Client-Side vs. Server-Side ڈیٹا اسٹوریج مثال کے طور پر، WhatsApp پیغامات آپ کے سمارٹ فون کے مقامی اسٹوریج میں محفوظ ہیں، اختیاری کلاؤڈ بیک اپ کے ساتھ. بعض اوقات، تمام ڈیٹا سرورز پر ذخیرہ کیا جاتا ہے، مثال کے طور پر، فیس بک میسرز میں تمام پیغامات فیس بک سرورز پر محفوظ ہیں. ترقی کے سائیکل کو شروع کرنے سے پہلے، آپ کو واضح طور پر بیان کرنے کی ضرورت ہے کہ کون سی اجزاء سرور کے وسائل کا استعمال کریں گے اور کون سی اجزاء آلہ کے مقامی وسائل کا استعمال کریں گے. ╔═══════════════════════════════════════════════════╗ ║ CLIENT-SIDE vs SERVER-SIDE STORAGE ║ ╚═══════════════════════════════════════════════════╝ CLIENT-SIDE SERVER-SIDE ┌──────────────┐ ┌──────────────┐ │ Mobile │ │ Server │ │ Device │ │ Cluster │ ├──────────────┤ ├──────────────┤ │ ┌──────────┐ │ │ ┌──────────┐ │ │ │ WhatsApp │ │ │ │ Facebook │ │ │ │ Messages │ │ │ │Messenger │ │ │ │ (Local) │ │ │ │ Messages │ │ │ └──────────┘ │ │ └──────────┘ │ │ │ │ │ │ + Optional │ │ + Backup │ │ Cloud │ │ + Sync │ │ Backup │ │ + Access │ └──────────────┘ └──────────────┘ بہتر ڈیٹا ڈھانچے ہر خط کوڈ آپ لکھتے ہیں سرور ٹیکس. زیادہ ٹیکس، آپ کو اس کو برقرار رکھنے کے لئے زیادہ ادا کرنے کی ضرورت ہے. اس وجہ سے یہ بہتر طریقہ کار ہے کہ آپ کو بہتر سافٹ ویئر کوڈ لکھنے اور اعداد و شمار کی ساختوں کا استعمال کرتے ہیں جو کم وقت اور جگہ پیچیدگی ہے. ╔═════════════════════════════════════╗ ║ OPTIMIZED DATA STRUCTURES ║ ╚═════════════════════════════════════╝ Data Structure Complexity O(1) ───────── Best (Hash Table) O(log n) ────── Good (Binary Tree) O(n) ───────── Acceptable (Array) O(n²) ───────── Poor (Nested Loops) O(2ⁿ) ───────── Worst (Exponential) ┌─────────────────────────────┐ │ Choose Lower Complexity │ │ = Less Server Tax │ │ = Lower Costs │ └─────────────────────────────┘ پرائیویسی ترتیبات آپ کے ایپلی کیشن کے صارفین کو انٹرنیٹ پر اپنے آپ کو محفوظ کرنے کے اختیارات ہونا چاہئے. آپ کو اچھے رازداری کے اختیارات ہونا چاہئے. مثال کے طور پر، WhatsApp میں، آپ اپنے پروفائل کی تصویر کو چھپا سکتے ہیں، دستاویزات پڑھ سکتے ہیں، اور آخری دیکھا. +-----------------------------------------+ | PRIVACY SETTINGS | +-----------------------------------------+ +-----------------------------------------+ | User Privacy Panel | +-----------------------------------------+ | [ ] Show Profile Photo | | [X] Hide Last Seen | | [X] Hide Read Receipts | | [ ] Show Online Status | | [X] Block User | | | | [Save Settings] | +-----------------------------------------+ مطابقت آپ کی اپلی کیشن کو ضروری قوانین کے مطابق ہونا چاہئے۔ مثال کے طور پر: If your application handles Protected Health Information (PHI) for covered entities, it should be HIPAA compliant. If your application is being launched in the EU, it should be GDPR compliant. ╔═════════════════════════════════════╗ ║ COMPLIANCE REQUIREMENTS ║ ╚═════════════════════════════════════╝ ┌──────────────────────────────────┐ │ Your Application │ └────────────┬─────────────────────┘ │ ┌──────┴──────┐ │ │ ┌─────▼─────┐ ┌────▼──────┐ │ HIPAA │ │ GDPR │ │Compliance │ │Compliance │ ├───────────┤ ├───────────┤ │ Medical │ │ EU │ │ PHI │ │ Privacy │ │ Protected │ │ Rules │ └───────────┘ └───────────┘ سیکورٹی کے مسائل اگرچہ سیکورٹی ایک بہت وسیع موضوع ہے، آپ کی ابتدائی تجزیہ میں آپ کو سپیم اور DDoS سے تحفظ پر غور کرنا چاہئے. آپ کو مناسب IAM ساخت اور مضبوط پاس ورڈ کی پالیسیوں کی ضرورت ہے. آپ کو اضافی سیکورٹی کے لئے 2FA کی اجازت دینے پر بھی غور کرنا چاہئے. ╔═════════════════════════════════════╗ ║ SECURITY LAYERS ║ ╚═════════════════════════════════════╝ ┌───────────────────────────────────┐ │ Security Layers │ ├───────────────────────────────────┤ │ Layer 5: 2FA Authentication │ ├───────────────────────────────────┤ │ Layer 4: IAM & Access Control │ ├───────────────────────────────────┤ │ Layer 3: DDoS Protection │ ├───────────────────────────────────┤ │ Layer 2: Spam Filtering │ ├───────────────────────────────────┤ │ Layer 1: Password Policy │ └───────────────────────────────────┘ استعمال کے علاقے میں دستیاب خدمات جیسا کہ عنوان سے پتہ چلتا ہے، آپ کے بارے میں سوچنے والے تمام خدمات اس جغرافیائی علاقے میں دستیاب ہونا چاہئے جہاں آپ اپنی درخواست شروع کرنے کا ارادہ رکھتے ہیں۔ مثال کے طور پر، اگر آپ چین میں ایک اپلی کیشن شروع کرنے کا ارادہ رکھتے ہیں تو، آپ کو اپنے ایپلی کیشن ڈیزائن میں فیس بک API پر غور نہیں کرنا چاہئے کیونکہ یہ کام نہیں کرے گا. +---------------------------------------+ | GEOGRAPHICAL SERVICE AVAILABILITY | +---------------------------------------+ GLOBAL SERVICE MAP +--------------+ +--------------+ | USA | | China | +--------------+ +--------------+ | [+] Facebook | | [-] Facebook | | [+] Google | | [-] Google | | [+] AWS | | [+] Alibaba | | [+] WhatsApp | | [+] WeChat | +--------------+ +--------------+ Check Service Availability Before Launch! قیمتوں کا تجزیہ کارکردگی اور کارکردگی کو نقصان پہنچانے کے بغیر، آپ کو زیادہ سے زیادہ ممکنہ طور پر لاگت کو کم کرنا چاہئے.When considering options, try to select open-source frameworks with good developer community support. ╔═════════════════════════════════════╗ ║ COST OPTIMIZATION ║ ╚═════════════════════════════════════╝ ┌────────────────────────────────────┐ │ Cost Optimization │ ├────────────────────────────────────┤ │ │ │ Open Source >>> Proprietary │ │ (Lower Cost) (Higher Cost) │ │ │ │ Serverless >>> Always-On │ │ (Pay per use) (Fixed Cost) │ │ │ │ Cache >>> DB Query │ │ (Expensive) (Cheaper) │ │ │ └────────────────────────────────────┘ Balance Cost vs Performance On-Prem / Cloud / ہائبرڈ فیصلہ کریں کہ آپ کے اعداد و شمار on-prem میں رہیں گے، مکمل طور پر کلاؤڈ پر، یا جزوی کلاؤڈ اور جزوی on-prem (ہائبرڈ). ╔═════════════════════════════════════╗ ║ DEPLOYMENT OPTIONS ║ ╚═════════════════════════════════════╝ ┌──────────────────────────────────────┐ │ Deployment Options │ └───────────┬──────────────────────────┘ │ ┌───────┼───────┐ │ │ │ ┌───▼───┐ ┌─▼────┐ ┌▼──────┐ │On-Prem│ │Cloud │ │Hybrid │ ├───────┤ ├──────┤ ├───────┤ │Local │ │ AWS │ │On-Prem│ │Servers│ │Azure │ │ + │ │ Data │ │ GCP │ │ Cloud │ │Center │ │ │ │ Mix │ └───────┘ └──────┘ └───────┘ │ ┌───▼────┐ │ VPC │ └────────┘ Horisontal Scaling / Vertical Scaling & Load Balancers کے مترادفات horizontal scaling میں، آپ موجودہ DB سرور / ایپ سرور کے ریپائلز ڈالتے ہیں اور ان instances کے درمیان ٹریفک کی توازن کرنے کے لئے ایک لوڈ بیلڈر کا استعمال کرتے ہیں. vertical scaling میں، آپ انسٹال کے نظام کی ترتیب کو بہتر بناتے ہیں. آپ کو بہتر بنانے کے لئے کیا کچھ حد ہے. وہاں دیگر فکریں بھی ہیں - مثال کے طور پر، اگر آپ کمپیوٹر کو بڑھاتے ہیں تو، آپ کو اس کے مطابق RAM کو بڑھانے کی ضرورت ہے. ایک حکمت انگیز شرط ہو جائے گا ایک مناسب موازنہ ہائی سٹوریل اور بیکٹیریا scaling ہے. لوڈ توازنروں کو مختلف انسٹالوں کے درمیان ٹریفک توازن کرنے کے لئے استعمال کیا جاتا ہے. لوڈ توازنروں کو سسٹم کی روک تھام کو کم کرنے میں مدد ملتی ہے. +-------------------------------------------------------------+ | HORIZONTAL & VERTICAL SCALING WITH LOAD BALANCERS | +-------------------------------------------------------------+ HORIZONTAL SCALING VERTICAL SCALING +---------------+ +---------------+ | Load Balancer | | Upgrade | +-------+-------+ | CPU + RAM | | +-------+-------+ | | +-------------+-------------+ | | | | | v v v (and v) v +---+ +---+ +---+ +---------------+ |DB1| |DB2| |DB3|... | Powerful | +---+ +---+ +---+ | Server | +---------------+ Add more servers Improve single server گاہکوں کی خریداری اور گاہکوں کی بحالی آپ کے کسٹمر بیس کو بہتر بنانے کے لئے فائنل تجزیہ اور A / B ٹیسٹنگ جیسے تجزیہ کو شامل کریں. ╔═════════════════════════════════════╗ ║ CUSTOMER ACQUISITION & RETENTION ║ ╚═════════════════════════════════════╝ ┌─────────────────────────────────────┐ │ Analytics Funnel │ ├─────────────────────────────────────┤ │ │ │ 1000 Users ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ │ │ │ │ │ 500 Signups ▓▓▓▓▓▓▓▓▓ │ │ │ │ │ 200 Active ▓▓▓▓ │ │ │ │ │ 100 Paid ▓▓ │ │ │ ├─────────────────────────────────────┤ │ A/B Testing │ │ ┌─────────┐ ┌─────────┐ │ │ │Version A│ │Version B│ │ │ │ 50% │ │ 50% │ │ │ └────┬────┘ └─────┬───┘ │ │ └──────┬────────┘ │ │ Compare │ └─────────────────────────────────────┘ خلاصہ : ================================ SYSTEM DESIGN IN A NUTSHELL 17 Core Concepts ================================ START HERE | ↓ 1. UX DESIGN & COMPONENTS → Design UI elements → Profile, messages, feeds | ↓ 2. CLASSES & SUBCLASSES → Define objects → User profiles with attributes | ↓ 3. DESIGN PATTERNS → Publisher-Subscriber → For news feeds | ↓ 4. INFRASTRUCTURE STACK → CDN for static content → Serverless functions → API Gateway → Cache strategy | ↓ 5. CONSISTENCY MODELS → Eventual (NoSQL) → Transactional (SQL) | ↓ 6. EVENT HANDLING → Request to response → Data packet routes | ↓ 7. DATABASE STRATEGY → SQL: Structured data → NoSQL: Key-value, docs → CAP Theorem considerations → Polyglot Persistence | ↓ 8. DATA STORAGE → Client-side (local) → Server-side (cloud) → Hybrid approach | ↓ 9. OPTIMIZED DATA STRUCTURES → Lower time complexity → Lower space complexity → Reduce server tax | ↓ 10. PRIVACY SETTINGS → Hide profile info → Block users → Read receipts control | ↓ 11. COMPLIANCE → HIPAA for medical PHI → GDPR for EU users | ↓ 12. SECURITY LAYERS → DDoS protection → IAM structure → 2FA authentication → Password policies → Spam filtering | ↓ 13. GEOGRAPHICAL SERVICES → Check availability → Regional restrictions → Example: Facebook in China | ↓ 14. COST OPTIMIZATION → Open source frameworks → Serverless options → Balance cost vs performance | ↓ 15. DEPLOYMENT OPTIONS → On-Premises → Cloud (AWS/Azure/GCP) → Hybrid approach → VPC considerations | ↓ 16. SCALING STRATEGIES → Horizontal: Add replicas → Vertical: Upgrade config → Load balancers → Mix both approaches | ↓ 17. CUSTOMER ANALYTICS → Funnel analytics → A/B testing → Acquisition & retention ================================ KEY TAKEAWAYS ================================ ★ 30,000 ft view first ★ Design before coding ★ Consider all 17 aspects ★ Balance trade-offs ★ Optimize for scale ★ Security & compliance ★ Cost-effective choices ================================ یہ فریم ورک بھی آپ کو کسی بھی سب سے اوپر MNC میں ابتدائی سطح کے نظام ڈیزائن انٹرویو سوالات کو صاف کرنے میں مدد ملے گی. جب میں نے اس مضمون کو لکھنا شروع کیا، میں نے اپنے دماغ میں بہت زیادہ تھا. میں نے مواد کو ختم کرنے کی ضرورت تھی کیونکہ یہاں ذکر کردہ بہت سے مفهوموں کو منفرد مضامین میں وضاحت کی جا سکتی ہے. پڑھنے کے لئے آپ کا شکریہ.Stay tuned. اگر آپ کے پاس کوئی سوالات ہیں تو، براہ مہربانی مجھے ایک ای میل بھیجنے کے لئے آزاد محسوس کریں. آپ بھی لنکڈین کے ذریعے مجھ سے رابطہ کر سکتے ہیں. ای میل ای میل لینڈنگ لینڈنگ X X