Ultimate System Design Learning Playlist Overview
- Target audience: software engineers, students, developers aiming for FAANG
- Covers theory plus real-world scalable system builds like BookMyShow, Amazon, IRCTC, Spotify
- Focus on practical code, concurrency, order placement, HLD & LLD concepts
Phase 1: Foundational Concepts
- Monolithic vs Microservice Architectures and conversion strategies
- Microservices communication, API Gateway vs Load Balancer distinctions
- Load balancer types & algorithms (round robin, IP hashing), proxy & reverse proxy concept and differentiation
- Deployment sequencing, concurrency maintenance techniques
For a detailed analogy on designing scalable systems, refer to Scalable System Design Explained Using a Restaurant Analogy.
Phase 2: Networking Protocols & API Design
- TCP, UDP protocols with focus on transport layer
- HTTP, HTTPS, WebSockets, WebRTC under application layer
- REST APIs vs gRPC: building APIs using gRPC
- CDN functionality & its importance for global platforms like Netflix
- Caching principles and request rate limiting techniques
Explore fundamentals and tools for effective API testing in Comprehensive Introduction to API Testing Fundamentals and Tools.
Phase 3: Distributed Systems & Databases
- Distributed systems overview; CAP theorem explained (Consistency, Availability, Partition Tolerance)
- Database choice criteria based on data structure, query patterns, scalability needs
- SQL vs NoSQL use cases; Indexing, sharding (including name-based & regional sharding)
- Consistent hashing mechanism for load and data distribution among servers
- Distributed transactions management using two-phase & three-phase commits
- Event-driven architecture, messaging queues like Kafka & RabbitMQ
Gain deeper architectural insights in Understanding Hexagonal Architecture: Transforming MVC Applications.
Phase 4: Containerization & Cloud Services
- Containerization essentials with Docker
- Serverless vs EC2 architectures on AWS
- Deploying scalable applications using cloud-native tools
Learn about key AWS services in Top AWS Services Explained for Beginners: EC2, S3, IAM & More.
Additional Topics Covered
- Authentication, authorization, encryption (end-to-end with private/public keys)
- Cron jobs for efficient long-term data management
- Polling mechanisms, file uploads, pre-signed URLs, and handling media storage
- Practical coding examples and migration from monolith to microservices
- Load balancer vs API gateway placement in high availability environments
- Real world scalability from zero to millions of users
For implementation examples and migration strategies, see Unlocking Microservices in the Browser with Single-SPA.
Key Takeaways
- System design is crucial for building scalable and reliable real-world systems
- Microservice architecture solves issues with monolithic systems like single points of failure
- API Gateways abstract and simplify client-service communication
- Load balancing and caching are vital for performance and reliability
- Consistency and fault-tolerance in distributed systems are achieved through CAP theorem trade-offs
- Proper database choice and sharding strategies are essential for handling large scale data
- Messaging queues enable asynchronous communication solving availability and decoupling challenges
- Security through SSL certificates, authentication, and encryption is foundational for safe communications
- Cloud and containerization modernize deployment and scalability
For Beginners and Advanced Engineers
- The playlist is structured week-wise for progressive learning
- Theoretical concepts paired with coding; real system designs like Amazon & Spotify
- Interview question preparation included
- Emphasizes understanding system trade-offs and practical solutions
Summary
This comprehensive system design series walks learners through essential modern architecture concepts, practical coding implementations, and key infrastructure components. It targets building highly scalable, resilient, and efficient real-world software systems, blending theory with realistic projects to prepare engineers for industry challenges and interviews.
[संगीत] [संगीत] [संगीत]
[संगीत] अगर आप सॉफ्टवेयर इंजीनियर हो चाहे आप कॉलेज स्टूडेंट हो या फैंग इंटरव्यूज के
लिए प्रिपेयर कर रहे हो या फिर आप एक ऐसे डेवलपर हो जो खुद का रियल वर्ल्ड स्केलेबल सिस्टम सिस्टम बनाना चाहता हो या फिर आप
खुद का एक स्टार्टअप बिल्ड करना चाहते हो तो सिस्टम डिजाइन इज मस्ट फॉर यू। तो हम आ रहे हैं एक ऐसी सीरीज के साथ जिसमें ना
सिर्फ हम थ्योरी सारे सिस्टम डिजाइन टॉपिक्स कवर कर रहे होंगे। उसके साथ ही साथ हम रियल वर्ल्ड स्केलेबल सिस्टम्स भी
बना रहे होंगे यूजिंग ऑल द एचएलडी एंड एलएलडी कांसेप्ट्स। तो हम कवर कर रहे होंगे बुक माय शो जैसा सिस्टम, Amazon
जैसा सिस्टम, iआरसीटीc स्पॉटfाई। सो ये चारों सिस्टम बिल्ड कर रहे होंगे यूजिंग ऑल द एचएलडी एंड एलएलडी कांसेप्ट्स। हम
इनका कोड लिख रहे होंगे और देखेंगे हम कैसे ककरेंसी को मेंटेन करेंगे। कैसे हमारा ऑर्डर प्लेस होगा। सो वी आर गोइंग
टू कवर एवरीथिंग इन दिस प्लेलिस्ट। अब देखते हैं कि कौन-कौन से ऐसे थ्योरी टॉपिक्स हैं जो हम इस प्लेलिस्ट में कवर
करने वाले हैं। तो सबसे पहले आ जाते हैं हमारे फाउंडेशनल कांसेप्ट्स जिसमें हम देख रहे होंगे व्हाट इज़ मोनोलेथ आर्किटेक्चर,
व्हाट इज़ माइक्रो सर्विस आर्किटेक्चर एंड व्हाट्स द डिफरेंस बिटवीन देम। सो वी विल बी कवरिंग दिस। हम देख रहे होंगे कि कैसे
हम एक मोनोलिथ एप्लीकेशन को माइक्रो सर्विस एप्लीकेशन में कन्वर्ट कर सकते हैं। हम देख रहे होंगे कैसे माइक्रो
सर्विसेज आपस में कम्युनिकेट करती हैं। हम देख रहे होंगे कि एपीआई गेटवे क्या होता है? लोड बैलेंसर क्या होता है? एपीआई
गेटवे और लोड बैलेंसर में क्या डिफरेंस होता है? और एक रियल वर्ल्ड प्रोजेक्ट में रियल वर्ल्ड सिस्टम में कौन पहले आता है?
एपीआई गेटवे और लोड बैलेंसर। सो वी विल बी कवरिंग ऑल दिस थिंग। फिर हम देख रहे होंगे लोड बैलेंसर के डिफरेंट टाइप्स एंड व्हाट
आर ऑल लोड बैलेंसर एल्गोरिदम्स जिसमें हम कवर कर रहे होंगे राउंड रबिन आईपी#श। सो वी आर गोइंग टू कवर ऑल सच थिंग्स इन दिस
लोड बैलेंसर टाइप। फिर हम देख रहे होंगे प्रॉक्सी क्या होता है? रिवर्स प्रॉक्सी क्या होता है? दोनों में डिफरेंस क्या है?
एंड हाउ रिवर्स प्रॉक्सी इज़ डिफरेंट फ्रॉम लोड बैलेंसर्स। सो दीज़ आर द काइंड ऑफ टॉपिक्स दैट वी आर गोइंग टू कवर इन दिस
फाउंडेशनल कांसेप्ट्स जो कि हमारा फेज वन होने वाला है जो हम एक वीक में कवर करेंगे। उसके बाद नेक्स्ट वीक
में हम देख रहे होंगे डिफरेंट नेटवर्किंग प्रोटोकॉल्स जिसमें हम सारे टीसीपी टीसीपी प्रोटोकॉल्स और यूडीपी प्रोटोकॉल्स कवर कर
रहे होंगे। हम देख रहे होंगे http https वेब सॉकेट्स वेब आरटीसी अ इनमें डिफरेंस हम देख रहे होंगे उसके बाद हम देखेंगे
रेस्ट एपीआई जीआरपीसी हाउ वी कैन बिल्ड एपीआई यूजिंग जीआरपीसी सो वी विल बी कवरिंग दिस फिर हम देख रहे
होंगे कि सीडीएन क्या होता है एंड व्हाट इज द नीड ऑफ़ सीडीएन इन अ रियल वर्ल्ड प्रोजेक्ट स्पेशली जब हम एक ग्लोबल
प्लेटफार्म बना रहे होते Netflix जैसा। तो, सीडीएन की कहां पे नीड आती है। तो, हम यह भी कवर कर रहे होंगे। हम देख रहे होंगे
कि व्हाई कैशिंग इज़ेंट? व्हाट इज़ कैशिंग। सो, वी विल बी कवरिंग दिस। एंड हाउ वी कैन कैश डेटा यूजिंग सीडीएन। हम यह भी देख रहे
होंगे। उसके बाद हम देखेंगे हम कैसे रिक्वेस्ट को यूजर की रिक्वेस्ट को रेट लिमिट कर सकते हैं। लेट्स से आप किसी
वेबसाइट पे जाते हैं एंड आप कंटिन्यू अ 20-25 टाइम्स रिफ्रेश बटन हिट करते हैं। तो हाउ वी विल हैंडल दिस थिंग इन बैक एंड।
सो वी विल बी कवरिंग दिस। उसके बाद हम देख रहे होंगे कि कैसे हम एक सिस्टम को फ्रॉम ज़ीरो टू मिलियन यूज़र्स तक स्केल कर सकते
हैं इन अ रियल वर्ल्ड प्रोजेक्ट। हम देख रहे होंगे डिफरेंट टाइप्स ऑफ स्केलिंग। व्हाट इज हॉरिजॉन्टल स्केलिंग? व्हाट इज
वर्टिकल स्केलिंग। तो हम सेकंड वीक में यह हमारा टारगेट होने वाला है। उसके बाद थर्ड वीक में हम आ जाते हैं डिस्ट्रीब्यूटेड
सिस्टम्स की तरफ। जहां हम देख रहे होंगे व्हाट इज़ डिस्ट्रीब्यूटेड सिस्टम्स। क्योंकि अब हम मिलियन यूज़र्स तक जा चुके
हैं। तो हमें इस डिस्ट्रीब्यूटेड सिस्टम्स की नीड होगी। सो वी विल बी कवरिंग द बेसिक्स ऑफ डिस्ट्रीब्यूटेड सिस्टम्स। हम
देख रहे होंगे कैप थ्योरम जो कि जिसका जिसको मैंने काफी बार मेरी सिस्टम डिज़ाइन प्लेलिस्ट में मेंशन किया है व्हेयर वी
डिस्कस्ड Netflix सिस्टम डिज़ाइन, Amazon सिस्टम डिज़ाइन, स्पॉटिफाई सिस्टम डिज़ाइन। सो, आई हैव डिस्कस्ड अ लॉट अबाउट दिस CP
थ्योरम इन ऑल दोज़ वीडियोस। सो, आई हाइली रिकमेंड यू टू वॉच दोज़ वीडियोस फर्स्ट। इट विल गिव यू अ बेटर ओवरव्यू हाउ वी आर
गोइंग टू डू इन इन दिस प्लेलिस्ट। उसके बाद हम देख रहे होंगे डेटाबेस चॉइस। क्योंकि हमारे पास सीक्वल डेटाबेस होते
हैं। नो सीक्वल डेटाबेस होते हैं। सो अकॉर्डिंग टू द रिक्वायरमेंट वी विल बी सेलेक्टिंग डेटाबेस। हम देख रहे होंगे कि
कहां पर हमें सीक्वल डेटाबेस यूज करना है। कहां पर हमें नो सीक्वल डेटाबेस यूज करना है। उसके बाद हम देख रहे होंगे कि
इंडेक्सिंग का डेटाबेस में क्या रोल होता है। एंड कैसे इंडेक्सिंग का यूज़ करके हम डेटाबेस क्वेरीज़ को फास्ट बना सकते हैं।
सो वी विल बी कवरिंग दिस। उसके बाद हम देख रहे होंगे शार्डिंग वर्सेस पार्टीशनिंग। शार्डिंग क्या होती है? शार्डिंग कैसे की
जाती है? वी विल बी कवरिंग दिस। उसके बाद हम देख रहे होंगे कंसिस्टेंट हैशिंग। कंसिस्टेंट हैशिंग की क्या नीड है और कैसे
हम इसे अचीव कर सकते हैं। उसके बाद हम देख रहे होंगे डिस्ट्रीब्यूटेड ट्रांजैक्शंस। टू फेस कमिट क्या होता है? थ्री फेस कमिट
क्या होता है। हम देख रहे होंगे ककरेंसी कंट्रोल जिसमें हम ऑप्टिमिस्टिक पैसिमिस्टिक लॉक देख रहे होंगे। हम
देखेंगे कि कैसे दो यूज़र्स एक सिस्टम पे आते हैं। वह अपनी टिकट बुक बुक करते हैं। लेट्स से दे ट्राई टू बुक द सेम टिकट।
लेकिन केवल एक ही यूजर उस टिकट को बुक कर पाता है। सो वी विल बी कवरिंग दिस कि कैसे हम यह मैनेज और मेंटेन कर सकते हैं। उसके
बाद हम देख रहे होंगे इवेंट ड्रिवन आर्किटेक्चर के बारे में। इसके बेसिक्स हम देख रहे होंगे मैसेजिंग कज़। मैसेजिंग कज़
की क्या जरूरत होती है? मैसेजिंग क्यूज़ इज़ आल्सो वन ऑफ़ द थिंग दैट आई डिस्कस्ड अ लॉट अह इन माय सिस्टम डिज़ाइन प्लेलिस्ट वेयर
वी डिस्कस्ड Netflix सिस्टम डिज़ाइन ब्लिंकिट सिस्टम डिज़ाइन। सो यस गो एंड वॉच दोज़ वीडियोस फर्स्ट। उसके बाद अह सो यस
दिस फज़ थ्री विल बी द टारगेट ऑफ़ थर्ड वीक। तो ये सारी चीजें हम थर्ड वीक में कवर कर रहे होंगे। उसके बाद हमारा आ जाता है फज़
फोर जहां पे हम डॉकर और कंटेनराइजेशन देख रहे होंगे कि डॉकर की हमें नीड क्या है हमारे सिस्टम में और कैसे हम चीजों को
कंटेनराइज करेंगे। सो वी विल बी कवरिंग दिस। उसके बाद हम देख रहे होंगे EC2 वर्सेस AWS लैम्ब्डा। एडब्ल्यूएस लैम्ब्डा
जो कि हमारा सर्वरस आर्किटेक्चर होने वाला है। तो इसे भी हम कोड करके देख रहे होंगे कि कैसे हम
AWS लैम्ब्डा का यूज़ कर सकते हैं। हमारे एप्लीकेशन में हमारे रियल वर्ल्ड प्रोजेक्ट में हम देख रहे होंगे कि कैसे
हम EC2 का यूज़ कर रहे होंगे। उसके बाद हम आ जाते हैं हमारे कुछ रियल वर्ल्ड ऐड ऑन्स में जहां हम देख रहे होंगे कि कैसे हम
ऑथेंटिकेशन एंड ऑथराइजेशन को मेंटेन करेंगे हमारे सिस्टम में। हम देखेंगे अ कुछ सिक्योरिटी फीचर्स जहां हम एंड टू एंड
इंक्रिप्शन के बारे में डिस्कस कर रहे होंगे यूजिंग प्राइवेट की एंड पब्लिक की कांसेप्ट। सो वी आर गोइंग टू कवर दिस।
उसके बाद हम क्रोन जॉब्स डिस्कस कर रहे होंगे। क्योंकि एक एक माय सीक्वल डेटाबेस पे जहां पे मिलियंस ऑफ यूजर हो जहां पे
मिलियंस ऑफ रिकॉर्ड स्टोर कर रहे होंगे। वी जस्ट कैन नॉट पुट टू मच लोड ऑन दैट माय सीक्वल डेटाबेस। तो हम देख रहे होंगे कि
कैसे हम क्रोन जॉब्स का यूज करके अ उस माय सीक्वल डेटाबेस में से कंप्लीटेड रिकॉर्ड्स को या अनयूज्ड रिकॉर्ड्स को फैच
करेंगे और उसके बाद हम उसे कैसेंडर डेटाबेस जो कि हमारा नो सीक्वल डेटाबेस है वहां हम उसे पुट कर देंगे। सो वी विल बी
कवरिंग दिस। उसके बाद हम देख रहे होंगे पोलिंग, लॉन्ग पोलिंग, वेब हुक्स। फिर हम देख रहे होंगे फाइल अपलोड्स। क्योंकि जब
हम Netflix जैसा सिस्टम बनाते हैं तो हम इमेजेस वीडियोस स्टोर कर रहे होते हैं। तो हम देखेंगे कि कैसे हम हमारी वीडियोस और
इमेजेस को S3 स्टोरेज व्हिच इज़ गोइंग टू बी आवर ब्लॉब स्टोरेज। तो का कैसे हम हमारे इमेजेस वीडियोस को व्हिच इज़ आवर
स्टैटिक डेटा। तो कैसे हम इन्हें स्टोर करते हैं। हम कैसे प्रीसाइन यूआरएल का यूज कर रहे होंगे। तो हम यह भी कवर करने वाले
हैं। उसके बाद यह सब कवर करने के बाद हम आ जाएंगे हमारे रियल वर्ल्ड प्रोजेक्ट्स में जहां हम फर्स्ट वीक में बना रहे होंगे बुक
माय शो जैसा क्लोन। इट विल बी बैक एंड ओरिएंटेड सिस्टम। क्योंकि हम हमारा मेनली फोकस बैक एंड पे होने वाला है। हम देख रहे
होंगे कि कैसे हम टू यूज़र्स की रिक्वेस्ट को सेम टाइम पे कंट्रोल कर रहे होंगे। हम देख रहे होंगे कैसे कैसे हम डेटाबेस लॉक
का इस्तेमाल करेंगे। हम पैसिमिस्टिक लॉक ऑप्टिमिस्टिक लॉक यूज कर रहे होंगे। Amazon सिस्टम डिज़ Amazon सिस्टम में भी
हम देख रहे होंगे कि कैसे हम कैसे एक यूजर ऑर्डर प्लेस करेगा। कैसे वो कैसे माइक्रो सर्विसेज आपस में कम्युनिकेट करेंगी। उसके
बाद हम देख रहे होंगे कि कैसे रिक्वेस्ट डिलीवरी को जाएगी। कैसे रिक्वेस्ट डिलीवरी एजेंट को जाएगी। कैसे रिक्वेस्ट उस
रेस्टोर में जाएगी। तो यह सब हम कवर कर रहे होंगे। हम आईआरसीटीसी कवर कर रहे होंगे। आईआरसीटीc में भी हम ककरेंसी देख
रहे होंगे। कैसे हम ककरेंट बुकिंग्स को मेंटेन करेंगे। सीट अलॉटमेंट हम डिस्कस करेंगे और आईआरसीटीc सिस्टम में यू वुड
हैव सीन कि वहां पे पार्शियल बुकिंग होती है। तो हम पार्शियल बुकिंग मैनेज कर रहे होंगे। स्पॉटिफाई सिस्टम
डिज़ाइन स्पॉटिफाई के सिस्टम में हम देख रहे होंगे कि कैसे हम हमारे ऑडियोज़ को S3 स्टोरेज में स्टोर कर रहे होंगे। कैसे हम
सीडीए का यूज़ कर रहे होंगे। तो आफ्टर कवरिंग ऑल द थ्योरी टॉपिक्स हम ये चारों सिस्टम बैठ के बनाने वाले हैं। सो स्टे
ट्यूंड विद मी। एंड वन वेरीेंट थिंग कि इन सिस्टम्स का कोड लिखने से पहले हमें आईडिया होना चाहिए कि इनका एक हाई लेवल
ओवरव्यू कैसा होता है। कैसे ये सिस्टम्स काम करते हैं। कैसे आपस में माइक्रो सर्विसेस कम्युनिकेट करती हैं। अ कैसे
डेटा का फ्लो होता है इन सिस्टम्स में। तो उसके लिए मैंने एक अलग से सिस्टम डिजाइन प्लेलिस्ट बनाई है। जहां मैंने इन सारे के
सारे सिस्टम्स का हाई लेवल डिजाइन डिस्कस किया है। सो वंस यू विल स्टार्ट दिस प्लेलिस्ट आई हाइली रिकमेंड यू टू वॉच दोज़
वीडियोस एज वेल पैरेलली। क्योंकि उसके बाद जब हम यह रियल वर्ल्ड प्रोजेक्ट्स का कोड लिख रहे होंगे तो एक आपको ओवरव्यू मिल मिल
चुका होगा कि कैसे यह सिस्टम्स काम करते हैं। तो आपको कोड करने में बहुत हेल्प होगी। तो
सो यस दिस इज़ ऑल फॉर दिस वीडियो एंड वी विल बी स्टार्टिंग विद आवर फर्स्ट वीक कांसेप्ट्स। सो स्टे ट्यूंड विद मी एंड शो
सम लव। थैंक्स। बाय बाय। [संगीत] हे एवरीवन वेलकम बैक वेलकम टू दिस
अल्टीमेट सिस्टम डिज़ प्लेलिस्ट सीरीज। तो यह वीडियो इस सीरीज का पहला वीडियो होने वाला है। जहां हम देखेंगे मोनोलिथ वर्सेस
माइक्रो सर्विसेस और हम देखेंगे कि हम कैसे एक मोनोलिथ एप्लीकेशन को एक माइक्रो सर्विस एप्लीकेशन में कन्वर्ट कर सकते
हैं। तो स्टार्ट करते हैं और समझते हैं इसे एक एग्जांपल की हेल्प से। तो लेट्स से कि आप एक स्टार्टअप काइंड ऑफ बिल्ड कर रहे
हैं। लेट्स से यूमी काइंड ऑफ एप्लीकेशन और उस एप्लीकेशन में आपके पास आपने सब कुछ सारे के सारे मॉड्यूल्स को एक सिंगल कोड
बेस में रखा हुआ है। लेट्स से एक आपका कोर्स मॉड्यूल होगा जहां पे आप डिफरेंट-डिफरेंट कोर्सेज क्रिएट कर रहे
होंगे। एक आपका ऑथ मॉड्यूल होगा जिसके थ्रू यूजर ऑथेंटिकेट करेगा। लॉग इन साइनअप फ्लो प्रोवाइड करेगा। एक हमारे पास
कार्ट मॉड्यूल होगा। एक हमारे पास पेमेंट मॉड्यूल होगा। एक हमारे पास ऑर्डर मॉड्यूल होगा जिसके
थ्रू हम अपनी बुकिंग को कंफर्म करेंगे। तो हमारे पास ऐसे डिफरेंट-डिफरेंट मॉड्यूल्स होंगे। अब मोनोलिथ आर्किटेक्चर में हम
क्या करते हैं? हम सारे के सारे मॉड्यूल्स को एक सिंगल कोड बेस में रखते हैं। सिंगल कोड बेस में रखते हैं। अब हमने बहुत जगह
सुना है कि ये सिंगल कोड बेस होता है। मोनोलिथ का मतलब पर एक्चुअल में ये सिंगल कोड बेस दिखता कैसा है? ये हम देखते हैं।
तो ये एक हमारा मोनोलिथ एप्लीकेशन है। जहां पे ये हमारे सारे के सारे कंट्रोलर्स अह कंट्रोल इज़ नथिंग बट अ हैंडलर। तो
हमारा ऑथ हैंडलर जहां हमने लॉग इन साइन अप डिफाइन किया है। हमारा अह कैटेगरी जो कोर्स की कैटेगरी डिफाइन करेगा वो एक
हमारा हैंडलर होगा। हमारे पास एक पेमेंट का हैंडलर होगा। एक प्रोफाइल का हैंडलर होगा। एक रेटिंग रिव्यू सेक्शन का हैंडलर
होगा। तो ऐसे हमारे पास डिफरेंट-डि डिफरेंट-डिफरेंट हैंडलर्स हैं। तो ये सारे के सारे जो मॉड्यूल्स हैं, यह हमने एक ही
कोड बेस में डिफाइन किए हैं। अब हमारे पास इस पूरे कोड बेस में एक केवल एक इंडेक्स डॉट जेS है जिसके थ्रू हम अपने एप्लीकेशन
को रन करेंगे। तो अभी यह एप्लीकेशन ऑलरेडी रनिंग है। तो यदि मैं इसे कंट्रोल सेव करता हूं तो आप वापस देखेंगे कि दिस ऐप इज
रनिंग एट 4000 पोर्ट और हमारा डेटाबेस कनेक्शन भी सक्सेसफुली एस्टैब्लिश हो गया है। तो सिंगल कोड बेस का मतलब है कि हमारा
सब कुछ सारे के सारे मॉड्यूल्स टाइटली कपल्ड होंगे और ये सारे के सारे मॉड्यूल्स एक साथ ही रन होंगे। हम सारे के सारे
मॉड्यूल्स को हम सारे के सारे मॉड्यूल्स को एक साथ बिल्ड करेंगे। हम सारे के सारे मॉड्यूल्स को एक साथ रन करेंगे।
टेस्ट करेंगे और डिप्लॉय करेंगे। तो इस कोड में हमारे पास केवल एक इंडेक्स
फाइल है जो कि हमारा एंट्री पॉइंट होगा और जब हम अपने एप्लीकेशन को रन करेंगे तो सबसे पहले इंडेक्स फाइल ट्रिगर होगी। दैट
मींस कि अब इस पूरे के पूरे कोड में पूरे के पूरे कोड बेस में यदि कहीं पर भी हमारा इशू आता है तो पूरा का पूरा एप्लीकेशन
क्रैश हो जाएगा। दैट मींस कि ये पूरा का पूरा सिस्टम सारे के सारे मॉड्यूल्स आपस में टाइटली कपल्ड हैं। हम सारे के सारे
मॉड्यूल्स को एक साथ बिल्ड कर रहे हैं। सारे के सारे मॉड्यूल्स एक साथ रन होंगे थ्रू दिस इंडेक्स डॉट जेएस फाइल। सारे के
सारे मॉड्यूल्स हम एक साथ डिप्लॉय भी कर रहे होंगे। तो पूरा का पूरा एप्लीकेशन और सारे मॉड्यूल्स आपस में टाइटली कपल्ड हैं।
दिस इज़ कॉल्ड आवर मोनोलिथिक आर्किटेक्चर। अब इस मोनोलिथ आर्किटेक्चर में प्रॉब्लम क्या है? तो हम पहले प्रॉब्लम्स को समझते
हैं। तो जो सबसे पहली प्रॉब्लम है कि सिंगल पॉइंट ऑफ फेलियर।
सिंगल पॉइंट ऑफ फेलियर। अब इसका मतलब क्या है? सिंगल पॉइंट ऑफ फेलियर। तो इस सिंगल पॉइंट
ऑफ फेलियर का मतलब है कि पूरे के पूरे एप्लीकेशन में इस पूरे के पूरे एप्लीकेशन में हमने कोई भी गड़बड़ की हमने चाहे वो
लॉग इन साइन अप फंक्शनैलिटी में गड़बड़ की या हमने कोर्स क्रिएट करने में मिस्टेक कर दिया पेमेंट सेक्शन में हमसे गलती हो गई
तो इस पूरे के पूरे कोड बेस में यदि हमसे कहीं पर भी कुछ भी गलती होती है तो पूरा का पूरा सिस्टम क्रैश हो जाएगा। दैट मींस
यहां पर हमारा सिंगल पॉइंट ऑफ फेलियर है। अब इसे एक एग्जांपल के थ्रू समझते हैं। लेट्स से कि हमारे पास डिफरेंट-डिफरेंट
मॉड्यूल्स हैं। ऑथ मॉड्यूल है, हमारे पास कार्ट मॉड्यूल है, हमारे पास हमारे पास ऑर्डर मॉड्यूल है। ऐसे हमारे पास
डिफरेंट-डिफरेंट मॉड्यूल्स हैं एप्लीकेशन में। नाउ लेट्स से कि इनिशियली जब हमारे सिस्टम
में 100 यूज़र्स थे हमारा सिस्टम इट वाज़ वर्किंग फाइन। उसके बाद हमारे सिस्टम में 10,000 यूज़र्स आए तब भी हमारा सिस्टम सही
से काम कर रहा था। हमारे सिस्टम में 1 लाख यूज़र्स आए तब भी हमारा सिस्टम सही से काम कर रहा था। लेकिन जैसे ही हमारे सिस्टम
में 1 मिलियन यूज़र्स आए, हमारा पेमेंट मॉड्यूल क्रैश हो गया। तो हमारा पेमेंट मॉड्यूल क्रैश हो गया। अब मोनोलिथ में यदि
हमारा पेमेंट मॉड्यूल क्रैश हो गया तो उसकी वजह से ना अब हमारा ऑथेंटिकेशन यह ऑथ मॉड्यूल काम करेगा। मतलब यूजर साइन
अप लॉग इन कुछ नहीं कर पाएगा। ना हमारा कार्ट काम करेगा। ना हमारा यह ऑर्डर मॉड्यूल काम करेगा। कहने का मतलब है कि
पेमेंट मॉड्यूल अकेले के फेल होने की वजह से हमारा सारा का सारा सिस्टम क्रैश हो गया और अब हमारी कोई भी फंक्शनैलिटी काम
नहीं कर रही है। तो दिस इज कॉल्ड मोनोलिथ सिस्टम जहां पे सारे के सारे सारे के सारे मॉड्यूल्स टाइटली कपल्ड होते हैं और
सिस्टम में कहीं भी एरर आने की वजह से या सिस्टम का कोई भी पार्ट क्रैश हो जाने की वजह से हमारा पूरा का पूरा सिस्टम क्रैश
हो जाता है। तो वही हमने एक प्रॉब्लम देखी हमारे मोनोलिथ सिस्टम की कि इट इज़ अ सिंगल पॉइंट ऑफ़ फ़ेलियर।
अब जो एक और प्रॉब्लम आती है मोनोलिथ सिस्टम में वो है डिप्लॉयमेंट की। कि यहां पे डिप्लॉयमेंट बॉटल नेक्स होते हैं।
डिप्लॉयमेंट बेसिकली डिप्लॉयमेंट इज अ बॉटल नेक हियर। डिप्लॉयमेंट
बॉटल नेक। अब इसका क्या मतलब होता है? तो लेट्स से कि फिर से हम वही पेमेंट मॉड्यूल का एग्जांपल लेते हैं। हमारे पास एक
पेमेंट मॉड्यूल है और अभी ये पेमेंट मॉड्यूल डिफरेंट-डिफरेंट फंक्शनैलिटीज यूज़ कर रहा है। अब हम हमें उसमें एक और फीचर
ऐड करना है। वो है क्रेडिट कार्ड का फीचर। क्रेडिट कार्ड का फीचर। दैट मींस हमको यह पेमेंट मॉड्यूल में कुछ
चेंजेस करने पड़ेंगे। ठीक है? पेमेंट मॉड्यूल में हमें चेंज करना है। दैट मींस अ यह सिर्फ एक छोटा सा पार्ट हमें चेंज
करना है। पर मोनोलिथ सिस्टम्स में क्या होता है कि लेट्स से हमने पूरा का पूरा सिस्टम यह पूरा का पूरा हमारा ऐप ऑलरेडी
डिप्लॉयड है। अब हमें इसमें एक छोटी सी फीचर छोटा सा फंक्शनैलिटी और ऐड करना है क्रेडिट कार्ड का कि यूजर अब क्रेडिट
कार्ड के थ्रू भी अपने पेमेंट्स कर पाएंगे। तो हमें एक छोटी सी फंक्शनैलिटी और ऐड करनी है। तो जो कि हम पेमेंट
मॉड्यूल में ऐड करेंगे। तो अब इस छोटी सी फंक्शनैलिटी को ऐड करने के लिए भी हमें पूरे के पूरे सिस्टम को दोबारा से डिप्लॉय
करना पड़ता है। तो ये एक बड़ी प्रॉब्लम होती है मोनोलिथ सिस्टम्स के साथ। क्योंकि हमारे पास डिफरेंट-डिफरेंट मॉड्यूल्स हैं।
हमारे पास पेमेंट का मॉड्यूल है। हमारे पास कार्ट एक मॉड्यूल है और हमारे पास ऑथेंटिकेशन का एक मॉड्यूल है। हमारे पास
ऑर्डर एक मॉड्यूल है। अब हमारे पास ऐसे डिफरेंट-डिफरेंट मॉड्यूल्स हैं। चेंज हमें सिर्फ इसमें करना है। वो भी छोटा सा और
उसकी वजह से हमें सारे के सारे सिस्टम को पूरे के पूरे इस सिस्टम को दोबारा से डिप्लॉय करना पड़ता है। तो यह एक बड़ी
प्रॉब्लम होती है मोनोलिथ सिस्टम्स के साथ। तो यस डिप्लॉयमेंट इज अ बॉटल नेक हियर। तो यह दूसरी प्रॉब्लम है जो हम फेस
करते हैं मोनोलिथ सिस्टम्स में। जो एक और प्रॉब्लम हम फेस करते हैं वो होती है इंडिविजुअल स्केलिंग।
इंडिविजुअल स्केलिंग। अब इसका क्या मतलब होता है? तो इसे भी हम
एक एग्जांपल के थ्रू समझते हैं। लेट्स से कि हमारे पास डिफरेंट-डिफरेंट मॉड्यूल्स हैं और जो हमारा पेमेंट मॉड्यूल
है वो उस पे बहुत ज्यादा ट्रैफिक आ रहा है।
लेट्स से उस पे डेली के 20 मिलियन प्लस यूज़र्स आ रहे हैं। और बाकी के बाकी के डिफरेंट-डिफरेंट मॉड्यूल्स हैं उस पे बाकी
के जो डिफरेंट-डिफरेंट मॉड्यूल्स हैं उनको बहुत ज्यादा यूज़ नहीं किया जा रहा है। लेकिन पेमेंट मॉड्यूल वो बहुत ज्यादा
यूज़र्स के द्वारा एक्सेस किया जा रहा है। तो इस केस में हम ये समझ जाएंगे कि यदि हमने इसको इस मॉड्यूल को स्केल नहीं किया
तो हमारा सिस्टम क्रैश हो सकता है। पर मोनोलिथ सिस्टम्स के साथ प्रॉब्लम क्या है कि हम एक इंडिविजुअल कॉम्पोनेंट को
इंडिविजुअल मो मॉड्यूल को अकेला स्केल नहीं कर सकते। हमें पूरे के पूरे सिस्टम को स्केल करना पड़ेगा। तो लेट्स से कि
यहां पर 20 मिलियन का ट्रैफिक आ रहा है और ऑथ और बाकी के बाकी के मॉड्यूल्स में मिला के 2 मिलियन का भी ट्रैफिक नहीं आ रहा है।
2 मिलियन से भी कम का ट्रैफिक आ रहा है। मतलब यहां पे हमें स्केल करने की नीड नहीं है। स्केल की नीड यहां पे नहीं है। पर
हमारा क्योंकि पूरा का पूरा सिस्टम सारे के सारे मॉड्यूल्स टाइटली कपल्ड हैं। तो यदि हम पेमेंट मॉड्यूल को स्केल करना चाह
रहे हैं तो हमें पूरा का पूरा सिस्टम ही स्केल करना पड़ेगा। यह एक बड़ी प्रॉब्लम होती है मोनोलिथ में। अब यहां ऑथेंटिकेशन
वाले मॉड्यूल में हमें स्केल करने की नीड नहीं थी। लेकिन तब भी हमें स्केल करना पड़ा। तो ये हमारे साथ पूरे सिस्टम के
कॉस्ट को बढ़ा देता है। इसकी वजह से कॉस्ट इनक्रीस हो जाती है। क्योंकि यहां पे स्केल करने की जरूरत नहीं थी। लेकिन फिर
भी हमें एक नई मशीन अपने सिस्टम में लगानी पड़ी। कहने का मतलब है कि नीड सिर्फ पेमेंट मॉड्यूल को स्केल करने की थी।
लेकिन हमें सारे के सारे मॉड्यूल्स को स्केल करना पड़ा। पूरे के पूरे सिस्टम को स्केल करना पड़ा। तो हमारा एक छोटी सी
छोटी मशीन में छोटे कंप्यूटर में एक और दूसरे सिस्टम में काम हो सकता था। जहां हम सिर्फ पेमेंट मॉड्यूल को स्केल कर देते।
लेकिन अब हमें सारे के सारे सारे के सारे सिस्टम को ही स्केल करना है। तो हमें एक बड़ी बड़ा सर्वर या बड़ी मशीन की नीड
होगी। तो इसीलिए हमारी कॉस्ट इनक्रीस हो जाती है। तो इंडिविजुअल कंपोनेंट्स को इंडिविजुअल मॉड्यूल्स को मोनोलेथ
आर्किटेक्चर में स्केल करना बहुत ही मुश्किल होता है। क्यों वो हमने देख ही लिया। अब ये सारी प्रॉब्लम्स ये तीनों
प्रॉब्लम्स को सॉल्व कौन करता है? तो ये हमारी तीनों प्रॉब्लम्स को चाहे वो सिंगल पॉइंट ऑफ फेलियर हो, चाहे वो डिप्लॉयमेंट
बॉटल नेक हो, चाहे वो इंडिविजुअल स्केलिंग हो। ये सारी की सारी प्रॉब्लम्स को सॉल्व करता है हमारा माइक्रो सर्विस
आर्किटेक्चर। अब माइक्रो सर्विस आर्किटेक्चर में क्या होता है कि हम हमने देखा हमारे पास डिफरेंट-डिफरेंट मॉड्यूल्स
हैं। हमारे पास एक ऑथ का मॉड्यूल है। हमारे पास हमारे पास एक कार्ड का मॉड्यूल है। हमारे पास हमारे पास ऑर्डर का एक
मॉड्यूल है। हमारे पास पेमेंट का मॉड्यूल है। तो हम क्या करते हैं? माइक्रो सर्विस आर्किटेक्चर में हम इन मॉड्यूल्स की
मॉड्यूल्स को सर्विसेज बना देते हैं। और ये सर्विसेस आपस में लूजली कपल्ड होती है। दैट मींस इनकी आपस में डिप आपस में एक
दूसरे पर डिपेंडेंसी नहीं होती है। और ये सर्विज आपस में ना तो टाइटली कपल्ड होती हैं और इन सर्विसेस को हम इंडिविजुअली
बिल्ड करते हैं। तो हम बिल्ड इन्हें इंडिविजुअली करते हैं। हम इन्हें रन भी इंडिविजुअली करेंगे। इनकी
टेस्टिंग भी इंडिविजुअली होगी और हमें हम इन्हें डिप्लॉय भी इंडिविजुअली कर सकते हैं।
तो ये होता है हमारे माइक्रो सर्विस आर्किटेक्चर में। इसे थोड़ा डिटेल से समझते हैं कि सबसे पहले हमने क्या किया कि
हमारे जो जो भी मॉड्यूल्स हमें समझ आ रहे थे उन सारे मॉड्यूल्स को हमने सर्विसेस बना दिया। लेट्स से ऑथेंटिकेशन जो हमारा
लॉग इन साइन अप फंक्शनैलिटी प्रोवाइड करेगा उसे हमने एक डिफरेंट सर्विस बना दिया। हमने कार्ड को एक डिफरेंट सर्विस
बना दिया। ऑर्डर को एक डिफरेंट सर्विस बना दिया। पेमेंट को एक डिफरेंट सर्विस बना दिया। तो अब हमारे पास ऐसे हमने एक हर एक
टास्क को स्मालसाल सर्विज में बना दिया। इसीलिए इसे बोलते हैं माइक्रो सर्विसेस। तो अब हमारे पास एक लेट्स से S1 सर्विस हो
गई, एक S2 सर्विस हो गई। एक हमारे पास S3 सर्विस हो गई। अब क्या होता है कि यह सर्विज जो होती हैं वो आपस में लूजली
कपल्ड होती हैं। मतलब वी कैन बिल्ड देम इंडिविजुअली, वी कैन रन देम इंडिविजुअली, टेस्ट देम इंडिविजुअली, डिप्लॉय देम
इंडिविजुअली। तो यह आपस में लूजली कपल्ड होती हैं। आपस में एक दूसरे पे डिपेंडेंट नहीं होती हैं। तो इस वजह से माइक्रो
सर्विसेस हमारी ये तीनों प्रॉब्लम्स को जो मोनोलिथ में आ रही थी उन तीनों प्रॉब्लम्स को सॉल्व कर देता है।
अब एक बार इसका कोड देखना जरूरी है कि कैसे हमारी सर्विज आपस में इंडिपेंडेंट होती
हैं। तो यह हमारा एक माइक्रो सर्विज डिफरेंट-डिफरेंट माइक्रो सर्विसेस वाला कोड हमारे पास जहां एक इनबाउंड सर्विस है
हमारे पास एक प्रोडक्ट सर्विस है। अ बेसिकली इट इज़ अ इट इज़ अ कोड फॉर Amazon काइंड ऑफ़ एप्लीकेशन। तो यहां पर हमारा एक
अलग से यूजर सर्विस है और अब आप देखोगे कि हर एक सर्विस में एक अलग से सेपरेट इंडेक्स डॉट जेएस फाइल है। हमने हमने
डिस्कस किया है कि इंडेक्स डॉट जेएस फाइल वुड बी अ वुड बी ओनली सिंगल एंट्री पॉइंट फॉर दिस एप्लीकेशन बेसिकली इस बैक एंड को
रन करने के लिए। तो इस इनबाउंड सर्विस का एक अलग से इंडेक्स है। इस यूजर सर्विस का एक अलग से इंडेक्स है। और हां एक चीज और
कि जो मोनोलिथ सिस्टम हम बना रहे थे उसमें लेट्स से ये हमारा पूरा का पूरा एप्लीकेशन
है। ये पूरा का पूरा हमारा एक ऐप है। और मोनोलिथ सिस्टम में सारे के सारे मॉड्यूल्स के लिए एक शेयर्ड
डेटाबेस हो सकता है। तो यह हमारा एक डेटाबेस है। अब इसमें हमारे पास एक पेमेंट की अलग से टेबल होगी। हमारे पास यूजर की
एक अलग से टेबल होगी। ऑर्डर की अलग से टेबल होगी। कोर्सेज की अलग से टेबल होगी। तो हम एक शेयरर्ड डेटाबेस यूज़ कर सकते
हैं। कहां पे? मोनोलिथ सिस्टम में। तो डिफरेंट-डिफरेंट मॉड्यूल्स होंगे और डेटाबेस हमारा एक ही होगा। और हमारे पास
उस डेटाबेस में डिफरेंट-डिफरेंट टेबल्स होंगी। लेट्स से पेमेंट के लिए अलग टेबल, यूज़र्स के लिए अलग टेबल, ऑर्डर्स के लिए
अलग टेबल। लेकिन माइक्रो सर्विसेस में हर सर्विस का एक अपना खुद का डेटाबेस हो सकता है। इट्स ओन डेडिकेटेड डेटाबेस। लेट्स से
सर्विस वन का अलग से डेटाबेस है। सर्विस टू का अलग से डेटाबेस है। सर्विस थ्री का अलग-अलग डेटाबेस है। और सर्विस की
फंक्शनैलिटी के हिसाब से हम डेटाबेस को सेलेक्ट कर सकते हैं। लेट्स से कि यह जो सर्विस टू है, यह यूजर रिलेटेड डेटा को
मैनेज कर रही है। तो, हम यहां पे आरडीबीएमएस डेटाबेस यूज़ कर सकते हैं। ये जो S1 सर्विस है, यह हमारी कार्ट की
फंक्शनैलिटी को मैनेज कर रही है। यहां पे हम नो सीक्वल डेटाबेस यूज़ कर सकते हैं। क्योंकि हर लेट्स से हम कोर्स कोर्स बाय
करने वाला यूमी वाला एग्जांपल लेते हैं। तो हर एक कोर्स की अपने एक अलग-अलग फीचर्स होंगे। अलग-अलग फंक्शनैलिटीज होंगी। उसमें
अलग-अलग की कॉमोनेंट्स होंगे। तो यहां पे हम की वैल्यू काइंड ऑफ़ डेटाबेस चाहेंगे कि हमारे कार्ट में क्योंकि हम कोर्सेज
डालेंगे। तो हर कोर्स के डिफरेंट फीचर्स हो सकते हैं। तो हम यहां पे की वैल्यू काइंड ऑफ़ डेटाबेस चाहेंगे। तो इसलिए हम
यहां पे नो सीक्वल डेटाबेस ले सकते हैं। तो ऐसे ही हम माइक्रो सर्विस आर्किटेक्चर में हर सर्विस का एक अपना ओन डेडिकेटेड
डेटाबेस हो सकता है। ये सब मैंने हमारे सिस्टम डिज़ाइन प्लेलिस्ट में ऑलरेडी डिस्कस किया है। जहां हमने Netflix सिस्टम
डिज़ाइन, स्विगी सिस्टम डिज़ाइन और ऐसे बहुत सारे अलग-अलग जॉइंट सिस्टम्स का डिज़ आर्किटेक्चर डिस्कस किया है। तो वहां हमने
ये सारी चीजें डिस्कस की हैं। तो इफ यू वांट टू लर्न मोर अबाउट दी सिस्टम्स प्लीज गो एंड वॉच दोज़ वीडियोस। तो
हमने देख लिया कि इन सर्विज का अपना खुद का डेटाबेस हो सकता है। तो इसीलिए इस कोड में आप देखेंगे कि इस यूजर सर्विस के लिए
हमने यहां पे पोस्ट ग्रेस इक्वल डेटाबेस यूज़ किया है और हमने यहां पे प्रिज़्मा का यूज़ किया है। वि इज़ आवर ओआरएम मॉडल। तो यह
एक हमारे पास एक अलग से यूजर सर्विस है और इस यूजर सर्विस में हमारे पास इंडेक्स जेएस फाइल है। इसका मतलब है कि हम इस यूजर
सर्विस को अलग से इंडिविजुअली रन कर सकते हैं और जो कि रन हो भी रही है। आप देख सकते हैं कि यूजर सर्विसेस इज़ रनिंग एट
पोर्ट नंबर 4002। तो हम इन सर्विज को अलग-अलग बिल्ड कर सकते हैं। अलग-अलग हम इन्हें रन कर सकते हैं।
जैसा कि आप देख रहे हैं ये इंडेक्स इस यूजर सर्विस को रन कर रहा है। ऐसे ही हर सर्विस का एक अपना इंडेक्स जेस है जो
उस सर्विस को रन करेगा। और ऐसे ही हम इन सर्विसेज को टेस्ट कर सकते हैं और इंडिपेंडेंटली
डिप्लॉय कर सकते हैं। तो आपने कोड बेस दोनों का देख लिया। आपने माइक्रो सर्विज का भी कोड देख कोड बेस देख लिया। अब आपको
आईडिया लग गया होगा कि कैसे इनके दोनों का कोड बेस डिफर करता है। आपने मोनोलिथ का भी कोड बेस देख लिया। तो अब देखते हैं हम कि
कैसे यह माइक्रो सर्विस आर्किटेक्चर हमारी मोनोलिथ्स की प्रॉब्लम को सॉल्व करता है। तो सबसे पहला जो प्रॉब्लम था हमारा वो था
सिंगल पॉइंट ऑफ फेलियर। मतलब कि पूरे कोड में यदि कहीं भी प्रॉब्लम आ जा रहा है। लेट्स से कि हमारा पेमेंट मॉड्यूल क्रैश
हो गया। पेमेंट मॉड्यूल क्रैश हो गया। तो मोनोलिथ में क्या हो रहा था कि इस मॉड्यूल के क्रैश होने की वजह से ना अब ऑथेंटिकेशन
काम कर रहा था। ना अब कोर्स वाला फीचर काम कर रहा था, ना कार्ट वाला फीचर काम कर रहा था। कुछ नहीं कर रहा था काम।
तो ना कार्ट काम कर रहा है ना लॉग इन साइन अप काम कर रहा है ना कोर्स काम कर रहा है लेकिन यदि हमारे माइक्रो सर्विस
आर्किटेक्चर में बेसिकली क्या होगा कि हम एक पेमेंट को एक अलग से माइक माइक्रो सर्विस बना देंगे और यह जो पेमेंट माइक्रो
सर्विस होगी यह सारी की सारी पेमेंट्स को ये क्रेडिट कार्ड पेमेंट्स को PayPal पेमेंट्स को सारी के सारे डिफरेंट-डिफरेंट
पेमेंट्स को मैनेज करेगी। लेट्स से कि ये पेमेंट मॉड्यूल जो है पेमेंट माइक्रो सर्विस बेसिकली ये अब हमारा क्रैश हो गया।
तो अब इस केस में हमारी यूजर सर्विस पे कुछ इंपैक्ट नहीं आएगा। यूजर सर्विस पे कुछ इंपैक्ट नहीं पड़ेगा।
क्यों? क्योंकि दोनों ही सर्विज जो हैं, वह आपस में लूजली कपल्ड है, इंडिपेंडेंट हैं। और एक का फेल होने से दूसरे पे कोई
इफ़ेक्ट नहीं पड़ेगा। क्योंकि अब हमने जो टाइटली कपल्ड वाली डिपेंडेंसी थी उसको हटा दिया। तो एक मॉड्यूल या एक हमारा माइक्रो
सर्विस यदि फेल होती है तो दूसरे माइक्रो सर्विस पे उसका कोई असर नहीं दिखेगा। तो यह होता है हमारा पहला प्रॉब्लम सॉल्व
माइक माइक्रो सर्विसेस की मदद से जो कि था सिंगल पॉइंट ऑफ फेलियर। अब हम आ जाते हैं दूसरे दूसरे प्रॉब्लम दूसरे प्रॉब्लम पे
जो कि था डिप्लॉयमेंट बॉटल नेक। तो डिप्लॉयमेंट में क्या हो रहा था कि यदि हम कहीं भी कुछ भी एक छोटा सा फीचर नया भी
लाते हैं मोनोलिथ्स में तो हमें पूरे के पूरे सिस्टम को दोबारा से डिप्लॉय करना पड़ रहा था। लेकिन माइक्रो सर्विसेस के
केस में ऐसा नहीं होता है। लेट्स से कि अब आप सेम पेमेंट का एग्जांपल लेते हैं जो हमने वहां भी लिया था कि अब हमें क्रेडिट
कार्ड पेमेंट्स को ऐड करना है। क्रेडिट कार्ड तो हमें ये नई एक नया फीचर छोटा सा फीचर
ऐड करना है। तो अब यदि हमें इसको इसमें कुछ चेंजेस करना है तो हम सिर्फ पेमेंट मॉड्यूल को दोबारा से डिप्लॉय करेंगे। हम
यह चेंज करेंगे और फिर हम पेमेंट मॉड्यूल को दोबारा से डिप्लॉय करेंगे। तो यह हमारा दूसरा प्रॉब्लम भी सॉल्व होता है थ्रू
माइक्रो सर्विस आर्किटेक्चर। अब जो तीसरा प्रॉब्लम हमारा आता है अ वो आता है हमारा कि इंडिविजुअल स्केलिंग पॉसिबल नहीं
थी मोनोलिथ सिस्टम्स में कि हमें सिर्फ पेमेंट मॉड्यूल को यदि स्केल करना था तो वो हम नहीं कर पा रहे थे क्योंकि सब कुछ
टाइटली कपल्ड था। एक दूसरे से डिपेंडेंट था। लेकिन अब हमने वह डिपेंडेंसी हटा दी है। सब कुछ लूजली कपल्ड है। सर्विज आपस
में एक दूसरे पर डिपेंडेंट नहीं है। तो हम कंपोनेंट्स को इंडिविजुअली स्केल कर सकते हैं। लेट्स से कि हमारे पेमेंट माइक्रो
सर्विस पे बहुत ज्यादा ट्रैफिक आ रहा है। लेट्स से 20 मिलियन। तो हम क्या करेंगे कि हम हमारी जो पेमेंट सर्विस है पेमेंट
सर्विस है उसको हम इंडिविजुअली स्केल कर देंगे। हम ज्यादा मशीनें लगा देंगे यहां पर पेमेंट सर्विस के लिए तो हम इसे
इंडिविजुअली स्केल कर देंगे। तो अब हमें पूरे के पूरे सिस्टम को स्केल नहीं करना पड़ा। हमने सिर्फ एक जो जिस पे
हमारा ज्यादा ट्रैफिक आ रहा था सिर्फ हमने उस सर्विस को स्केल कर दिया। तो आप देख सकते हैं कि माइक्रो सर्विस ने हमारी
तीनों की तीनों प्रॉब्लम्स को अ जो कि बड़ी प्रॉब्लम्स थी उन तीनों प्रॉब्लम्स को सॉल्व कर दिया। तो ये होता है हमारा
मोनोलिथ सिस्टम वर्सेस माइक्रो सर्विस सिस्टम्स। अब हम आ जाते हैं अपने दूसरे पार्ट में कि हम कैसे एक मोनोलिथ सिस्टम
को एक माइक्रो सर्विस सिस्टम में कन्वर्ट कर सकते हैं। लेकिन उससे पहले हम देखते हैं कुछ मिसकंसेप्शंस जो लोगों को हैं
रिगार्डिंग मोनोलिथ एंड माइक्रो सर्विसेस। तो मोनोलिथ को लोग ऐसा समझते हैं कि एवरीथिंग रंस ऑन अ वन सिंगल मशीन। कि सब
कुछ जो है वो एक केवल सिंगल मशीन पर रन कर रहा है। मतलब केवल एक मशीन पर रन कर रहा है। पर हमने देखा जब हमने स्केल वाला
पॉइंट डिस्कस किया कि यदि हमें केवल एक मॉड्यूल को लेट्स से पेमेंट मॉड्यूल को स्केल करना है तो मोनोलिथ्स में हम क्या
करते हैं कि हम पूरे के पूरे सिस्टम को ही स्केल कर देते हैं। दैट मींस कि हमने एक और ऐप सर्वर लिया होगा। हमारे पास एक और
ऐप सर्वर आया होगा। लेट्स से यह ऐप सर्वर वन है। यह ऐप सर्वर टू है। तो जो मिसकसेप्शन है रिगार्डिंग मोनोलिथ कि
एवरीथिंग रंस ऑन अ वन सिंगल मशीन। तो ऐसा बिल्कुल भी नहीं है। हम ऑलरेडी डिस्कस कर चुके हैं कि यदि हमें मोनोलिथ्स को स्केल
करना होता है तो हम कर लेते हैं। इंडिविजुअल कंपोनेंट्स को हम स्केल नहीं कर पाते हैं। मतलब इट्स वेरी हार्ड। पर हम
हां पूरे के पूरे सिस्टम को वी कैन स्केल। क्योंकि आप खुद सोचिए कि यदि कोई सिस्टम है वो मोनोलिथ आर्किटेक्चर को फॉलो कर रहा
है और वहां पे 20-30 मिलियन यूज़र्स हैं और लेट्स से वन ऐप सर्वर इज़ नॉट एबल टू हैंडल दिस अमाउंट ऑफ ट्रैफिक। तो ऑब्वियसली हमें
स्केल करना ही पड़ेगा। तो यह जो मिसकंसेप्शन है यह कि मोनोलिथ के में सब कुछ केवल एक सिंगल मशीन पर काम करता है।
तो ऐसा बिल्कुल भी नहीं है। वी कैन स्केल मोनोलिथ सिस्टम्स इंडिविजुअली। इंडिविजुअल मॉड्यूल्स हम स्केल नहीं कर
सकते। लेकिन हां, हम पूरे के पूरे सिस्टम को स्केल कर सकते हैं। तो ये होता है हमारा मिसकंसेप्शन रिगार्डिंग मोनोलिथ्स।
अब माइक्रो सर्विसेस के केस में ज्यादातर लोगों को यह लगता है कि एवरीथिंग रंस ऑन मतलब जो सर्विसेस होती हैं वो
एव्री सर्विस रंस ऑन टाइनी टाइनी मशीनंस। कि जैसे यह यूजर सर्विस है कि यह यूजर सर्विस है तो यह यूजर सर्विस एक अलग से
स्मॉल मशीन पर चल रही होगी। लेट्स से M1 मशीन यह हमारी कार्ट वाली सर्विस है। यह अलग से चल रही होगी M2 मशीन पे। तो ऐसा
नहीं होता है। अ यह हम कब करते हैं? जब हमें स्केल करना होता है। लेट्स से कि हमें कार्ट वाली
सर्विस को स्केल करना होता है। तो हम है कि कार्ट के लिए हमने एक अलग से मशीन लगा ली। पर लेट्स से हमारे सिस्टम में यूज़र्स
कम है और एक हमारा अलग से सिंगल सिस्टम सारे के सारे माइक्रो सर्विसेस को हैंडल कर पा रहा है। तो हमें एक सिंगल मशीन में
ही हमारा काम हो जाता है। लेट्स से एक हमारी एक सिंगल मशीन है। और इस सिंगल मशीन में हमारी कार्ड सर्विस भी चल रही है।
हमारी यूजर सर्विस भी चल रही है और हमारी अलग-अलग पेमेंट सर्विस और अदर सर्विज वो सारी रन कर रही हैं। हमें नीड कब पड़ेगी?
अलग-अलग मशीनंस की या अलग-अलग सिस्टम्स की। जब हमारे पास ट्रैफिक बढ़ेगा और जब हमें लगेगा
कि इट माइट क्रैश तो हम अलग से अपनी इंडिविजुअल सर्विज को स्केल कर सकते हैं। तो ये मिसकंसेप्शंस होते हैं लोगों को
रिगार्डिंग माइक्रो सर्विस एंड मोनोलिथ्स। तो वो भी हमने कवर कर लिए। अब हम देखते हैं कि कैसे हम एक मोनोलिथ सिस्टम को एक
माइक्रो सर्विस सिस्टम में कन्वर्ट कर सकते हैं। फ्रॉम मोनोलिथ टू मोनोलिथ टू माइक्रो सर्विसेस।
माइक्रो सर्विसेस। तो सबसे पहले यह जानना जरूरी है कि इट्स नॉट अ वन डे एक्टिविटी।
इट्स नॉट अ वन डे एक्टिविटी कि आप एक ही दिन में सारा का सारा माइग्रेशन कर दोगे। ऐसा बिल्कुल भी
नहीं होता है। तो इट्स नॉट अ वन डे एक्टिविटी। और जो दूसरा पॉइंट यह है कि हम सारे के
सारे सिस्टम को मतलब पूरे के पूरे सिस्टम को एक बार में माइग्रेट नहीं करते। लेट्स से अगेन सेम एग्जांपल जो हम इतने टाइम से
डिस्कस कर रहे हैं कि हमारे पास एक मोनोलिथ सिस्टम है जहां पे एक ऑथेंटिकेशन वाला मॉड्यूल है। एक पेमेंट वाला मॉड्यूल
है। एक कार्ट वाला मॉड्यूल है। अ एक है हमारे पास कोर्स वाला मॉड्यूल। तो ऐसा नहीं होगा कि हम एक साथ सारे के सारे ये
मॉड्यूल्स को एक साथ माइग्रेट कर देंगे। एक साथ हम इनको माइक्रो सर्विस बना देंगे और सारा का सारा ट्रैफिक हम वहां मूव कर
देंगे। तो ऐसा बिल्कुल भी नहीं होता। हम स्मालस्मॉल सर्विसेस से या स्माल मॉड्यूल्स से स्टार्ट करते हैं। लेट्स से
हमें पेमेंट्स में प्रॉब्लम जा रही है। तो हम क्या करेंगे कि हम पहले पेमेंट मॉड्यूल उठाएंगे और हम इस पेमेंट मॉड्यूल को
माइग्रेट करने का ट्राई करेंगे माइक्रो सर्विसेस में। तो ऐसे हम माइग्रेशन करते हैं। तो ऐसा बिल्कुल भी नहीं होता कि हम
एक ही बार में पूरे के पूरे सिस्टम को माइग्रेट कर देते हैं टू माइक्रो सर्विस। जो तीसरा पॉइंट है जो हमें ध्यान में रखना
है वो है कि हम लेट्स से हमने पेमेंट पेमेंट मॉड्यूल जो था हमारा उसको हमने एक माइक्रो सर्विस बना दिया। तो पेमेंट
मॉड्यूल का बेसिकली काम क्या है? पेमेंट को प्रोसेस करना यूज़र्स की पेमेंट को कलेक्ट करना। तो ऑब्वियसली इस पेमेंट
सर्विस पे ट्रैफिक जा रहा होगा। तो हमने लेट्स से कि हमारा यह मोनोलथ सिस्टम है। यहां पे भी हमारा पेमेंट की फंक्शनैलिटी
है। बेसिकली पेमेंट मॉड्यूल है और यह हमने पेमेंट माइक्रो सर्विस भी बना दी। तो हम ऐसा बिल्कुल भी नहीं करेंगे कि हम पूरे के
पूरे ट्रैफिक को जैसे ही हमारा यह पेमेंट सर्विस बनके तैयार हुई तो हम पूरे के पूरे ट्रैफिक को इस माइक्रो सर्विस पे ट्रांसफर
कर देंगे। हम ऐसा बिल्कुल भी नहीं करेंगे। तो ये तीनों पॉइंट्स आपको ध्यान में रखने हैं। पहला कि इट्स नॉट अ वन डे एक्टिविटी।
दूसरा कि हम एक ही बार में पूरे के पूरे सिस्टम को माइग्रेट नहीं करेंगे। वी आर नॉट गोइंग टू माइग्रेट द एंटायर सिस्टम इन
अ सिंगल गो। और तीसरा पॉइंट कि वी आर नॉट गोइंग टू अह वी आर नॉट गोइंग टू ट्रांसफर 100% ट्रैफिक अह टू माइक्रो सर्विस इन अ
सिंगल गो। भले ही वह बनके तैयार हो गई। जैसे इस केस में भी हमारा पेमेंट माइक्रो सर्विस बनके तो रेडी हो गई है लेकिन हम
पूरे के पूरे ट्रैफिक को यहां पे एक बार में माइग्रेट नहीं करेंगे या राउट नहीं करेंगे। तो अब देखते हैं कि एक Amazon का
एग्जांपल लेते हैं और देखते हैं कि कैसे हम एक मोनोलिथ सिस्टम को माइक्रो सर्विस सिस्टम में कन्वर्ट कर सकते हैं। तो जो
सबसे पहला पॉइंट होता है वह होता है अंडरस्टैंड अंडरस्टैंड योर मोनोलिथ।
अंडरस्टैंड योर मोनोलिथ। अब यहां पर हम Amazon का एग्जांपल ले रहे हैं। तो हमें समझना होगा कि जो हमारा Amazon का मोनोलिथ
सिस्टम है उसमें कौन-कौन से मॉड्यूल्स होंगे। तो हम एक हमारा ऑथेंटिकेशन का ऑथ मॉड्यूल होगा। एक हमारा सर्च वाला मॉड्यूल
होगा। जिसके थ्रू यूजर डिफरेंट-डिफरेंट प्रोडक्ट्स को सर्च करेगा। एक हमारे पास कार्ड का मॉड्यूल होगा। एक हमारे पास
पेमेंट का मॉड्यूल होगा, एक हमारे पास ऑर्डर का मॉड्यूल होगा। ऐसे हमारे पास डिफरेंट-डिफरेंट मॉड्यूल्स होंगे। तो जो
हमारा पहला पॉइंट होता है अ पहला स्टेप होता है वो होता है कि हमें पहले अपने मोनोलिथ को समझना है। अंडरस्टैंड योर
मोनोलिथ। अब उसके बाद उसके बाद जो दूसरा पॉइंट आता है वो यह होता है कि आइडेंटिफाई करो हाई इंपैक्ट एरियाज को। आइडेंटिफाई
आइडेंटिफाई हाई इंपैक्ट एरियाज हाई इंपैक्ट
एरियाज अब इसका मतलब क्या होता है कि लेट्स से हमने पहले भी देखा कि लेट्स से पेमेंट
सर्विस जो था पेमेंट मॉड्यूल जो था इस पे बहुत ट्रैफिक आ रहा था और यह आगे जाके क्रैश हो सकता है। हमने यह फिगर आउट कर
लिया। तो हम क्या करेंगे कि हम हमने यह समझ लिया कि हां यह हमारा हाई इंपैक्ट एरिया हो सकता है। यहां पर हम
क्रैश कर सकते हैं आगे चलके नियर फ्यूचर में। तो हम क्या करेंगे कि हम सबसे पहले इस पेमेंट मॉड्यूल को उठाएंगे और हम इसको
एक अलग से पेमेंट सर्विस में बनाने का ट्राई करेंगे। तो ये हमारा हो जाएगा पेमेंट सर्विस। तो
ये होता है हमारा दूसरा पॉइंट जहां हम आइडेंटिफाई करते हैं हाई इंपैक्ट एरियाज को। तो हमने डिसाइड कर लिया कि ठीक है
पहले हम हमारी पेमेंट माइक्रो सर्विस को डिजाइन करेंगे। उसके बाद जो थर्ड पॉइंट होता है वो हमारा होता है कि हम एपीआई
कॉन्ट्रैक्ट्स को बिल्ड करते हैं। बिल्ड एपीआई कॉन्ट्रैक्ट्स एपीआई
कॉन्ट्रैक्ट्स एंड वी विल आल्सो सेट अप कम्युनिकेशन। सेटअप कम्युनिकेशन। अब यह जो माइक्रो
सर्विज होती हैं, यह इनका आपस में कम्युनिकेशन दो टाइप का होता है। एक सिंक्रोनस कम्युनिकेशन, एक एसिंक्रोनस
कम्युनिकेशन। जो सिंक्रोनस कम्युनिकेशन होता है, वो रेस्ट एपीआई के थ्रू होता है। जीआरपीसी के थ्रू होता है। एसिंक्रोनस
कम्युनिकेशन के लिए हम डिफरेंट मैसेजिंग क्यूज़ होते हैं हमारे पास अ काफ का, रैबिट एमक्यू। तो इन माइक्रो सर्विसेस का
कम्युनिकेशन हमें आपस में डिफाइन करना होता है। तो इसके लिए हम एपीआई कॉन्ट्रैक्ट्स बिल्ड करेंगे और
कम्युनिकेशन सेटअप करेंगे। डिसाइड करेंगे कि कौन सा मैसेजिंग क्यों हमें यूज करना है। यदि हम एसिंक कम्युनिकेशन रख रहे हैं
हमारे सिस्टम में तो तो ये सारी चीजें हमें डिफाइन करनी होती है। तो ये हो जाता है हमारा थर्ड पॉइंट। उसके बाद हम क्या
करते हैं? मॉड्यूल बाय मॉड्यूल माइग्रेट करते हैं। तो हम सबसे पहले एक छोटा सा मॉड्यूल
लेंगे। वही सेम लेट्स से पेमेंट मॉड्यूल। तो टेक मॉड्यूल एंड वर्क ऑन इट।
बेसिकली हियर वी आर गोइंग मॉड्यूल बाय मॉड्यूल। पहले हम एक मॉड्यूल पे काम करेंगे। फिर दूसरे फिर तीसरे। ऐसे करके हम
पूरे के पूरे सिस्टम को स्लोली फ्रॉम मोनोलिथ टू माइक्रो सर्विस में माइग्रेट करते हैं। तो टेक मॉड्यूल एंड वर्क ऑन इट।
तो सबसे पहले हमने पेमेंट मॉड्यूल लिया और हम उस पर काम करेंगे। तो यह हो जाता है हमारा चौथा पॉइंट। अब इसके बाद यह जानना
बहुत ही जरूरी है कि कैसे हम इसे कोड में माइग्रेट कर रहे होंगे। तो यह हमारा एक माइक्रो सर्विस आर्किटेक्चर है। तो हम
यहां पे एक नई सर्विस डिफाइन करेंगे व्हिच इज़ आवर पेमेंट सर्विस। और फिर हम क्या करेंगे कि उस पेमेंट सर्विस में उस कोड को
लेकर आएंगे जो हमने मोनोलिथ में लिखा था। हम सिमिलर टू दिस यूजर सर्विस हम डिफरेंट-डिफरेंट उसका उस पेमेंट सर्विस
में हम जो डेटाबेस यूज़ करने वाले हैं हम वो डिफाइन कर रहे होंगे। लेट्स से हम कोई माय सीक्वल डेटाबेस यूज़ कर रहे हैं। तो हम
पहले इस पेमेंट सर्विस के लिए डेटाबेस चॉइस करेंगे। डेटाबेस सेलेक्ट करेंगे। तो लेट्स से कि हम माय सीक्वल डेटाबेस यूज कर
रहे हैं। तो पहले हम ये डिसाइड करेंगे। उसके बाद हम माय सीक्वल डेटाबेस यहां पे सेटअप करेंगे। हमारे पास ऐसे डिफरेंट हम
डॉकर को सेटअप करेंगे हमारे सिस्टम में इस माइक्रो सर्विस के लिए। उसके बाद हमारी खुद की एक इंडेक्स डॉट जेएस फाइल होगी
जिसके थ्रू हम पेमेंट सर्विस को रन करेंगे। से डिफरेंट-डिफरेंट हमारे पास अ फोल्डर स्ट्रक्चर होगा उस पर्टिकुलर
माइक्रो सर्विस के लिए और वो सारी चीजें हम माइग्रेट करेंगे जो हमारे मोनोलिथ सिस्टम में थी। तो इस मोनोलिथ सिस्टम में
पेमेंट के लिए हमने जोज जोज हमने पेमेंट ऑप्शंस रखे हुए थे वो सारे फीचर्स हम इस माइक्रो सर्विस में भी लेके आएंगे। ऐसे
करके हम स्लोली मॉड्यूल बाय मॉड्यूल माइग्रेट करेंगे। अब सक्सेसफुली माइग्रेशन होने हो जाने के बाद हम ऑब्वियसली टेस्ट
करेंगे। हम उसे डिप्लॉय करेंगे और फिर हम उसका उस पे उस सर्विस की मॉनिटरिंग भी करेंगे। बिकॉज़
इट इज़ वेरीेंट कि हम देख रहे हैं कि वह सही से काम कर रही है या नहीं और हम चीजें ऑब्जर्व करेंगे कि यह सही से ट्रैफिक को
हैंडल कर पा रही है या नहीं या इस पे कोई ट्रैफिक आ रहा है तो यह क्रैश तो नहीं हो जा रही। तो ये सारी चीजें भी हम डिस्कस ये
सारी चीजें भी हम मेंटेन करेंगे। तो ये जो हो जाता है हमारा फिफ्थ पॉइंट कि हम मॉनिटरिंग करेंगे।
मॉनिटरिंग एंड ऑब्जरवेबिलिटी। तो ये सारी चीजें भी हम यहां पे मेंटेन करेंगे। उसके बाद जो होता है हमारा वो
होता है सिक्स्थ पॉइंट व्हिच इज़ स्केलिंग। स्केलिंग एंड ऑप्टिमाइजेशन। तो अब इस फज़ में हम क्या करते हैं कि अब
हमने सक्सेसफुली माइग्रेट तो कर लिया। हमने हमारी माइक्रो सर्विस को डिजाइन कर लिया है। अब हम इसको लेट्स से स्केल करने
की नीड है। तो वो हम कैसे स्केल करेंगे? तो हम लेट्स से ये हमारी पेमेंट सर्विस है। तो अब हम इस पेमेंट सर्विस को
इंडिविजुअली स्केल कर सकते हैं। हम नंबर ऑफ मशीनंस बढ़ा देंगे। नंबर ऑफ मशीनंस इनक्रीस कर सकते हैं। लेट्स से कि ये जो
पेमेंट माइक्रो सर्विस है, यह बहुत ज्यादा लोड ले रहा है और हम फिगर आउट कर सकते हैं कि आगे चलके ये माइक्रो सर्विस क्रैश कर
सकती है। तो वी कैन इंक्रीस नंबर ऑफ मशीनंस इस पेमेंट माइक्रो सर्विस के लिए। तो ऐसे करके हम हॉरिजॉन्टली स्केल कर सकते
हैं इंडिविजुअल कॉमोनेंट्स को। हम ऑप्टिमाइजेशन भी परफॉर्म कर रहे होंगे। लेट्स से कि इस पेमेंट माइक्रो सर्विस को
हाई सर्वर सीपीयू की नीड है तो हम इसे वो असाइन कर देंगे। तो ऐसे करके हम स्केलिंग और ऑप्टिमाइजेशन को मेंटेन करेंगे। अब जो
हमारा पेमेंट मॉड्यूल का कोड है वह हमारे मोनोलिथ सिस्टम में भी है। अभी यह हमारा मोनोलिथ सिस्टम है। तो ये जो हमारा पेमेंट
मॉड्यूल का कोड है यह अभी मोनोलिथ में भी है। और हमने एक अलग से पेमेंट माइक्रो सर्विस भी डिफाइन कर दी। पेमेंट माइक्रो
सर्विस भी बिल्ड कर दी। तो क्या अब हम यह पेमेंट मॉड्यूल को जो मोनोलिथ में लिखा हुआ है तो क्या अब हम इसे रिमूव कर देंगे
या डीकमीशन कर देंगे एक्चुअली वी आर नॉट गोइंग टू डू दिस अ क्यों और कब तक तो यह हम तब तक डीकमीशन नहीं करेंगे जब तक हमारा
100% ट्रैफिक इस माइक्रो सर्विस पेमेंट माइक्रो सर्विस में नहीं राउट हो जाता। तो जब तक हमारा
100% 100% ट्रैफिक राउट नहीं हो जाता इस माइक्रो सर्विस में तब तक हम इस पेमेंट मॉड्यूल को डीकमीशन
नहीं करेंगे मोनोलिथ सिस्टम से। तो अब हम कैसे ट्रैफिक को मेंटेन कर रहे होंगे पहले वो देखते हैं। तो ट्रैफिक को मेंटेन करने
के लिए हम कैनरी डिप्लॉयमेंट का यूज़ कर रहे होंगे। कैनरी डिप्लॉयमेंट। अब ये कैनडी डिप्लॉयमेंट में क्या होता है कि हम
एक स्मॉल सबसेट ऑफ यूज़र्स को लेते हैं और जो हमारा नया सॉफ्टवेयर वर्जन है इस केस में पेमेंट सर्विस तो हम क्या करते हैं उस
स्मॉल सबसेट ऑफ यूज़र्स को राउट कर देते हैं। उनकी रिक्वेस्ट को राउट कर देते हैं नए सॉफ्टवेयर वर्जन पे जो कि यहां पे
हमारा पेमेंट सर्विस है। तो हम क्या करेंगे कि हम स्मॉल सबसेट ऑफ यूज़र्स को की रिक्वेस्ट को राउट कर देंगे
इस पेमेंट माइक्रो सर्विस पे। अब यदि इन यूज़र्स के लिए यह पेमेंट सर्विस सही से काम करती है और क्रैश नहीं करती है तो फिर
हम इस सबसेट को और बढ़ाएंगे। तो कैनरी डिप्लॉयमेंट में क्या होता है कि सबसे पहले हम 0 1% यूज़र्स को
0 1 यूज़र्स 0.1% यूज़र्स की रिक्वेस्ट को इस पे राउट करेंगे। पेमेंट सर्विस पे राउट करेंगे। इफ इट वर्क्स फाइन फॉर 0.1%
यूज़र्स तो हम 1% यूज़र्स को राउट करेंगे। इनके लिए भी सही से काम करता है तो हम 5%
इनके लिए भी सही से काम करता है तो हम 10% और इनके लिए भी यदि सही से काम करता है तो 50 और फिर ऐसे करके 100% तो ऐसे करके हम
100% ट्रैफिक को राउट करते हैं टू माइक्रो सर्विस। तो कैनरी डिप्लॉयमेंट इसमें हमारी हेल्प करता है फिगर आउट करने में कि कितने
परसेंट यूज़र्स को कितने परसेंट अ यूज़र्स की रिक्वेस्ट को हमें राउट करना है। ट्रैफिक को राउट करना है। तो कैनरी
डिप्लॉयमेंट हमारी इसमें मदद करता है। हम बेसिकली स्मॉल सबसेट ऑफ यूज़र्स को लेते हैं और नए सॉफ्टवेयर वर्जन पे हम उन
यूज़र्स की रिक्वेस्ट को राउट करते हैं। अब यहां पे हमारा एक अह माइक्रोसर्फेस डिज़ाइन पैटर्न पिक्चर में आता है जिसे हम बोलते
हैं स्ट्र्रांगुलर डिज़ाइन पैटर्न। स्ट्र्रांगुलर डिज़ाइन पैटर्न।
तो, यह स्ट्र्रांगुलर डिज़ाइन पैटर्न क्या होता है? कि इसे भी हम एक एग्जांपल के थ्रू समझते हैं कि लेट से हमारे पास यह
हमारा मोनोलिथ सिस्टम है जहां पर हमारा पूरा का पूरा कोड लिखा हुआ है। तो यह हमारा मोनोलिथ सिस्टम है। यहां
पे हमारी पेमेंट मॉड्यूल है। और यह एक हमारी पेमेंट माइक्रो सर्विस है जो हमने अभी-अभी बिल्ड की है। अभी इस पे कोई
ट्रैफिक नहीं जा रहा। तो हम कैनरी डिप्लॉयमेंट से फिगर आउट करेंगे कि कितने परसेंट ऑफ यूज़र्स को हमें राउट करना है।
तो यह राउटिंग होती कैसी है? इसके लिए कैसे होती है? इसके लिए हम स्ट्रांगुलर डिज़ाइन पैटर्न का यूज़ करते हैं। तो, इसमें
हमारे पास एक कंट्रोलर कंट्रोलर काइंड ऑफ़ थिंग होती है। तो, यह कंट्रोलर क्या करता है? यह एपीआई
रिक्वेस्ट आती हैं। लेट्स से डिफरेंट-डिफरेंट यूज़र्स की एपीआई रिक्वेस्ट आ रही हैं। लेट्स से कि 100
एपीआई रिक्वेस्ट आई। 100 एपीआई रिक्वेस्ट। तो ये कंट्रोलर क्या करता है कि इनिशियली ये 90%
रिक्वेस्ट को 90% एपीआई रिक्वेस्ट को या 90% ट्रैफिक को मोनोलिथ में राउट कर देता है और 10% को इस माइक्रो सर्विस में राउट
कर देता है। तो लेट्स से कि यदि हमारे पास 100 रिक्वेस्ट हैं तो 90 रिक्वेस्ट जाएंगी मोनोलिथ के पास। 10 रिक्वेस्ट जाएंगी
माइक्रो सर्विस के पास। अब लेट्स से कि यह जो माइक्रो सर्विस है पेमेंट माइक्रो सर्विस है वो इन 10 रिक्वेस्ट को भी सही
से प्रोसेस नहीं कर पाता। तो इस केस में ये जो 10% है इसको हम रिड्यूस करके जीरो कर देंगे और हम सारे के सारे ट्रैफिक को
राउट कर देंगे मोनोलिथ की तरफ। अब हमने ये सारे के सारे ट्रैफिक को मोनोलिथ की तरफ राउट कर दिया। तो अब यहां से हम जो भी
हमने यहां ट्रैफिक या रिक्वेस्ट भेजी थी, इसे हम रोल बैक कर देते हैं। तो, यह है हमारा स्ट्रेंुलर डिज़ पैटर्न। यह मदद करता
है ट्रैफिक को मेंटेन और मैनेज करने में। अह कैनरी भी हमारा ट्रैफिक को मैनेज करने में हेल्प करता है। तो इफ यू वांट मी टू
मेक अ वीडियो ऑन दिस ट्रें डिज़ाइन पैटर्न व्हिच इज़ आवर माइक्रो सर्विस डिज़ाइन पैटर्न। सो, इफ यू वांट मी टू मेक वीडियो
ऑन दैट। अह प्लीज लेट मी नो इन द कमेंट सेक्शन। आई विल मेक अ सेपरेट वीडियो ऑन दैट। तो यह हो गया हमारा ट्रैफिक के बारे
में कि हम कैसे ट्रैफिक को कंट्रोल और मैनेज करेंगे। अब जो दूसरी चीज हमारी आती है वो होती है कि कैसे हम ट्रांजैक्शंस को
मेंटेन करेंगे। ट्रांजैक्शंस को हम कैसे मेंटेन कर रहे होंगे। तो ट्रांजैक्शंस को मेंटेन करने के
लिए हमें हम एक अनदर माइक्रो सर्विस डिजाइन पैटर्न यूज़ करते हैं जिसे हम बोलते हैं सागा डिज़ पैटर्न।
तो यह सागा डिज़ाइन पैटर्न क्या होता है कि लेट्स से हमारे पास एक पेमेंट सर्विस है। पेमेंट माइक्रो सर्विस है
और हमारे पास एक लेट्स से ऑर्डर माइक्रो सर्विस है और एक हमारे पास
यूजर माइक्रो सर्विस है। अब लेट्स से कि एक कोई ट्रांजैक्शन रिलेटेड क्वेरी आती है और हां एक चीज और कि लेट्स से हर सर्विस
का अपना एक ओन डेडिकेटेड डेटाबेस है। तो इसका भी अपना ओन डेडिकेटेड डेटाबेस है। इस माइक्रो सर्विस का भी अपना ओन डेडिकेटेड
डेटाबेस है। और इस माइक्रो सर्विस का भी अपना ओन डेडिकेटेड डेटाबेस है। तो सागा डिज़ाइन पैटर्न में क्या होता है कि लेट्स
से कोई ट्रांजैक्शन रिलेटेड क्वेरी हमारे पास आती है और वह ट्रांजैक्शन रिलेटेड क्वेरी को उसको तीनों के तीनों माइक्रो
सर्विस से होके जाना है। लेट्स से वो ट्रांजैक्शन जो है वो तीनों माइक्रो सर्विसेस पे डिपेंड करता है। तो वो इस पे
इससे हो के भी जाएगा। वो इससे हो के भी जाएगा और पेमेंट से भी होके जाएगा। लेट्स से कि अब उस ट्रांजैक्शन को अ यहां पे वो
ट्रांजैक्शन सक्सेसफुली कंप्लीट हो गया। लेट्स से यहां पे छह डेटाबेस टेबल्स में चेंज करना था और छह के छह में हमने
सक्सेसफुली चेंज कर दिया। तो यहां पे ट्रांजैक्शन सक्सेसफुल हुआ। रिक्वेस्ट जाती है ऑर्डर सर्विस के पास। ऑर्डर
माइक्रो सर्विस। अब ऑर्डर माइक्रो सर्विस में पांच टेबल्स में हमें चेंज करना था। यहां भी हमने सक्सेसफुली कर दिया। अब इसके
बाद रिक्वेस्ट जाती है पेमेंट माइक्रो सर्विस में। लेकिन यहां पे लेट्स से आठ में हमें चेंज करना था। आठ में हमें चेंज
करना था और हम सिर्फ दो में कर पाए। छह में हमारा ट्रांजैक्शन फेल हो गया या हम चेंज नहीं कर पाए। तो इस केस में क्या
होता है कि ट्रांजैक्शन को रोल बैक करना और ट्रांजैक्शन को मेंटेन करना बहुत ही मुश्किल होता है। तो इस ट्रांजैक्शन को
मैनेज और मेंटेन करने के लिए हम यूज़ करते हैं सागा डिज़ाइन पैटर्न। व्हिच इज़ अनदर माइक्रो सर्विस डिज़ाइन पैटर्न। सो इफ यू
वांट मी टू मेक वीडियो ऑन दैट, प्लीज लेट मी नो इन द कमेंट सेक्शन। आई विल मेक अ सेपरेट वीडियो ऑन दैट। अह तो हम यहां पे
सागा डिज़ाइन पैटर्न का यूज़ करेंगे। ट्रांजैक्शन को मेंटेन करने के लिए क्योंकि
इफ ट्रांजैक्शन इज़ गोइंग थ्रू विद डिफरेंट-डिफरेंट माइक्रो सर्विसेस तो उसे मेंटेन करना बहुत ही मुश्किल हो जाता है।
यदि वो ट्रांजैक्शन सिर्फ एक माइक्रो सर्विस से रिलेटेड है तो तो ठीक है कि हमने यहां पे चेंज कर दिया। यदि नहीं हुआ
तो हमने रोल बैक कर दिया। रिवर्ट कर दिया। पर यहां पे क्या है कि इस ट्रांजैक्शन को डिफरेंट-डिफरेंट माइक्रो सर्विसेस से हो
के जाना है। लेट्स से इसमें सक्सेसफुल हो गया। इसमें सक्सेसफुल हो गया। इसमें फेल हो गया। तो फिर यहां पे ट्रांजैक्शन को
रोल बैक करना इज़ अ बिग चैलेंज। तो उसके लिए हम यूज़ करते हैं सागा डिज़ पैटर्न को। तो अब तक हमने देख लिया कि इस माइग्रेशन
में फ्रॉम मोनलिथ टू माइक्रो सर्विस हम कैसे ट्रैफिक को कंट्रोल करेंगे। हम कैसे ट्रांजैक्शन को कंट्रोल करेंगे। अब हम
देखते हैं एक और इंपॉर्टेंट पॉइंट कि हम डेटा कंसिस्टेंसी कैसे मैनेज करेंगे। हमारे सिस्टम में डाटा कंसिस्टेंसी
तो हमारे पास सबसे पहले अभी हमने पेमेंट सर्विस को माइग्रेट किया है। बेसिकली हमने
एक नई पेमेंट सर्विस बिल्ड की है। तो हमारे पास एक मोनोलिथ सिस्टम होगा और उस मोनोलिथ सिस्टम में
अभी भी हमारा पेमेंट का कोड है। पेमेंट मॉड्यूल है और एक हमारी नई पेमेंट माइक्रो सर्विस
रेडी है। तो अभी भी यह पेमेंट मॉड्यूल को हमने मोनोलिथ से डीकमीशन नहीं किया। वो हम
डिस्कस कर चुके हैं कि हम सिर्फ इसे डीकमीशन तभी करेंगे जब हम 100% ट्रैफिक को राउट कर देंगे टू माइक्रो सर्विस। अभी
लेकिन हमारी सिर्फ पेमेंट सर्विस बनके तैयार हुई है। हमारा हम कह सकते हैं कि हमारा कोड माइग्रेट हुआ है। हमारा फुली
यह पेमेंट मॉड्यूल माइग्रेट नहीं हुआ है। यह कब माइग्रेट कहलाया जाएगा? जब हम 100% ट्रैफिक को राउट कर देंगे। तो अभी सिर्फ
हमारा कोड माइग्रेट हुआ है। तो अब इस मोनोलिथ सिस्टम का अपना एक अलग डेटाबेस होगा जहां पे एक पेमेंट टेबल होगी। हम
ऑलरेडी ये डिस्कस कर चुके हैं और इस पेमेंट माइक्रो सर्विस का अपना एक इंडिविजुअल डेटाबेस होगा। अब ये दोनों ही
डेटाबेस में इस डेटाबेस की पेमेंट टेबल और यह जो डेटाबेस है यह सेम डेटा सेम पेमेंट्स का डेटा कैरी कर रहे होंगे कि
किस यूजर ने क्या पेमेंट की। पेमेंट का मीडियम क्या था? इट कैन बी क्रेडिट कार्ड और एनी अदर मीडियम। तो
इन टेबल इस टेबल में इस डेटाबेस टेबल में और इस डेटाबेस में डेटा शुड बी कंसिस्टेंट। ऐसा नहीं होना चाहिए कि लेट्स
से एक वेरिएबल है उसकी वैल्यू यहां पे लेट्स से x = 5 है और यहां पे x = 4 है। तो ऐसा नहीं होना चाहिए। वरना हमारा डेटा
इनकंसिस्टेंट हो जाएगा। तो इसके लिए हम क्या करते हैं? हम इसके लिए एक और पैटर्न यूज़ करते हैं व्हिच इज़ आउटबॉक्स पैटर्न।
तो हम आउटबॉक्स पैटर्न में क्या करते हैं कि जभी भी कोई यूजर पेमेंट करेगा तो हम उस उस डेटा को उस ऑपरेशन को राइट करेंगे
हमारे इस मोनोलिथ डेटाबेस के पेमेंट टेबल में। राइट? अब उसके बाद हमारे पास इस सेम मोनोलिथ डेटाबेस में एक आउटबॉक्स टेबल
होगा। तो हम उस आउटबॉक्स टेबल में भी उस राइट को एंट्री करेंगे। उस राइट की एंट्री करेंगे। और फिर उस आउटबॉक्स टेबल से हम
इवेंट पुश कर देंगे काफका में। सो हियर वी विल बी हैविंग काफका। तो यहां पर हमारा लेट्स से काफका है। अब
यह काफका में हम इवेंट पुश कर देंगे और फिर इस काफका से यह इवेंट जाएगा इस पेमेंट माइक्रो सर्विस के डेटाबेस में। सो दिस इज़
हाउ यूजिंग आउटबॉक्स पैटर्न वी विल मैनेज डेटा कंसिस्टेंसी व्हाइल माइग्रेटिंग फ्रॉम मोनोलिथ टू
माइक्रो सर्विस। नाउ आई थिंक दिस इज़ इनफ फॉर दिस वीडियो। एक बार वापस से रिवाइज करते हैं हमने क्या-क्या देखा। सो
वी हैव डिस्कस्ड मोनोलिथ वर्सेस माइक्रो सर्विसेस। दोनों में क्या डिफरेंस होता है? दोनों के कोड बेस में क्या डिफरेंस
होता है। सो वी हैव डिस्कस्ड दिस। उसके बाद हमने देखा कि कैसे हम एक मोनोलिथ एप्लीकेशन को माइक्रो सर्विस एप्लीकेशन
में कन्वर्ट कर सकते हैं। हमने प्रिकॉशंस देखे कि हम अह पूरे के पूरे सिस्टम को एक बार में माइग्रेट नहीं करेंगे। वी विल गो
मॉड्यूल बाय मॉड्यूल। हमने देखा कि हम एक साथ 100% ट्रैफिक को भी माइग्रेट नहीं करेंगे या 100% ट्रैफिक को राउट नहीं
करेंगे टू माइक्रो सर्विस। अ उसके बाद हमने डिफरेंट स्टेप्स देखे मोनोलिथ एप्लीकेशन को माइक्रो सर्विस एप्लीकेशन
में कन्वर्ट करने के। उसमें हमने देखा कि हम मॉड्यूल बाय मॉड्यूल माइग्रेट करेंगे। सबसे पहले हम कोड को माइग्रेट करेंगे। हम
कोड को लेकर आएंगे हमारे माइक्रो सर्विस एप्लीकेशन वाली रेपोजिटरी में। तो सबसे पहले हम कोड माइग्रेट करेंगे। उसके बाद जब
हमारा कोड माइग्रेट हो जाएगा फिर हम उसकी टेस्टिंग करेंगे, डिप्लॉय करेंगे और फिर हम यूजिंग कैनरी मेथड अ कैनरी
डिप्लॉयमेंट्स, ट्रेंगुलर डिज़ पैटर्न। फिर हम ट्रैफिक को मूव करेंगे उस माइक्रो सर्विस पे। यदि हम 100% सक्सेसफुली
ट्रैफिक को राउट कर पाते हैं तब हम कह सकते हैं कि यस हमारी माइक्रो सर्विस जो है वो माइग्रेट हो चुकी है सक्सेसफुली।
सो हियर कोड माइग्रेशन एंड सर्विस माइग सर्विस माइग्रेशन या मॉड्यूल माइग्रेशन इज़ डिफरेंट।
तो यह चीज का थोड़ा ध्यान रखना कि जब मैंने बोला है कि हमने कोड माइग्रेट कर लिया तो यह कोड माइग्रेशन में क्या होगा
कि हम अपने कोड को माइक्रो सर्विस वाली रिपॉजिटरी में लेके आएंगे। हम डेटाबेस कॉन्फ़िगरेशन करेंगे। डेटाबेस डिसाइड
करेंगे। उसके लिए जो भी कॉन्फ़िगरेशन की जरूरत होगी, वह हम वहां डिफाइन करेंगे। तो, यह हो गया हमारा कोड माइग्रेशन। कोड
माइग्रेशन के बाद हम टेस्टिंग करेंगे। उस कोड की डिप्लॉय करेंगे और एक बार सक्सेसफुली डिप्लॉय हो जाने के बाद हम फिर
उस पे ट्रैफिक ट्रैफिक का टेस्ट करेंगे कि वह ट्रैफिक को सही से कंट्रोल कर पा रहा है या नहीं तो उसके लिए हम कैनरी और
स्ट्रेंगलर का यूज़ करेंगे। तो एक बार यदि हमारा सही से ट्रैफिक राउट हो पा रहा है तो फिर हम बोलेंगे कि ठीक है हमने
सक्सेसफुली हमारे मोनोलिथ से माइक्रो सर्विस में एक मॉड्यूल को माइग्रेट कर दिया। इस केस में
हम देख रहे थे पेमेंट। तो हम बोल सकते हैं आफ्टर राउटिंग 100% ट्रैफिक टू माइक्रो सर्विस कि हमने पेमेंट मॉड्यूल को सही से
माइग्रेट कर दिया। ऐसे करके हम डिफरेंट-डिफरेंट अदर मॉड्यूल्स को भी माइग्रेट कर देंगे। और हमने एक चीज और
देखी कि हम इस पेमेंट मॉड्यूल को जो हमारा पेमेंट मॉड्यूल था जो मोनोलिथ में हमने लिखा था। तो इसको हम तभी डीकमीशन करेंगे
जब हम 100% ट्रैफिक को राउट कर देंगे टू माइक्रो सर्विस। तो एक चीज यह भी ध्यान में रखने वाली है। उसके बाद हमने कुछ
इंपॉर्टेंट केसेस देखे कि हम कैसे ट्रैफिक को मैनेज करते हैं। अ व्हाइल माइग्रेटिंग फ्रॉम मोनोलिथ टू माइक्रो सर्विस। हम कैसे
ट्रांजैक्शंस को मैनेज करते हैं। हमने देखा कि कैसे हम डेटा कंसिस्टेंसी को मैनेज करते हैं। सो वी हैव डिस्कस्ड
डिफरेंट-डिफरेंट थिंग्स और ये हमने देखा सिर्फ एक मॉड्यूल के लिए कि एक मॉड्यूल को कैसे हम माइग्रेट करेंगे। ऐसे ही सेम
स्टेप्स को फॉलो करते हुए सेम प्रिकॉशंस को ध्यान में रखते हुए हम अदर मॉड्यूल्स को भी माइग्रेट करेंगे। और एक बार सारे
मॉड्यूल्स सक्सेसफुली माइग्रेट हो जाएंगे। तो एज वी हैव ऑलरेडी नो कि यह इंडिविजुअल सर्विज बन जाएंगी। लेट्स से पेमेंट अपने
में एक इंडिविजुअल सर्विस होगी। यूजर एक अपने में इंडिविजुअल सर्विस होगी। तो ऐसे करके हम पूरे के पूरे मोनोलिथ एप्लीकेशन
को माइक्रो सर्विस एप्लीकेशन में कन्वर्ट कर देंगे। उसके बाद हम एपीआई गेटवे के बारे में देखेंगे। तो एपीआई गेटवे इज़
समथिंग दैट वी विल बी डिस्कसिंग इन अ वेरी नेक्स्ट वीडियो। सो यस। एंड आई थिंक दिस इज ऑल फॉर दिस। दिस
इज इनफ फॉर दिस वीडियो। वी विल सी यू इन द नेक्स्ट वीडियो। और नेक्स्ट वीडियो में हम बात करने वाले हैं एपीआई गेटवे वर्सेस लोड
बैलेंसर के बारे में कि दोनों में डिफरेंस क्या होता है और एक रियल वर्ल्ड प्रोजेक्ट में क्या पहले आता है। और भी हम कुछ
इंपॉर्टेंट क्वेश्चंस देख रहे होंगे रिगार्डिंग एपीआई गेटवे एंड लोड बैलेंसर। सो यस दिस इज़ ऑल फॉर दिस वीडियो। वी विल
सी यू इन द नेक्स्ट वीडियो। सो टिल देन बय शो सम लव थैंक्स [संगीत]
हे एवरीवन वेलकम बैक वेलकम टू दिस अल्टीमेट सिस्टम डिज़ प्लेलिस्ट सीरीज। तो यह वीडियो इस सीरीज का दूसरा वीडियो होने
वाला है। और इस वीडियो में हम देखेंगे एपीआई गेटवे वर्सेस लोड बैलेंसर। और साथ ही साथ हम देखेंगे कुछ इंपॉर्टेंट
क्वेश्चंस जो अक्सर इंटरव्यू में पूछे जाते हैं रिगार्डिंग दिस एपीआई गेटवे एंड लोड बैलेंसर। तो स्टार्ट करते हैं और एक
बार डिस्कस करते हैं कि इससे पिछले वीडियो में हमने क्या-क्या डिस्कस किया। तो लास्ट वीडियो में हमने देखा व्हाट इज़ मोनोलिथ
एप्लीकेशन। हमने देखा व्हाट इज़ माइक्रो सर्विस एप्लीकेशन। अह वी हैव डिस्कस्ड कि कैसे हम एक मोनोलिथ एप्लीकेशन को एक
माइक्रो सर्विस एप्लीकेशन में कन्वर्ट कर सकते हैं। उसके लिए हमने प्रिकॉशंस देखे। हमने डिफरेंट स्टेप्स देखे और साथ ही साथ
हमने कुछ इंपॉर्टेंट पॉइंट्स देखे कि कैसे हम ट्रैफिक को कंट्रोल करते हैं। कैसे हम ट्रांजैक्शंस को मैनेज करते हैं और हमने
देखा कि कैसे हम डेटा कंसिस्टेंसी को मैनेज करते हैं व्हाइल माइग्रेटिंग फ्रॉम मोनोलिथ टू माइक्रो सर्विसेस। तो अब हम
कंप्लीटली आ चुके हैं अपने माइक्रो सर्विस आर्किटेक्चर की तरफ। तो अब हमें एपीआई गेटवे को डिस्कस करना बहुत इंपॉर्टेंट है।
तो स्टार्ट करते हैं और इसे एक एग्जांपल के थ्रू समझते हैं। तो लेट्स से कि हम एक Amazon काइंड ऑफ एप्लीकेशन हमने बनाया। तो
उस एप्लीकेशन में एक हमारे पास यूजर सर्विस होगी, एक हमारे पास पेमेंट सर्विस होगी
और एक हमारे पास लेट्स से ऑर्डर सर्विस है। तो ऐसे हमारे पास डिफरेंट-डिफरेंट अदर
सर्विज भी होंगी। अब एक हमारे पास लेट्स से यूजर है एंड ही इज़ यूजिंग मोबाइल डिवाइस और लैपटॉप डिवाइस डिवाइस कैन बी
एनीथिंग एंड दिस डिवाइस विल बी अ क्लाइंट। तो यह यूजर है और इस यूजर को अब अपना लेट्स से फोन नंबर या ईमेल एड्रेस चेंज
करना है। तो यह कैसे पॉसिबल होगा? एक हमारे पास एपीआई एंड पॉइंट होगा। ऐसा कुछ एपीआई वी1 अपडेट प्रोफाइल। तो इस टाइप का
एक हमारे पास एपीआई एंड पॉइंट होगा। लेकिन क्या यह एपीआई एंड पॉइंट इस यूजर को पता है?
ऑब्वियसली नो। यह यूजर तो सिंपली क्या करेगा कि यह एक बटन पे क्लिक करेगा। लेट्स से अपडेट प्रोफाइल बटन पे और वहां पे फिर
यह अपनी इंफॉर्मेशन को चेंज कर देगा। लेट से फोन नंबर और ईमेल एड्रेस और उसके बाद वह सेव पे क्लिक करेगा। अब जैसे ही यूजर
सेव पे क्लिक करेगा तो यह एपीआई एंड पॉइंट ट्रिगर हो जाएगा। लेकिन क्या इस एपीआई एंड पॉइंट के बारे में और किस माइक्रो सर्विस
को कॉल करना है? क्या यह सब इंफॉर्मेशन इस यूजर को पता है? ऑब्वियसली नहीं। वह तो सिंपली एक बटन पे क्लिक करेगा। अपडेट
प्रोफाइल वहां अपनी इंफॉर्मेशन को अपडेट करेगा एंड देन ही विल क्लिक ऑन सेव। उसको यह एपीआई एंड पॉइंट हमारे बैक एंड में
क्या है? किस माइक्रो सर्विस को कॉल करना है? कौन सी माइक्रो सर्विस क्या करती है? उसको यह कुछ आईडिया नहीं है। वो तो सिंपली
यूआई पे बटन में क्लिक करेगा। अपनी इंफॉर्मेशन चेंज करेगा। इंफॉर्मेशन को सेव कर देगा। तो बेसिकली यूजर को हमारे बैक
एंड के बारे में और माइक्रो सर्विसेस के बारे में कोई इंफॉर्मेशन नहीं है। ना ही उसको इंफॉर्मेशन है इस एपीआई एंड पॉइंट के
बारे में। तो अब क्या हमें इस यूजर को ये सब बताना पड़ेगा कि भाई तुम्हें अपनी इंफॉर्मेशन को चेंज करने के लिए इस एपीआई
एंड पॉइंट को हिट करना पड़ेगा। तो क्या हमें यह सब इंफॉर्मेशन यूजर को देनी पड़ेगी? क्या हमें क्लाइंट को बताना
पड़ेगा कि ये इफ यू वांट टू चेंज योर इंफॉर्मेशन बेसिक इंफॉर्मेशन तो तुम्हें इस माइक्रो सर्विस को कॉल करना पड़ेगा। तो
क्या यह सब हमें क्लाइंट को बताना पड़ेगा? एंड इज इट गुड टू टेल दिस काइंड ऑफ़ इनेशन टू क्लाइंट और यूजर ऑब्वियसली नॉट। तो इस
केस में हमारा एक इंटरफ़ेस काइंड ऑफ़ थिंग आती है। एंड वी कॉल दिस इंटरफ़ेस एज गेटवे। तो, यह
एपीआई गेटवे क्या करता है? यह क्लाइंट की रिक्वेस्ट को एक्सेप्ट करता है और फिर उसको फॉरवर्ड कर देता है। उस रिक्वेस्ट को
फॉरवर्ड कर देता है या राउट कर देता है टू करेक्ट माइक्रो सर्विस। इस केस में यूजर को अपनी बेसिक इंफॉर्मेशन अपडेट करनी थी।
एंड दिस इनेशन इज़ पावर्ड बाय दिस यूजर सर्विस। तो गेटवे को पता होगा कि ठीक है यूजर वांट्स टू चेंज ह इंफॉर्मेशन। तो वह
सिंपली क्या करेगा? वह सिंपली इस रिक्वेस्ट को फॉरवर्ड कर देगा या राउट कर देगा टू दिस माइक्रो सर्विस। तो, यह
काम होता है हमारे एपीआई गेटवे का। एंड एपीआई गेटवे इज़ स्मार्ट इनफ टू अंडरस्टैंड दिस एंड पॉइंट। तो, क्लाइंट रिक्वेस्ट हिट
करेगा और यह वाला एंड पॉइंट, यह वाला एपीआई एंड पॉइंट ट्रिगर हो जाएगा। अब जैसे ही यह
एपीआई एंड पॉइंट गेटवे को मिलेगा तो गेटवे समझ जाएगा कि किस माइक्रो सर्विस को कॉल करना है। तो इस केस में उसको पता रहेगा कि
ओके वी हैव टू इनवोक दिस यूजर माइक्रो सर्विस। तो वो सिंपली इस यूजर माइक्रो सर्विस को इनवोक कर देगा। तो एपीआई गेटवे
को हम एक इंटरफ़ेस समझ सकते हैं जो मतलब बेसिकली इट एक्ट्स एज़ एन इंटरफ़ेस बिटवीन क्लाइंट एंड माइक्रो सर्विसेस। और एक ये
सिंगल एंट्री पॉइंट होता है सारी की सारी एपीआई रिक्वेस्ट के लिए। मतलब क्लाइंट को कोई भी रिक्वेस्ट करना है लेट्स से पेमेंट
से रिलेटेड, ऑर्डर से रिलेटेड कोई भी इंफॉर्मेशन या कोई भी एपीआई रिक्वेस्ट उसे करना है तो उसका सिंगल एंट्री पॉइंट होगा
यह एपीआई गेटवे। बेसिकली यह एपीआई गेटवे क्लाइंट की रिक्वेस्ट को लेगा। एंड ही इज़ स्मार्ट इनफ टू राउट रिक्वेस्ट टू द
करेक्ट करेक्ट बैक एंड माइक्रो सर्विस। तो यह काम होता है हमारे एपीआई गेटवे का। और अब इस एपीआई गेटवे के आने से इस यूजर को
या क्लाइंट को हमारी बैक एंड की माइक्रो सर्विसेस से डायरेक्ट कम्युनिकेट नहीं करना। वो सिर्फ अपनी रिक्वेस्ट को एपीआई
गेटवे को दे देगा। एंड रेस्ट ऑफ़ द थिंग्स विल बी मैनेज्ड बाय दिस एपीआई गेटवे। तो यह काम होता है हमारे एपीआई गेटवे का और
सिंपल वर्ड्स में देखें तो हमारा एपीआई गेटवे हमें बताता है कि यूजर किस माइक्रो सर्विस से बात करना चाहता है। तो
यह हो गया हमारा एपीआई गेटवे। अब देखते हैं एपीआई गेटवे के कुछ एडवांटेजेस या कुछ फैसिलिटीज जो एपीआई गेटवे प्रोवाइड करता
है। तो फर्स्ट है हमारा एपीआई कंपोज़शन। लेट्स से कि आप एक आप Amazon वेबसाइट पर हैं और आपने सेम क्रेडेंशियल से आपके
मोबाइल डिवाइस पर भी लॉग इन किया है एंड कंप्यूटर डिवाइस या लैपटॉप पे भी लॉग इन किया है। एंड यू वांट टू सी दैट माय
ऑर्डर्स पेज। तो ऐसा हो सकता है ऐसा पॉसिबल है कि आपके मोबाइल डिवाइस में आपको उस पेज में कम सेक्शंस दिख रहे होंगे।
लेट्स से आपको सिर्फ एक प्रोडक्ट डिटेल्स का सेक्शन दिख रहा होगा जो आपने ऑर्डर किए हैं और आपको एक इनवॉइस डिटेल का सेक्शन
दिख रहा होगा। दैट्स इट। लेकिन यही चीज यही सेम पेज जब आप कंप्यूटर या लैपटॉप डिवाइस में ओपन करेंगे तो आपको प्रोडक्ट
डिटेल भी दिख रही होगी। जो प्रोडक्ट आपने ऑर्डर किया आपको इनवॉइस डिटेल भी दिख रही होगी। आपको जो आपने प्रोडक्ट ऑर्डर किया
उसके रेटिंग्स एंड रिव्यू दिख रहे होंगे। तो ऐसे आपको डिपेंड्स ऑन डिवाइस। हमारा नंबर ऑफ
सेक्शंस बदल जाते हैं। तो ऐसा क्यों हो रहा है? तो यह भी पॉसिबल है। बेसिकली यह एपीआई गेटवे हमें यह फैसिलिटी प्रोवाइड
करता है। मोबाइल डिवाइस के केस में यह हमें लिमिटेड नंबर ऑफ एपीआई प्रोवाइड करता है। और सेम पेज सेम पेज पे कंप्यूटर या
लैपटॉप डिवाइस के केस में यह हमें ज्यादा एपीआई प्रोवाइड करता है। तो लेट्स से कि हम यदि कंप्यूटर या लैपटॉप यूज़ कर रहे हैं
तो हमें यह प्रोवाइड करेगा एपीआई टू फेच प्रोडक्ट डिटेल्स। तो यह हमारी डिटेल जो होगी वह हमें प्रोडक्ट सर्विस से मिलेगी।
एपीआई टू फेच इनवॉइस डिटेल्स। तो यह हमें इनवॉइस सर्विस से मिलेगी। एपीआई टू फच रेटिंग एंड रिव्यूज तो यह हमें रेटिंग एंड
रिव्यू सर्विस से मिलेगी। तो ऐसे करके एपीआई गेटवे डिफरेंट-डिफरेंट माइक्रो सर्विसेस को कॉल करता है। डिपेंड्स ऑन द
डिवाइस। तो, दिस इज़ द फर्स्ट फैसिलिटी दैट एपीआई गेटवे प्रोवाइड्स। यह एपीआई कंपोज़शन को हम ग्राफ क्यूएल के थ्रू भी मैनेज कर
सकते हैं। ग्राफ क्यूएल को हम फिर किसी नेक्स्ट वीडियो में देखेंगे। बट जस्ट फॉर बेसिक इनेशन मैंने बताया कि इस एपीआई
कंपोज़शन को हम ग्राफ क्यूएल के थ्रू भी मैनेज कर सकते हैं। तो यह हो गया हमारा फर्स्ट फैसिलिटी। जो नेक्स्ट फैसिलिटी है
वह है कि एपीआई गेटवे हमें ऑथेंटिकेशन एंड ऑथराइजेशन में भी हेल्प करता है। बेसिकली इट हैंडल्स ऑथेंटिकेशन एंड ऑथराइजेशन। तो
ये एपीआई गेटवे अ सिर्फ ऑथराइज्ड क्लाइंट्स की रिक्वेस्ट को एक्सेप्ट करता है और उन्हें रिसोर्सेज यूज करने देता है।
तो एक बार हम ओथ 2.0 का फ्लो देखते हैं। तो सबसे पहले क्लाइंट ऑथ सर्वर से एक्सेस टोकन रिक्वेस्ट करेगा और ऑथ सर्वर उसे
एक्सेस टोकन प्रोवाइड करेगा। फिर यह क्लाइंट उस एक्सेस टोकन को एपीआई रिक्वेस्ट के साथ एपीआई गेटवे को प्रोवाइड
करेगा। और फिर यह एपीआई गेटवे उस एक्सेस टोकन को वैलिडेट करेगा फ्रॉम दिस ऑथ सर्वर। और यदि वह टोकन वैलिड होगा तो यूजर
की रिक्वेस्ट को या क्लाइंट की रिक्वेस्ट को एप्रोप्रियट माइक्रो सर्विस की तरफ राउट कर देगा यह एपीआई गेटवे। और यदि यह ए
यदि यह टोकन वैलिड नहीं होगा तो उस रिक्वेस्ट को यह रिजेक्ट कर देगा। तो इससे हमें यह एडवांटेज मिला कि हर सर्विस में
हर माइक्रो सर्विस में अपना-अपना एक ऑथेंटिकेशन मैकेनिज्म होने के बजाय हमने एक ऑथ सर्वर बना दिया और वही ऑथ सर्वर
हमारी सारी की सारी सारे के सारे यूज़र्स को ऑथेंटिकेट करेगा। तो इंस्टेड ऑफ हैविंग ऑथेंटिकेशन मैकेनिज्म इन ईच एंड एव्री
सर्विस हमने उसे एक सेंट्रलाइज्ड ऑथ सर्वर बना के उस उस रिक्वायरमेंट को फुलफिल कर दिया। तो ऐसे एपीआई गेटवे हमारी
ऑथेंटिकेशन में हेल्प करता है। जो नेक्स्ट एडवांटेज है एपीआई गेटवे का वो है सर्विस डिस्कवरी। तो जब हम जब हम लास्ट लेक्चर
में देख रहे थे कि हम माइक्रो सर्विसेस को इंडिविजुअली स्केल कर सकते हैं। लेट्स से हमारे पास कोई एक ये यूजर सर्विस है और इस
यूजर सर्विस पे लेट्स से बहुत बहुत सारा ट्रैफिक आ रहा है। तो हम इसे इंडिविजुअली स्केल कर सकते हैं। तो इंडिविजुअली स्केल
करने का मतलब क्या है? कि हम एक नई मशीन लगा देंगे इस यूजर सर्विस के लिए। बेसिकली हम एक नया सर्वर लगा देंगे। तो अब लेट्स
से एक हमारा यूजर सर्विस का इंस्टेंस यह है। लेट्स से यूजर वन एक है ये। एंड बोथ यूजर सर्विसेस आर रनिंग ऑन
डिफरेंट-डिफरेंट मशीनंस। तो इस मशीन का अपना एक IPपी एड्रेस होगा। राइट? और इस मशीन का भी अपना IPपी एड्रेस होगा। तो ये
दोनों की दोनों यूजर सर्विस जो हैं वो डिफरेंट-डिफरेंट सर्वर पे हैं। इस वजह से इनके IPपी एड्रेससेस चेंज होंगे। IP
एड्रेसेस डिफरेंट होंगे। लेट्स से इसका x.z है। इसका a.b.c
है। और ऐसे ही ये यूज़र्स वन सर्विस लेट्स से 4000 पोर्ट पे चल रही है। और यूजर टू जो है वो 40001 पोर्ट पे चल रही है। तो ये
सारी इंफॉर्मेशन हम कहां स्टोर करते हैं? और इन सबकी ये सारी इंफॉर्मेशनेशंस को कौन हैंडल करता है? तो यहां हमारा आता है
सर्विस डिस्कवरी पिक्चर में। तो ये सर्विस डिस्कवरी क्या करता है कि जभी भी कोई नई माइक्रो सर्विस हम बनाते हैं लेट्स से हम
एक माइक्रो यूजर माइक्रो सर्विस का नया इंस्टेंस बना रहे हैं लेट्स से यूजर थ्री तो हमको हमें इस माइक्रो सर्विस को
रजिस्टर करना पड़ेगा सर्विस डिस्कवरी के साथ। ऐसा हम क्यों करते हैं कि लेट्स से जब क्लाइंट की रिक्वेस्ट आएगी लेट्स से ये
रिक्वेस्ट कि क्लाइंट ने रिक्वेस्ट किया और उसको कुछ ऑर्डर करना है तो ये एंड पॉइंट ट्रिगर होगा स्लश एपीआई v1 ऑर्डर और
यह रिक्वेस्ट जाएगी एपीआई गेटवे के पास। अब ऑर्डर सर्विस के डिफरेंट-डिफरेंट हमारे पास इंस्टेंसेस हो सकते हैं। लेट्स से
ऑर्डर वन, ऑर्डर टू, ऑर्डर थ्री। तो ऐसे करके हमारे पास ऑर्डर के डिफरेंट-डिफरेंट इंस्टेंसेस हो सकते हैं। ऑर्डर वन, ऑर्डर
टू एंड लेट्स से ऑर्डर थ्री। तो अब उनमें से ऐसा होगा कि कुछ माइक्रो
सर्विसेस जो होंगी वो डीमी हो गई होंगी या फिर हम कह सकते हैं कि वो डाउन होंगी ऑलरेडी डाउन। लेट्स से ऑर्डर थ्री जो है
वह एक्टिव नहीं है। इनक्टिव है। ऑर्डर टू माइक्रो सर्विस है। बेसिकली ये दोनों इंस्टेंस हमारे लेट्स से इनएक्टिव हैं।
सिर्फ ये वाला इंस्टेंस है जो एक्टिव है। तो ये सब इंफॉर्मेशनेशन सर्विस डिस्कवरी प्रोवाइड करती है। एपीआई गेटवे सिंपली ये
एंड पॉइंट को समझेगा और वह समझ जाएगा कि ठीक है मुझे ऑर्डर माइक्रो सर्विस को इनवोक करना है। तो ये सर्विस डिस्कवरी से
पूछेगा कि ऑर्डर सर्विस का कौन सा इंस्टेंस फ्री है? तो यह सर्विस डिस्कवरी बताएगी कि ठीक है यह ऑर्डर वन जो इंस्टेंस
है यह अभी अवेलेबल है। इसका IP एड्रेस X.Y.Z है और यह 402 पोर्ट पे चल रही है। तो, यह इंफॉर्मेशन यह सर्विस डिस्कवरी इस
एपीआई गेटवे को बताएगी और फिर एपीआई गेटवे इस रिक्वेस्ट को राउट कर देगा टू करेक्ट बैक एंड माइक्रो सर्विस। बेसिकली ऑर्डर
सर्विस। तो यह काम होता है हमारे सर्विस डिस्कवरी का। इसमें हम यूरेका सर्वर का यूज कर सकते हैं। तो यह हो गए हमारे कुछ
एडवांटेजेस या कुछ फैसिलिटीज जो हमें एपीआई गेटवे प्रोवाइड करता है। अब देखते हैं हम लोड बैलेंसर के बारे में कि लोड
बैलेंसर क्या होता है। तो उससे पहले एक बार रिवाइज़ करते हैं कि एपीआई गेटवे क्या है? तो एपीआई गेटवे सिंपली क्लाइंट की
रिक्वेस्ट को एक्सेप्ट करता है और उसे राउट कर देता है टू करेक्ट बैक एंड माइक्रो सर्विस। अ सिंपल वर्ड्स में हम
देखें तो हम बोल सकते हैं कि एपीआई गेटवे हमें बताता है कि यूजर किस माइक्रो सर्विस से बात करना चाहता है। अब जो लोड बैलेंसर
है, वह हमें यह बताता है कि यूजर माइक्रो सर्विस के किस इंस्टेंस से बात करना चाहता है। तो हमने देखा कि लेट्स से एक हमारे
पास यह यूजर है और यह यूजर हमारी पेमेंट माइक्रो सर्विस से बात करना चाहता है। तो यह हमें कौन बताएगा? यह हमें बताएगा एपीआई
गेटवे। एपीआई गेटवे कि एपीआई गेटवे को एंड पॉइंट मिला। उसके
बाद वह उस एपीआई एंड पॉइंट को देख के समझ जाएगा कि ठीक है यूजर को पेमेंट माइक्रो सर्विस से बात करना है या ही वांट्स टू
इनवोक पेमेंट माइक्रो सर्विस तो एपीआई गेटवे इज़ स्मार्ट इनफ टू डू दिस तो वो यह सिंपली अपनी एक्टिविटी या अपना यहां पे
रोल प्ले करेगा। अब उसके बाद ऐसा पॉसिबल है कि हमारे पास पेमेंट माइक्रो सर्विस के डिफरेंट-डिफरेंट इंस्टेंसेस हो सकते हैं।
लेट्स से पेमेंट वन, पेमेंट टू, पेमेंट टू और ऐसे करके एक और लेट्स से पेमेंट
थ्री। तो ऐसे हमारे पास सेम माइक्रो सर्विस के डिफरेंट-डिफरेंट इंस्टेंसेस हो सकते हैं। और इस केस में अब ऐसा भी पॉसिबल
हो सकता है कि लेट्स से यह जो इंस्टेंस है यह ऑलरेडी बिजी है। बहुत ज्यादा ट्रैफिक ले रहा है। यह वाला इंस्टेंस लेट्स से
इनएक्टिव है। और सिर्फ यह वाला इंस्टेंस एक्टिव है। और इट इज़ अवेलेबल टू टेक ट्रैफिक। तो, अब यह लोड बैलेंसर डिसाइड
करेगा कि माइक्रो सर्विस के किस इंस्टेंस से यूजर
को बात करनी है। लेट्स से यह अवेलेबल है पेमेंट वन तो यह उसको उसकी रिक्वेस्ट को पेमेंट वन की तरफ राउट कर देगा। तो यह काम
होता है हमारा लोड बैलेंसर का। सिंपल वर्ड्स में हम देखें तो लोड बैलेंसर ट्रैफिक को डिस्ट्रीब्यूट कर देता है टू
डिफरेंट माइक्रो सर्विस इंस्टेंसेस। जैसा कि हमने इसमें देखा यूजर को पेमेंट माइक्रो सर्विस से बात करनी थी। तो लोड
बैलेंसर ने देखा कि ठीक है पेमेंट थ्री जो है वह तो ऑलरेडी ट्रैफिक ले रहा है। पेमेंट टू इंस्टेंस है वह अभी इनक्टिव है।
सिर्फ पेमेंट वन इंस्टेंस अभी एक्टिव है और ट्रैफिक लेने के लिए अवेलेबल है। तो लोड बैलेंसर ने यूजर की रिक्वेस्ट को राउट
कर दिया टू दिस माइक्रो सर्विस इंस्टेंस। तो यह काम होता है हमारे लोड बैलेंसर का। अब हम दोनों ही कंपोनेंट्स डिस्कस कर चुके
हैं। हमने एपीआई गेटवे भी देख लिया। हमने लोड बैलेंसर भी देख लिया। और हमने समझा कि एपीआई गेटवे सिंपली हमें बताएगा कि यूजर
किस माइक्रो सर्विस से बात करना चाहता है। बेसिकली हमें एंड पॉइंट मिलेगा। लेट्स से एपीआई
वी1 पेमेंट। तो लेट्स से कि यूजर पेमेंट माइक्रो सर्विस से बात करना चाहता है। तो
यहां पर एपीआई गेटवे इस एंड पॉइंट को देखेगा। एंड ही इज़ स्मार्ट इनफ टू अंडरस्टैंड कि ओके यूजर वांट्स टू टॉक टू
पेमेंट माइक्रो सर्विस। अब इस पेमेंट माइक्रो सर्विस के डिफरेंट-डिफरेंट इंस्टेंसेस हो सकते हैं। लेट्स से P1, P2
एंड P3। तो यूजर की रिक्वेस्ट को किस इंस्टेंस पर फॉरवर्ड करना है यह डिसाइड करता है हमारा लोड बैलेंसर।
अब कुछ लोड बैलेंसर्स में रिक्वेस्ट को सही माइक्रो सर्विस पे राउट करने की भी
कैपेबिलिटी होती है। अह वो वो लोड बैलेंसर्स में आते हैं हमारे एडब्ल्यूएस के लोड बैलेंसर्स। तो इनमें यह कैपेबिलिटी
होती है कि यह यूजर की रिक्वेस्ट को सही बैक एंड माइक्रो सर्विस पर राउट कर सकते हैं। पर दीज़ एडब्ल्यूएस लोड बैलेंसर्स आर
वेरी एक्सपेंसिव। तो ज्यादा हम इसे यूज़ नहीं करते। मतलब हम कह सकते हैं कि अभी हम गेटवे को भी कंसीडर कर रहे हैं। अब हमने
देख लिया एपीआई गेटवे लोड बैलेंसर। अब हम देखते हैं कुछ रियल वर्ल्डेंट क्वेश्चंस जो अक्सर इंटरव्यू में पूछे जाते हैं। तो
उनमें सबसे पहला है कि इफ एपीआई गेटवे इज अ सिंगल एंट्री पॉइंट इफ एपीआई गेटवे इज अ सिंगल एंट्री पॉइंट
देन हाउ डस इट हैंडल मिलियंस ऑफ रिक्वेस्ट? और दूसरा क्वेश्चन हमारा आ सकता है कि क्या यह सच में सिंगल एंट्री
पॉइंट होता है? और एक और क्वेश्चन जो अक्सर पूछा जाता है वह है कि वि कम्स फर्स्ट एपीआई गेटवे
एपीआई गेटवे और लोड बैलेंसर। तो दोनों में से हम क्या पहले यूज़ करते हैं या पहले क्या
लगाते हैं? एपीआई गेटवे या लोड बैलेंसर। तो हमने देखा कि हमारे एप्लीकेशन में दो माइक्रो सर्विसेस हैं।
एक हमारे पास ऑर्डर माइक्रो सर्विस है और एक हमारे पास यूजर माइक्रो सर्विस है। और दोनों ही माइक्रो सर्विसेस को हमने
हॉरिजॉन्टली स्केल कर दिया। तो अब हमारे पास इन माइक्रो सर्विसेस के डिफरेंट-डिफरेंट इंस्टेंसेस होंगे। राइट?
इस ऑर्डर माइक्रो सर्विस के हमारे पास डिफरेंट इंस्टेंस होंगे। इस यूजर माइक्रो सर्विस के हमारे पास डिफरेंट इंस्टेंस
होंगे। तो अब इस अवेले एपीआई गेटवे और लोड बैलेंसर को समझने के लिए कि वाकई में यह एपीआई गेटवे सिंगल एंट्री पॉइंट है या
नहीं और एपीआई गेटवे पहले आता है या लोड बैलेंसर। तो इन क्वेश्चंस का आंसर जानने के लिए हमें इसे एक लार्जर स्केल पे देखना
होगा। जहां पे हमारे पास अवेलेबिलिटी ज़ोन होगा, अवेलेबल रीजंस होगा, डिफरेंट रीजंस होंगे। तो एक बार समझते हैं ये
अवेलेबिलिटी ज़ोन और रीजंस को। तो लेट्स से कि हमारे पास एक यूएसए का स्टेट है मैसच्यूसेस।
और इस स्टेट के अंदर हमारे पास डिफरेंट-डिफरेंट सिटीज हैं। लेट्स से हमारे पास एक बॉस्टन सिटी है और एक हमारे
पास कैंब्रिज सिटी है। तो ये हमारे पास इस स्टेट के अंदर ऐसे दो सिटीज हैं। तो अब हम इस स्टेट को एक रीजन कंसीडर कर सकते हैं।
कि एक हमारा कंप्लीट रीजन हो गया। और इस रीजन के अंदर हमारे पास ये सिटीज हैं। हमारे पास बॉस्टन है। हमारे पास कैमब्रिज
है। तो, हम इन सिटीज को अवेलेबिलिटी ज़ोन कंसीडर कर सकते हैं। लेट्स से ये हो गया अवेलेबिलिटी ज़ोन वन। यह हो गया
अवेलेबिलिटी ज़ोन टू। अब इन सिटीज के अंदर हमारे डेडिकेटेड डेटा सेंटर हो सकता है। हमारे एप्लीकेशन का। तो, लेट्स से इस
Cambridge में भी हमारे एप्लीकेशन का एक डेडिकेटेड डेटा सेंटर होगा। सिमिलरली हमारे पास एक और रीजन हो सकता है। तो ऐसे
करके हमारे पास डिफरेंट-डिफरेंट रीजंस और डिफरेंट-डिफरेंट अवेलेबिलिटी ज़ोन हो सकते हैं। अब इनकी हमें नीड क्या है? कि लेट्स
से अ हमारा बॉस्टन अवेलेबिलिटी ज़ोन डाउन हो गया। तो इस केस में हम क्या कर सकते हैं? यूजर की
रिक्वेस्ट को या सारे के सारे ट्रैफिक को इस दूसरे अवेलेबिलिटी ज़ोन में राउट कर सकते हैं। और लेट्स से यदि हमारा दोनों के
दोनों ही अवेलेबिलिटी ज़ोन डाउन हो जाते हैं तो इस स्टेट इस केस में हम हमारा रीजन ही स्विच कर सकते हैं। लेट्स से अभी रीजन
मैसेज चूसेट्स था। तो अब हम इसे चेंज करके न्यूयॉर्क कर सकते हैं। तो यह होता है हमारा रीजन एंड अवेलेबिलिटी ज़ोन। तो अब
समझते हैं एपीआई गेटवे और लोड बैलेंसर को एक एग्जांपल की हेल्प से। तो लेट्स से कि ये एक हमारा यूजर है और यह यूजर कुछ ऑर्डर
करना चाहता है लेट्स से Amazon काइंड ऑफ़ वेबसाइट से। तो वो सिंपली एक प्लेस ऑर्डर बटन पे क्लिक करेगा। ही विल सिंपली क्लिक
ऑन प्लेस ऑर्डर बटन। अब जैसे ही वो इस प्लेस ऑर्डर बटन पे क्लिक करेगा तो एक एपीआई एंड पॉइंट ट्रिगर होगा। लेट्स से
स्लश एपीआई v1 ऑर्डर तो ऐसा कुछ एक एपीआई एंड पॉइंट ट्रिगर होगा। अब जैसे ही यूजर प्लेस ऑर्डर
बटन पे क्लिक करेगा तो ब्राउज़र एक रिक्वेस्ट इस रिक्वेस्ट को इनिशिएट करेगा। अब हमारा ब्राउज़र देखेगा कि यहां पर ये
इंग्लिश के कुछ अल्फाबेट्स आ गए हैं जो कि हमारा डोमेन नेम है। तो हमारा ब्राउज़र कंफ्यूज हो जाएगा क्योंकि वो तो IP
एड्रेसेस में बात करता है। उसे हम करेक्ट IPपी एड्रेस देंगे। वो हमारी रिक्वेस्ट को सही जगह राउट कर देगा। सही जगह पहुंचा
देगा। पर अब यहां पे हमारे पास डोमेन नेम है और हमें चाहिए IPपी एड्रेस और किसका IPपी एड्रेस कौन सा IPपी एड्रेस ये भी
हमें डिसाइड करना है। तो ब्राउज़र हमारा डीएनएस को कॉल करेगा और ये डीएनएस डीएनएस लोड बैलेंसर्स की हेल्प से हमें IP एड्रेस
ला के देगा। लेकिन वही सेम क्वेश्चन कौन सा IPपी एड्रेस किसका IPपी एड्रेस तो हमारा लेट्स से एप्लीकेशन एक कैलिफोर्निया
रीजन में होस्टेड है और एक है हमारा मैसच्यूसेस रीजन में तो ये हमारे पास दो डिफरेंट
रीजंस हैं और हमने हर रीजन के लिए एक अलग एपीआई गेटवे कॉन्फ़िगर करके रखा है। लेट्स से ये हो गया हमारा एपीआई गेटवे ए और यह
हो गया हमारा एपीआई गेटवे बी। तो अब यह जो डीएनएस लोड बैलेंसर क्या करेगा? यह डीएनएस लोड बैलेंसर हमारे इन रीजन वन और रीजन टू
के एपीआई गेटवेज़ के IP एड्रेसेस को ला के देगा। तो हमारे डीएनएस लोड बैलेंसर को डिफरेंट-डिफरेंट रीजंस के एपीआई गेटवे के
IPपी एड्रेसेस मिल जाएंगे। तो उसके बाद ये देखिएगा कि कौन सा रीजन यूजर के क्लोज है। लेट्स से ये हमारा यूजर फाइव है जिसने ये
रिक्वेस्ट की थी। तो ये हमारा यूजर फाइव कैलिफोर्निया रीजन के पास है। तो हम क्या करेंगे? हम इस डोमेन नेम की जगह हम यह
एपीआई गेटवे ए का IPपी एड्रेस यूज़ करेंगे। क्यों? क्योंकि हमारा यूजर फाइव जो है ये कैलिफोर्निया रीजन के कैलिफोर्निया रीजन
के पास है। तो इसलिए हम एपीआई गेटवे ए का IPपी एड्रेस यूज़ करेंगे। तो ये हमारा
डीएनएस लोड लोड बैलेंसर क्या करेगा कि हमें IP एड्रेस ला के देगा हमारे अ गेटवे का एपीआई गेटवे का और उसमें भी वो फाइंड
करेगा कि यूजर के क्लोज वाला रीजन कौन सा है। तो इस केस में एपीआई गेटवे इज़ क्लोज टू यूजर। तो हम यह वाला IPपी एड्रेस यूज़
करेंगे। अब ब्राउज़र इस रिक्वेस्ट को इनिशिएट करेगा और एक HTTP रिक्वेस्ट हिट कर देगा। अब यह रिक्वेस्ट जाएगी इस एपीआई
गेटवे के पास। अब इस एपीआई गेटवे को क्या करना है कि इसको ऑर्डर माइक्रो सर्विस को इनवोक करना
है। अब यहां पे भी हमारे पास डिफरेंट-डिफरेंट अवेलेबिलिटी ज़ोन है। हमारे पास एक लॉस एंजेलिस है। हमारे पास
सैन फ्रांसिस्को है। तो इस केस में अवेलेबिलिटी ज़ोन अगेन हमारे सर्विस डिस्कवरी के पास जाएगा और उससे पूछेगा कि
सबसे पहले मुझे मेरा क्लोजेस्ट अवेलेबिलिटी ज़ोन बताओ। यूजर का क्लोजेस्ट अवेलेबिलिटी ज़ोन। तो लेट्स से कि सर्विस
डिस्कवरी बताता है कि ओके Aजी1 जो है वो यूजर के क्लोज है। पहली चीज उसने यह बताई और दूसरी चीज हमें क्या चाहिए? हमें इस
लोड बैलेंसर का भी एड्रेस चाहिए। तभी तो यह एपीआई गेटवे ट्रैफिक को राउट करेगा लोड बैलेंसर में। तो सर्विस डिस्कवरी यह हमारा
सर्विस डिस्कवरी इस लोड बैलेंसर का एड्रेस भी बताएगा। तो यह हमारे लोड बैलेंसर का एड्रेस भी बताएगा। तो यह दो चीजें हमें
बताएगा क्लोजेस्ट नियरेस्ट अवेलेबिलिटी जोन इस केस में लेट्स से लॉस एंजेलिस और यह बताएगा हमारे लोड बैलेंसर का एड्रेस।
उसके बाद यह एपीआई गेटवे इस रिक्वेस्ट को राउट कर देगा या ट्रैफिक को राउट कर देगा टू दिस लोड बैलेंसर।
अब हमारे पास यहां भी माइक्रो सर्विसेस यू कैन सी कि हमारे पास डिफरेंट-डिफरेंट ऑर्डर माइक्रो सर्विज हैं या ऑर्डर
माइक्रो सर्विस के डिफरेंट-डिफरेंट इंस्टेंसेस हैं। लेट्स से एक हमारे पास O1 है, एक हमारे पास O2 है और एक हमारे पास
O3 है। तो अब हमारा लोड बैलेंसर डिसाइड करेगा कि यूजर की रिक्वेस्ट को किस ऑर्डर माइक्रो सर्विस में राउट करना है बेस्ड ऑन
ट्रैफिक एंड हेल्थ चेक। तो ये सब पैराटर्स चेक करने के बाद हमारा लोड बैलेंसर यूजर की रिक्वेस्ट को राइट राउट
कर देगा टू करेक्ट अ ऑर्डर सर्विस ऑर्डर माइक्रो सर्विस इंस्टेंस। तो यहां हमारा एपीआई गेटवे रीजन लेवल पे काम कर रहा है।
हमारे रीजन के अंदर डिफरेंट-डिफरेंट अवेलेबिलिटी ज़ोन होंगे। तो हमारा एपीआई गेटवे सर्विस डिस्कवरी की मदद से पता
करेगा कि हमें किस किस अवेलेबिलिटी ज़ोन पे हमारे ट्रैफिक को राउट करना है। बेसिकली वो क्लोजेस्ट या नियरेस्ट अवेलेबिलिटी ज़ोन
फाइंड करेगा और फिर उस लोड बैलेंसर का एड्रेस फाइंड करेगा। और ऐसे करके वह ट्रैफिक को राउट करेगा डिफरेंट
अवेलेबिलिटी ज़ों्स में। तो यह हमारा एपीआई गेटवे रीजन लेवल पर काम कर रहा है। और सिमिलरली यह हमारा लोड बैलेंसर
अवेलेबिलिटी ज़ोन लेवल पे काम कर रहा है। बेसिकली यह डिसाइड करेगा कि माइक्रो सर्विस के किस इंस्टेंस पे यूजर की
रिक्वेस्ट को राउट करना है। तो ये हो गया हमारा एपीआई गेटवे और ये हो गया हमारा लोड बैलेंसर। अब लेट्स से कि हमारा
अवेलेबिलिटी ज़ोन कंप्लीटली डाउन हो गया। लॉस एंजेलिस कंप्लीटली डाउन हो गया। तो इस केस में एपीआई गेटवे सर्विस डिस्कवरी को
पूछेगा कि मुझे क्लोजेस्ट अवेलेबिलिटी ज़ोन बताओ यूजर के इस यूजर फाइव के। तो सर्विस डिस्कवरी बोलेगा कि क्लोजेस्ट अवेलेबिलिटी
ज़ोन तो अवेलेबिलिटी ज़ोन वन है। लेकिन यह डाउन है। तो, वह एक और अवेलेबिलिटी ज़ोन। सेकंड क्लोजेस्ट अवेलेबिलिटी ज़ोन बताएगा
यूजर के व्हिच इज़ अवेलेबिलिटी ज़ोन टू सैन फ्रांसिस्को। और इसका लोड बैलेंसर लोड बैलेंसर का एड्रेस भी वो बताएगा। तो यहां
पे हमें यह दो चीजें मिलेंगी और इसके बाद हम ट्रैफिक को राउट कर देंगे। बेसिकली यह एपीआई गेटवे ट्रैफिक को राउट कर देगा टू
दिस लोड बैलेंसर। क्योंकि अब इसे लोड बैलेंसर का एड्रेस मिल गया तो यह ट्रैफिक को यहां राउट कर देगा। अब लेट्स से कि यदि
हमारे दोनों ही अवेलेबिलिटी ज़ोन डाउन हो जाते हैं तो इस केस में हम कंप्लीटली रीजन को ही स्विच कर देंगे। क्योंकि अब हमारे
पास डिफरेंट रीजंस भी हैं। तो यदि हमारा लॉस एंजेलिस अवेलेबिलिटी ज़ोन डाउन होता है, सैन फ्रांसिस्को भी डाउन होता है। तो
इस केस में हम रीजन को ही स्विच कर देंगे। और इस केस में अब यह डीएनएस लोड बैलेंसर एपीआई गेटवे बी के IPपी एड्रेस को देगा और
फिर हमारी एक नई hटीtp रिक्वेस्ट ट्रिगर होगी जो जाएगी इस एपीआई गेटवे बी के पास। तो ऐसे हमारे एपीआई गेटवे और लोड बैलेंसर
काम करते हैं। बेसिकली हमने इन एपीआई गेटवेज के पब्लिक आईपीस को यूज़ किया और हमने हमारी रिक्वेस्ट को डिफरेंट-डिफरेंट
रीजंस में डिफरेंट-डिफरेंट अवेलेबिलिटी ज़ोन में राउट किया। तो अब जो हमारा पहला क्वेश्चन था कि एपीआई गेटवे सिंगल एंट्री
पॉइंट है। तो ये कैसे मिलियंस ऑफ यूज़र्स की रिक्वेस्ट को हैंडल करता है? तो यस इट इज़ अ सिंगल एंट्री पॉइंट क्योंकि इसके
पीछे हमारी थाउजेंड्स ऑफ माइक्रो सर्विसेस हो सकती हैं। बट स्टिल इट इज़ इट कैन ईज़ली मैनेज
ट्रैफिक और इट कैन ईज़ली मैनेज मिलियंस ऑफ़ यूज़र्स रिक्वेस्ट। कैसे? क्योंकि यहां पे हमारा लोड बैलेंसर आ गया। हमारे पास
डीएनएस बेस्ड लोड बेस्ड लोड बैलेंसर है। तो एक ही एपीआई गेटवे पे हम कंप्लीटली ट्रैफिक को मूव नहीं करेंगे। हम रीजन वाइज़
जाएंगे। लेट्स से इफ समवन इज़ फ्रॉम इंडिया तो हम इंडिया के क्लोज वाले रीजन में उस यूजर की रिक्वेस्ट को राउट करेंगे। तो ऐसे
रीजन वाइज़ हम एपीआई गेटवेज़ को कॉन्फ़िगर करेंगे और एपीआई गेटवे ईजीली मिलियंस ऑफ यूज़र्स को हैंड उनकी रिक्वेस्ट को हैंडल
कर लेगा। सो दिस इज़ अबाउट एपीआई गेटवे। और जो हमारा सेकंड क्वेश्चन कि व्हिच कम्स फर्स्ट। तो यस डीएनएस बेस्ड लोड बैलेंसर
कम्स फर्स्ट और फिर उसके बाद हमारे आते हैं एपीआई गेटवे। तो आई थिंक दिस इज़ इनफ फॉर दिस वीडियो। और
अब आपको समझ आ गया होगा कि कैसे हम डीएनएस बेस्ड लोड बैलेंसर की मदद से ट्रैफिक को डिफरेंट रीजंस में स्विच कर सकते हैं।
लेट्स से हमारा एक कंप्लीट रीजन ही डाउन हो गया। तो हम ट्रैफिक को किसी दूसरे रीजन में स्विच कर सकते हैं। तो डीएनए स्लोड
बैलेंसर हमें इसमें हेल्प करता है और हम इससे लेटेंसी भी रिड्यूस कर सकते हैं। लेट्स से कि हमारा ह्यूज ट्रैफिक इज़ कमिंग
फ्रॉम इंडिया। तो हम क्लोजेस्ट पॉसिबल रीजन में यूज़र्स की रिक्वेस्ट को राउट कर देंगे। एंड देन वी कैन रिड्यूस द लेटेंसी
ऑफ़ आवर सिस्टम। सो दिस इज ऑल फॉर दिस वीडियो एंड वी विल सी यू इन द नेक्स्ट वीडियो और नेक्स्ट वीडियो में हम बात
करेंगे लोड बैलेंसर के डिफरेंट टाइप्स की और कुछ लोड बैलेंसर बैलेंसिंग एल्गोरिदम्स की। सो यस दिस इज़ ऑल फॉर दिस वीडियो। वी
विल सी यू इन द नेक्स्ट वीडियो। सो टिल देन बय शो सम लव। थैंक्स। [संगीत]
हे एवरीवन, वेलकम बैक। वेलकम टू दिस अल्टीमेट सिस्टम डिज़ाइन प्लेलिस्ट सीरीज। तो, यह वीडियो इस सीरीज का तीसरा वीडियो
होने वाला है। और इस वीडियो में हम देखेंगे लोड बैलेंसिंग, इट्स टाइप्स एंड सम ऑफ़ द लोड बैलेंसिंग एल्गोरिदम्स। तो,
स्टार्ट करते हैं और एक बार डिस्कस करते हैं कि इससे पिछले लेक्चर में हमने क्या-क्या डिस्कस किया। तो, लास्ट लेक्चर
में हमने देखा एपीआई गेटवे वर्सेस लोड बैलेंसर। और साथ ही साथ हमने देखे कुछ इंपॉर्टेंट क्वेश्चंस जैसे कि इफ एपीआई
गेटवे इज़ अ सिंगल एंट्री पॉइंट देन हाउ डस इट हैंडल मिलियंस ऑफ रिक्वेस्ट और हमने देखा कि एक रियल वर्ल्ड प्रोजेक्ट में
रियल वर्ल्ड एप्लीकेशन में पहले एपीआई गेटवे आता है या लोड बैलेंसर? तो हमने ये सारे क्वेश्चंस लास्ट लेक्चर में डिस्कस
किए। तो लास्ट लेक्चर से आपको लोड बैलेंसिंग का एक ब्रीफ आईडिया लग गया होगा कि यह क्या चीज है? यह कैसे काम करता है।
तो इस लेक्चर में हम देखते हैं इसे थोड़ा डेप्थ में। हम इसके कुछ टाइप्स को समझते हैं। हम लोड बैलेंसिंग को अचीव करने की
कुछ एल्गोरिदम्स देखते हैं। तो स्टार्ट करते हैं और देखते हैं एक बार कि लोड बैलेंसिंग होता क्या है? तो जैसा कि हमने
डिस्कस किया था पिछले कुछ लेक्चर्स में कि हम हमारी माइक्रो सर्विसेस को इंडिविजुअली स्केल कर सकते हैं। लेट्स से कि हमारे पास
हमारा कोई लेट्स से चैटिंग एप्लीकेशन है तो वहां पे हमारे पास एक चैट सर्विस होगी। तो हमारे पास यहां पे एक चैट सर्विस होगी।
तो अब हम इस चैट सर्विस को इंडिविजुअली स्केल कर सकते हैं। और इसे इंडिविजुअली स्केल करने की नीड क्या है? कि लेट्स से
हमारी जो चैट सर्विस पे है उस पे काफी सारा ट्रैफिक आने लग गया। तो उसकी वजह से क्या होगा कि हमारा सिस्टम स्लो हो सकता
है। तो हम क्या कर सकते हैं कि हम इस चैट सर्विस को इंडिविजुअली स्केल कर सकते हैं। इंडिविजुअ इंडिविजुअली स्केल करने का मतलब
क्या है? कि हम इसे हॉरिजॉन्टली स्केल कर सकते हैं। हम एक नई चैट सर्विस नई चैट सर्विस का इंस्टेंस बना सकते हैं।
लेट्स से ये हो गया हमारा चैट सर्विस का फर्स्ट इंस्टेंस। यह हो गया हमारा चैट सर्विस का सेकंड इंस्टेंस।
तो बेसिकली हमने क्या किया कि पहले हमारी जो चैट सर्विस थी वो एक सर्वर पे चल रही थी। अब हमने उसे उसके लिए चैट सर्विस के
लिए एक और सर्वर बढ़ा बढ़ा दिया। तो हमने बेसिकली हमारी चैट सर्विस को हॉरिजॉन्टली स्केल कर दिया। तो ये हमने देखा था कि हम
हमारी सर्विस को इंडिविजुअली स्केल कर सकते हैं। अब हम कैसे डिसाइड करेंगे कि यूजर की रिक्वेस्ट को हमें किस चैट सर्विस
के इंस्टेंस पे राउट करना है। लेट्स से कि ये एक यूजर है और इस यूजर को एक मैसेज भेजना। लेट्स से कि यह यूजर ए है और हमारे
पास यह यूजर बी है। तो लेट्स से कि इस यूजर ए को एक मैसेज भेजना है यूजर बी को M1 मैसेज। तो अब क्या यह यूजर ए डायरेक्ट
इस यूजर बी को मैसेज भेज सकता है? नहीं भेज सकता। तो इन दोनों के कम्युनिकेशन के लिए हमें एक सर्वर की नीड पड़ेगी। तो यह
हमारा एक सर्वर हो गया। और यह हमारा सर्वर हमारी चैट सर्विस को मैनेज कर रहा है। तो बेसिकली हम कह सकते हैं कि यह हमारी एक
चैट सर्विस है। तो हमें इन दोनों के कम्युनिकेशन के लिए एक चैट सर्विस या एक सर्वर की नीड है। तो इनका कम्युनिकेशन
कैसे होगा कि सबसे पहले यह यूजर ए इस M1 मैसेज को इस सर्वर को देगा और उसको बताएगा कि मुझे इस मैसेज को यूजर बी को पहुंचाना
है। तो यह सर्वर इस मैसेज को यूजर बी को दे देगा। तो ऐसे करके इनका कम्युनिकेशन होगा। अब बेसिकली कहने का
मतलब यह है कि इस यूजर ए को यदि यूजर बी को मैसेज भेजना है तो उसको वाया सर्वर जाना पड़ेगा। मतलब उसे पहले इस सर्वर को
मैसेज देना पड़ेगा। तो इस सर्वर को मैसेज देना पड़ेगा। और अब हमने देखा कि हमारे पास चैट सर्विस के मल्टीपल इंस्टेंसेस
हैं। लेट्स से एक हमारे पास ये चैट सर्विस का फर्स्ट इंस्टेंस है चैट वन और एक हमारे पास ये सेकंड इंस्टेंस है और ये हमारा
यूजर ए है। इसको मैसेज भेजना है लेट्स से M1 मैसेज भेजना है यूजर बी को। तो यहां पे लेट्स से
हमारा हो गया यूजर बी। तो अब कैसे हम डिसाइड करेंगे कि इस यूजर की रिक्वेस्ट को इस यूजर ए की रिक्वेस्ट को किस किस
माइक्रो सर्विस इंस्टेंस पे भेजना है या किस सर्वर पे भेजना है। तो उसके लिए हमारा आता है लोड बैलेंसर। यह लोड बैलेंसर
बेसिकली क्या करता है? यह हमारे ट्रैफिक को डिस्ट्रीब्यूट कर देता है टू मल्टीपल माइक्रो सर्विस इंस्टेंसेस।
यह हेल्थ चेक करता है कि कौन सी हमारी माइक्रो सर्विस इंस्टेंस एक्टिव है, एक्टिव नहीं है और यह ट्रैफिक को देखता है
कि कौन सी माइक्रो सर्विस इंस्टेंस ट्रैफिक ले रही है और कौन सी माइक्रो सर्विस इंस्टेंस ट्रैफिक लेने के लिए
अवेलेबल है। तो ये सारे पैरामीटर्स के बेसिस पे ये डिसाइड करता है कि यूजर की रिक्वेस्ट को किस माइक्रो सर्विस इंस्टेंस
पे राउट करना है। तो बेसिकली लोड बैलेंसर का क्या काम क्या है? कि यह ट्रैफिक को डिस्ट्रीब्यूट कर देता है अमोंग मल्टीपल
माइक्रो सर्विस इंस्टेंसेस। तो, यह यूजर रिक्वेस्ट करेगा एक पोस्ट रिक्वेस्ट और यह बोलेगा कि मुझे इस M1 मैसेज को यूजर बी को
भेजना है। तो, यह लोड बैलेंसर क्या करेगा? लेट्स से कि यदि यह चैट टू यह वाला इंस्टेंस हमारा डाउन है या हम कह सकते हैं
कि अभी ट्रैफिक लेने के लिए रेडी नहीं है तो यह लोड बैलेंसर क्या करेगा कि यह इस यूजर ए की रिक्वेस्ट को इस चैट सर्विस वन
इंस्टेंस को दे देगा और फिर यह चैट सर्विस यह वाला सर्वर हमारा इस रिक्वेस्ट को भेज देगा यूजर बी को। तो इसके लिए हम वेब
सॉकेट कम्युनिकेशन यूज़ करते हैं। तो जो कि मैंने हमारे सिस्टम डिज़ाइन प्लेलिस्ट में ऑलरेडी डिस्कस किया है। सो इफ यू वांट टू
लर्न अबाउट वेब सॉकेट कम्युनिकेशन सो आई आई वुड हाइली रिकमेंड यू टू वॉच दोज़ वीडियोस। तो ये इस वीडियो का पार्ट नहीं
है। तो आई एम नॉट डिस्कसिंग वेब सॉकेट कम्युनिकेशन इन डेप्थ। तो ऐसे करके लोड बैलेंसर हमारा अह ट्रैफिक को राउट करने
में हेल्प करता है टू मल्टीपल माइक्रो सर्विस इंस्टेंसेस। तो ये हो गया हमारा लोड बैलेंसर। अब हम
देखते हैं कि हमारे लोड कुछ लोड बैलेंसर के टाइप्स। तो हमारे पास लोड बैलेंसर के दो टाइप्स होते हैं। फर्स्ट होता है L4
लोड बैलेंसर और एक होता है हमारा L7 लोड बैलेंसर। अब ये L4 और L7 क्या है? तो हमने कॉलेज स्टेज में कंप्यूटर नेटवर्क्स
में ओएसआई मॉडल पढ़ा। हमने देखा कि उस ओएसआई मॉडल में हमारे पास सेवन डिफरेंट लेयर्स होती है। पहली हमारा फिजिकल लेयर
होती है। फिर हमारी डेटा लिंक लेयर होती है। हमारे पास नेटवर्क लेयर होती है। हमारे पास ट्रांसपोर्ट लेयर होती है। ये
जो ट्रांसपोर्ट लेयर है वो हमारी फोर्थ लेयर होती है। उसके बाद हमारे पास सेशन लेयर होती है। हमारे पास प्रेजेंटेशन लेयर
होती है। और लास्ट में हमारे पास एक सेवंथ लेयर व्हिच इज़ एप्लीकेशन लेयर। तो यह हमारे पास सेवंथ लेयर एक एप्लीकेशन लेयर
होती है। तो यह हमारे ओएसआई मॉडल में डिफरेंट लेयर्स होती हैं। अब हम हमारे लोड बैलेंस को ये L4 लोड बैलेंसर को और L7 लोड
बैलेंसर को नाम से ही समझ सकते हैं। इस L4 लोड बैलेंसर का मतलब है कि हमारे ओएसआई मॉडल के फोर्थ लेवल पे या फोर्थ लेयर पे
काम करता है। व्हिच इज़ आवर ट्रांसपोर्ट लेयर। तो ये हमारा L4 लोड बैलेंसर ट्रांसपोर्ट लेयर पे काम करता है। और जो
हमारा L7 लोड बैलेंसर है वो इस एप्लीकेशन लेयर पे काम करता है। तो अब एक-एक करके इस इन लोड बैलेंसर्स के टाइप को समझते हैं L4
और L7 को। तो सबसे पहले स्टार्ट करते हैं L4 लोड बैलेंसर से। तो यह जो हमारा L4 लोड बैलेंसर होता है, यह हमारा ट्रांसपोर्ट
लेयर पे काम करता है। ट्रांसपोर्ट लेयर पर काम करता है। और अब हमारे पास ट्रांसपोर्ट लेयर में हमारे पास
दो डिफरेंट प्रोटोकॉल्स होते हैं। हमारे पास एक TCP प्रोटोकॉल होता है। हमारे पास यूडीपी प्रोटोकॉल होता है। तो हम कह सकते
हैं कि हमारा जो ये L4 लोड बैलेंसर है, यह TCP और यूडीपी लेवल पे काम करता है। इसका मतलब यह है कि यह जो हमारा L4 लोड बैलेंसर
है यह HTTP रिक्वेस्ट हेडर्स कि हमने लेट्स से रिक्वेस्ट के साथ कुछ
हेडर पास किया तो यह ना तो HTTP रिक्वेस्ट को समझता है ना हेडर्स को समझता है। यह कुकीज़ को नहीं समझता। यह HTTP पाथ को नहीं
समझता। तो बेसिकली यह जो हमारा L4 लोड बैलेंसर है यह TCP यूडीपी लेवल पर काम करता है। इस
वजह से उसे वो ना तो यह HTTP रिक्वेस्ट HTTP रिक्वेस्ट को रीड कर सकता है ना हेडर्स को रीड कर सकता है ना कुकीज़ को रीड
कर सकता है ना ही HTTP पाथ को रीड कर सकता है। लेट्स से कि हमारे पास एक ऐसा कोई पाथ है सश एपीआई वी1 स्लश ऑर्डर तो ये हमारा
एल4 लोड बैलेंसर इस डेटा को रीड नहीं कर पाएगा तो फिर यह कैसे पता लगाएगा कि हमें यूजर की रिक्वेस्ट को कहां राउट करना है
तो यह एल4 लोड बैलेंसर क्या करता है यह कुछ चीजें नोटिस करता है यह देखता है सोर्स का IP एड्रेस
हमारे सोर्स का या क्लाइंट का IPपी एड्रेस पोर्ट यह देखता है डेस्टिनेशन का IPपी एड्रेस और पोर्ट
और यह देखता है प्रोटोकॉल वेदर इट इज़ अ TCP प्रोटोकॉल और यूडीपी प्रोटोकॉल। तो ये कुछ चीजें हैं जिसके बेसिस पे ये एल4 लोड
बैलेंसर डिसाइड करता है कि यूजर की रिक्वेस्ट को कहां राउट करना है। तो इसको एक एग्जांपल के थ्रू समझते हैं। लेट्स से
कि हमारे पास एक चैटिंग एप्लीकेशन है और उस चैटिंग एप्लीकेशन में हमारे पास एक चैट सर्विस है और उस चैट सर्विस को हमने
हॉरिजॉन्टली स्केल कर दिया। तो अब हमारे पास चैट सर्विस के मल्टीपल इंस्टेंसेस हैं। हमारे पास चैट सर्विस का ये फर्स्ट
इंस्टेंस है, सेकंड इंस्टेंस है एंड थर्ड इंस्टेंस है। और ये तीनों चैट सर्विसेस हमारी डिफरेंट-डिफरेंट सर्वर्स पे रन हो
रही हैं। हमारे पास सर्वर वन है, सर्वर टू है और सर्वर थ्री है। तो इन तीनों सर्वर के अपने-अपने IPपी एड्रेस हैं। राइट? और
हम हमने क्या किया कि हमने इस चैट सर्विस को हर सर्वर में 5000 पोर्ट पे रन किया। तो ये हो गया हमारा चैट सर्विस के बारे
में। अब लेट्स से कि हमारे पास एक क्लाइंट है। ये हमारा क्लाइंट है। तो उस क्लाइंट का भी कुछ IPपी एड्रेस होगा। क्लाइंट
डिवाइस का भी IP एड्रेस होगा। तो लेट्स से ये उसका एक कोई IP एड्रेस है और लेट्स से एक डिफ़ॉल्ट पोर्ट है जो OS ने उसे असाइन
की। अब यहां पे हमारा L4 लोड बैलेंसर है। तो अब देखते हैं कि यह काम कैसे करता है। तो क्लाइंट हमने जैसे देखा कि L4 लोड
बैलेंसर को ट्रैफिक को राउट करने के लिए यह कुछ चीजें कॉन्फ़िगर करता है। उसमें सबसे पहला है
सोर्स IPपी एड्रेस और पोर्ट, डेस्टिनेशन का IP एड्रेस और पोर्ट और TCP और यूडीपी प्रोटोकॉल। तो इनके बेसिस पर यह फाइंड आउट
करता है। अब यह हमारी चैट सर्विस है। तो अब जैसे ही कोई यूजर उस चैटिंग एप्लीकेशन को ओपन करेगा तो यह हमारा क्लाइंट जो है
वह चैट सर्विस के साथ कम्युनिकेशन इस्टैब्लिश करने की कोशिश करेगा। तो बेसिकली हमारी यह रिक्वेस्ट हमारा यह चैट
सर्विस इनवोक होगा। तो अब हमारे पास चैट सर्विस के मल्टीपल इंस्टेंसेस हैं। तो यह लोड बैलेंसर क्या करेगा? सबसे पहले यह
क्लाइंट के IPपी एड्रेस को देखेगा। उसके पोर्ट को देखेगा और उसके बाद यह इस रिक्वेस्ट को लेगा और फिर यह डिसाइड करेगा
कि इनमें से कौन सा माइक्रो सर्विस इंस्टेंस अवेलेबल है, कौन सा डाउन नहीं है। और उसके बाद यह डिसाइड करने के बाद वो
उस डेस्टिनेशन एड्रेस पे लेट्स सेकंड वाले इंस्टेंस पे यह उस यूजर की रिक्वेस्ट को राउट कर देगा। अब उस उस रिक्वेस्ट में कुछ
भी हो सकता है। उस रिक्वेस्ट में हो सकता है कि रूम क्रिएट करो, मैसेज सेंड करो या कोई रूम है ऑलरेडी रूम है उसको जॉइ करो।
तो ऐसे रिक्वेस्ट कुछ भी हो सकती है। पर यह रिक्वेस्ट से यह एल4 लोड बैलेंसर एकदम अनजान है। उसे
यह समझ नहीं आएगा कि यह इसका मतलब क्या है? वह बेसिकली क्या करेगा? यह एल4 लोड बैलेंसर क्लाइंट से रिक्वेस्ट लेगा और कोई
एक डेस्टिनेशन डेस्टिनेशन पे डेस्टिनेशन सर्वर पे रिक्वेस्ट को राउट कर देगा। अब यह चैट सर्विस हैंडल कर लेगा कि इस
रिक्वेस्ट के साथ क्या करना है? हमें क्या कोई नया रूम क्रिएट करना है, मैसेज सेंड करना है या नया रूम जॉइ करना है। तो उस
चैट सर्विस यह डिसाइड कर लेगा। लोड बैलेंसर एल4 लोड बैलेंसर सिर्फ क्या करेगा कि ये कनेक्शन इस्टैब्लिश कर देगा। अ
लेट्स से इस एल4 लोड बैलेंसर ने डिसाइड किया कि ठीक है यूजर की रिक्वेस्ट को मैं इस सर्वर टू पे राउट करूंगा। तो ये यहां
पे एक क्लाइंट का इस सर्वर टू के साथ कम्युनिकेशन इस्टैब्लिश हो जाएगा। लेट्स से TCP कम्युनिकेशन इस्टैब्लिश हो जाएगा।
तो अब ये एलफो लोड बैलेंसर सिर्फ अ पैकेट्स को पैकेट्स को डेटा पैकेट्स को सेंड होते हुए देखेगा। लेट्स से ऐसे कुछ
फॉर्म में जहां वो डेटा को रीड ही नहीं कर पाएगा। तो ये सिर्फ डेटा को डेटा पैकेट्स को सेंड होते हुए देखेगा। और अब ये यूजर
लेट्स से ये जो क्लाइंट है ये हमारा यूजर ए है तो अब इस यूजर ए का बेसिकली इस क्लाइंट का और इस सर्वर टू का टीसीp
कनेक्शन कनेक्शन इस्टैब्लिश हो गया है। तो अब यह यूजर ए कोई भी मैसेज सेंड करेगा तो वह मैसेज हर बार इस चैट सर्विस टू या
सर्वर टू पे जाएगा। जब तक हम कनेक्शन को डिस्ट्रॉय नहीं करते या कनेक्शन को खत्म नहीं करते तो हर बार यह इस यूजर ए की
रिक्वेस्ट जो होगी वो हमेशा इस इस चैट सर्विस टू पे जाएगी। तो यह होता है हमारा एल4 लोड बैलेंसर। तो इस लोड बैलेंसर को हम
कह सकते हैं कि इट्स अ इट्स इट्स लाइक अ पोस्ट ऑफिस क्लर्क हु ओनली लुक्स एट द एनवेलप्स फ्रॉम एड्रेस एंड टू एड्रेस।
मतलब कहां से ये एड्रेस कहां से ये एनवेलप को कहां तक जाना है। एनवेलप के अंदर क्या है? यह एल4 लोड बैलेंसर को उससे कोई मतलब
नहीं है। वो उसे देखेगा नहीं और उसे जानना भी। तो लेट्स से कि हमारे पास एक यूजर है। लेट्स से यूजर ए है और एक हमारे पास यूजर
बी है। अब लेट्स से कि ये यूजर ए है। इसको हाय मैसेज भेजना है इस यूजर बी को। और हमारे पास लेट्स से चैट सर्विस के मल्टीपल
इंस्टेंसेस हैं। हमारे पास एक ये इंस्टेंस है, एक चैट सर्विस टू है और एक चैट सर्विस का हमारे पास थर्ड इंस्टेंस है। तो अब ये
जो हमारा एल4 लोड बैलेंसर होगा वो सिंपली क्या करेगा कि यह सिंपली यूजर ए की रिक्वेस्ट को लेगा। उसको कोई मतलब नहीं है
कि उस रिक्वेस्ट में क्या है। यह सिंपली इसकी रिक्वेस्ट को लेगा। यह इसका पोर्ट और IP एड्रेस देखेगा और फिर यह डिसाइड कर
देगा कि कर लेगा L4 लोड बैलेंसर कि इन तीनों में से कौन से सर्वर से कनेक्ट करना है। यूजर ए का कनेक्शन इस्टैब्लिश करना
है। लेट्स से उसने सर्वर टू को सेलेक्ट किया। तो ये लोड बैलेंसर फोर ने यूजर ए का इस सर्वर टू के साथ TCP कनेक्शन
एस्टैब्लिश कर दिया। अब उसके बाद क्या होगा कि ए यूजर ए जो है यह अपने हाय के मैसेज को भेज सकता है इस इस सबसे पहले इस
चैट सर्विस टू को और फिर चैट सर्विस टू इसे भेज देगा यूजर बी को तो यहां पे इस लोड बैलेंसर फोर को कोई मतलब नहीं है कि
उस मैसेज में क्या था http रिक्वेस्ट जो थी वो क्या थी उससे कोई मतलब नहीं है उसे कोई मतलब नहीं है उस रिक्वेस्ट के पाथ से
हेडर से कुकीज़ से उसने सिंपली पोल पोर्ट लिया और IP एड्रेस लिया इस क्लाइंट का और उसका कनेक्शन इस्टैब्लिश कर दिया विद आवर
वन ऑफ़ विद आवर वन ऑफ़ द सर्वर। तो, यह काम था हमारे लोड बैलेंसर 4 का। अब हमारे पास रिक्वेस्ट कुछ भी हो सकती है। लेट्स से
स्लैश एपीआई V1 क्रिएट रूम क्रिएट रूम या फिर हो सकती है लेट्स से सेंड मैसेज। तो
जो हमारा लोड बैलेंसर फोर है उनको इनसे कुछ मतलब नहीं है कि इस रिक्वेस्ट में इन रिक्वेस्ट में क्या है उसको इससे कुछ मतलब
नहीं है। वह सिंपली यूजर ए का कनेक्शन एस्टैब्लिश कर देगा इस सर्वर के साथ या कोई भी सर्वर के साथ चैट चैट सर्विस के
सर्वर के साथ और उसके बाद हमारे चैट सर्विस में ऑब्वियसली लॉजिक होगा इन केसेस को हैंडल करने का। एक नए रूम को क्रिएट
करने का, एक मैसेज को सेंड करने का। तो हमारे पास चैट सर्विस में यह लॉजिक इंप्लीमेंटेड होगा। तो ये सारी चीजें
होंगी वो हैंडल कर लेगा यह हमारा चैट सर्विस। हमारा लोड बैलेंसर फोर जो है वो सिंपली कनेक्शन एस्टैब्लिश कर देगा इस
यूजर और अह वन ऑफ़ द सर्वर के बीच में। तो यह होता है हमारा लोड बैलेंसर फोर। अब हम देखते हैं हमारा सेकंड टाइप वि इज आवर लोड
बैलेंसर L7 लोड बैलेंसर। तो यह हमारा L7 लोड बैलेंसर एप्लीकेशन
लेयर पर काम करता है। और एप्लीकेशन लेयर में हमारे पास डिफरेंट प्रोटोकॉल्स होते हैं। हमारे पास HTTP प्रोटोकॉल होता है।
हमारे पास HTTPS है। हमारे पास वेब सॉकेट्स हैं। तो ये जो L7 लोड बैलेंसर है, ये एप्लीकेशन लेयर पे काम करता है। और उस
लेयर में हमारे पास HTTP प्रोटोकॉल है। हमारे पास HTTPS है। हमारे पास वेब सॉकेट्स हैं। तो, हमारे पास ऐसे डिफ़ेंट
प्रोटोकॉल्स हैं। तो, हम कह सकते हैं कि जो हमारा L7 लोड बैलेंसर है, वह इस HTTP को भी समझता है। HTTP को HTTPS को भी
समझता है। वेब सॉकेट्स कनेक्शन को भी समझता है। जो कि हमने नहीं देखा था L4 लोड बैलेंसर में। वो ना HTTP को समझ पा रहा
था, ना इसके हेडर्स को, कुकीज़ को, एचटीटीp पाथ को। तो वो ये सारी चीजें वहां पे नहीं समझ पा रहा था। लेकिन ये जो L7 लोड
बैलेंसर है ये एप्लीकेशन लेयर पे काम करता है और एप्लीकेशन लेयर में हमारे पास ये डिफरेंट प्रोटोकॉल्स हैं। तो हम कह सकते
हैं कि जो हमारा L7 लोड बैलेंसर है वो इस HTTP रिक्वेस्ट को भी समझेगा, HTTPS को भी समझेगा और वेब सॉकेट्स को भी समझेगा। तो
ऐसे हम कुछ रिक्वेस्ट करेंगे। लेट्स से हमें कोई रूम जॉइ करना है तो हम उसकी बॉडी में यह सेंड कर देंगे। पहले क्या हो रहा
था कि हम अह हमारा L4 लोड बैलेंसर के बॉडी में क्या जा रहा है? रिक्वेस्ट का पाथ क्या है? तो वह यह सब कुछ नहीं समझ रहा
था। लेकिन L7 लोड बैलेंसर इज़ स्मार्ट इनफ टू अंडरस्टैंड द पाथ द बॉडी। तो ये होता है हमारे L7 लोड बैलेंसर में। अब क्या
होगा कि लेट्स से हमारे पास एक यूजर है और एक हमारा यूजर है। वो लेट्स से अ अपनी प्रोफाइल को अपडेट करना चाहता है। तो
हमारे पास ऐसे मल्टीपल माइक्रो सर्विसेस होंगी। हमारे पास एक चैट की सर्विस हो सकती है और उसके हमारे पास मल्टीपल
इंस्टेंसेस हो सकते हैं। लेट्स से चैट वन एंड चैट टू। हमारे पास यूजर सर्विस हो सकती है। और इस यूजर सर्विस के हमारे पास
मल्टीपल इंस्टेंसेस हो सकते हैं। लेट्स से यूजर वन एंड यूजर टू। तो ये हमारे पास ऐसे डिफरेंट-डिफरेंट माइक्रो सर्विसेस के
मल्टीपल इंस्टेंसेस हैं। अब यूजर रिक्वेस्ट करेगा बेसिकली वो एक एपीआई एंड पॉइंट ट्रिगर करेगा। लेट्स से स्लैश एपीआई
V1 अपडेट प्रोफाइल ऐसा कुछ एक एपीआई एंड पॉइंट वो ट्रिगर करेगा। तो अब यहां पे रिक्वेस्ट को यूजर की रिक्वेस्ट
को कहां राउट करना है? तो इसके लिए हमारे पास एक लोड बैलेंसर सेवन है। तो यह लोड बैलेंसर से हमने देखा
L7 को कि लोड लोड बैलेंसर L7 जो है वो इस एपीआई रिक्वेस्ट को समझ सकता है। HTTP रिक्वेस्ट को समझ सकता है। http रिक्वेस्ट
के पाथ को समझ सकता है कि यह पाथ हमें कहां ले जा रहा है। यह हेडर्स को समझ सकता है। यह कुकीज़ को समझ सकता है। तो ऐसे ये
बेसिकली रिक्वेस्ट को समझ सकता है। तो जैसे ही इस लोड बैलेंसर सेवन को रिक्वेस्ट मिलेगी वो समझ जाएगा कि ठीक है आई हैव टू
इनवोक वन ऑफ़ द यूजर सर्विस इंस्टेंसेस। अब हमारे पास यहां पे दो यूजर सर्विस के इंस्टेंस हैं। तो वो चेक कर लेगा कि कौन
सा अवेलेबल है थ्रू सर्विस डिस्कवरी। तो वो चेक कर लेगा कि अच्छा ठीक है यूजर टू इंस्टेंस है। ये लेट्स से अवेलेबल है। ये
वाला अभी अवेलेबल है और ये वाला लेट्स से अभी डाउन है या हम कह सकते हैं ऑलरेडी ट्रैफिक ले रहा है। तो ये लोड L7 लोड
बैलेंसर यूजर की रिक्वेस्ट को राउट कर देगा टू दिस माइक्रो सर्विस इंस्टेंस। तो ये होता है हमारा L7 लोड बैलेंसर। दोनों
में हमने डिफरेंस भी डिस्कस कर लिया। अब देखते हैं हम कुछ लोड बैलेंसिंग एल्गोरिदम्स को। तो हमारे पास लोड
बैलेंसिंग की दो एल्गोरिदम्स होती हैं। फर्स्ट होती है हमारे पास स्टैटिक एल्गोरिदम।
स्टैटिक एल्गोरिदम। अब इस स्टैटिक एल्गोरिदम में हमारे पास आ जाती है राउंड रबिन।
हमारे पास राउंड रबिन आ जाती है। हमारे पास आ जाती है वेटेड राउंड रबिन। हमारे पास यहां आ गई वेटेड राउंड रबिन।
और एक हम डिस्कस कर सकते हैं IP#श IP#श तो ये हमारी कुछ लोड बैलेंसिंग की स्टैटिक
एल्गोरिदम्स हैं और डायनेमिक एल्गोरिदम्स में हमारे पास डायनेमिक एल्गोरिदम्स में हमारे पास आ
जाती है लीस्ट कनेक्शन हमारे पास आ जाती है वेटेड लीस्ट कनेक्शन
अह लीस्ट कनेक्शन हमारे पास आ जाती है एक और डायनेमिक एल्गोरिदम वेटेड लीस्ट लीस्ट कनेक्शन
कनेक्शन वेटेड लीस्ट कनेक्शन और एक हमारे पास आ जाती है
लीस्ट रिस्पांस टाइम लीस्ट रिस्पांस टाइम तो ये कुछ हमारी लोड बैलेंसिंग की
एल्गोरिदम्स हैं हमारे पास स्टैटिक एल्गोरिदम्स भी हैं। हमारे पास डायनेमिक एल्गोरिदम्स भी हैं। तो सबसे पहले हम
डिस्कस करते हैं सम ऑफ दी स्टैटिक एल्गोरिदम्स। तो सबसे पहले आती है हमारे पास राउंड रॉबिन। तो हम सेम एग्जांपल लेते
हैं। लेट्स से हमारे पास डिफरेंट यूज़र्स हैं। लेट्स से ये U1 यूजर हो गया। ये हमारे पास U2 यूजर हो गया। हमारे पास ऐसे
ही और दो और यूजर हैं। लेट्स से U3 एंड U4। U3 एंड U4। तो अब क्या होगा कि हमारे पास लेट्स से एक चैटिंग चैट सर्विस
है चैटिंग एप्लीकेशन है बेसिकली तो उस चैट सर्विस के हमारे पास मल्टीपल इंस्टेंसेस हो सकते हैं। तो लेट्स से हमारे पास इस
चैट सर्विस के दो इंस्टेंसेस हैं चैट वन एंड चैट टू। अब यहां पे आ जाएगा हमारा लोड बैलेंसर। तो अब यह लोड बैलेंसर क्या
करेगा? इन यूज़र्स की रिक्वेस्ट को लेगा। लेट्स से यह यूजर की रिक्वेस्ट को लेगा। यूजर टू की रिक्वेस्ट को लेगा। यूजर थ्री
की रिक्वेस्ट को लेगा एंड यूजर फोर की रिक्वेस्ट को लेगा। तो अब यह कैसे डिसाइड करेगा कि यूजर की रिक्वेस्ट को कौन से
यूजर की रिक्वेस्ट को कहां राउट करना है या कहां पे ट्रैफिक को डिस्ट्रीब्यूट करना है? ट्रैफिक को कैसे डिस्ट्रीब्यूट करना
है? तो उसके लिए हमारी फर्स्ट एल्गोरिदम है व्हिच इज़ राउंड रॉबिन। तो राउंड रॉबिन में क्या होगा? लेट्स से कि इस यूजर वन की
रिक्वेस्ट को हमने नाम दे दिया फर्स्ट रिक्वेस्ट। सेकंड, थर्ड एंड दिस इज़ फोर्थ रिक्वेस्ट। तो राउंड रॉबिन में क्या होता
है? है लोड बैलेंसर फर्स्ट यूजर की रिक्वेस्ट को लेट्स से इसने इस इंस्टेंस पे राउट कर दिया चैट वन
पे जो सेकंड रिक्वेस्ट आई उसको यहां राउट कर दिया फिर जो थर्ड रिक्वेस्ट आई उसको यहां राउट कर दिया फोर्थ रिक्वेस्ट आई
उसको यहां राउट कर दिया अब लेट्स से कोई दो और नई रिक्वेस्ट आती हैं लेट्स से फिफ्थ और सिक्स्थ तो यह फिफ्थ को इसने
यहां राउट कर दिया और सिक्स्थ को यहां राउट कर दिया तो बेसिकली अह यह जो हमारी एल्गोरिदम है। राउंड रबिन एल्गोरिदम है।
यह इक्वली इक्वली ट्रैफिक को डिस्ट्रीब्यूट कर रही है। एक यूजर की रिक्वेस्ट को इस इंस्टेंस पे दूसरे यूजर
की रिक्वेस्ट को इस इंस्टेंस पे ऐसे करके यह इक्वली ट्रैफिक को डिस्ट्रीब्यूट कर रही है। लेकिन अब इसमें प्रॉब्लम क्या हो
सकती है कि लेट्स से यह जो हमारी चैट सर्विस थी बेसिकली ये हमारी जो चैट सर्विस है यह एक दूसरे सर्वर पे है और यह भी एक
दूसरे सर्वर पे है। तो अब यहां पे प्रॉब्लम क्या आ सकती है कि लेट्स से ये वाला जो हमारा सर्विस है सर्वर है ये काफी
स्ट्रांग है। इसकी कैपेसिटी बहुत ज्यादा है। इसमें हमने मल्टीपल सीपीयूस यूज़ किया। हमने इसमें मेमोरी भी ज्यादा यूज़ की। तो
हम कह सकते हैं कि ये वाला ये वाला हमारा जो सर्वर है ये बहुत पावरफुल सर्वर है और ये वाला जो सर्वर है ये उतना पावरफुल नहीं
है। तो अब इसमें प्रॉब्लम क्या आ रही है कि ये सर्वर जो है इसकी कैपेसिटी तो ज्यादा है। इसमें हमने ज्यादा सीपीयू यूज़
किए। ज्यादा हमने मेमोरी यूज़ की। तो इसकी कैपेसिटी कैपेसिटी ज्यादा है। इसका मतलब क्या है कि ये ज्यादा नंबर ऑफ रिक्वेस्ट
को हैंडल कर सकता है। राइट? लेकिन हम राउंड रबिन में क्या कर रहे हैं? हम ट्रैफिक को इक्वली डिस्ट्रीब्यूट कर रहे
हैं। हम एक यहां भेज रहे हैं। एक हम यहां भेज रहे हैं। फिर हम यहां भेज रहे हैं। फिर यहां भेज रहे हैं। ऐसे हम ट्रैफिक को
इक्वली डिस्ट्रीब्यूट कर रहे हैं। तो अब जब हमारे इस ये वाले सर्वर की कैपेसिटी ज्यादा है तो हम इसकी कैपेसिटी को सही से
यूटिलाइज ही नहीं कर पा रहे हैं। हम कह सकते हैं कि हमारी इस सर्वर की कैपेसिटी वेस्ट हो जा रही है। क्योंकि इसकी
कैपेसिटी है लेट्स से 100 रिक्वेस्ट को हैंडल करने की। लेकिन हम सिर्फ पांच यहां कर दे रहे हैं और पांच यहां कर दे रहे
हैं। तो इसकी वजह से क्या हो रहा है कि हम इस इस वाले सर्वर को सही से यूटिलाइज नहीं कर पा रहे हैं। तो ये एक प्रॉब्लम आती है
हमारे राउंड रॉबिन एल्गोरिदम में। अब इस प्रॉब्लम को कौन सॉल्व करता है? तो इस प्रॉब्लम को सॉल्व करता है हमारा
वेटेड राउंड रॉबिन। वेटेड राउंड
रॉबिन। तो अब वेटेड राउंड रबिन में क्या होता है? अगेन लेट्स से सेम एग्जांपल। हमारे पास
चार यूज़र्स हैं। एक हमारे पास U1 है, U2 है, हमारे पास U3 है और एक हमारे पास यूजर फोर है। अब ये हमारे पास चार यूज़र्स हैं
और हमारे पास सेम दो चैट सर्विस के इंस्टेंस हैं। एक हमारे पास चैट वन है और एक चैट टू है। अब वेटेड राउंड रॉबिन में
क्या होता है कि हम इन सर्वर्स को इन सर्वर्स को हम कुछ वेट असाइन कर देते हैं। लेट्स से इसको हमने वेट असाइन कर दिया।
इसको हमने वेट असाइन कर दिया थ्री। इसको हमने वेट असाइन कर दिया थ्री। और इसको हमने वेट असाइन कर दिया
वन। लेट्स से वन वेट असाइन कर दिया। तो अब ये कैसे काम करेगा? अब रिक्वेस्ट कैसे आएंगी? लेट्स से इस यूजर ने रिक्वेस्ट की।
इस यूजर ने रिक्वेस्ट की। इसने रिक्वेस्ट की और ये U4 ने रिक्वेस्ट की। तो अब क्या हो गया कि इस चैट सर्विस को हमने क्या
किया? हमने वेट असाइन कर दिया थ्री। वेट या हम इसे कह सकते हैं इसकी कैपेसिटी हमने डिफाइन कर दी थ्री। तो क्या होगा कि
फर्स्ट थ्री रिक्वेस्ट जो हैं हमारी अब वो जाएंगी इस चैट सर्विस वन के पास। लेट्स से फर्स्ट रिक्वेस्ट, सेकंड रिक्वेस्ट और
थर्ड रिक्वेस्ट। उसके बाद जो फोर्थ रिक्वेस्ट होगी वो हमारी जाएगी इस चैट सर्विस टू के पास। तो यह हमारी फोर्थ
रिक्वेस्ट यहां गई। अब लेट्स से फिर से कोई नई चार सर्विसेज चार रिक्वेस्ट आती हैं। लेट्स से फिफ्थ रिक्वेस्ट, सिक्स्थ,
सेवंथ एंड एट्थ रिक्वेस्ट। तो अब क्या होगा? फिफ्थ, सिक्स्थ और सेवंथ रिक्वेस्ट जो होगी वो जाएगी इस चैट सर्विस वन के पास
और एट्थ रिक्वेस्ट होगी वो जाएगी इस चैट सर्विस टू के पास। तो, यह होता है हमारा वेटेड राउंड रॉबिन। और अब हमने इसमें
राउंड रॉबिन की प्रॉब्लम को सॉल्व कर दिया। राउंड रबिन में क्या हो रहा था हम कि हम जो हमारा स्ट्रांग सर्वर या पावरफुल
सर्वर है हम उसकी कैपेसिटी को यूज़ नहीं कर पा रहे थे। लेकिन इसमें हमने वेट असाइन करके हमारे स्ट्रांग कंप्यूटर को या
पावरफुल कंप्यूटर को वेट असाइन करके ज्यादा वेट असाइन करके राउंड रॉबिन की प्रॉब्लम को सॉल्व कर दिया। लेकिन अब एक
प्रॉब्लम वेटेड राउंड रॉबिन में भी आती है। लेट्स से कि यह हमारे पास चार रिक्वेस्ट आई। फर्स्ट, सेकंड, थर्ड और
फोर्थ रिक्वेस्ट। तो अब ऐसा हो सकता है कि लेट्स से यह वाली जो रिक्वेस्ट थी यह सिर्फ 10 से 10 10 मिली सेकंड में कंप्लीट
हो जा रही है। यह भी 10 मिली सेकंड में यह भी 10 मिलीसे में। तो फर्स्ट, सेकंड एंड थर्ड रिक्वेस्ट फर्स्ट,
सेकंड एंड थर्ड रिक्वेस्ट मिला के टोटल 30 मिलीसे में यह एग्जीक्यूट हो जा रही हैं। लेकिन लेट्स से कि जो हमारी फोर्थ
रिक्वेस्ट थी वो अकेले ही 10 सेकंड ले रही है। 10 सेकंड ले रही है। और अभी यह वाली हमारी रिक्वेस्ट किसके पास गई थी? अह जो
हमारा कम पावरफुल कंप्यूटर है, कम पावरफुल सिस्टम है, यह रिक्वेस्ट उसके पास गई थी। चैट टू के पास
और यह वाली कहां पे गई थी? हमारी स्ट्रांग कंप्यूटर के पास गई थी। स्ट्रांग सर्वर के पास गई थी। व्हिच इज़ आवर चैट वन। तो अब हम
इसमें भी देख सकते हैं कि हम इस वाले पे क्योंकि ये 10 सेकंड ले रही है। फिर लेट्स से कि एक एट्थ रिक्वेस्ट आ गई हमारी वो भी
10 सेकंड ले रही है। तो हम दे देख सकते हैं कि इस पे इस जो हमारा जो कम पावरफुल कंप्यूटर है उस पे फिर से हमारा लोड बढ़
जाएगा। तो ये एक प्रॉब्लम आती है हमारे वेटेड राउंड रबिन में। तो ये थी हमारी सेकंड एल्गोरिदम लोड बैलेंसिंग एल्गोरिदम।
अब जो हमारी थर्ड लोड बैलेंसिंग एल्गोरिदम है वो है IP#श IP#श
तो अब IP#श में क्या होता है कि लेट्स से हमारे पास सेम एग्जांपल हम लेते हैं सो दैट इट वुड बी इजी फॉर यू टू अंडरस्टैंड
हमारे पास चार यूजर हैं। हमारे पास U1 है, U2, U3 एंड वी हैव U4। अब ये चार यूज़र्स हैं और ये चारों यूज़र्स एक चैटिंग
एप्लीकेशन यूज कर रहे हैं। तो बेसिकली वो या तो मोबाइल से यूज कर रहे होंगे या लैपटॉप से। तो उस मोबाइल या लैपटॉप का
डिवाइस का एक अपना IPपी एड्रेस होगा। तो हम बोल सकते हैं कि ये जो हमारे चारों यूज़र्स हैं इनके जो डिवाइस हैं या बेसिकली
कह सकते हैं कि हमारे जो क्लाइंट हैं इनके अपने-अपने IPपी एड्रेसेस होंगे। राइट? ये रिक्वेस्ट जाएगी लोड बैलेंसर के पास।
अब लोड बैलेंसिंग में हम क्या कर सकते हैं कि हम एक हैश फंक्शन को इनके IPपी एड्रेसेस देंगे। चारों क्लाइंट के या
चारों यूज़र्स के जो डिवाइस है उसके IPपी एड्रेस देंगे। और ये हैश हैश फंक्शन क्या करेगा कि एक हैश वैल्यू निकालेगा उससे।
दिस हैश वैल्यू कैन बी एनीथिंग। लेट्स से 1 2 3 4 तो ऐसे एक हमारे पास हैश वैल्यू मिल जाएंगी। अब सेम हमारे पास चैट सर्विस
वन है। हमारे पास चैट सर्विस टू है। चैट सर्विस वन है और चैट सर्विस टू है। तो क्या होगा कि हमारे हैश वैल्यू के
अकॉर्डिंग हम रिक्वेस्ट को राउट कर देंगे टू करेक्ट माइक्रो सर्विस इंस्टेंस। लेट्स से हैश वैल्यू यदि हमारी वन आ रही है तो
हम सारी रिक्वेस्ट को राउट करेंगे इसमें। हमारे पास यदि हैश वैल्यू आ रही है टू तो हम रिक्वेस्ट को राउट करेंगे इस वाले
इंस्टेंस पे। तो ऐसे करके हम डिपेंड्स ऑन हैश वैल्यू हम यूज़र्स की रिक्वेस्ट को राउट करेंगे। अब इसमें एक प्रॉब्लम यह आती
है कि यदि लेट्स से हमने लोड बैलेंसर के पहले एक प्रॉक्सी कॉन्फ़िगर किया। लेट्स से हमने यहां पे एक प्रॉक्सी कॉन्फ़िगर किया।
यह हमारा एक प्रॉक्सी है। प्रॉक्सी हम नेक्स्ट वीडियो में डिस्कस करेंगे। सो, डोंट वरी अबाउट दैट। तो, लेट्स से एक
हमारा यहां पे प्रॉक्सी है। अब इस प्रॉक्सी सर्वर का एक अपना IP एड्रेस होगा। राइट? तो अब यदि हमने इन इस लोड
बैलेंसर और यूज़र्स के क्लाइंट के बीच में एक प्रॉक्सी सर्वर लगा दिया तो इस लोड बैलेंसर को ऐसा लगेगा कि सारी रिक्वेस्ट
जो है वो एक ही सोर्स से आ रही हैं। राइट? इस प्रॉक्सी सर्वर से आ रही हैं। तो अब इस केस में हमारे यूज़र्स तो ये चार यूज़र्स या
चारों क्लाइंट तो अलग-अलग थे। लेकिन लोड बैलेंसर को लगेगा कि ये जो सारी रिक्वेस्ट हैं ये आ रही हैं केवल एक सर्वर से
प्रॉक्सी सर्वर से केवल एक सोर्स से। तो इस केस में क्या होगा कि हमारी हैश वैल्यू हमेशा हमेशा सेम आएगी। जब हम हैश फंक्शन
को IP एड्रेस देंगे तो हमारी हैश वैल्यू हमेशा सेम आएगी। तो हमेशा हैश वैल्यू सेम आएगी। तो हमारा लेट्स से हैश वैल्यू हमारी
वन आ रही है। तो इस केस में ये लोड बैलेंसर क्या करेगा? हर रिक्वेस्ट को सिर्फ इस इंस्टेंस पे ही राउट करेगा। हर
रिक्वेस्ट को सिर्फ इस इंस्टेंस पे ही राउट करेगा। तो ये होती है हमारी थर्ड एल्गोरिदम थर्ड लोड बैलेंसिंग
एल्गोरिदम और ये हमारा कंप्लीट होता है यहां पे स्टैटिक एल्गोरिदम्स हमने जिसमें राउंड रबिन कवर किया हमने वेटेड राउंड
रॉबिन देखा और हमने IP#श देखा। अब जो हमारी नेक्स्ट एल्गोरिदम्स हैं वो हैं डायनेमिक एल्गोरिदम्स जिसमें आती है हमारी
लीस्ट कनेक्शन वेटेड लीस्ट कनेक्शन और एक हमारी आती है लीस्ट रिस्पांस टाइम। तो एक-एक करके इनको समझते हैं। तो जो हमारी
पहली डायनेमिक एल्गोरिदम है वो है लीस्ट कनेक्शन। तो लीस्ट कनेक्शन में हमारे पास क्या होगा? लेट्स से सेम एग्जांपल हम
कंसीडर करते हैं। लेट्स से हमारे पास चार डिफरेंट यूज़र्स हैं। U1, U2, U3, U4 एंड हमारे पास अह दो चैट सर्विसेस के इंस्टेंस
हैं। चैट सर्विस वन एंड चैट सर्विस टू। तो अब इसमें लीस्ट कनेक्शन में हम क्या करते हैं कि लेट्स से ये जो हमारा यूजर वन है
और जो यूजर टू है ये ऑलरेडी इस चैट सर्विस वन से चैट सर्विस वन इंस्टेंस से कनेक्टेड है। बेसिकली इनका टीसीp कनेक्शन ऑलरेडी
इस्टैब्लिश्ड है। तो यह जो हमारे यूजर वन और यूजर टू है यह ऑलरेडी कनेक्टेड हैं या ऑलरेडी इनका कनेक्शन इस्टैब्लिश्ड है इस
चैट सर्विस वन से। और यह जो हमारा यूजर थ्री है इसका कनेक्शन इस्टैब्लिश्ड है इस चैट सर्विस से। तो अब जो नई रिक्वेस्ट
आएगी लेट्स से ये यूजर फोर आता है और इसकी रिक्वेस्ट आती है लेट्स से फोर उसकी आईडी फोर है। यह रिक्वेस्ट आती है। तो अब यह जो
रिक्वेस्ट है यह जाएगी उस सर्विस के पास। उस सर्वर के पास जिसके पास सबसे कम कनेक्शंस हैं। तो इस केस में इस चैट
सर्विस वन के पास दो कनेक्शंस हैं और यह जो चैट सर्विस टू है इसके पास सिर्फ एक कनेक्शन है। तो जैसा कि नाम से हमें समझ
आता है कि लीस्ट कनेक्शन। तो जो न्यू रिक्वेस्ट जाएगी वो उस सर्विस के या उस सर्वर के पास जाएगी। उस इंस्टेंस के पास
जाएगी जिसके पास कम कनेक्शन है। तो इस केस में चैट सर्विस टू के पास कम कनेक्शन है। तो यह रिक्वेस्ट जो होगी यह जाएगी इसके
पास। तो अब इसके एक्टिव कनेक्शन हो जाएंगे टू। तो यह होता है हमारा लीस्ट कनेक्शन। अब हमारी जो चैट सर्विस का फर्स्ट
इंस्टेंस है उससे हमारे दो यूज़र्स कनेक्टेड हैं। यूजर वन यूजर टू। और जो हमारा चैट सर्विस का सेकंड इंस्टेंस है
उससे हमारे दो यूज़र्स कनेक्टेड हैं U3 एंड U4। तो अब हमारा बेसिकली हम कह सकते हैं कि ये
यूज़र्स हैं इनका डिफरेंट-डिफरेंट इंस्टेंसेस से चैट सर्विस के डिफरेंट-डिफरेंट इंस्टेंसेस से TCP
कनेक्शन इस्टैब्लिश्ड हो गया है। पर क्या टीसीपी कनेक्शन इस्टैब्लिश होने का यह मतलब है कि ट्रैफिक भी राउट होने लगा है?
नहीं। तो हम ये कह सकते हैं कि कनेक्शन तो इस्टैब्लिश हो गया है लेकिन अभी रिक्वेस्ट नहीं जा रही हैं। तो लेट्स से कि यह जो
यूजर वन है यह कंटिन्यू रिक्वेस्ट कर रहा है और यह यूजर टू भी कंटिन्यू रिक्वेस्ट कर रहा है। लेट्स से इसने रिक्वेस्ट की
फर्स्ट, फिर इसने की, फिर इसने थर्ड की, इसने फोर्थ रिक्वेस्ट की। तो अब ये सारी रिक्वेस्ट कहां जाएंगी? ये सारी रिक्वेस्ट
जाएंगी इस इंस्टेंस के पास। फर्स्ट रिक्वेस्ट जाएगी, सेकंड जाएगी, थर्ड जाएगी, फोर्थ जाएगी। क्यों? क्योंकि यह
यूजर वन और यूजर टू अ इस चैट सर्विस वन इंस्टेंस से इस सर्वर से कनेक्टेड हैं। तो यह सारी रिक्वेस्ट गई यहां पे। अब टीसीp
कनेक्शन तो इसका भी इस्टैब्लिश्ड था लेकिन यहां पे कोई ट्रैफिक नहीं आया। तो यदि हमारे पास ये दोनों सर्वर की कैपेसिटी सेम
है तो तो ठीक है। लेकिन यदि लेट्स से कि दोनों सर्वर की कैपेसिटी में डिफरेंस है। लेट्स से ये हमारा बहुत पावरफुल कंप्यूटर
है। अ या हम कह सकते हैं कि यह वाला हमारा पावरफुल कंप्यूटर है। और यह वाला जो हमारा है वो वीक कंप्यूटर है। हम कह सकते हैं।
तो इस केस में अब देखो कि हमारे वीक वाले कंप्यूटर पे वीक सर्वर पे जा ट्रैफिक जा रहा है। रिक्वेस्ट राउट हो रही है। और जो
हमारा स्ट्रांग कंप्यूटर है, पावरफुल पावरफुल कंप्यूटर है, पावरफुल सर्वर है, वहां पे हमारी अभी एक भी रिक्वेस्ट नहीं
आई। तो, यह एक प्रॉब्लम आती है लीस्ट कनेक्शंस में और इस प्रॉब्लम को सॉल्व करता है वेटेड लीस्ट कनेक्शन। तो जैसे
हमने वेटेड राउंड रबिन में हमारे सर्वर को वेट असाइन कर दिया था। यहां भी हमने हमारे सर्वर को वेट असाइन कर दिया। तो अब हम
इसमें क्या करते हैं? वेटेड लीस्ट कनेक्शन में हम सबसे पहले कैलकुलेट करते हैं रेश्यो ऑफ एक्टिव कनेक्शंस टू वेट। तो
लेट्स से कि हमारे इस इस सिस्टम में ये जो यूजर वन है और ये जो यूजर टू है इसका टीसीp कनेक्शन एस्टैब्लिश्ड हो चुका है इस
सर्वर से। ओके? तो इसके एक्टिव कनेक्शंस हो गए इस सर्वर के एक्टिव कनेक्शंस हो गए टू। राइट? तो हमने हमने सबसे पहले क्या
करना है? कैलकुलेट करना है रेश्यो ऑफ़ एक्टिव कनेक्शंस टू वेट। तो हमारे एक्टिव कनेक्शंस हैं टू और वेट है 10। तो ये हो
गया हमारा वन। राइट? टू। सिमिलरली अब हम यहां पे हमारे एक्टिव कनेक्शन केवल एक ही है। केवल
ये U3 एक्टिव कनेक्शन है। तो हम यहां पे भी वेट कैलकुलेट कर लेंगे। बेसिकली रेश्यो एक्टिव कनेक्शंस और वेट का। तो यह हो
जाएगा हमारा वन। तो इसके बाद ये रेशियो कैलकुलेट करने के बाद हम क्या करेंगे कि जो हमारा दूसरा पॉइंट है कि सर्वर विद लेस
रेशियो विल गेट द रिक्वेस्ट। तो इसमें हमारे पास जो रेश्यो आया जो सबसे कम रेश्यो था वो ये था टू वाला। यहां पे
रेश्यो आया वन। तो हम क्या करेंगे कि हम रिक्वेस्ट को उस सर्वर पे राउट करेंगे जहां पे रेश्यो कम आया। तो हमारा रेश्यो
इस सर्वर के लिए कम आया। तो हम रिक्वेस्ट को लेट्स से यह कोई नई रिक्वेस्ट आई थी लेट्स से रिक्वेस्ट फोर्थ इस U4 की तो हम
इस रिक्वेस्ट को राउट कर देंगे इस वाले सर्वर पे तो अब हमने देखा कि हमने हमारा यह वाला जैसे पावरफुल कंप्यूटर था
पावरफुल सर्वर था यह वाला हमारा पावरफुल सर्वर था तो अब हम देख सकते हैं कि हमने इसमें एक और एक्टिव कनेक्शन बढ़ा दिया U4
बट स्टिल इट हैज़ कैप कैपेसिटी कैपेबिलिटी टू टू हैंडल मोर रिक्वेस्ट। तो अब हमने यहां पे कैपेबिलिटी को कैपेसिटी को भी यूज़
किया सर्वर की कैपेसिटी को। तो ये होता है हमारा सेकंड डायनेमिक एल्गोरिदम। सेकंड डायनेमिक लोड बैलेंसिंग एल्गोरिदम। अब जो
हमारी नेक्स्ट आती है एल्गोरिदम वो है लीस्ट रिस्पांस टाइम। तो इस लीस्ट रिस्पांस टाइम में सबसे
पहले हम TTFB टाइम को कैलकुलेट करते हैं। ये TTFB टाइम इज़ नथिंग बट टाइम टू फर्स्ट बाइट। तो इसका मतलब क्या होता है? कि टाइम
इंटरवल बिटवीन सेंडिंग अ रिक्वेस्ट एंड रिसीविंग रिस्पांस फ्रॉम द सर्वर। लेट्स से ये यूजर ने कुछ रिक्वेस्ट भेजी। लेट्स
से इसने बोला कि मुझे M1 मैसेज सेंड करना है यूजर टू को। राइट? तो यह रिक्वेस्ट गई इस चैट सर्विस वन के पास। तो यह चैट
सर्विस वन इसे एकनॉलेजमेंट सेंड करेगा कि ठीक है आई विल सेंड योर रिक्वेस्ट। उसके बाद यह चैट सर्विस वन यूजर टू को यह M1
मैसेज भेज देगा और फिर यह चैट सर्विस इसे वापस से एकनॉलेज करेगा कि ठीक है मैंने तुम्हारे मैसेज को भेज दिया है यूजर टू
को। तो बेसिकली यह उसका हो जाएगा रिस्पांस। तो इस रिक्वेस्ट को सेंड होने में और रिस्पांस के आने में जितना टाइम
लगता है उसे हम बोल देते हैं TTFB टाइम टाइम टू फर्स्ट बाइट। तो लेट्स से कि यह वाले सर्वर का हमारा TTFB टाइम है थ्री 3
मिलीसे इसका टू और इसका वन। तो हम सबसे पहले TTFB टाइम कैलकुलेट करेंगे हर सर्वर का। उसके बाद हम सर्वर ऐसा सर्वर पिक
करेंगे जिसके लिए इसकी वैल्यू सबसे कम आए। राइट? तो अब देखते हैं हम कैसे काम करेगा। तो सबसे पहले सर्वर वन के लिए देखते हैं।
तो सर्वर वन के लिए एक्टिव कनेक्शंस हैं दो और TTFB टाइम है थ्री। तो यह हो जाएगा हमारा सिक्स। सिमिलरली इसके लिए हम
कैलकुलेट करें सर्वर टू के लिए तो TTFB टाइम है टू और एक्टिव कनेक्शंस हैं ज़ीरो। तो 0 * 2 तो ये हो जाएगा ज़ीरो। अब हम
सर्वर थ्री के लिए कैलकुलेट करें तो ये हो जाएगा फोर एक्टिव कनेक्शंस इन 1 TTFB टाइम तो दैट वुड बी फोर। तो अब हमने क्या
डिसाइड किया कि हम सबसे कम वाला सेलेक्ट करेंगे। हमारे पास एक है सिक्स, एक है ज़ीरो और एक है फोर। तो अब हम सबसे कम वाला
सेलेक्ट करेंगे ये वाला। तो ये कौन सा है हमारा? सर्वर टू। तो हम क्या करेंगे? जो नई रिक्वेस्ट आ रही है लेट्स से इस यूजर
फोर की रिक्वेस्ट आ रही है। तो अब हम इस रिक्वेस्ट को राउट करेंगे या ट्रैफिक को राउट करेंगे इस वाले सर्वर पे। तो अब इसके
एक्टिव कनेक्शंस बढ़ के क्या हो जाएंगे? वन। अब इसके लिए हमारा अभी भी यह सिक्स आ रहा है।
यह हमारा सिक्स आ रहा है। इसके लिए हमारा फोर स्टिल सेम रहेगा। लेकिन अब यहां पे चैट सर्विस टू या सर्वर टू के लिए यह चेंज
हो जाएगा। अब यहां एक्टिव कनेक्शन ज़ीरो की जगह वन हो गया। तो यहां पे वन तो ये हो जाएगा हमारा टू। स्टिल इस केस में भी यहां
पे सिक्स है। यहां पे फोर है। यहां पे टू है। तो इस केस में भी हम इसे ही कंसीडर करेंगे। और हम नई रिक्वेस्ट को लेट्स से
थर्ड रिक्वेस्ट को जो नई रिक्वेस्ट आई है उसे भी हम इसमें राउट कर देंगे। इस सर्वर में राउट कर देंगे। तो ऐसे हमारा ये लीस्ट
रिस्पांस टाइम एल्गोरिदम काम करता है। ये सारी तीनों हमने अ डायनेमिक एल्गोरिदम्स भी डिस्कस कर ली। और हां एक चीज और इस
लीस्ट रिस्पांस टाइम के बारे में कि यदि लेट्स से अ क्लैश होता है दो डिफरेंट सर्वर्स के बीच में लेट्स से दोनों में
फोर फोर आया। तो इस केस में अब हम क्या करेंगे कि हम राउंड रॉबिन का यूज़ कर लेंगे। तो यदि
हमारे दो सर्वर के बीच में क्लैश होता है तो फिर हम राउंड रबिन का यूज कर लेंगे। तो ये था हमारा लेक्चर थ्री जिसमें हमने देखा
लोड बैलेंसर। लोड बैलेंसिंग लोड बैलेंसिंग के डिफरेंट टाइप्स जिसमें हमने L4 लोड बैलेंसर देखा। हमने L7 लोड बैलेंसर देखा।
और फिर हमने देखा कुछ लोड बैलेंसिंग एल्गोरिदम्स जिसमें हमने स्टैटिक एल्गोरिदम भी डिस्कस की। हमने डायनेमिक
एल्गोरिदम्स भी डिस्कस की। स्टैटिक एल्गोरिदम में हमने राउंड रॉबिन, वेटेड राउंड रॉबिन देखे और इनसे इनके क्या
डिसएडवांटेजेस थे वो देखे। हमने आईपी हैश देखा। फिर हमने स्विच किया डायनेमिक एल्गोरिदम्स की तरफ जिसमें हमने देखा
लीस्ट कनेक्शन, वेटेड लीस्ट कनेक्शन। और हमने एक और देखा लीस्ट रिस्पांस टाइम। तो यस, दिस इज़ ऑल फॉर दिस लेक्चर थ्री। आई
होप यू एंजॉयड दिस लेक्चर। सो, याह, दिस इज़ ऑल फॉर दिस वीडियो। वी विल सी यू इन द नेक्स्ट वीडियो। सो, टिल देन बाय-बाय। शो
सम लव। थैंक्स। [संगीत] हे एवरीवन, वेलकम बैक। वेलकम टू दिस
अल्टीमेट सिस्टम डिज़ प्लेलिस्ट सीरीज। और आज के इस वीडियो में हम डिस्कस करने वाले हैं एक और इंटरेस्टिंग टॉपिक जिसमें हम
देखेंगे व्हाट इज प्रॉक्सी? प्रॉक्सी सर्वर जिसे हम फॉरवर्ड प्रॉक्सी भी कहते हैं। हम देखेंगे व्हाट इज रिवर्स
प्रॉक्सी। और इसके बाद हम कुछ इंपॉर्टेंट क्वेश्चंस डिस्कस करेंगे। जैसे हाउ प्रॉक्सी इज़ डिफरेंट फ्रॉम वीpए, हाउ
प्रॉक्सी इज़ डिफरेंट फ्रॉम लोड बैलेंसर? डू वी नीड प्रॉक्सी सर्वर एवरीवेयर? और आगे चलके हम वीडियो में देखेंगे कि रिवर्स
प्रॉक्सी जो है हमारा वह लोड बैलेंसिंग का भी काम कर सकता है। तो हम देखेंगे कि यदि रिवर्स प्रॉक्सी लोड बैलेंसिंग कर सकता है
तो फिर लोड बैलेंसर की हमें नीड क्या है? और यदि हम अपने एप्लीकेशन में रिवर्स प्रॉक्सी यूज़ कर रहे हैं। रिवर्स प्रॉक्सी
सर्वर यूज़ कर रहे हैं तो क्या फिर हमें लोड बैलेंस को यूज़ करना भी है या नहीं? तो ये सारे क्वेश्चंस हम डिस्कस करेंगे। तो
स्टार्ट करते हैं और एक बार समझते हैं प्रॉक्सी सर्वर को फॉरवर्ड प्रॉक्सी को एक एग्जांपल की हेल्प से। तो लेट्स से कि एक
5 छ साल का बच्चा है और इस बच्चे को चॉकलेट खाना है। तो अब यह बच्चा क्या करेगा? यह खुद तो शॉप में जाएगा नहीं। यह
क्या करेगा? यह अपने पेरेंट्स को बोलेगा कि आई वांट टू ईट चॉकलेट। तो यह अपने पेरेंट्स को बोलेगा और फिर पेरेंट्स जो
हैं वह जाएंगे शॉप में शॉपकीपर के पास और वहां से यह चॉकलेट लेकर आएंगे और फिर यह चॉकलेट अपने बच्चे को दे देंगे। तो
बेसिकली यहां पे पेरेंट ने क्या किया कि अपने बच्चे को अपने बच्चे को शॉप से या आउटर वर्ल्ड से
हाइड रखा। बेसिकली उन्होंने यहां पे एनोनिमिटी को मेंटेन किया। उन्होंने क्या किया? अह बच्चे को चॉकलेट खाना था तो वह
खुद दुकान में गए। चॉकलेट लाई और बच्चे को चॉकलेट लाकर दे दी। तो बेसिकली यहां पे शॉपकीपर को नहीं पता कि पेरेंट्स ने यह
चॉकलेट किसके लिए ली। तो हम कह सकते हैं कि यहां पे पेरेंट्स ने अपने बच्चे को हाइड रखा शॉपकीपर से इस शॉप से। तो सेम
काम करता है हमारा प्रॉक्सी सर्वर। तो प्रोक्सी सर्वर को अब सेम एग्जांपल की हेल्प से समझते हैं। तो चाइल्ड को हम
मानते हैं क्लाइंट। तो यह हो गया हमारा क्लाइंट और जो हमारा पेरेंट था इस चाइल्ड के
पेरेंट्स थे उसे हम मानते हैं प्रॉक्सी सर्वर। तो यह हो गया हमारा प्रॉक्सी सर्वर और फिर यहां पे आ जाता है हमारा इंटरनेट।
यह हो गया हमारा इंटरनेट। और यहां पे हो गया हमारा सर्वर जिससे हमें रिक्वेस्ट करना है। तो यह
क्लाइंट हो गया हमारा चाइल्ड। यह प्रॉक्सी हो गया पेरेंट्स जो बच्चे को चॉकलेट लाकर दे रहे थे और यह
सर्वर हो गया हमारा शॉप या शॉपकीपर। तो जब यह क्लाइंट कोई रिक्वेस्ट करेगा, तो यह रिक्वेस्ट सबसे जब पहले जाएगी इस प्रॉक्सी
सर्वर के पास। अब इस क्लाइंट का अपना IPपी एड्रेस होगा। राइट? लेट से इस क्लाइंट का IPपी एड्रेस है यह कोई भी ऐसा रैंडम और इस
प्रॉक्सी सर्वर का IP एड्रेस है लेट्स से यह कोई भी ऐसे रैंडम IPपी एड्रेस तो अब क्या होगा कि जब यह रिक्वेस्ट इंटरनेट पे
जाएगी सबसे पहले तो यह क्लाइंट बोलेगा कि लेट्स से इसको Google.com चाहिए तो यह रिक्वेस्ट जाएगी प्रॉक्सी सर्वर के पास।
अब ये प्रॉक्सी सर्वर जब ये इंटरनेट पे IP राउट करेगा तो वो इस क्लाइंट का IPपी राउट ना करके अपना खुद का IP भेजेगा। यह खुद का
IPपी भेजेगा और जब यह रिक्वेस्ट सर्वर के पास जाएगी तो सर्वर के पास भी इस प्रॉक्सी सर्वर का IP एड्रेस जाएगा। तो इस सर्वर को
यह लगेगा कि ये जो रिक्वेस्ट है facebook.com या google.com की ये रिक्वेस्ट मुझे इस IPपी एड्रेस से आई है।
तो ऐसे करके हम हमारे क्लाइंट को हाइड रख सकते हैं टू आउटर नेटवर्क। बेसिकली हम अपने लोकल नेटवर्क को हाइड कर सकते हैं।
तो ऐसे करके प्रॉक्सी सर्वर हमें एनोनिमिटी प्रोवाइड करता है। बेसिकली हम कह सकते हैं कि यह जो हमारा प्रॉक्सी
सर्वर है इट ब्रिंग्स एनोनिमिटी टू क्लाइंट। यह क्लाइंट को एनोनिमस रखता है आउटर वर्ल्ड से। तो अब यह रिक्वेस्ट जाएगी
सर्वर के पास और सर्वर तो सर्वर इस रिक्वेस्ट को फुलफिल करेगा और डाटा सेंड कर देगा इस प्रॉक्सी सर्वर को। अब ये
प्रॉक्सी सर्वर आगे चल के इस डेटा को सेंड कर देगा क्लाइंट को। तो ये काम होता है हमारे प्रॉक्सी सर्वर का। अब प्रॉक्सी
सर्वर का यूज़ करने से क्या हो गया कि अ हमने बेसिकली क्लाइंट को हाइड कर लिया आउटर नेटवर्क से। हमने एनोनिमिटी प्रोवाइड
की क्लाइंट को और उसके बाद अब कोई भी सर्वर क्लाइंट से डायरेक्टली कम्युनिकेट नहीं कर सकता। क्योंकि सर्वर को तो आईडिया
ही नहीं है कि किसने रिक्वेस्ट की थी। बेसिकली उसको यह लगेगा कि यह जो रिक्वेस्ट आई है यह प्रॉक्सी सर्वर से आई है। उसे
नहीं पता एक्चुअल क्लाइंट या एक्चुअल ओरिजिन क्या है इस रिक्वेस्ट का। तो हम कह सकते हैं कि यह प्रॉक्सी सर्वर की मदद से
क्या होगा कि कोई भी सर्वर क्लाइंट से डायरेक्ट कम्युनिकेट नहीं कर सकता। तो यह काम होता है हमारे प्रॉक्सी सर्वर का। अब
कुछ और एडवांटेजेस जो प्रॉक्सी सर्वर हमें प्रोवाइड करता है तो उसे समझते हैं और एक एग्जांपल के थ्रू इसे देखते हैं। तो लेट्स
से कि आप एक कंपनी में काम कर रहे हैं। लेट्स से कोई एक्स वzेड कंपनी है और उस कंपनी में
आपके पास लेट्स से डिफरेंट ऐसे क्लाइंट्स हैं। एक आप हो गए और आपके ऐसे डिफरेंट कलीग्स हो गए। अब उनके पास सबके पास
अपने-अपने डिफरेंट लैपटॉप्स हैं और सबके हर क्लाइंट का एक अपना IPपी एड्रेस होगा। राइट? इसका ये IPपी एड्रेस है। इसका ये
ऐसे करके हमारे हर क्लाइंट के डिफरेंट IPपी एड्रेसेस होंगे। तो अब हमारी कंपनी ने क्या डिसाइड किया? इस XYZ कंपनी ने
क्या डिसाइड किया कि आप जब भी कुछ वेब पे ब्राउज़ करोगे, कुछ भी ब्राउज़ करोगे इंटरनेट पे तो वह जाएगा प्रॉक्सी सर्वर के
थ्रू। मतलब आप डायरेक्ट इंटरनेट को एक्सेस नहीं कर सकते। पहले आपको प्रॉक्सी सर्वर के थ्रू होते हुए जाना पड़ेगा। तो यह हम
हमारी कंपनी ने डिसाइड किया। अब लेट्स से कि चारों चारों ये क्लाइंट चारों यूज़र्स अपनी-अपनी रिक्वेस्ट भेजते हैं। लेट्स से
किसी को google.com चाहिए, किसी को facebook.com कोई चैट जेपीटी को एक्सेस करना चाहता है।
तो ऐसे चारों क्लाइंट ने अपनी-अपनी रिक्वेस्ट की। तो ये रिक्वेस्ट सबसे पहले जाएगी इस प्रॉक्सी सर्वर के पास। अब
प्रॉक्सी सर्वर हमने देखा कि हमें IP एनोनिमिटी तो प्रोवाइड कर ही रहा है। एक फीचर क्या है प्रॉक्सी सर्वर का? यह IP
एनोनिमिटी हमें प्रोवाइड कर रहा है। लेकिन और क्या फीचर है? तो यह जब चारों क्लाइंट्स
रिक्वेस्ट करेंगे तो यह प्रॉक्सी सर्वर चेक करेगा। यह बेसिकली क्या है? हमारे इस XYZ कंपनी का प्रॉक्सी सर्वर है। तो ये
बेसिकली चेक करेगा कि क्लाइंट ने जो भी रिक्वेस्ट किया लेट्स से कि ये C3 क्लाइंट ने बोला है कि मुझे चैट GPT चाहिए। तो यह
चैट चैट GPT को एक्सेस करना चाहता है। तो क्या करेगा कि यह प्रॉक्सी सर्वर चेक करेगा। बेसिकली इसमें पहले से ही डिफाइन
होगा कि हमें क्या यूजर को एक्सेस करने देना है, क्या नहीं एक्सेस करने देना। तो, यह जो हमारा प्रॉक्सी सर्वर है, वह देखेगा
कि क्या चैट जीपीटी को यूजर को एक्सेस करने देना है या नहीं। तो प्रॉक्सी सर्वर बोलेगा नहीं चैट जीपीटी उसके लिए अलाउड
नहीं है। तो, वह क्या करेगा? यूजर की रिक्वेस्ट को कैंसिल कर देगा और बोल देगा कि कुछ भी मैसेज एक्स वzेड कि लेट्स से
दिस साइट इज नॉट अलाउड या दिस साइट इज रेस्ट्रिक्टेड। ऐसा कुछ मैसेज वो उसे भेज देगा क्लाइंट C3 को। अब लेट्स से कोई एक
और यह C2 आता है C2 क्लाइंट और यह बोलता है कि मुझे Google.com खोल के दो। तो ये रिक्वेस्ट जाएगी सबसे पहले कहां? प्रॉक्सी
सर्वर के पास। अब प्रॉक्सी सर्वर चेक करेगा कि क्या यह यूजर की रिक्वेस्ट वैलिड है या नहीं? मतलब क्या हमें यूजर को यह
एक्सेस करने देना है या नहीं? तो लेट्स से वो बोलता है उसमें डिफाइन है कि ठीक है Google.com यूजर एक्सेस कर सकता है। तो
फिर यह प्रॉक्सी सर्वर इस रिक्वेस्ट को Google के सर्वर पे भेजेगा। लेकिन क्या होगा कि जब Google के सर्वर पे यह
रिक्वेस्ट जाएगी तो Google के सर्वर को यह लगेगा कि यह रिक्वेस्ट जो आई है वो इस सोर्स से आई है। उसको इस C2 क्लाइंट या
इसके IPपी एड्रेस का पता नहीं लगेगा। क्यों? क्योंकि यह प्रॉक्सी सर्वर ने यहां पे हमारे क्लाइंट को हाइड कर दिया और आगे
इसने इंटरनेट पे अपने IPपी एड्रेस को एक्सपोज किया। तो इस सर्वर वन के पास जब रिक्वेस्ट जाएगी तो उसको लगेगा कि वो
देखेगा कि ये जो रिक्वेस्ट है ये इस IPपी एड्रेस से आई है। तो वो इस बेसिकली उसके लिए तो यह क्लाइंट ही है। तो यह इस
क्लाइंट की रिक्वेस्ट को फुलफिल करेगा और डेटा को सेंड कर देगा इस प्रॉक्सी सर्वर को और फिर प्रॉक्सी सर्वर इस डेटा को या
रिस्पांस को फर्दर सेंड कर देगा C टू क्लाइंट को। तो यह काम होता है हमारे प्रॉक्सी सर्वर का। तो बेसिकली दूसरा जो
हमने एडवांटेज देखा पहला तो हमने देखा कि इट प्रोवाइड्स आईपी एनोनिमिटी बेसिकली इट ब्रिंग्स एनोनिमिटी टू क्लाइंट जो दूसरा
एग्जांपल हमने देखा वो देखा दूसरा जो हमने एडवांटेज देखा वो हमने देखा एक्सेस कंट्रोल
कि यदि कुछ हमारे लेट्स से कोई एक्स वzेड कंपनी में कुछ साइट्स बैन है तो हम उन साइट्स को एक्सेस नहीं कर सकते तो यह काम
यह हमें कौन एडवांटेज प्रोवाइड करता है यह एडवांट वांटेज भी हमें प्रोवाइड करता है हमारा प्रॉक्सी सर्वर। जो तीसरा एडवांटेज
है वो है कि यह रिक्वेस्ट की ग्रुपिंग कर सकता है। यह रिक्वेस्ट की ग्रुपिंग कर सकता है। अब इसका क्या मतलब है? तो लेट्स
से कि ये चार क्लाइंट्स हैं हमारे पास। चारों क्लाइंट्स के अपने-अपने IPपी एड्रेस हैं। राइट? और ये चारों क्लाइंट्स लेट्स
से Google.com को एक्सेस करना चाहते हैं। तो ये चारों क्लाइंट्स अपनी-अपनी रिक्वेस्ट को प्रॉक्सी सर्वर को देंगे। तो
ये प्रॉक्सी सर्वर क्या करेगा? इन इन रिक्वेस्ट की चारों क्लाइंट्स की रिक्वेस्ट की ग्रुपिंग कर देगा। क्यों?
क्योंकि वो सेम रिसोर्स को एक्सेस करना चाहते हैं। तो यह प्रॉक्सी सर्वर इन चारों क्लाइंट्स की रिक्वेस्ट की ग्रुपिंग कर
देगा। बेसिकली वह चारों क्लाइंट्स की रिक्वेस्ट को क्लब कर देगा और एज अ सिंगल रिक्वेस्ट भेज देगा Google.com के सर्वर
पे। उसके बाद Google.com Google सर्वर से हमारे पास रिस्पांस आएगा और फिर यह प्रॉक्सी सर्वर उस रिस्पांस को
भेज देगा चारों डिफरेंट-डिफरेंट क्लाइंट्स को। तो थर्ड एग्जाम थर्ड एडवांटेज क्या है इस प्रॉक्सी सर्वर का कि ये रिक्वेस्ट की
ग्रुपिंग करने में हेल्प करता है। और एक और क्या हो सकता है कि यदि कोई रिस्ट्रिक्टेड कंटेंट आप कंटेंट आप अपने
लेट्स से पर्सनल लैपटॉप में देखना चाहते हैं तो यह प्रॉक्सी सर्वर आपको उस रेस्ट्रिक्टेड कंटेंट को भी एक्सेस करने
में हेल्प कर सकता है। तो यह होता है हमारा प्रॉक्सी सर्वर। अब आप समझ गए होंगे कि प्रॉक्सी सर्वर बेसिकली क्या कर रहा है
कि क्लाइंट को एनोनिमस रख के क्लाइंट नेटवर्क को हाइड रख के अ काम कर रहा है। उसकी रिक्वेस्ट को फुलफिल कर रहा है और
कोई भी सर्वर डायरेक्टली कम्युनिकेट नहीं कर सकता अब क्लाइंट से। तो बेसिकली सर्वर को क्या सर्वर को पता ही नहीं चलेगा कि जो
रिक्वेस्ट उसके पास आ रही है उसका एक्चुअल ओरिजिन क्या है। तो यह काम होता है हमारे प्रॉक्सी सर्वर का। तो ये हमने समझ लिया
प्रॉक्सी सर्वर जिसे हम फॉरवर्ड प्रॉक्सी भी कहते हैं। और ये जो प्रॉक्सी है हमारे पास ये दो टाइप की होती है। फॉरवर्ड
प्रॉक्सी और रिवर्स प्रॉक्सी। तो फॉरवर्ड प्रॉक्सी हमने डिस्कस कर लिया। अब हम डिस्कस करते हैं रिवर्स प्रॉक्सी। और हां
एक चीज और कि यह जो हमारी फॉरवर्ड प्रॉक्सी या प्रॉक्सी सर्वर होता है यह हमेशा
क्लाइंट और इंटरनेट के बीच में होता है। क्लाइंट और इंटरनेट के बीच में होता है यह हमारा प्रॉक्सी सर्वर और यह प्रॉक्सी
सर्वर हमें कैशिंग में भी हेल्प करता है। अब ये कैशिंग में कैसे हमें हेल्प करता है लेट्स से तो यह हमारा क्लाइंट है और यहां
पे हमारा एक प्रॉक्सी सर्वर है। अब लेट्स से कि यह क्लाइंट कुछ रिक्वेस्ट करता है। लेट्स से सेम google.com तो यह रिक्वेस्ट
जाएगी प्रॉक्सी सर्वर के थ्रू। तो यह रिक्वेस्ट जाएगी प्रॉक्सी सर्वर के थ्रू। फिर यहां पे यह रिक्वेस्ट जाएगी इंटरनेट
पे और फिर यहां पे हमारा होगा सर्वर Google का सर्वर। तो ऐसे करके हमारी रिक्वेस्ट जाएगी। Google रिस्पांस देगा।
यह रिस्पांस आएगा प्रॉक्सी सर्वर के बाद। उसके बाद प्रॉक्सी सर्वर इस रिस्पांस को दे देगा क्लाइंट को। तो प्रॉक्सी सर्वर को
एक बार पता चला कि ठीक है Google क्लाइंट ने Google.com एक्सेस किया। Google.com एक्सेस किया। तो अब क्या होगा कि यह जो ये
जो प्रॉक्सी सर्वर है यह कैशिंग भी करता है। तो नेक्स्ट टाइम जब क्लाइंट सेम रिक्वेस्ट करेगा सेम google.com तो इस
प्रॉक्सी सर्वर के पास यह डाटा होगा। प्रॉक्सी सर्वर को पता होगा कि यूजर को क्या दिखाना है। तो ये प्रॉक्सी सर्वर अब
सर्वर के पास ना जाके यहीं से क्लाइंट को रिस्पांस दे देगा। तो यह एक एक और एडवांटेज होता है कैशिंग
एक और एडवांटेज होता है प्रॉक्सी सर्वर का। तो ये अब हमने देख लिया प्रॉक्सी सर्वर। अब हम समझते हैं रिवर्स प्रॉक्सी
को। तो रिवर्स प्रॉक्सी बेसिकली सीट्स इन फ्रंट ऑफ सर्वर्स। तो ये जो रिवर्स प्रॉक्सी सर्वर हमारा होता है यह सर्वर्स
के सामने होता है। बेसिकली इट सीट्स इन फ्रंट ऑफ सर्वर्स। लेट्स से हमारे पास एक ये सर्वर वन है,
सर्वर टू है, सर्वर थ्री है। लेट्स से ये हमारे तीनों लेट्स से facebook.com के सर्वर्स हैं। तो
जो हमारे रिवर्स प्रॉक्सी होता है, यह सर्वर्स के सामने बैठता है। तो अब ये इसकी हेल्प यह क्या मदद करता है हमें? इसको हम
समझते हैं। तो रिवर्स प्रॉक्सी लगाने से अब क्या होगा कि इंटरनेट से कोई भी रिक्वेस्ट आएगी तो वह यह रिक्वेस्ट सबसे
पहले रिवर्स प्रॉक्सी से होते हुए जाएगी। रिवर्स प्रॉक्सी लेट्स से कि किसी यूजर ने किसी क्लाइंट ने
google.com लेट्स से facebook.com एक्सेस किया एक्सेस करना चाहता है facebook.com तो यह डायरेक्ट Facebook के किसी सर्वर पे
ना जाते हुए सबसे पहले इस रिवर्स प्रॉक्सी पे जाएगी। की यह रिक्वेस्ट रिवर्स प्रॉक्सी पे। उसके बाद यह रिवर्स प्रॉक्सी
फ़र्दर इस रिक्वेस्ट को सेंड करेगा टू वन ऑफ़ द सर्वर। तो, हम कह सकते हैं कि रिवर्स प्रॉक्सी के आने से यह जो सर्वर्स हैं,
इनके IPपी एड्रेस एक्सपोज नहीं हुए इंटरनेट पे। बेसिकली इंटरनेट को नहीं पता लगा कि इन सर्वर्स के facebook.com
सर्वर्स के IP एड्रेसेस क्या हैं। तो, यह चीज हमने इंटरनेट को एक्सपोज नहीं की। कैसे?
रिवर्स प्रॉक्सी की हेल्प से। तो यह जो रिवर्स प्रॉक्सी है, यह बेसिकली IP एनोनिमिटी प्रोवाइड करता है सर्वर्स को।
तो, जैसे हमारा जो प्रॉक्सी सर्वर था, वो IP एनोनिमिटी ला रहा था क्लाइंट के लिए। बेसिकली इट वाज़ ब्रिंगिंग IPपी एनोनिमिटी
टू क्लाइंट। और यहां पे सेम जो हमारा रिवर्स प्रॉक्सी है, यह IP एनोनिमिटी प्रोवाइड कर रहा है सर्वर्स को। तो, यह
पहला एडवांटेज होगा रिवर्स प्रॉक्सी का IP एनोनिमिटी। टू सर्वर।
अब जो दूसरा एडवांटेज होता है, वह यह होता है कि रिवर्स प्रॉक्सी हमें लोड बैलेंसिंग में भी हेल्प करता है। बेसिकली इट कैन
राउटर द ट्रैफिक टू मल्टीपल सर्वर्स या मल्टीपल सर्वर इंस्टेंसेस। तो जब ये रिक्वेस्ट लेट्स से Facebook.com की
रिक्वेस्ट इंटरनेट पे आती है। फिर इंटरनेट से रिवर्स प्रॉक्सी पे आती है। तो रिवर्स प्रॉक्सी देखेगा कि कौन सा हमारा सर्वर
कौन सा हमारा सर्वर एक्टिव है। बेसिकली ट्रैफिक लेने के लिए अवेलेबल है, एक्टिव है और कौन सा डाउन नहीं है। तो, ऑन द
बेसिस ऑफ़ हेल्थ, चेक एंड अवेलेबिलिटी यह क्या करेगा? इस यूजर की रिक्वेस्ट को राउट कर देगा टू वन ऑफ़ द सर्वर। तो हम कह सकते
हैं कि जो हमारा रिवर्स प्रॉक्सी है यह ट्रैफिक को भी राउट कर रहा है। ट्रैफिक को भी डिस्ट्रीब्यूट कर रहा है। तो ये लोड
बैलेंसिंग का भी काम कर रहा है। उसके बाद सेम यह कैशिंग में भी हेल्प करता है। यह कैशिंग में भी मदद करता है। अब उसके बाद
जो एक और एडवांटेज है वो है कि हमें डिफरेंट अटैक से बचाता है। लेट्स से डीडॉस अटैक। तो क्या होगा कि हमारे हमारा जो
सर्वर्स हैं ये जो हमारे तीनों सर्वर्स हैं इनके आईपी तो एक्सपोज है नहीं। इंटरनेट पे। तो जब भी कोई रिक्वेस्ट आएगी
तो सबसे पहले रिक्वेस्ट जाएगी रिवर्स प्रॉक्सी के पास। तो बेसिकली हमने हमारे रिवर्स प्रॉक्सी के IP को एक्सपोज किया है
इंटरनेट पे। हमने इन सर्वर्स के IP को एक्सपोज नहीं किया है। तो जब भी कोई अटैक होगा तो वो सबसे पहले इस रिवर्स प्रॉक्सी
पे जाएगा। हमारे सर्वर्स पे कोई अटैक नहीं होगा। क्योंकि हमने इसके आईपी को एक्सपोज ही नहीं किया। हमने IP को हमने किसके IP
को एक्सपोज किया? हमने रिवर्स प्रॉक्सी के IP को एक्सपोज़ किया है इंटरनेट पे। तो ये कुछ एडवांटेजेस होते हैं हमारे रिवर्स
प्रॉक्सी के। और ये जो रिवर्स प्रॉक्सी है इट सीट्स इन फ्रंट ऑफ सर्वर्स। तो ये इंटरनेट और सर्वर के बीच में होता है। अब
हमने समझ लिया प्रॉक्सी सर्वर को रिवर्स प्रॉक्सी को। और हमने देखा कि दोनों में सिर्फ डायरेक्शन ऑफ कम्युनिकेशन का
डिफरेंस है। जो हमारा प्रॉक्सी सर्वर है वो क्लाइंट के लिए काम कर रहा है। वो क्लाइंट नेटवर्क को हाइड कर रहा है। और जो
हमारा रिवर्स प्रॉक्सी है वो सर्वर के लिए काम कर रहा है। वो सर्वर के नेटवर्क को हाइड कर रहा है। तो बेसिकली हम कह सकते
हैं कि दोनों में सिर्फ डायरेक्शन ऑफ कम्युनिकेशन का डिफरेंस है। तो ये होता है हमारे प्रॉक्सी सर्वर और रिवर्स प्रॉक्सी।
अब हम देखते हैं कुछ इंपॉर्टेंट क्वेश्चंस रिगार्डिंग दिस प्रॉक्सी एंड रिवर्स प्रॉक्सी। तो जो सबसे पहला क्वेश्चन है वो
कि हाउ प्रॉक्सी इज़ डिफरेंट फ्रॉम वीpए। तो हमने देखा कि जो प्रॉक्सी सर्वर है यह हमें क्या एडवांटेजेस प्रोवाइड कर रहा है?
यह IP एनोनिमिटी प्रोवाइड कर रहा है। IP एनोनिमिटी प्रोवाइड कर रहा है। यह क्या कर रहा है? हमें एक्सेस कंट्रोल प्रोवाइड कर
रहा है कि क्या हमें यूजर को एक्सेस करने देना है, क्या नहीं देना। हम इसके थ्रू रिस्ट्रिक्टेड कंटेंट कंटेंट को एक्सेस कर
सकते हैं। रिस्ट्रिक्टेड कंटेंट को यह हमें कैशिंग का एक एडवांटेज प्रोवाइड कर रहा है कि प्रॉक्सी सर्वर के थ्रू हम
कैशिंग कर सकते हैं। तो ये कुछ एडवांटेजेस हैं और एक और कि हां रिक्वेस्ट की ग्रुपिंग। तो ये कुछ एडवांटेजेस हैं जो
हमें प्रॉक्सी सर्वर प्रोवाइड कर रहा है। तो अब समझते हैं वीपीए को। तो लेट्स से कि एक हमारा क्लाइंट है और यह क्लाइंट वीपीए
से कनेक्टेड है। तो यह हो गया हमारा वीपीए क्लाइंट और यह क्लाइंट को लेट्स से कुछ रिक्वेस्ट करना है सर्वर से तो यहां पे हो
गया हमारा इंटरनेट और यह हो गया हमारा सर्वर। अब क्लाइंट वीपीए से कनेक्टेड है तो लेट्स से यह हो गया हमारा वीपीए सर्वर।
अब क्लाइंट जो भी रिक्वेस्ट करेगा वह रिक्वेस्ट जाएगी एक वीपीए टनल से होते हुए। क्योंकि क्लाइंट अभी वीpए से
कनेक्टेड है। तो यह एक वीपीए टनल बना लेगा। तो अब इस टनल से होके यूज़र्स की या क्लाइंट की रिक्वेस्ट जाएगी। और इस टनल से
होके जो भी रिक्वेस्ट जाएगी वो एक एज इंक्रिप्टेड डेटा जाएगी। इंक्रिप्टेड डेटा। तो क्लाइंट की जो भी रिक्वेस्ट
रहेगी वो इंक्रिप्टेड फॉर्म में सर्वर के पास जाएगी। और सर्वर के पास मैकेनिज्म होगा उसे डिक्रिप्ट करने का। तो यह सर्वर
इस रिक्वेस्ट को डिक्रिप्ट कर लेगा। और ऐसे करके हम इस वीपीए टनल में से इंक्रिप्टेड डेटा पास करेंगे। तो ये काम
होता है हमारे वीपीए का। तो बेसिकली हमने क्या देखा कि वीpए इंक्रिप्टेड डेटा को ट्रांसफर कर रहा है। और यह जो हमारा
प्रॉक्सी सर्वर था, यह बेसिकली क्या कर रहा था? यह IP मास्किंग कर रहा था। IP मास्किंग यह क्लाइंट नेटवर्क को हाइड कर
रहा था सर्वर से इंटरनेट से। तो, यह काम था हमारे प्रॉक्सी सर्वर का। आईपी मास्किंग अ बेसिकली यहां पे वो कुछ
भी एज इंक्रिप्टेड डेटा सेंड नहीं कर रहा था। वो सिर्फ आईपी मास्किंग कर रहा था। यहां पे कुछ भी इंक्रिप्टेड डेटा जैसा
नहीं था। लेकिन जो हमारा वीपीए है उसमें मतलब क्लाइंट के वीpए से कनेक्ट करने के बाद वीpए टनल में जो भी डेटा जाएगा वो एक
वो एज इंक्रिप्टेड डेटा ट्रांसफर होगा। और सर्वर में मैकेनिज्म होगा उसे डिक्रिप्ट करने का। तो सर्वर उस डेटा को डिक्रिप्ट
कर लेगा। उस रिक्वेस्ट को डिक्रिप्ट कर लेगा। तो यह डिफरेंस होता है हमारा प्रॉक्सी सर्वर और वीपीए में। अब जो
नेक्स्ट क्वेश्चन हमारा था वो था कि हाउ प्रॉक्सी इज़ डिफरेंट फ्रॉम लोड बैलेंसर। तो लोड बैलेंसर को हम जैसा सब जानते हैं
कि यह बेसिकली ट्रैफिक को डिस्ट्रीब्यूट कर देता है अमोंग मल्टीपल सर्वर्स सर्वर इंस्टेंसेस। तो लोड बैलेंसर क्या करता है
कि ट्रैफिक को डिस्ट्रीब्यूट कर देता है अमोंग मल्टीपल सर्वर इंस्टेंसेस लेट्स से हमारा सर्वर वन हो गया। यह सर्वर टू हो
गया, सर्वर थ्री हो गया। तो लोड बैलेंसर क्या करेगा? हेल्थ चेक और सर्वर की अवेलेबिलिटी के हिसाब से ट्रैफिक को राउट
कर देगा टू मल्टीपल सर्वर्स। तो ये काम हमारा होता है लोड बैलेंसर का। अब सेम काम हमारा रिवर्स प्रॉक्सी भी कर
रहा है। हमने देखा कि हमारा रिवर्स प्रॉक्सी जो है या हमारा जो रिवर्स प्रॉक्सी है ये सर्वर्स के सामने है। हमने
देखा कि इट सीट्स इन फ्रंट ऑफ सर्वर्स। तो जो हमारा रिवर्स प्रॉक्सी है ये सर्वर्स के सामने है और हमने देखा कि ये हमारा
रिवर्स प्रॉक्सी भी लोड बैलेंसिंग कर सकता है। हमने देखा कि ये जो हमारा रिवर्स प्रॉक्सी है यह भी ट्रैफिक को राउट कर
सकता है टू डिफरेंट अ सर्वर इंस्टेंसेस। तो हमने यह देखा तो एक तरीके से रिवर्स प्रॉक्सी हमें लोड बैलेंसिंग का फीचर
प्रोवाइड कर रहा है ऑलरेडी। तो दोनों में डिफरेंस क्या है? तो लेट्स से कि इसे एक एग्जांपल के थ्रू समझते हैं। लेट्स से कि
हमारा कोई एप्लीकेशन है उसमें अभी ज्यादा यूज़र्स नहीं है। तो हमारे पास उस एप्लीकेशन का केवल एक ही सर्वर है। लेट्स
से S1 सर्वर। तो अब यदि हमारे पास केवल एक ही सर्वर है तो क्या हमें लोड बैलेंसर की नीड है? नहीं है। क्यों? क्योंकि हमारे
पास सिर्फ एक ही सर्वर है और हमें लोड बैलेंसर की नीड कब होती है? जब हमें ट्रैफिक को डिस्ट्रीब्यूट करना होता है टू
मल्टीपल सर्वर इंस्टेंसेस। लेकिन यहां पे तो हमारे पास सिर्फ एक ही सर्वर है। तो क्या हमें यहां लोड बैलेंसर की नीड है? तो
यहां पे हमें लोड बैलेंसर की नीड नहीं है। लेकिन क्या हमें रिवर्स प्रॉक्सी की नीड यहां है? तो यस हमें रिवर्स प्रॉक्सी की
नीड हो सकती है क्योंकि रिवर्स प्रॉक्सी लोड बैलेंसिंग के अलावा भी एक हमें आईपी एनोनिमिटी फीचर प्रोवाइड कर रहा है। IP
एनोनिमिटी यह बेसिकली सर्वर को एनोनिमस रखता है इंटरनेट से। उसके आईपी को एनोनिमस रखता है। आईपी मास्किंग करता है। यह लॉगिन
प्रोवाइड कर रहा है। यह कैशिंग में हमारी हेल्प करता है। यह कैशिंग कर रहा है। तो, हम कह सकते हैं एसएसएल टर्मिनेशन
तो हम कह सकते हैं कि जो हमारा रिवर्स प्रॉक्सी है यह लोड बैलेंसिंग लोड बैलेंसिंग के अलावा भी बहुत सारे फीचर्स
प्रोवाइड कर रहा है। तो भले ही हमारे एप्लीकेशन में यदि केवल एक ही सर्वर है तो भी हमें रिवर्स प्रॉक्सी की नीड हो सकती
है। हमें भले लोड बैलेंसर की नीड ना पड़े लेकिन हमें रिवर्स प्रॉक्सी की नीड हो सकती है। तो, यह होता है हमारा दूसरा
क्वेश्चन कि हाउ प्रॉक्सी बेसिकली रिवर्स प्रॉक्सी इज़ डिफरेंट फ्रॉम लोड बैलेंसर। अब जो नेक्स्ट क्वेश्चन है कि डू वी नीड
प्रॉक्सी सर्वर एवरीवेयर? तो यदि हमारे पास छोटे एप्लीकेशनेशंस हैं जहां ज्यादा ट्रैफिक नहीं आ रहा है और जहां सिक्योरिटी
ज्यादा कंसर्न नहीं है। बेसिकली बहुत छोटे एप्लीकेशन लेट्स से टू डू लिस्ट काइंड ऑफ़ एप्लीकेशन। वहां हमें प्रॉक्सी सर्वर्स की
नीड नहीं होती। लेकिन हां यदि हमारे हमारा एक ग्लोबल एप्लीकेशन है, ग्लोबल प्लेटफार्म है तो यस
वी डू नीड प्रॉक्सी सर्वर्स। तो ये हो गया हमारा एक और क्वेश्चन का आंसर। अब जो नेक्स्ट क्वेश्चन है कि इफ रिवर्स
प्रॉक्सी कैन डू लोड बैलेंसिंग जो कि हमने देखा कि यस रिवर्स प्रॉक्सी कैन डू लोड बैलेंसिंग देन व्हाट्स द नीड ऑफ लोड
बैलेंसर्स? और एक क्वेश्चन यह और आता है कि यदि रिवर्स प्रॉक्सी लोड बैलेंसिंग का काम कर ले रहा है तो क्या हमें लोड
बैलेंसर की नीड है भी या नहीं? तो जब भी हम कोई ग्लोबल एप्लीकेशन या लार्ज स्केल सिस्टम बनाते हैं तो हमारे पास ग्लोबली
ट्रैफिक आ रहा है आ रहा होता है डिफरेंट-डिफरेंट रीजंस से डिफरेंट-डिफरेंट अवेलेबिलिटी ज़ोंन से। तो जब भी हमारा
लार्ज स्केल एप्लीकेशन है यदि हमारे पास हमने लार्ज स्केल एप्लीकेशन बनाया तो यस वी डू नीड लोड बैलेंसर एंड वी आल्सो नीड
रिवर्स प्रॉक्सी। तो हम ग्लोबली ट्रैफिक को डिस्ट्रीब्यूट करने के लिए लोड बैलेंसर यूज करेंगे ही।
हम रिवर्स प्रॉक्सी भी यूज करेंगे। पर फिर यह जो हमारा रिवर्स प्रॉक्सी है, यह लोड बैलेंसिंग के अलावा सारे फीचर्स प्रोवाइड
करेगा। लोड बैलेंसिंग के लिए हम लोड बैलेंसर यूज़ करेंगे। IP एनोनिमिटी IPपी एनोनिमिटी आईपी मास्किंग लॉगिंग कैशिंग
कैशिंग एसएसएल टर्मिनेशन ये सब फीचर्स के लिए हम रिवर्स प्रॉक्सी यूज़ करेंगे। तो तो ये था हमारा लेक्चर फोर जिसमें हमने देखा
प्रॉक्सी सर्वर रिवर्स प्रॉक्सी। हमने इनसे जुड़े कुछ क्वेश्चंस भी डिस्कस किए। तो आई होप अब आपको प्रॉक्सी और रिवर्स
प्रॉक्सी अच्छे से समझ आ गया है। एंड यस दिस इज ऑल फॉर दिस वीडियो। वी विल सी यू इन द नेक्स्ट वीडियो। सो टिल देन बय शो सम
लव। थैंक्स। [संगीत] हे एवरीवन वेलकम बैक। वेलकम टू दिस
अल्टीमेट सिस्टम डिज़ प्लेलिस्ट सीरीज। और आज के इस वीडियो में हम बात करने वाले हैं नेटवर्किंग प्रोटोकॉल्स के बारे में
जिसमें मेनली हमारा फोकस होने वाला है ट्रांसपोर्ट लेयर के प्रोटोकॉल्स में और एप्लीकेशन लेयर के प्रोटोकॉल्स में। तो
स्टार्ट करते हैं और समझते हैं कि ये नेटवर्किंग प्रोटोकॉल्स है क्या? इसकी हमें क्या नीड है और कैसे डिफरेंट लेयर के
प्रोटोकॉल्स साथ में काम करते हैं और कैसे हमारी हेल्प करते हैं। तो स्टार्ट करते हैं और समझते हैं कि नेटवर्किंग
प्रोटोकॉल्स होता क्या है? लेट मी जस्ट मिनिमाइज माय वीडियो ताकि पूरी स्क्रीन आपको विज़िबल हो।
ओके? तो सबसे पहले ये डेफिनेशन देखते हैं कि नेटवर्किंग प्रोटोकॉल्स आर द सेट ऑफ रूल्स एंड कन्वेंशंस दैट गवर्न्स हाउ डेटा
इज़ ट्रांसमिटेड एंड रिसीव्ड अक्रॉस अ नेटवर्क। तो बेसिकली ये नेटवर्किंग प्रोटोकॉल्स हमें बताते हैं कि ओवर द
इंटरनेट ओवर द नेटवर्क दो डिवाइसेस के बीच में डेटा कैसे ट्रांसफर होना चाहिए, कैसे रिसीव होना चाहिए। तो बेसिकली हम कह सकते
हैं कि ये नेटवर्किंग प्रोटोकॉल्स हमें बताते हैं कि ओवर द नेटवर्क ओवर द इंटरनेट दो डिवाइसेस आपस में कैसे कम्युनिकेट
करेंगी। तो ये काम होता है हमारे नेटवर्किंग प्रोटोकॉल्स का। अब इन ने नेटवर्किंग प्रोटोकॉल्स की नीड क्या है और
कैसे ये डिफरेंट लेयर के नेटवर्किंग प्रोटोकॉल्स साथ में काम करते हैं। तो एक बार इसे समझते हैं। तो हमारे ओएसआई मॉडल
में कुछ हमारे पास डिफरेंट लेयर्स होती है। हमारे पास सेवन डिफरेंट लेयर्स होती हैं। उन सेवन डिफरेंट लेयर्स में एक हमारे
पास होती है नेटवर्क लेयर। नेटवर्क लेयर। एक हमारे पास होती है ट्रांसपोर्ट लेयर।
और एक होती है हमारे पास एप्लीकेशन लेयर। अब यह तीन मैंने मेंशन क्यों किए हैं? क्योंकि यहां पे हम इन तीनों को यूज़ करने
वाले हैं। बेसिकली हम इन तीनों के प्रोटोकॉल्स को डिस्कस करने वाले हैं। तो नेटवर्क लेयर में हमारे पास IPV4
और IPV6 प्रोटोकॉल्स होते हैं। IPV4 और IPV6। तो ये नेटवर्किंग प्रोटोकॉल्स हमें बेसिकली राउटिंग और IP एड्रेसिंग में
हेल्प करते हैं। उसके बाद हमारा आ जाता है TCP प्रोटोकॉल और यूडीपी प्रोटोकॉल। ये प्रोटोकॉल्स होते हैं हमारे ट्रांसपोर्ट
लेयर में और एप्लीकेशन लेयर में हमारे पास क्लाइंट सर्वर प्रोटोकॉल्स होते हैं। क्लाइंट सर्वर प्रोटोकॉल्स। इन क्लाइंट
सर्वर प्रोटोकॉल्स में हमारे पास HTTP प्रोटोकॉल होता है, HTTPS होता है, वेब सॉकेट्स होता है। तो कई बार लोग कंफ्यूज
हो जाते हैं कि वेब सॉकेट एक पीियर टू पीियर प्रोटोकॉल है। बट इट इज़ नॉट वो पीियर टू पीियर प्रोटोकॉल नहीं है। वो
क्लाइंट सर्वर प्रोटोकॉल है। तो यहां पे एक हमारा हो जाता है वेब सॉकेट। उसके बाद अह एप्लीकेशन लेयर प्रोटोकॉल्स में ही एक
हमारे पास होता है पीियर टू पीियर प्रोटोकॉल। पीियर टू पीियर और इस पीियर टू पीियर प्रोटोकॉल में हमारे पास होता है
वेब आरटीसी। तो यह ऐसे हमारे पास डिफरेंट लेयर के डिफरेंट नेटवर्किंग प्रोटोकॉल्स होते हैं।
तो अब समझते हैं एक एग्जांपल के थ्रू कि कैसे ये डिफरेंट लेयर के नेटवर्किंग प्रोटोकॉल्स साथ में काम करते हैं। तो
लेट्स से कि आप WhatsApp एप्लीकेशन यूज कर रहे हैं। यह आपकी डिवाइस है। लेट्स से दिस इज़ योर डिवाइस एंड दिस इज़ योर फ्रेंड्स
डिवाइस। अब आपको WhatsApp के थ्रू आपको एक मैसेज भेजना है अपने फ्रेंड को। लेट्स से हाय हाउ आर यू? ऐसा कुछ मैसेज आपको अपने
फ्रेंड को भेजना है। तो जो सबसे पहला टास्क हमारे लिए होगा वो होगा कि हमें ओवर द नेटवर्क ओवर द इंटरनेट हमारे फ्रेंड की
डिवाइस को ढूंढना है। राइट? बेसिकली यहां से हमें मैसेज को यहां भेजना है। तो जो हमारा सबसे पहला काम होगा वो यह होगा
कि हम इस डिवाइस को या इस डिवाइस के IPपी एड्रेस को फाइंड करें। राइट? क्योंकि ओवर द इंटरनेट ओवर द नेटवर्क तो बहुत सारी
डिवाइसेस हैं। अ हर डिवाइस के अपने-अपने IPपी एड्रेस हैं। तो हमें सबसे पहले फाइंड आउट करना होगा इस डिवाइस को या इस डिवाइस
के IPपी एड्रेस को ताकि हम जो भी हमें मैसेज भेजना है लेट्स से हाय मैसेज। तो यह हम सही जगह मैसेज को भेज सकें। इसके लिए
जो हमारा सबसे पहला काम होगा वो होगा डिवाइस को फाइंड करना। अपने फ्रेंड की डिवाइस को फाइंड करना। तो अब अपने फ्रेंड
की डिवाइस को फाइंड करने के लिए यहां पे हमारा नेटवर्क प्रोटोकॉल्स, नेटवर्क लेयर के प्रोटोकॉल्स, IPV4 और IPV6 प्रोटोकॉल
हमारी हेल्प करते हैं। क्यों? क्योंकि ये IPV6 प्रोटोकॉल और IPV4 प्रोटोकॉल राउटिंग में और IP एड्रेसिंग में हेल्प करते हैं।
तो ये काम होता है हमारा नेटवर्क लेयर के प्रोटोकॉल्स का। यह बेसिकली ओवर द नेटवर्क ओवर द इंटरनेट हमें दूसरी डिवाइस या
रिक्वायर्ड डिवाइस का IP एड्रेस हमें लाके देते हैं। तो ये यहां पे काम आते हैं हमारे नेटवर्क लेयर के प्रोटोकॉल्स। अब
केवल IPपी एड्रेस फाइंड करना इज नॉट इनफ। तो अब हमें क्या होता है कि हमें इस डिवाइस से इस डिवाइस पे मैसेज भेजना है।
अब हमने पढ़ा है सबने देखा है कि ये मैसेज हम डायरेक्ट इस डिवाइस से इस डिवाइस पे नहीं भेज सकते। बीच में हमें सर्वर्स की
नीड होगी। राइट? तो लेट्स से ये हमारी डिवाइस ए है। यह हमारे फ्रेंड की डिवाइस है। डिवाइस बी। तो यहां पे हम डायरेक्ट
मैसेज को हाय मैसेज को डिवाइस बी को नहीं भेज सकते। हमें सर्वर की नीड होगी। राइट? तो ये हो गया हमारा सर्वर। बेसिकली ये
हमारे WhatsApp के सर्वर्स हो गए। तो सबसे पहले हम इस मैसेज को सर्वर को भेजेंगे। WhatsApp के सर्वर को
भेजेंगे। इंक्रिप्टेड फॉर्म में हमारा मैसेज एज इंक्रिप्टेड फॉर्म में जाएगा सर्वर के पास। उसके बाद यह सर्वर इस
इंक्रिप्टेड मैसेज को भेज देगा इस डिवाइस बी को। फिर ये डिवाइस भी उस मैसेज को डिक्रिप्ट करके रीड कर लेगा। तो बेसिकली
हम कह सकते हैं कि हम डायरेक्ट मैसेज डिवाइसेस के बीच में ट्रांसफर नहीं करने वाले। हम मैसेज को वाया सर्वर भेजेंगे। तो
हमने अब IPपी एड्रेस तो फाइंड कर लिया हमारी डिवाइस बी का। लेकिन ओवर द इंटरनेट ओवर द नेटवर्क केवल IPपी एड्रेस फाइंड
करना इज़ नॉट इनफ। तो हमें सबसे पहले मैसेज भेजना है इस सर्वर को। तो हमारे पास एक रिलायबल पाथ होना चाहिए फ्रॉम डिवाइस ए टू
सर्वर। राइट? तभी हम इस मैसेज को इस सर्वर को भेज पाएंगे और फिर यह सर्वर इस मैसेज को डिवाइस बी को भेजेगा। तो यहां हमें नीड
आती है एक रिलायबल पाथ की। रिलायबल पाथ की और एक सिक्यर्ड कनेक्शन की बिटवीन दिस डिवाइस एंड सर्वर। क्यों? क्योंकि जब इन
इस डिवाइस और सर्वर के बीच में एक कनेक्शन इस्टैब्लिश होगा तभी तो हम अपने मैसेज इस इस सर्वर को भेज पाएंगे। राइट? WhatsApp
सर्वर को भेज पाएंगे। राइट? तो नेक्स्ट जो हमें नीड आती है वो आती है रिलायबल पाथ की और एक सिक्यर्ड कनेक्शन की। सिक्यर्ड
कनेक्शन की। तो अब यह रिलायबल पाथ और सिक्यर्ड कनेक्शन हमें कौन प्रोवाइड करता है? तो ये रिलायबल पाथ और सिक्यर्ड
कनेक्शन हमें ट्रांसपोर्ट लेयर के प्रोटोकॉल्स प्रोवाइड करते हैं। जिसमें हमारे पास होता है टीसीp प्रोटोकॉल और
यूडीपी प्रोटोकॉल। ओके? तो अब हमारे नेटवर्क लेयर के प्रोटोकॉल ने हमें IP एड्रेस दे दिया। इन्होंने हमें IP
एड्रेसिंग और राउटिंग में हेल्प की। ट्रांसपोर्ट लेयर ने हमें एक सिक्यर्ड कनेक्शन दे दिया और रिलायबल पाथ दे दिया
फ्रॉम दिस डिवाइस A टू सर्वर। बेसिकली यह ट्रांसपोर्ट लेयर के प्रोटोकॉल्स हमें बताएंगे कि हाउ डेटा शुड ट्रैवल बिटवीन
दिस क्लाइंट एंड दिस सर्वर। तो ये काम होगा हमारे ट्रांसपोर्ट लेयर के प्रोटोकॉल्स का। ओके? तो अब हमारे पास IP
एड्रेस भी है हमारे सर्वर का और हमारे क्लाइंट बी का या डिवाइस बी का और हमारे पास एक सिक्यर्ड रिलायबल कनेक्शन भी है,
रिलायबल पाथ भी है। अब क्वेश्चन यह आता है कि हाउ एग्जैक्टली आई वुड से हाय हाउ आर यू टू माय फ्रेंड किस फ़ॉर्मेट में यह होगा
और कैसे हम उस फॉर्मेट को मैनेज करेंगे ताकि दोनों एप्स इसे समझ सकें। तो दैट्स वेयर द एप्लीकेशन लेयर प्रोटोकॉल कम्स इन।
अब एप्लीकेशन लेयर में हमारे पास डिफरेंट प्रोटोकॉल्स होते हैं। हमारे पास HTTP होता है। हमारे पास HTTPS होता है। तो अब
ये हमारे HTTP और HTTPS प्रोटोकॉल ये सब प्रोटोकॉल डिफाइन करते हैं रूल्स ऑफ कॉन्वर्सेशन बिटवीन एप्लीकेशनेशंस। अब
WhatsApp में हम वेब सॉकेट कम्युनिकेशन या वेब सॉकेट प्रोटोकॉल का यूज़ करते हैं। वो हम देखेंगे आगे कि यह वेब सॉकेट प्रोटोकॉल
होता क्या है? पर इन ऑर्डर टू कम्युनिकेट या हम कह सकते हैं कि क्लाइंट और सर्वर के बीच में कम्युनिकेशन के लिए हम वेब सॉकेट
प्रोटोकॉल का यूज़ करते हैं WhatsApp में। तो अब ये हमारा एप्लीकेशन लेयर के प्रोटोकॉल्स हमें बताते हैं कि मैसेज
एक्चुअल में डिलीवर कैसे होगा। तो ये होता है हमारे एप्लीकेशन लेयर के प्रोटोकॉल। अब हमने देखा कि नेटवर्क लेयर के प्रोटोकॉल
हमें क्या बता रहे हैं? यह हमें डिवाइस फाइंड करके दे रहे हैं। दे फाइंड्स द डिवाइस। फाइंड्स द डिवाइस। उसके
बाद जो हमारे ट्रांसपोर्ट लेयर के प्रोटोकॉल हैं, यह एक रिलायबल पाथ क्रिएट कर रहे हैं और
यह सिक्यर्ड सिक्यर्ड कनेक्शन इस्टैब्लिश कर रहे हैं बिटवीन क्लाइंट एंड सर्वर। तो, यहां पे
यह ट्रांसपोर्ट लेयर के प्रोटोकॉल दे क्रिएट्स अ पाथ। और जो एप्लीकेशन लेयर के प्रोटोकॉल हैं,
वह हमें क्या बता रहे हैं कि मैसेज एक्चुअल में कैसे डिलीवर होगा। तो डिलीवर द एक्चुअल मैसेज
एक्चुअल मैसेज। तो ये हमारे डिफरेंट लेयर्स के प्रोटोकॉल्स और हमने देखा कि कैसे ये डिफरेंट लेयर्स के प्रोटोकॉल साथ
में काम करते हैं। अब देखते हैं ट्रांसपोर्ट लेयर के प्रोटोकॉल्स क्योंकि इस लेक्चर में हमारा टारगेट होने वाला है
ट्रांसपोर्ट लेयर के प्रोटोकॉल्स और एप्लीकेशन लेयर के प्रोटोकॉल्स को कवर करना। तो ट्रांसपोर्ट लेयर में हमारे पास
होते हैं TCP प्रोटोकॉल और यूडीपी प्रोटोकॉल। तो अब TCP प्रोटोकॉल को सबसे पहले समझते हैं। तो ये जो TCP प्रोटोकॉल
होता है ये एक रिलायबल कनेक्शन प्रोवाइड करता है। रिलायबल कनेक्शन और यहां पे हमारे जो भी पैकेट्स बेसिकली
हम डेटा को पैकेट्स के फॉर्म में डिलीवर करते हैं। तो जो भी हमारे पैकेट्स की डिलीवरी होगी वो एक ऑर्डर में होती है। तो
पैकेट्स की जो डिलीवरी होगी हमारे वो एक ऑर्डर में होगी। एक सीक्वेंस में होगी और यह टीसीp प्रोटोकॉल मेक श्योर करता है कि
हर पैकेट एव्री पैकेट शुड बी डिलीवर्ड। मतलब ऐसा नहीं होना चाहिए कि लेट्स से हमने कोई पैकेट डिलीवर के लिए भेजा और वह
डिलीवर नहीं हुआ तो हम ऐसे ही उसे छोड़ दें। तो बेसिकली हम कह सकते हैं कि यह जो टीसीp प्रोटोकॉल होता है, यह मेक श्योर
करता है कि पैकेट डिलीवर हो ही। तो यहां पर हम कह सकते हैं कि डिलीवरी पैकेट्स यहां पर डिलीवर होगा ही। तो यह होता है
हमारा TCP प्रोटोकॉल। अब ये TCP प्रोटोकॉल में इस रिलायबल कनेक्शन के लिए हम थ्री वे हैंडशेक टेक्निक का यूज़ करते हैं। अब ये
थ्री वे हैंडशेक टेक्निक क्या होती है? तो इसमें सबसे पहला पॉइंट होता है कि क्लाइंट और सर्वर एक दूसरे को इंट्रोड्यूस करते
हैं। लेट्स से कि यह हमारे पास एक क्लाइंट है। तो यह हमारा हो गया क्लाइंट और यहां पे हो गया हमारा सर्वर। तो सबसे पहले एक
दूसरे को वो इंट्रोड्यूस करेंगे। जो दूसरा पॉइंट होता है वो यह कि दे एग्री ऑन हाउ दे विल टॉक। तो यहां वो सीक्वेंस नंबर
शेयर करते हैं और पोर्ट शेयर करते हैं। थर्ड होता है कि वो दोनों कंफर्म करते हैं कि ठीक है वी बोथ आर रेडी फॉर
कम्युनिकेशन। तो इसे एक एग्जांपल के थ्रू समझते हैं। तो सबसे पहले यह क्लाइंट एक कनेक्शन रिक्वेस्ट भेजेगा इस सर्वर को।
लेट्स से कि यह क्लाइंट आप हैं। दिस इज़ यू। एंड यह जो सर्वर है, यह आपका फ्रेंड है। तो, सबसे पहले यह क्लाइंट क्या करेगा?
यह कनेक्शन रिक्वेस्ट भेजेगा और लेट्स से यह बोलेगा हे हाउ आर यू? तो यहां पे बेसिकली हमने कॉन्वर्सेशन को स्टार्ट किया
और यहां हम एक कोई ऐसा रैंडम सीक्वेंस नंबर शेयर करेंगे सर्वर से। अब उसके बाद सर्वर बोलेगा लेट्स से आपका फ्रेंड बोलेगा
कि यस आई एम हियर आर यू रेडी? तो यह वो ऐसे एक एकनॉलेजमेंट सेंड करेगा और वहां यहां पे वो अपना भी एक सीक्वेंस नंबर शेयर
करेगा। अपना भी सीक्वेंस नंबर शेयर करेगा। और यहां हम सर्वर के रिस्पांस पे एक और एकनॉलेजमेंट सेंड करेंगे इस सर्वर को। तो
यहां पे ये थ्री डिफरेंट वेज़ में या थ्री डिफरेंट स्टेप्स में हमारा यह प्रोसेस कंप्लीट हुआ रिलायबल कनेक्शन इस्टैब्लिश
करने का। तो इसीलिए हम इसे बोलते हैं थ्री वे हैंडशेक। तो अब जैसे ही ये क्लाइंट ने सर्वर को एक और एकनॉलेजमेंट सेंड किया तो
हम कह सकते हैं कि अब दोनों ही साइड ये क्लाइंट एंड सर्वर दे बोथ आर रेडी फॉर कम्युनिकेशन और यहां फिर यहां फिर हम एक
क्लाइंट और सर्वर के बीच में कनेक्शन ओपन कर देंगे। तो यह होता है हमारा रिलायबल कनेक्शन थ्रू अह थ्री वे हैंडशेक। तो अब
इस टीसीp प्रोटोकॉल में क्या होता है कि क्लाइंट और सर्वर के बीच में लेट्स से ये क्लाइंट है और ये सर्वर है। तो यहां डेटा
को हम पैकेट्स के फॉर्म में सेंड करते हैं। और हर पैकेट के लिए हर डेटा पैकेट के लिए
सर्वर एक एकनॉलेजमेंट सेंड करता है। लेट्स से यहां हमने एक डेटा पैकेट सेंड किया। डेटा पैकेट सेंड किया। तो हर डेटा पैकेट
के लिए सर्वर एकनॉलेजमेंट सेंड करता है। अब लेट्स से कि बिकॉज़ ऑफ सम एक्स वz रीजन कोई डेटा पैकेट अच्छे से या सही से सर्वर
तक डिलीवर नहीं हुआ। तो इस केस में ऐसा नहीं होगा कि हम उसे छोड़ देंगे या उस पैकेट को डेटा पैकेट को वापस दोबारा सेंड
नहीं करेंगे। तो TCP प्रोटोकॉल में TCP कनेक्शन में यदि कोई डाटा पैकेट सही से डिलीवर नहीं हुआ तो इस केस में क्लाइंट
उसे रिसेंड करता है। वापस से उसे भेजता है सर्वर को और सर्वर फिर उस पैकेट के लिए एकनॉलेजमेंट सेंड करता है। तो यहां हम मेक
श्योर करते हैं कि हमारा हर पैकेट अच्छे से डिलीवर हो सर्वर तक। तो यहां डिलीवरी इज़ मस्ट। या हम डिलीवरी पर फोकस करते हैं।
और दूसरी चीज क्या होती है कि यहां पे हर पैकेट का एक सीक्वेंस होता है। यहां हम ऑर्डर मेंटेन करते हैं पैकेट्स के सेंड
होने का। हम ऑर्डर या सीक्वेंस मेंटेन करते हैं। तो लेट्स से कि यहां पे हमारे पास थ्री डिफरेंट डेटा पैकेट्स हैं। तो यह
एक ऑर्डर में डिलीवर होंगे और हर और हर पैकेट का एक सीक्वेंस नंबर होता है। तो यहां पे हम ऑर्डर पे भी फोकस कर रहे हैं
या सीक्वेंस पे भी फोकस कर रहे हैं। तो ये होता है हमारा TCP प्रोटोकॉल। अब यूडीपी प्रोटोकॉल इसका एकदम अपोजिट
होता है टीसीp प्रोटोकॉल का। तो यूडीपी प्रोटोकॉल इज़ कनेक्शन। यहां पे हम यहां पे बेसिकली थ्री वे हैंडशेक जैसा कुछ नहीं
होता। तो यह कनेक्शन है। यह अनरिलायबल है। अनरिलायबल है। अब इसका क्या मतलब है? कि लेट्स से डेटा हम सेंड कर रहे हैं। डेटा
पैकेट्स सेंड कर रहे हैं और लेट्स से कि कोई एक डेटा पैकेट सही से सेंड नहीं हुआ। डेटा पैकेट इज़ लॉस्ट। तो इस केस में कोई
भी उस डेटा पैकेट को दोबारा सेंड करने का ट्राई नहीं करता। तो हम कह सकते हैं कि ये अनरिलायबल है, कनेक्शन लेस है क्योंकि
यहां पे कोई कुछ भी थ्री वे हैंडशक जैसा नहीं है। सीधे हम डेटा पैकेट्स को स्टार सेंड करना स्टार्ट कर देते हैं। सो दिस इज़
कनेक्शन लेस। उसके बाद यहां पे कोई भी हम ऑर्डर मेंटेन नहीं करते कि डेटा पैकेट से एक ऑर्डर में या एक सीक्वेंस में जाएंगे।
तो यहां हम ऑर्डर मेंटेन जैसा भी कुछ नहीं है। तो अब यह यूडीपी प्रोटोकॉल क्योंकि अनरिलायबल है। यहां पे डेटा पैकेट्स को
दोबारा सेंड नहीं करना अ यह ऑर्डर भी मेंटेन नहीं करता। तो इस वजह से यह यूडीपी प्रोटोकॉल फास्ट बन जाता है। यूडीपी
प्रोटोकॉल फास्ट बन जाता है। और जो हमारा टीसीp प्रोटोकॉल है वो फास्ट नहीं होता। क्यों? क्योंकि यहां पे हम डिलीवरी को देख
रहे हैं कि सही से हर पैकेट डिलीवर हो रहा है या नहीं। बेसिकली यह टीसीपी प्रोटोकॉल रिलायबल होता है। तो यहां हर डिलीवरी हर
पैकेट की डिलीवरी पे ध्यान दिया जाता है। उसके बाद यहां हम ऑर्डर या सीक्वेंस भी मेंटेन करते हैं। तो इस वजह से ये टीसीपी
प्रोटोकॉल थोड़ा स्लो होता है। और यूडीपी प्रोटोकॉल इसका एकदम अपोजिट है। ये अनरिलायबल है। यहां ऑर्डर मेंटेन नहीं
करते। कनेक्शन लेस है। तो इस वजह से यूडीपी प्रोटोकॉल फास्ट होता है। तो ये था हमारा यूडीपी प्रोटोकॉल। अब यह यूडीपी
प्रोटोकॉल का हम यूज करते हैं वीडियो कॉल में, वीडियो स्ट्रीमिंग में, वीडियो कॉल में, वीडियो स्ट्रीमिंग में, वीडियो गेम्स
में। तो इन जगहों पर हम यूडीपी प्रोटोकॉल का यूज करते हैं। तो अब लेट्स से कि आप आपके फ्रेंड के साथ वीडियो कॉल कर रहे
हैं। तो ऐसा होता है कि बिकॉज़ ऑफ सम नेटवर्क इशू या किसी और वजह से कई बार कुछ फ्रेम्स मिस हो जाते हैं। कुछ फ्रेम्स मिस
हो जाते हैं। तो हम कह सकते हैं कि डेटा पैकेट्स मिस हो जाते हैं। तो क्या वो डेटा पैकेट्स या फ्रेम्स वापस से आपको देखने को
मिलते हैं? नहीं। उस पे जोर नहीं दिया जाता। हमारा वीडियो कॉल कंटिन्यू चालू रहता है। यूडीपी डाटा पैकेट्स को सेंड
करते रहता है। और जो लॉस्ट होते जा रहा है, जो फ्रेम्स मिस होते जा रहे हैं, तो उस पे वह ध्यान नहीं देता। और सिमिलरली
ऐसे ही यहां पे ऑर्डरिंग भी मेंटेन नहीं होती। लेट्स से बिकॉज़ ऑफ़ सम ग्लिच, कोई ग्लिच की वजह से कोई फ्रेम्स आगे पीछे चले
गए। तो, यहां पे यह भी मैटर नहीं करता। लेट्स से फ्रेम वन को पहले आना था, लेकिन, फ्रेम टू पहले चला गया। तो यहां पे इसका
भी ज्यादा कुछ फर्क नहीं पड़ता। तो ये होता है हमारा यूडीपी प्रोटोकॉल। तो अब हमने डिस्कस कर लिया हमारे ट्रांसपोर्ट
लेयर के प्रोटोकॉल्स। अब हम डिस्कस करते हैं हमारे एप्लीकेशन लेयर के प्रोटोकॉल्स को। तो एप्लीकेशन लेयर के प्रोटोकॉल्स में
हमारे पास होते हैं क्लाइंट सर्वर प्रोटोकॉल, क्लाइंट सर्वर प्रोटोकॉल और एक हमारे पास
होता है पीियर टू पीियर प्रोटोकॉल। पीियर टू पीियर प्रोटोकॉल। तो आप सबसे पहले समझते हैं क्लाइंट सर्वर प्रोटोकॉल्स को।
तो यह जो क्लाइंट सर्वर प्रोटोकॉल्स होते हैं, यह डिफाइन करते हैं कि कैसे क्लाइंट और सर्वर डेटा एक्सचेंज करेंगे। कैसे इनके
बीच में कम्युनिकेशन होगा। तो, यह क्लाइंट सर्वर प्रोटोकॉल में एक यहां हमारे पास क्लाइंट होता है और एक यह हमारे पास सर्वर
होता है। तो क्लाइंट सर्वर प्रोटोकॉल में क्लाइंट मेक्स अ रिक्वेस्ट। क्लाइंट हमेशा रिक्वेस्ट करता है और सर्वर उस रिक्वेस्ट
के लिए रिस्पांस देता है। तो यहां पे क्लाइंट हमेशा कनेक्शन इस्टैब्लिश करता है। सर्वर कभी भी सामने से रिस्पांस नहीं
देता। वो हमेशा रिस्पांस तभी देता है जब क्लाइंट रिक्वेस्ट करता है। तो इट इज़ अ वन वे कम्युनिकेशन काइंड ऑफ़ प्रोटोकॉल। तो
यहां हमें हमारे पास क्लाइंट हमेशा रिक्वेस्ट को इनिशिएट करेगा या कनेक्शन को इनिशिएट करेगा और सर्वर उस रिक्वेस्ट के
लिए रिस्पांस सेंड करेगा। तो इस क्लाइंट सर्वर प्रोटोकॉल में हमारे आ जाते हैं http प्रोटोकॉल, https
हमारे पास एफटीपी है जो कि फाइल ट्रांसफर के लिए यूज़ होता है। हमारे पास एसएमटीपी हैं। तो दे ऑल बेस्ड ऑन क्लाइंट सर्वर
प्रोटोकॉल। तो इन सब में क्या होता है कि ये वन वे कम्युनिकेशन प्रोटोकॉल्स हैं। जहां हमेशा क्लाइंट रिक्वेस्ट इनिशिएट
करेगा या कनेक्शन इनिशिएट करेगा। अब जो हमारा वेब सॉकेट है वो भी है क्लाइंट सर्वर प्रोटोकॉल ही लेकिन ये थोड़ा
डिफरेंट है। ये बायरेक्शनल होता है। जो हमारे ये प्रोटोकॉल्स थे http, https, एफटीपी, एसएमटीपी ये यूनडायरेक्शनल थे।
यहां पे हमेशा क्लाइंट रिक्वेस्ट इनिशिएट करता है। क्लाइंट कनेक्शन इनिशिएट करता है और सर्वर फिर रिस्पांस देता है और यहां
हमारा कनेक्शन क्लोज हो जाता है। लेकिन वेब सॉकेट जो है वो हमारा बायडायरेक्शनल है। अब वेब सॉकेट में क्या होता है कि
सर्वर और क्लाइंट लेट्स से ये हमारा क्लाइंट है। यह हमारा सर्वर है। तो वेब सॉकेट में क्लाइंट और सर्वर एक दूसरे को
इंडिपेंडेंटली मैसेजेस भेज सकते हैं। यहां जरूरी नहीं है कि यह सर्वर तभी रिस्पांस देगा जब क्लाइंट रिक्वेस्ट करेगा। यदि
सर्वर के पास इस क्लाइंट के लिए कुछ मैसेज है तो वह सामने से भी मैसेज कर सकता है। अब इन प्रोटोकॉल्स में क्या हो रहा था कि
लेट्स से इस सर्वर के पास यदि कुछ इंफॉर्मेशन है भी इस क्लाइंट के लिए तो भी यह तभी रिस्पांस देगा जब यह क्लाइंट
रिक्वेस्ट करेगा। लेकिन वेब सॉकेट में यदि इस सर्वर के पास लेट्स से कुछ इंफॉर्मेशन है इस क्लाइंट के लिए तो वो सामने से भी
मैसेज कर सकता है। इस इस वेब सॉकेट कम्युनिकेशन में यह जरूरी नहीं है कि क्लाइंट को हर बार रिक्वेस्ट करना पड़े।
तो ये होता है हमारा वेब सॉकेट कनेक्शन। अब यहां हमारे http, https, एफटीपी और एसएमटीपी यह होते हैं यूनीडरेक्शनल और यह
वेब सॉकेट होता है हमारा बायडरेक्शनल। इस वेब सॉकेट प्रोटोकॉल का यूज हम WhatsApp, Telegram जैसे एप्लीकेशन बनाने
में करते हैं। तो लेट्स से यह हम एक यूजर है। हमारा यूजर ए है WhatsApp का। यह यूजर बी है। और यहां हमारे पास लेट्स से
WhatsApp का सर्वर है। तो हम क्या करते हैं? सर्वर और क्लाइंट के बीच में या यूजर के बीच में एक वेब सॉकेट कनेक्शन
इस्टैब्लिश कर देते हैं। उससे क्या होता है कि वेब सॉकेट कनेक्शन इस्टैब्लिश हो जाने के बाद अब यह क्लाइंट और सर्वर एक
दूसरे को इंडिपेंडेंटली मैसेज भेज सकते हैं। तो यह क्लाइंट इस सर्वर को इंडिपेंडेंटली मैसेज भेज सकता है और यह
सर्वर क्लाइंट को इंडिपेंडेंटली मैसेज भेज सकता है। और इस सर्वर को वेट नहीं करना पड़ेगा इस क्लाइंट के रिक्वेस्ट करने के
लिए। यदि उसके पास कुछ मैसेज है इस क्लाइंट ए के लिए तो वो सामने से ही रिस्पांस भेज सकता है। तो यह होता है
हमारा वेब सॉकेट कम्युनिकेशन या वेब सॉकेट प्रोटोकॉल। अब हम देखते हैं http और https तो ये http https प्रोटोकॉल दे आर
रिस्पांसिबल फॉर द कंटेंट ऑफ योर वेब रिक्वेस्ट लाइक आस्किंग फॉर अ वेब पेज और सेंडिंग लॉग इन इनेशन तो लेट्स से आप कोई
एप्लीकेशन यूज़ लेट्स से Amazon या कोई और ई-कॉमर्स एप्लीकेशन तो वहां पे हम लॉगिन इनेशन से लॉगिन इनेशन सेंड करते हैं। लॉग
इन के लिए हम अपने पासवर्ड और ईमेल एड्रेस प्रोवाइड करते हैं। तो ये सारी रिक्वेस्ट होती हैं। ये होती हैं थ्रू http।
अब ये हो गया हमारा एचटीटीp कनेक्शन। अब ये HTTP प्रोटोकॉल हमारा अनइंक्रिप्टेड फॉर्म में डेटा भेजता है। तो जो हमारी
रिक्वेस्ट होती है वो अनइंक्रिप्टेड फॉर्म में जाती है। तो इस वजह से क्या होता है? डिफरेंट अटैक्स होने का हमें डर रहता है।
तो जो भी हमारे बड़े एप्लीकेशनेशंस होते हैं उसमें हम HTTPS का यूज़ करते हैं। HTTPS स्टैंड्स फॉर हाइपर टेक्स्ट
ट्रांसफर प्रोटोकॉल और एस का मतलब होता है सिक्योर। तो हम HTTP प्रोटोकॉल को जब सिक्योर कर देते हैं
थ्रू एसएसएल और टीएलएस। टीएलएस स्टैंड्स फॉर ट्रांसपोर्ट लेयर सिक्योरिटी। तो ये इंक्रिप्शन लेयर हम ऐड कर देते हैं थ्रू
टीएलएस जो हमें एक सिक्योर कम्युनिकेशन प्रोवाइड करता है ओवर द नेटवर्क। तो अब टी http में क्या हो रहा था कि जो भी हम
रिक्वेस्ट कर रहे थे वो अनइंक्रिप्टेड फॉर्म में जा रही थी। लेकिन https में हमने क्या किया कि एसएसएल और टीएलएस का
यूज़ करके एक इंक्रिप्शन लेयर ऐड कर दी। तो अब हमारे HTTPS में जो भी रिक्वेस्ट जाएगी वह वह इंक्रिप्टेड डाटा के फॉर्म में
जाएगी। तो यह होते हैं हमारे HTTP और HTTPS प्रोटोकॉल। अब एफटीपी प्रोटोकॉल हमारा होता है फाइल ट्रांसफर के लिए।
एसएमटीपी होता है हमारा मेल के लिए। तो एफटीपी हो गया हमारा फाइल ट्रांसफर के लिए। यह भी एक क्लाइंट सर्वर प्रोटोकॉल
है। और एसएमटीपी जो होता है हमारा वह होता है मेल के लिए। मेल सेंड करने के लिए, मेल सेंड के लिए और वेब सॉकेट हमने डिस्कस
कर ही लिया कि जो हमारा वेब सॉकेट होता है, यह WhatsApp और Telegram जैसे एप्लीकेशन बनाने में यूज़ हम करते हैं।
जहां हमें बायडायरेक्शनल कम्युनिकेशन की नीड होती है। तो, यह हो गए हमारे क्लाइंट सर्वर प्रोटोकॉल्स। अब आपने अक्सर सुना
होगा कि जो हमारा HTTP और HTTPS है यह TCP बेस्ड है। TCP प्रोटोकॉल बेस्ड है। तो इसका क्या मतलब होता है? तो इसका ये मतलब
होता है कि अब ये हमारे क्या है? ये हमारे एप्लीकेशन लेयर प्रोटोकॉल्स हैं। राइट? जिसके जिसके थ्रू हम डेटा को सेंड करेंगे
जिसके थ्रू हमारे डेटा की एक्चुअल डिलीवरी होगी। तो ये होता है हमारा डिलीवरी के लिए प्रोटोकॉल्स और टीसीp होता है हमारा
कनेक्शन स्टैब्लिश करने के लिए रिलायबल कनेक्शनस्टैब्लिश करने के लिए। तो अक्सर हमने सुना है कि हम बोलते हैं http और
https टीसीp बेस्ड प्रोटोकॉल है। तो इसका ये मतलब होता है कि http और https के थ्रू डेटा सेंड करने के पहले क्लाइंट और सर्वर
के बीच में एक थ्री वे हैंडशेक होता है जिसके थ्रू वो एक रिलायबल कनेक्शन या कम्युनिकेशन इस्टैब्लिश करते हैं और फिर
हम डेटा को या कोई भी रिक्वेस्ट को सेंड करते हैं थ्रू एचटीटीp और एचटीटीपीएस प्रोटोकॉल। तो ये मतलब होता है हमारा जब
हम सुनते हैं कि HTTP और HTTPS TCP बेस्ड प्रोटोकॉल है। तो इसका ये मतलब होता है। तो अब हमने देख लिया हमारे क्लाइंट सर्वर
प्रोटोकॉल्स। अब जो हमारा नेक्स्ट है वो है पीियर टू पीियर प्रोटोकॉल। पीियर टू पीियर प्रोटोकॉल। तो अब इस पीियर टू पीियर
प्रोटोकॉल में क्या होता है कि यहां पे क्लाइंट और सर्वर के बीच में कोई डिस्क्रिमिनेशन नहीं होता। क्लाइंट सर्वर
के बीच में कोई डिस्क्रिमिनेशन नहीं होता। हर कोई एक दूसरे को मैसेज सेंड कर सकता है। लेट्स से यहां पर हमारे पास दो
क्लाइंट हैं। क्लाइंट ए एंड क्लाइंट बी। तो पीियर टू पीियर में कोई भी किसी को भी इंडिपेंडेंटली मैसेजेस भेज सकता है। कोई
भी किसी को भी इंडिपेंडेंटली मैसेज भेज सकता है। तो यह होता है हमारा पीियर टू पीियर प्रोटोकॉल। क्लाइंट सर्वर प्रोटोकॉल
में क्या हो रहा था कि लेट्स से हमारे पास यह दो क्लाइंट हैं। क्लाइंट ए और क्लाइंट बी। तो क्लाइंट सर्वर प्रोटोकॉल में क्या
हो रहा था कि यह दोनों क्लाइंट आपस में एक दूसरे से डायरेक्ट कम्युनिकेट नहीं कर सकते। उनको कम्युनिकेशन के लिए एक सर्वर
की नीड थी। पर पीियर टू पीियर प्रोटोकॉल में क्या होता है कि दोनों ही क्लाइंट यह क्लाइंट ए और क्लाइंट बी दोनों आपस में एक
दूसरे से डायरेक्ट कम्युनिकेट कर सकते हैं। तो ये होता है हमारा पीियर टू पीियर प्रोटोकॉल और क्लाइंट सर्वर प्रोटोकॉल में
डिफरेंस। तो यस दिस इज ऑल फॉर दिस वीडियो। और इस वीडियो में अब हमने कवर कर लिया कि ट्रांसपोर्ट लेयर प्रोटोकॉल्स क्या होते
हैं? एप्लीकेशन लेयर प्रोटोकॉल्स क्या होते हैं? और कैसे डिफरेंट लेयर के प्रोटोकॉल्स साथ में काम करते हैं? सो यस
दिस इज़ ऑल फॉर दिस वीडियो। वी विल सी यू इन द नेक्स्ट वीडियो। सो टिल देन ब बाय। शो सम लव। थैंक्स। [संगीत]
हे एवरीवन, वेलकम बैक। वेलकम टू दिस अल्टीमेट सिस्टम डिज़ प्लेलिस्ट सीरीज। और आज के इस वीडियो में हम बात करने वाले हैं
स्केलिंग के बारे में। हम देखेंगे कि व्हाट इज़ स्केलिंग? स्केलिंग के डिफरेंट टाइप्स। और हम देखेंगे कि हमें स्केलिंग
की नीड क्या है? तो स्टार्ट करते हैं और स्केलिंग को समझते हैं एक एग्जांपल के थ्रू। तो, लेट्स से कि एक आपका पिज़्ज़ा
पार्लर है और उस पिज़्ज़ा पार्लर में पिज़्ज़ा शॉप में आपके पास केवल एक सिंगल शेफ है। सिंगल शेफ है। अब इस शेफ की दो क्वालिटीज
हैं। पहला तो यह कि यह बहुत स्लो है। दूसरा कि यह 1 घंटे में हर घंटे केवल दो ही ऑर्डर दो ही पिज़्ज़ा ऑर्डर प्रिपेयर कर
सकता है। सो, टू ऑर्डर पर आवर। तो यह इस शेफ की क्वालिटीज हैं। अब लेट्स से वीकेंड्स पे वीकेंड्स पे आपके पिज़्ज़ा
पार्लर पे या आपके पिज़्ज़ा शॉप पे हर घंटे 10 पिज़्ज़ा ऑर्डर्स 10 पिज़्ज़ा ऑर्डर आते हैं। हर घंटे 10 पिज़्ज़ा ऑर्डर आते हैं।
तो, अब इस केस में यह शेफ तो 10 पिज़्ज़ा ऑर्डर ले ही नहीं पाएगा क्योंकि इसकी मैक्सिमम कैपेसिटी है टू ऑर्डर्स पर आवर।
यह 1 घंटे में केवल दो ही आर्डर प्रिपेयर कर सकता है। तो अब इस केस में हम हमारे कस्टमर्स को वेट करने तो बोल नहीं सकते।
तो इस केस में हमें कुछ सॉल्यूशन चाहिए ताकि हम कस्टमर्स को कस्टमर्स को वेट भी ना कराएं और हम उन्हें पिज़्ज़ा भी टाइम पर
डिलीवर कर दें। तो अब इस केस में हमारे पास दो सॉल्यूशन हो सकते हैं। पहला कि हम इस स्लो शेफ की जगह ये जो हमारा शेफ है ये
स्लो है। तो इस स्लो शेफ की जगह हमें एक फास्ट शेफ रख लें। तो पहला हमारा सॉल्यूशन क्या है? कि हम एक फास्ट शेफ रख लें जो
तेजी से पिज़्ज़ा बना सकता है और जो 1 घंटे में 10 ऑर्डर बना सकता है। 10 पिज़्ज़ा बना सकता है। तो पहला सॉल्यूशन हमारा यह है कि
हम एक फास्ट शेफ रख लें। फास्ट शेफ रखेंगे। मतलब इसमें ज्यादा कैपेबल कैपेबिलिटी होगी पिज़्ज़ा
ऑर्डर बनाने की। और ये और ये स्ट्रांग होगा। पावरफुल होगा। पावरफुल होगा। स्ट्रांग होगा। तभी यह पिज़्ज़ा बना पा रहा
है। पावरफुल इन द सेंस पिज़्ज़ा बनाने में। तो, यह हो गया हमारा पहला सॉल्यूशन। और जो दूसरा सॉल्यूशन है, वो क्या हो सकता है कि
हम एक सिंगल शेफ ना रख के हम ऐसे तीन-चार शेफ हायर कर लें। तीन-चार शेफ हायर कर लें। तो, यह दो सॉल्यूशन होते हैं हमारे
पास इस प्रॉब्लम को सॉल्व करने के लिए। जहां हमारे पास वीकेंड्स पे दिन के 10 पिज़्ज़ा ऑर्डर आ रहे हैं। तो अब इसको
कंप्यूटर साइंस लैंग्वेज में बोलते हैं वर्टिकल स्केलिंग। वर्टिकल स्केलिंग या स्केल अप और इसे
बोलते हैं हॉरिजॉन्टल स्केलिंग। हॉरिजॉन्टल स्केलिंग।
या हम इसे बोलते हैं स्केल आउट। तो वर्टिकल स्केलिंग में बेसिकली हमने क्या किया कि हमने जो हमारा स्लो शेफ था उसको
हमने रिप्लेस कर दिया और हम एक फास्ट शेफ ले आए जो तेजी से पिज़्ज़ा बना सकता है। और हॉरिजॉन्टल स्केलिंग में हमने क्या किया
कि हमने नंबर ऑफ शेफ बढ़ा दिए। अब हमारा केवल एक शेफ नहीं है। अब हमारे पिज़्ज़ा शॉप में ऐसे मल्टीपल शेफ हो गए। तो अब कितने
भी ऑर्डर्स आएंगे? ये आपस में डिस्ट्रीब्यूट हो जाएंगे। लेट से 15 ऑर्डर्स आ रहे हैं। तो यह आपस में
डिस्ट्रीब्यूट हो जाएंगे ऑर्डर्स। कुछ ऑर्डर्स फर्स्ट शेफ को मिल जाएंगे। कुछ सेकंड को,
कुछ थर्ड को, कुछ फोर्थ को। ऐसे करके ये ऑर्डर्स को डिस्ट्रीब्यूट कर लेंगे एंड दे विल प्रिपेयर फूड एट टाइम। तो ये दो
सॉल्यूशन हमारे पास आते हैं। अब वर्टिकल स्केलिंग और हॉरिजॉन्टल स्केलिंग को समझते हैं। तो सबसे पहले हमें वी ऑल नो कि एक
हमारे पास होता है क्लाइंट एक हमारे पास होता है सर्वर। अब इस सर्वर पे हम क्या करते हैं? हम हमारा कोई भी एप्लीकेशन
होस्ट कर देते हैं। लेट्स से आपने कोई एप्लीकेशन बनाया तो उस एप्लीकेशन को आपने एक सर्वर या कंप्यूटर पे होस्ट कर दिया।
राइट? अब इस सर्वर की अपनी कैपेबिलिटी होगी। इसकी कुछ रैम होगी। इसमें कुछ सीपीयूस होंगे, पावरफुल सीपीू हो सकते
हैं। वीक CPU हो सकते हैं। तो ऐसे इस सर्वर की कुछ अपनी कैपेबिलिटी होगी। अब हमने एप्लीकेशन को हमारे एप्लीकेशन को इस
सर्वर पे होस्ट कर दिया। तो, यह जो हमारा क्लाइंट है, यह यूजर रिक्वेस्ट करेगा। यह रिक्वेस्ट करेगा और फिर यह सर्वर हमारा
एप्लीकेशन यहां इसे रिस्पांस देगा। तो बेसिकली यहां हम हमारा रिक्वेस्ट रिस्पांस साइकिल होगा। अब यदि हमारे एप्लीकेशन में
नंबर ऑफ यूज़र्स कम है लेट्स से नंबर ऑफ यूज़र्स फाइव 10 या लेट्स से 100 की रेंज में है तो इस केस में हम इस केस में
पॉसिबल है कि हमारा ये सर्वर हमारा जो सर्वर जहां हमने एप्लीकेशन होस्ट किया ये इन 100 यूज़र्स को ईजीली मैनेज कर सकता है।
लेकिन फ्यूचर में लेट्स से यदि हमारे एप्लीकेशन में नंबर ऑफ यूज़र्स बढ़ गए। लेट्स से नंबर ऑफ यूज़र्स 10,000 हो गए या
1 मिलियन नंबर ऑफ यूज़र्स हो गए। तो इस केस में अब यह पॉसिबल हो सकता है कि ये ये सर्वर हमारा इतना सारा लोड हैंडल ना कर
पाए। तो ये सर्वर अब क्योंकि हमारे नंबर ऑफ यूज़र्स बढ़ गए तो इस सर्वर पे आने वाली नंबर ऑफ रिक्वेस्ट भी बढ़ जाएंगी। तो इसकी
वजह से क्या होगा? क्या हो सकता है कि यह सर्वर शायद इतने ज्यादा लोड को हैंडल ना कर पाए। और ये सर्वर हमारा सिंगल पॉइंट ऑफ
फेलियर सिंगल पॉइंट ऑफ फेलियर बन सकता है। तो अब इस केस में हम क्या कर सकते हैं? हमारे पास दो ऑप्शंस हैं। या तो हम इस
सर्वर की कैपेसिटी को बढ़ा सकते हैं। इस सर्वर की कैपेसिटी को बढ़ा सकते हैं। और जो दूसरा ऑप्शन हमारे पास है वो है कि हम
ऐसे ही तीनचार और सर्वर को यूज़ कर लेंगे। बेसिकली हम क्या करेंगे? हम ऐसे ही तीन-चार और सर्वर को यूज़ कर लेंगे। और इन
तीनों चारों सर्वर में हमारे एप्लीकेशन को हमारे एप्लीकेशन को होस्ट कर देंगे। तो यहां पे हमने क्या किया? हमने नंबर ऑफ
सर्वर्स बढ़ा दिए। पहले हमारे पास केवल एक सर्वर था। अब हमने नंबर ऑफ सर्वर्स बढ़ा दिए। तो ये दो ऑप्शंस हैं हमारे पास। पहला
ऑप्शन है यह है कि हम अपने सर्वर की कैपेसिटी को बढ़ा दें। और जो दूसरा ऑप्शन हमारे पास है वह है कि हम नंबर ऑफ सर्वर्स
बढ़ा दें। अब हम सबसे पहले देखते हैं वर्टिकल स्केलिंग जिसमें हमने देखा कि हम अपने सर्वर की कैपेसिटी को बढ़ा दें। तो
वर्टिकल स्केलिंग में वर्टिकल स्केलिंग में हम क्या कर सकते हैं कि जो हमारा सर्वर था जो हमारे सर्वर की
कुछ कैपेसिटी होगी। उसकी कुछ रैम होगी। लेट से 16GB रैम 16GB रैम कुछ उसमें CPU होंगे। तो ऐसे
हमारे सर्वर की कैपेसिटी होगी। तो हम क्या कर सकते हैं? हम जो हमारा करंट सर्वर था उसकी जगह हम एक बड़ा सा मशीन या बड़ा सा
सर्वर खरीद सकते हैं। बड़ा सा सर्वर बाय कर सकते हैं। तो यहां हमारा जो सर्वर था इसको हमने रिप्लेस कर दिया और हम बड़ी
मशीन या बिग मशीन को लेकर आए। तो यहां हमने ये किया और अब इस सर्वर की लेट्स से रैम हो गई 32GB 32GB रैम रैम
और लेट्स से इसमें कुछ CPU हो गए स्ट्रांग CPU हो गए पावरफुल CPU हो गए तो हमने बेसिकली क्या किया हमने हमारे सर्वर को
हमारा जो प्रीवियस सर्वर था उसको रिप्लेस कर दिया एंड वी बोट बिगर मशीन अब वर्टिकल स्केलिंग में दूसरी चीज़ हम क्या कर सकते
हैं कि हम इसी सर्वर को इसी सर्वर की कैपेसिटी को बढ़ा दें। इसकी लेट्स से पहले रैम थी 16GB
16GB तो हम इसे एनहांस करके 32GB कर सकते हैं और सिमिलरली हम यहां नंबर ऑफ CPU भी बढ़ा सकते हैं और पावरफुल सीपीयूस लगा
सकते हैं। तो ये दो काम कर सकते हैं हम वर्टिकल स्केलिंग में। अब हॉरिजॉन्टल स्केलिंग में हम क्या करेंगे कि हम अ
सर्वर की कैपेसिटी को नहीं बढ़ाएंगे। इसके बजाय हम क्या करेंगे? हम नंबर ऑफ सर्वर्स को ही बढ़ा देंगे। लेट्स से पहले हमारे
पास केवल ये एक सर्वर था। अब हॉरिजॉन्टल स्केलिंग में हम क्या करते हैं? हम नंबर ऑफ सर्वर्स को ही बढ़ा देते हैं। अब यहां
हमारे पास नंबर ऑफ सर्वर्स तीन हो गए। तो तीनों सर्वर में हमने हमारे एप्लीकेशन को होस्ट कर दिया। तो अब
डिफरेंट-डिफरेंट यूज़र्स आएंगे। लेट्स से ये डिफरेंट-डिफरेंट यूज़र्स आएंगे। तो अब हमारे केवल एक ही सर्वर पे लोड नहीं
पड़ेगा। हमारे केवल एक ही सर्वर पे लोड नहीं पड़ेगा। अब यहां पे हम यूज़र्स की रिक्वेस्ट को डिस्ट्रीब्यूट कर सकते हैं
टू मल्टीपल सर्वर इंस्टेंसेस। तो ये काम होता है हमारे हॉरिजॉन्टल स्केलिंग का। अब एक बार हॉरिजॉन्टल स्केलिंग और वर्टिकल
स्केलिंग दोनों में डिफरेंस को देखते हैं। तो जो हमारा हॉरिजॉन्टल स्केलिंग होता है, हॉरिजॉन्टल स्केलिंग होता है। यहां पे
हमारे पास नंबर ऑफ मशीनंस ज्यादा होती है। लेट्स से हमारे पास नंबर ऑफ मशीनंस या नंबर ऑफ कंप्यूटरटर्स, नंबर ऑफ सर्वर्स
थ्री हैं। और वर्टिकल स्केलिंग में हमारे पास केवल एक बड़ा कंप्यूटर होता है। बड़ा कंप्यूटर होता है। तो ये हो गया हमारा
पहला डिफरेंस। अब हॉरिजॉन्टल स्केलिंग में हमें लोड बैलेंसर्स की नीड होती है। क्योंकि लोड बैलेंसर डिसाइड करता है कि
यूजर की रिक्वेस्ट को किस सर्वर इंस्टेंस पे राउट करना है। तो इसके लिए हमें यहां लोड बैलेंसर की नीड होती है। यहां पे
क्योंकि हमारे पास सिंगल एप्लीकेशन सर्वर है तो यहां हमें लोड बैलेंसर की नीड लोड बैलेंसर्स की नीड नहीं होती। अब जो तीसरा
हमारा पॉइंट है वह है कि यहां पर हमारे पास केवल एक सिंगल सर्वर है। और यदि इस सिंगल सर्वर में कुछ भी
प्रॉब्लम आती है या यह क्रैश हो जाता है तो इट विल बिकम सिंगल पॉइंट ऑफ फेलियर। सिंगल पॉइंट ऑफ फेलियर। लेकिन यहां पे
हमारे पास नंबर ऑफ सर्वर्स ज्यादा हैं तो यदि एक सर्वर या दो सर्वर क्रैश भी हो गए या किसी वजह से ये स्लो स्लो डाउन हो गए
एंड दे आर नॉट एबल टू हैंडल द ट्रैफिक। तो इस केस में हमारे पास हमारे पास अदर सर्वर्स भी होते हैं। अदर सर्वर
इंस्टेंसेस भी होते हैं। तो हम यूजर की रिक्वेस्ट को वहां राउट कर देते हैं। तो यहां पे हमारा सिंगल पॉइंट ऑफ फेलियर का
हमें डर नहीं रहता। तो हम कह सकते हैं कि इट इज़ रेिलिएंट।
रेिलिएंट। अब जो नेक्स्ट पॉइंट है हमारा वो है डेटा कंसिस्टेंसी। तो यहां पे हमारे पास केवल
एक ही सिंगल सर्वर है, बिगर सर्वर है। तो यहां पे डेटा हमेशा कंसिस्टेंट होता है। तो यहां हमें डेटा कंसिस्टेंसी देखने को
मिलती है। डेटा कंसिस्टेंसी देखने को मिलती है। लेकिन यहां पे हमारे पास अ डिफरेंट एप्लीकेशन सर्वर्स हैं। तो यहां
पे डेटा कंसिस्टेंसी कैन बिकम एन इशू। तो ये यहां पर डेटा कंसिस्टेंसी एक प्रॉब्लम हो सकती है। डेटा कंसिस्टेंसी
कैन बिकम अ बॉटल नेक हियर। जो नेक्स्ट पॉइंट है वो है स्केलिंग। अब यहां पे हम हमने क्या किया? हमने नंबर ऑफ मशीनंस या
नंबर ऑफ सर्वर्स को बढ़ा दिया। तो यदि अब हमारे नंबर ऑफ यूज़र्स इनक्रीस भी होते हैं। तो हम क्या कर सकते हैं? हम और
मशीनंस लगा सकते हैं। लेट्स से फोर फाइव। वैसे हम और मशीनंस भी लगा सकते हैं और हम ईजीली हमारे एप्लीकेशन को हमारे सिस्टम को
ईजीली स्केल कर सकते हैं। यदि हमारे नंबर ऑफ यूज़र्स बढ़ते हैं तो। लेकिन यहां पे हम एक हद तक ही इस सर्वर की कैपेसिटी को बढ़ा
सकते हैं। एक हद तक ही हम इसकी RAM को बढ़ा सकते हैं। पावरफुल CPU प्रोवाइड कर सकते हैं। तो यहां पे स्केलिंग जो होती है,
इट्स नॉट दैट इजी। तो यहां हम कह सकते हैं कि हमारे हार्डवेयर की एक लिमिट होती है। हार्डवेयर की एक लिमिट होती है। लेकिन
यहां पे स्केलिंग इज़ ईजी। स्केलिंग इज़ ईजी। अब जो नेक्स्ट पॉइंट है हमारा वो है कम्युनिकेशन से रिलेटेड। तो यहां पे
हॉरिजॉन्टल स्केलिंग में हमारे पास नंबर ऑफ सर्वर्स होते हैं। मल्टीपल सर्वर्स होते हैं। मल्टीपल सर्वर इंस्टेंसेस होते
हैं। तो इनमें आपस में कम्युनिकेशन होता है नेटवर्क कॉल्स के थ्रू। इनमें बेसिकली आरपीसी कम्युनिकेशन होता है। और जो
वर्टिकल स्केलिंग होती है यहां पे हमारे पास सिंगल एप्लीकेशन सर्वर होता है। और सिंगल एप्लीकेशन में हमारे पास मल्टीपल
सर्विसेज हो सकती हैं। मल्टीपल मॉड्यूल्स हो सकते हैं। तो यहां पे इंटरप्रो कम्युनिकेशन होता है। इंटर प्रोसेस
कम्युनिकेशन होता है। और यहां पे हमारे कम्युनिकेशन जो होता है सर्वर्स के बीच में वह होता है थ्रू नेटवर्क कॉल्स।
नेटवर्क कॉल्स। तो नेटवर्क कॉल्स की वजह से ये हमारा हॉरिजॉन्टल स्केलिंग होती है। ये थोड़ा स्लो हो जाती है और इंटरप्रोस
कम्युनिकेशन की वजह से हमारी वर्टिकल स्केलिंग जो होती है वो होती है फास्ट। अब क्वेश्चन ये आता है कि एक रियल वर्ल्ड में
रियल वर्ल्ड प्रोजेक्ट में रियल वर्ल्ड सिनेरियो में हमें कौन सी स्केलिंग यूज़ करना चाहिए? हॉरिजॉन्टल स्केलिंग या
वर्टिकल स्केलिंग? तो रियल वर्ल्ड केस में हम हाइब्रिड अप्रोच को देखते हैं। हाइब्रिड अप्रोच को अपनाते हैं। जिसमें हम
कुछ हॉरिजॉन्टल स्केलिंग की की फीचर्स को लेते हैं। और वर्टिकल स्केलिंग के भी कुछ फीचर्स को लेते हैं। हॉरिजॉन्टल
स्केलिंग के फीचर में हम लेते हैं एक रेिलिएंट। और दूसरा लेते हैं हम स्केलिंग। कि यहां
पे स्केलिंग इजी होती है। और वर्टिकल स्केलिंग में हम लेते हैं डेटा कंसिस्टेंसी और फास्ट। क्योंकि यह हमारा
वर्टिकल स्केलिंग होती है। वह फास्ट होती है बिकॉज़ ऑफ इंटर प्रोसेस कम्युनिकेशन। अब हॉरिजॉन्टल स्केलिंग में हम लोड
बैलेंसर का कांसेप्ट लेके आते हैं। यहां पे हमारा होता है लोड बैलेंसर और यहां पे हमारे पास मल्टीपल सर्वर इंस्टेंसेस होते
हैं। लेट्स से सर्वर वन, सर्वर टू, सर्वर थ्री। ऐसे हमारे पास मल्टीपल सर्वर इंस्टेंसेस होते हैं। और लेट्स से कि अब
हमारे पास ऐसे थाउजेंड्स ऑफ यूजर आ रहे हैं हमारे एप्लीकेशन में। थाउजेंड्स ऑफ यूजर आ रहे हैं। तो इस केस में एक सिंगल
सर्वर पे लोड नहीं पड़ता। एक सिंगल सर्वर पे लोड नहीं आता। जो यूज़र्स की रिक्वेस्ट होती हैं, वह डिस्ट्रीब्यूट हो जाती हैं
टू मल्टीपल सर्वर इंस्टेंसेस। और ऐसे करके हम ट्रैफिक को डिस्ट्रीब्यूट कर देते हैं। और केवल एक सर्वर पे केवल एक सर्वर
इंस्टेंस पे लोड नहीं पड़ता। सो दिस इज़ अबाउट हॉरिजॉन्टल स्केलिंग एंड वर्टिकल स्केलिंग। और हमने इसके डिफरेंस भी देखे
दोनों में। हमने देखा स्केलिंग की हमें नीड क्या है? हमने स्केलिंग को एक एग्जांपल के थ्रू भी समझा। सो यस दिस इज़
ऑल फॉर दिस वीडियो। वी विल सी यू इन द नेक्स्ट वीडियो। सो टिल देन बय। शो सम लव। थैंक्स।
[संगीत] हे एवरीवन वेलकम बैक वेलकम टू दिस अल्टीमेट सिस्टम डिज़ प्लेलिस्ट सीरीज और
आज के इस वीडियो में हम बात करने वाले हैं कि कैसे हमारे एप्लीकेशन को फ्रॉम ज़ीरो टू मिलियन यूज़र्स तक स्केल कर सकते हैं। तो
स्टार्ट करते हैं और सबसे पहले डिस्कस करते हैं कि हमें स्केल करने की नीड क्या है? तो इसे एक एग्जांपल के थ्रू समझते
हैं। लेट्स से कि आप एक टिकट काउंटर पर खड़े हो। लेट्स से मूवी टिकट काउंटर पे। वहां पे यह कोई एक बंदा है। यह आपको
टिकट्स प्रोवाइड कर रहा है। अब लेट्स से कि अचानक से इस टिकट काउंटर पे लेट्स से 1000 यूज़र्स आ जाते हैं। जिनको मूवी टिकट
चाहिए। तो 1000 यूज़र्स के अचानक आने से क्या होगा कि सबसे पहले तो इस बंदे पे बहुत ज्यादा लोड आ जाएगा। दूसरा क्या कि
जो हमारा टिकट प्रोवाइड करने की स्पीड है, पेस है वह स्लो हो जाएगी क्योंकि अब 1000 पीपल हैं तो वन बाय वन प्रोसेसिंग होगी।
तो जो लेट्स से 500 के बाद के यूज़र्स हैं उनको बहुत लेट टिकट मिलेगी। तो इससे क्या हो रहा है? सबसे
पहले तो कि इस बंदे पे बहुत ज्यादा लोड आ जा रहा है। दूसरा क्या हो रहा है कि हमारा सिस्टम स्लो हो जा रहा है। तो इस प्रॉब्लम
को हम कैसे सॉल्व कर सकते हैं? हम इस प्रॉब्लम को ऐसे सॉल्व कर सकते हैं कि हम एक और टिकट काउंटर बना दें और वहां पे भी
हम किसी एक आदमी को बिठा दें तो यह भी सेम टिकट प्रोवाइड करेगा। तो अब यह 1000 लोगों को
हम 500 500 में डिवाइड कर सकते हैं। 500 500 में हम डिवाइड कर सकते हैं। तो 500 पीपल विल गो देयर। 500 पीपल विल कम हियर।
तो ऐसे करके हम इन पे से लोड कम कर सकते हैं। और अब जो लेट्स से 500 के बाद के यूज़र्स थे उनको भी जल्दी टिकट मिलेगी। तो
ऐसे करके हमारा जो सिस्टम की जो परफॉर्मेंस डिक्रीज हो गई थी उसको भी हम हमने मेंटेन कर लिया। तो ये होती है हमें
स्केलिंग की नीड। अब सेम काम हमारे सिस्टम्स में होता है। लेट्स से कि हमारा कोई एप्लीकेशन है और उसमें एक साथ हमारे
पास 1000 रिक्वेस्ट या 5000 रिक्वेस्ट आ रही हैं या 10,000 रिक्वेस्ट आ रही हैं। तो उससे क्या होता
है? सबसे पहले जो हमारा सर्वर वो स्लो काम करने लगता है तो वह स्लो काम करने लगता है। उसकी परफॉर्मेंस डिक्रीज हो
जाती है। दूसरा क्या होता है कि वो पूरा का पूरा सिस्टम हमारा क्रैश कर सकता है। तो ये सारी प्रॉब्लम्स से बचने के लिए हम
हमारे सिस्टम को स्केल करते हैं। अब देखते हैं और समझते हैं कि कैसे हम हमारे एप्लीकेशन को फ्रॉम ज़ीरो टू मिलियन यूज़र्स
तक स्केल कर सकते हैं। तो जब हम कॉलेज में कॉलेज स्टेज़ में कोई भी प्रोजेक्ट बनाते हैं तो उसमें क्या होता है कि हम सेम
सर्वर के अंदर अपना एप्लीकेशन भी रखते हैं। सेम सर्वर के अंदर हमारा एप्लीकेशन भी होता है। एप्लीकेशन दैट मींस बिनेस
लॉजिक। तो यह एप्लीकेशन एक नोट js एप्लीकेशन हो सकता है या स्प्रिंग बूट एप्लीकेशन हो सकता है। तो हम हमारे सेम
सर्वर में सिंगल सर्वर में हमारा एप्लीकेशन भी रन हो रहा होता है और उसी सेम सर्वर में हमारा डेटाबेस भी होता है।
अ इट कैन बी अ मंगो डीबी डेटाबेस और एनी सीक्वल डेटाबेस। तो क्या होता है कि हमारे सिंगल सर्वर में एप्लीकेशन भी रन होता है
और डेटाबेस भी रन होता है। तो इस केस में हमारा क्लाइंट सर्वर से डायरेक्ट कम्युनिकेट कर सकता है। और अब इस सर्वर
में एप्लीकेशन भी है और डेटाबेस भी है। तो ये जो हमारा क्लाइंट है यह सर्वर के साथ डायरेक्ट कम्युनिकेट कर सकता है। तो ये था
हमारा पहला पॉइंट जहां पे हमारे पास केवल एक सिंगल सर्वर होता है और उसी सिंगल सर्वर में हमारे पास एप्लीकेशन भी होता
है। दैट मींस बिनेस लॉजिक और डेटाबेस भी होता है। तो ये था हमारा पहला पॉइंट। अब नेक्स्ट क्या होता है कि लेट्स से हमारे
एप्लीकेशन में कुछ यूज़र्स आते हैं। कुछ यूज़र्स बढ़ जाते हैं हमारे सिस्टम में। तो अब हम क्या करते हैं कि हम हम एप्लीकेशन
के लिए बिजनेस लॉजिक के लिए एक सेपरेट सर्वर यूज करते हैं और डेटाबेस के लिए हम एक सेपरेट सर्वर यूज़ करते हैं। तो अब यहां
पे देखिए कि हमने हमारे डेटाबेस को एक सिंगल सर्वर में रखा और यहां पे एप्लीकेशन को भी एक सिंगल सर्वर में रखा। तो क्लाइंट
विल मेक अ रिक्वेस्ट और ये रिक्वेस्ट जाएगी एप्लीकेशन सर्वर के पास और फिर एप्लीकेशन सर्वर इस डेटाबेस को कॉल करेगा।
यदि वो रिक्वेस्ट में कोई डेटाबेस रिलेटेड ऑपरेशन परफॉर्म होना है तो ये एप्लीकेशन इस डेटाबेस को क्वेरी करेगा। तो अब इस केस
में हमने क्या किया कि जो हमारे सिंगल सर्वर पे लोड पड़ रहा था यह सर्वर हमारा एप्लीकेशन को भी लॉ मेंटेन कर रहा था और
डेटाबेस को भी मेंटेन कर रहा था। तो अब इस केस में हमने क्या किया कि हमने लोड को डिस्ट्रीब्यूट कर दिया। अब हमारा जो
एप्लीकेशन सर्वर होगा वो सिर्फ बिजनेस लॉजिक से रिलेटेड अ टास्क परफॉर्म करेगा और उस पे सिर्फ उतना ही लोड रहेगा। और जो
हमारा डेटाबेस सर्वर होगा उस पे सिर्फ डेटाबेस का लोड होगा। तो ऐसे करके हमने हमारे एप्लीकेशन और डेटाबेस के लिए
डिफरेंट-डिफरेंट सर्वर्स यूज़ किए। अब लेट्स से कि हमारे एप्लीकेशन में और यूज़र्स बढ़ जाते हैं और जो हमारा सिंगल
एप्लीकेशन सर्वर था यह सिंगल एप्लीकेशन सर्वर था यह बहुत ज्यादा ट्रैफिक को कंट्रोल नहीं कर पा रहा था। तो इससे क्या
हो रहा था कि या तो हमारा सिस्टम क्रैश कर सकता था। हमारा सिस्टम क्रैश कर सकता था। हमारे सिस्टम की परफॉर्मेंस स्लो हो सकती
थी। क्योंकि अब यहां पे रिसोर्सेज बहुत ज्यादा यूज़ हो रहे होंगे। CPU, हमारा मेमोरी। तो ये सब बहुत ज्यादा यूज हो रहे
होंगे। इनका इनका यूटिलाइजेशन बढ़ जाएगा। तो इससे क्या होगा? हमारे सिस्टम की परफॉर्मेंस स्लो हो सकती है। और एक एक चीज
और कि अब यहां पे हमारे पास केवल एक सिंगल एप्लीकेशन सर्वर था। तो इट कैन बिकम अ सिंगल पॉइंट ऑफ़ फेलियर। तो अब क्या होता
है कि जैसे ही हमारे पास नंबर ऑफ यूज़र्स बढ़ते हैं, तो हम क्या करते हैं? हम मल्टीपल एप्लीकेशन सर्वर्स का यूज़ कर लेते
हैं। अब हम हमने क्या किया कि हमने ऐप सर्वर्स को बढ़ा दिया। पहले हमारे पास एक सिंगल एप्लीकेशन सर्वर था। अब हमारे पास
तीन एप्लीकेशन सर्वर्स हैं। लेकिन अब इस क्लाइंट को तो नहीं पता कि उसको अपनी रिक्वेस्ट को कौन किस एप्लीकेशन सर्वर पे
भेजना है। राइट? तो, यह काम कौन करता है? यह काम करता है हमारा लोड बैलेंसर। लोड बैलेंसर डिसाइड करता है कि यूजर की
रिक्वेस्ट को इस क्लाइंट की रिक्वेस्ट को किस ऐप सर्वर में राउट करना है। बेसिकली यह लोड बैलेंसर
डिसीजन करेगा कि यूजर की रिक्वेस्ट को किस ऐप सर्वर पे भेजना है बेस्ड ऑन द ट्रैफिक एंड सम अदर पैराटर्स कि कौन सा हमारा
एप्लीकेशन सर्वर एक्टिव है, कौन सा हमारा एप्लीकेशन सर्वर इनएक्टिव है। तो ये सारे पैराटर्स के बेसिस पे लोड बैलेंसर डिसाइड
करेगा कि यूजर की रिक्वेस्ट को किस एप्लीकेशन सर्वर पर भेजना है। तो यहां ये होता है हमारा थर्ड पॉइंट जहां हमने नंबर
ऑफ यूज़र्स के बढ़ने से मल्टीपल एप्लीकेशन सर्वर्स यूज़ किए। प्लस हमने लोड बैलेंसर का कांसेप्ट भी यूज़ किया। अब लोड बैलेंसर
के बारे में मैंने ऑलरेडी वीडियोस बना चुकी हैं। सो इफ यू वांट टू नो कि कैसे लोड बैलेंसर्स काम करते हैं लोड बैलेंसर
के डिफरेंट टाइप्स एंड सम ऑफ़ द लोड बैलेंसिंग एल्गोरिदम। सो आई हैव मेड अ सेपरेट वीडियो ऑन दैट। सो, प्लीज गो एंड
वॉच दैट वीडियो फॉर बेटर अंडरस्टैंडिंग। तो, यह था हमारा तीसरा पॉइंट जहां हमने मल्टीपल एप्लीकेशन सर्वर्स को यूज़ किया।
प्लस हमने लोड बैलेंसर को यूज़ किया टू डिस्ट्रीब्यूट टू द ट्रैफिक। अब जो नेक्स्ट पॉइंट हमारा आता है वो था डेटाबेस
रेप्लीकेशन। अब यहां क्या हो रहा था कि हमने एप्लीकेशन सर्वर्स को तो स्केल कर दिया था। हमने नंबर ऑफ एप्लीकेशन सर्वर
बढ़ा दिए थे। लेकिन हमारा के हमने डेटाबेस हमारा केवल एक ही था। तो व्हाट इफ कि हमारा ये डेटाबेस क्रैश हो जाता है। व्हाट
इफ हमारा डेटाबेस क्रैश हो जाता है या इसमें कुछ प्रॉब्लम आ जाती है। तो इस केस में कोई भी यूजर की रिक्वेस्ट फुलफिल नहीं
हो पाएगी। राइट? क्योंकि डेटाबेस ऑलरेडी क्रैश हो चुका है। तो लेट्स से कि कोई यूजर आता है और उसे अपनी पर्सनल डिटेल
चाहिए या पर्सनल इनेशन चाहिए। तो अब यह डेटाबेस उस यूजर की रिक्वेस्ट को अ फुलफिल नहीं कर पाएगा क्योंकि ये डेटाबेस अभी
डाउन है या प्रॉपर्ली वर्क नहीं कर रहा है फॉर सम बिकॉज़ ऑफ़ सम एक्स वzेड रीज़न। तो, क्या हो रहा था कि हमें यहां पे डेटाबेस
हमारा सिंगल पॉइंट ऑफ़ फेलियर बन गया था। कि यदि ये डेटाबेस हमारा फेल होता है तो अब कोई भी यूजर की रिक्वेस्ट फुलफिल नहीं
हो पाएगी। तो इसके लिए हमने क्या किया? हमने डेटाबेस स्केल कर दिया। हमने डेटाबेस रेप्लिकेशन किया। हमने यहां मास्टर स्लेव
आर्किटेक्चर को यूज़ किया। तो अब समझते हैं कि इसमें हुआ क्या? तो पहले हमारे पास क्या था कि डेटाबेस के लिए हमने केवल एक
सिंगल सर्वर यूज किया था और यदि वो हमारा सर्वर क्रैश हो जा रहा था तो हमारा यूजर की हम कोई भी क्वेरी को कोई भी उसकी
रिक्वेस्ट को फुलफिल नहीं कर पा रहे थे। लेकिन अब यहां पे क्या हुआ कि हमने एक मास्टर नोड लिया अ इट कैन बी अ सर्वर वन
ऑफ़ द सर्वर और यहां पे हमने डिफरेंट स्लेव नड्स भी लिए। तो अब क्या हो रहा है कि लेट्स से कोई यूजर या क्लाइंट रिक्वेस्ट
करेगा। यह रिक्वेस्ट जाएगी वन ऑफ द एप्लीकेशन सर्वर पे और उसके बाद लेट्स से क्लाइंट को या यूजर को अपनी पर्सनल डिटेल
चाहिए। तो यह रीड ऑपरेशन के लिए रीड रिक्वेस्ट के लिए यह रिक्वेस्ट जाएगी वन ऑफ द स्लेव के पास। तो यह स्लेव सर स्लेव
सर्वर या स्लेव नोट्स क्या करेंगे? यूजर की रीड रिक्वेस्ट को फुलफिल करेंगे। लेट्स से कि इस यूजर को अपनी पर्सनल डिटेल चाहिए
तो यह रिक्वेस्ट जाएगी वन ऑफ द स्लेव के पास। तो यह स्लेव यूजर की रिक्वेस्ट को फुलफिल करेंगे। और यदि कोई राइट ऑपरेशन
आता है लेट्स से यूजर को अपना ईमेल एड्रेस चेंज करना है या कोई और इंफॉर्मेशन अपडेट करनी है बेसिकली राइट ऑपरेशन राइट
रिक्वेस्ट। तो ये राइट ऑपरेशन जाएगा हमेशा मास्टर नोड के पास। मास्टर नोड के पास। तो बेसिकली यहां पे हमने क्या किया? हमने
डेटाबेस रेप्लिकेशन किया। तो अब हमारे मास्टर नोड में या हमारे मास्टर डेटाबेस में कोई भी राइट ऑपरेशन परफॉर्म होगा हम
उस हम उस चेंज को या हम उस राइट ऑपरेशन को हर एक स्लेव नोड में रेप्लिकेट कर देंगे। तो हम कह सकते हैं कि ये जो हमारे स्लेव
नोड्स होते हैं यह कॉपी होती है इस मास्टर नोड की। तो बेसिकली कोई भी राइट ऑपरेशन आएगा वो इस मास्टर नोड में वो चेंज होगा
और फिर ये मास्टर नोड उस चेंज को रेप्लिकेट कर देगा टू ऑल इट्स स्लेव नोड। तो ये होता है हमारा डेटाबेस रेप्लिकेशन।
तो डेटाबेस रेप्लिकेशन करके अब हमने क्या किया कि ये जो हमारा डेटाबेस से सिंगल पॉइंट ऑफ फेलियर वाली प्रॉब्लम बन रही थी
कि हमारा डेटाबेस सिंगल पॉइंट ऑफ फेलियर बन रहा था। उस प्रॉब्लम को हमने सॉल्व कर दिया। तो अब लेट्स से कि यदि हमारा स्लेव
वन डाउन होता है तो हमारे पास मल्टीपल स्लेव नोड्स हैं। राइट? स्लेव वन यदि डाउन होगा तो यूजर की रिक्वेस्ट को स्लेव टू
सर्व कर सकता है। स्लेव थ्री कर सर्व कर सकता है। स्लेव फोर सर्व कर सकता है। और एक अब यहां पे डाउट आता है कि व्हाट इफ
हमारा मास्टर नोड ही डाउन हो जाए। तो यदि ऐसा कुछ होता है कि हमारा मास्टर नोड डाउन हो जाता है तो इस केस में क्या होता है कि
वन ऑफ द स्लेव नोड विल बिकम अ मास्टर नोड। तो हमारा स्लेव नोड मास्टर नोड बन जाएगा और वो एज अ मास्टर नोड वर्क करेगा। और फिर
यह स्लेव नोड क्या करेगा? यह राइट ऑपरेशंस को लेने लगेगा। क्यों? क्योंकि अब ये मास्टर नोड एज अ मास्टर नोड वर्क कर रहा
है। तो ऐसे करके हमने हमारे डेटाबेस की सिंगल पॉइंट ऑफ फेलियर वाली प्रॉब्लम को सॉल्व कर दिया थ्रू मास्टर स्लेव
आर्किटेक्चर। तो ये था हमारा फोर्थ पॉइंट जहां हमने डेटाबेस रेप्लिकेशन किया। अब जो थर्ड फिफ्थ पॉइंट हमारा आता है वो है कैश
मेमोरी फॉर बेटर परफॉर्मेंस। तो अब इसे समझते हैं कि कैश मेमोरी होती क्या है? तो ये हमारे डिफरेंट एप्लीकेशन सर्वर्स हैं।
बेसिकली हम कह सकते हैं कि हमारा एप्लीकेशन टियर है और ये हमारा डेटा टियर है जहां हमारा डेटाबेस है। तो ये हमारे
पास डिफरेंट ऐसे एप्लीकेशन सर्वर्स हैं। राइट? और यहां पर यह डाटा टियर है। जहां हमारे डिफरेंट स्लेव नोड्स हैं और एक
हमारा मास्टर नोड है। तो अब लेट्स से कि ये कोई क्लाइंट रिक्वेस्ट करता है। तो रिक्वेस्ट सबसे पहले पहले वन ऑफ द
एप्लीकेशन सर्वर्स के पास जाती है। राइट? यह लोड बैलेंसर डिसाइड करता है कि किस एप्लीकेशन सर्वर के पास यूजर की रिक्वेस्ट
जाएगी। अब लेट्स से कि यह क्लाइंट रिक्वेस्ट करता है कि मुझे अपनी पर्सनल इनेशन चाहिए। लेट्स से हमारे पास कोई
एप्लीकेशन है। लेट्स से ई-कॉमर्स काइंड ऑफ़ एप्लीकेशन है। और उस एप्लीकेशन में क्लाइंट बोलता है कि मुझे अपनी पर्सनल
इंफॉर्मेशनेशन चाहिए। तो लेट्स से कि इस क्लाइंट से इस ऐप सर्वर वन तक जाने में रिक्वेस्ट जाने में 2 मिलीसे का टाइम लग
रहा है। राइट? अब ये एप्लीकेशन सर्वर के पास इंफॉर्मेशनेशन नहीं है। ये एप्लीकेशन सर्वर कहां से इंफॉर्मेशन लेके आ रहा है?
ये एप्लीकेशन सर्वर जाएगा किसी स्लेव नड के पास और वहां से पूछेगा कि ये यूजर है। इसकी मुझे डिटेल चाहिए। तो अब लेट्स से कि
ये एप्लीकेशन सर्वर वन स्लेव वन के पास जाता है। स्लेव नड के पास जाता है और वहां से यह यूजर की पर्सनल इंफॉर्मेशनेशन लेके
आता है। अब लेट्स से कि ऐप सर्वर वन से स्लेव नड तक जाने में 4 मिलीसे का टाइम लग रहा है। क्यों?
क्योंकि डेटाबेस ऑपरेशंस जो होते हैं दे आर वेरी कॉस्टली। स्पेशली जब हमारे नंबर ऑफ यूज़र्स बढ़ जाते हैं तो डेटाबेस क्वेरीज़
स्लो हो जाती हैं। तो डेटाबेस ऑपरेशंस वैसे ही दे आर वेरी कॉस्टली। तो अब क्या हो रहा है कि ऐप सर्वर वन को स्लेव वन तक
जाने में बेसिकली उससे रिक्वेस्ट करने में 4 मिलीसे का टाइम लग रहा है। अब 4 मिलीसे लेट्स से रिक्वेस्ट को स्लेव वन से ऐप
सर्वर आने में भी लगेगा। राइट? तो यहां 4 मिलीसे यह हो गया और फिर यह ऐप सर्वर से वन से वापस इस क्लाइंट तक रिस्पांस जाने
में भी लेट्स से 2 मिलीसे का टाइम लग रहा है। तो इफ वी कैलकुलेट तो ये कितना हो जाएगा? 2 + 4 6 + 4 10 + 2 12 तो बेसिकली
हम कह सकते हैं कि 12 मिलीसे में यूजर को अपना रिस्पांस मिल जा रहा है या यूजर को अपनी पर्सनल डिटेल्स मिल जा रही हैं। पर
यदि हम कैश मेमोरी यूज़ करते हैं तो उससे क्या फायदा होगा? अब हम देखते हैं तो कैश मेमोरी हम डिस्ट्रीब्यूटेड कैश यहां यूज़
कर रहे हैं। तो अब कोई भी रिक्वेस्ट आएगी उसको डायरेक्ट डेटाबेस में या डेटाबेस में चेक नहीं करना कि लेट्स से यूजर ने कुछ
रिक्वेस्ट किया तो हर बार ये ऐप सर्वर को यहां डेटाबेस या किसी स्लेव डेटाबेस के पास नहीं आना। वो क्या करेगा? सिंपली इस
कैश मेमोरी में चेक करेगा कि लेट्स से मेरे पास एक यूजर है। क्या इस यूजर की इंफॉर्मेशन यहां स्टर्ड है। यदि यह यूजर
की इंफॉर्मेशनेशन स्टर्ड होगी तो यह ऐप सर्वर यहीं से कैश मेमोरी से ही यूजर की रिक्वेस्ट को फुलफिल कर देगा और उसे
डेटाबेस तक जाना नहीं पड़ेगा। तो लेट्स से कि अब क्लाइंट को ऐप सर क्लाइंट की रिक्वेस्ट को ऐप सर्वर थ्री तक आने में
लेट्स से 2 मिली सेकंड का टाइम लग रहा है और कैश से वो इंफॉर्मेशनेशन फाइंड आउट करने में लेट्स से 1 मिलीसे का टाइम लग
रहा है। ऐसा क्यों? क्योंकि जो हमारी कैश मेमोरी होती है इट इज़ फास्ट बिकॉज़ इट इज़ इन मेमोरी सॉल्यूशन। तो यहां पे 1 मिलीसे
का टाइम लगा और इस कैश से इस डेटा को लेने में यहां पे भी लेट्स से 1 मिलीसे। बेसिकली ऐप सर्वर ने रिक्वेस्ट किया ऐप
सर्वर 3 ने कैश से तो इसमें 1 मिलीसे का टाइम और कैश से इस ऐप सर्वर 3 तक रिस्पांस जाने में 1 मिलीसे का टाइम और उसके बाद ऐप
सर्वर थ्री से क्लाइंट तक वापस रिस्पांस जाने में 2 मिलीसे और टाइम लगा। तो ये कितना हो गया? 2 + 2 4 5 एंड 6 तो यू कैन
सी कि जो रिक्वेस्ट 12 मिलीसे में फुलफिल हो रही थी वो यहां पे 6 मिलीसे में फुलफिल हो गई इफ वी आर यूजिंग कैश मेमोरी तो यू
कैन सी कि कैश मेमोरी का यूज़ करने से हमने क्वेरीज़ को या हमने हमारे सिस्टम को की परफॉर्मेंस को बढ़ा दिया और हमने हमारे
सिस्टम को फास्ट कर दिया। तो यह हो गया हमारा कैश मेमोरी का यूज़। अब व्हाट इफ की कैश मेमोरी में यूजर की डिटेल नहीं है।
लेट्स से ये क्लाइंट आया। ये यूजर आया और बोला मुझे पर्सनल डिटेल चाहिए। अब व्हाट इफ की इस कैश मेमोरी में यूजर की डिटेल
नहीं है। तो इस केस में क्या होता है? फिर ऐप सर्वर को वापस स्लेव नड में ही जाना पड़ता है। स्लेव नड के पास जाना पड़ता है।
और फिर यह स्लेव नड से यूजर की डिटेल लेके आएगा। और यहां पे फिर यह डिटेल को कैश मेमोरी में स्टोर करेगा फॉर फ्यूचर
रेफरेंस। और फिर यह यूजर की डिटेल को क्लाइंट को भेज देगा। तो, यह होता है हमारा कैश मेमोरी का यूज़। और हमने देखा कि
कैसे हम कैश का यूज करके कैश मेमोरी का यूज करके हम हमारे सिस्टम की परफॉर्मेंस को बढ़ा सकते हैं। और हमारे जो रिक्वेस्ट
का रिस्पांस टाइम है या हम कह सकते हैं हम लेटेंसी को हम डिक्रीज कर सकते हैं। जो काम हमारा डेटाबेस के थ्रू 12 मिलीसे में
हो रहा था वो हमने कैश के थ्रू 6 मिलीसे में कंप्लीट कर दिया। तो ये था हमारा फिफ्थ पॉइंट जहां हमने देखा कैश मेमोरी।
अब जो हमारा नेक्स्ट पॉइंट है वो है सीडीएन। तो सीडीएन को हम बोलते हैं कंटेंट डिलीवरी नेटवर्क। और यह जो हमारा सीडीएन
होता है इट डज़ कैशिंग। बेसिकली हम कह सकते हैं कि सीडीएन हमारा कैशिंग करता है और यह हमारा सीडीएन हमें स्टैटिक डेटा स्टोर
करने में हेल्प करता है। स्टैटिक डेटा जैसे HTML पेजेस, HTML पेजेस, अ वीडियोस, वीडियोस, इमेजेस। तो ऐसा यदि हमारे पास
कोई स्टैटिक डेटा है तो ये स्टैटिक डेटा स्टोर करने में सीडीए हमारी हेल्प करता है। अब सीडीए को हम एक एग्जांपल के थ्रू
समझते हैं। लेट्स से कि हमने कोई एक ग्लोबल एप्लीकेशन बनाया अ Netflix जैसा या लेट्स से SWGI जैसा। तो हमने कोई एक
ग्लोबल एप्लीकेशन बनाया। अब इस ग्लोबल एप्लीकेशन में हमारे पास डे डेटा सेंटर्स हैं। राइट? इस डेटा सेंटर में हमारे पास
एप्लीकेशन सर्वर्स भी आ जाएंगे। एप्लीकेशन सर्वर आ जाएंगे। हमारे पास डेटाबेस सर्वर्स आ जाएंगे। जहां हम मास्टर नोड और
स्लेव नोड देखेंगे। तो हमारे पास ऐसे डेटा सेंटर में एक डेटा सेंटर के अंदर हमारे पास एप्लीकेशन सर्वर्स भी होंगे।
डाटा सेंटर के अंदर हमारे पास एप्लीकेशन सर्वर्स भी होंगे और हमारे पास डेटाबेस सर्वर्स भी होंगे जिसमें हमारे
पास मास्टर नोड भी होंगे प्लस स्लेव नोड भी होंगे। तो ये हो गया हमारा एक डेटा सेंटर। अब यदि हम ग्लोबल एप्लीकेशन बनाते
हैं Netflix जैसा तो क्या होता है कि हम डेटा सेंटर्स को इन डेटा सेंटर्स को ज्योग्राफिकली डिस्ट्रीब्यूट कर देते हैं।
तो क्या होता है कि लेट्स से एक डाटा सेंटर हमारा इंडिया में है। एक डेटा सेंटर हमारा इंडिया में है और एक डेटा सेंटर
हमारा लेट्स से यूएसए में है। एक डेटा सेंटर हमारा लेट्स से यूएसए में है। तो ऐसे करके हमने डिस्ट्रीब्यूट कर दिया।
रीजन वाइज रीजन वाइज डिस्ट्रीब्यूट कर दिया। एक डाटा सेंटर हमारा इंडिया रीजन में है। एक डाटा सेंटर हमारा लेट्स से
यूएसए रीजन में है। अब क्या हो सकता है कि लेट्स से बहुत ज्यादा ट्रैफिक एक दूसरे रीजन से यूके रीजन से आ रहा है। तो इस केस
में क्या होता है कि यूजर की रिक्वेस्ट को बहुत ट्रैवल करना पड़ता है और यह हमारा लेटेंसी को इंक्रीस कर देता है। क्यों?
क्योंकि यह यूजर जो है यह यूके में है और डेटा सेंटर इंडिया में है या यूएसए में है। तो इस केस में क्या होता है कि यूजर
की रिक्वेस्ट को बहुत ट्रैवल करना पड़ता है और इससे क्या होता है? लेटेंसी इनक्रीस हो जाती है और इट गिव्स बैड यूजर
एक्सपीरियंस टू यूजर। अब क्यों ऐसा हो रहा है? क्योंकि लेट्स से कोई यूजर इंडिया में है तो इंडिया में तो ऑलरेडी डेटा सेंटर
है। तो यूजर की रिक्वेस्ट को यहां ज्यादा ट्रैवल नहीं करना। लेकिन व्हाट इफ ह्यूज ट्रैफिक इज कमिंग
फ्रॉम यूके। तो इस केस में क्या होता है कि हम सीडीएन को नए सीडीएन को होस्ट कर देते हैं यहां यूके में। तो अब क्या होगा
कि यूके से किसी भी यूजर की रिक्वेस्ट जाएगी। तो वो इन डेटा सेंटर्स में इंडिया और यूएसए के डेटा सेंटर में ना जाके वो
यूजर की रिक्वेस्ट इस सीडीएन में जाएगी और यह सीडीएन यूजर की रिक्वेस्ट को सर्व कर देगा। तो बेसिकली हमने क्या किया? हमने
लोकल सीडीएन होस्ट कर दिया यूके में। हमने एक सीडीएन होस्ट कर दिया यूके में। और अब यही सीडीए यहां यूके के यूज़र्स की
रिक्वेस्ट को सर्व करेगा। अब लेट्स से कि जो डेटा यूजर को चाहिए वो लेट्स से इस सीडीएन में नियरेस्ट सीडीएन में या सीडीएन
जो यूके में होस्टेड है उस सीडीएन में वो डेटा नहीं है जो यूजर को चाहिए। तो इस केस में क्या होता है? इस यूजर की रिक्वेस्ट
एक और नियरेस्ट सीडीए में जाती है। लेट्स से एक और यहां पे नियरेस्ट सीडीएन है। नियरेस्ट सीडीए तो इस यूजर की रिक्वेस्ट
इस सीडीएन में जाएगी और यहां से इस यूजर की रिक्वेस्ट फिर फुलफिल होगी। एंड व्हाट इफ कि इस सीडीएन में भी वो डेटा नहीं है
जो यूजर को चाहिए। तो फिर क्या होता है कि फिर यह यूजर की रिक्वेस्ट वन ऑफ द डेटा सेंटर में जाएगी जो या तो इंडिया में है
या यूएसए में है। तो ऐसे करके सीडीएन हमें लेटेंसी को रिड्यूस करने में हेल्प करता है और बेसिकली हम इसे यूज़ करते हैं टू
स्टोर स्टैटिक डेटा। स्टैटिक डेटा में हमारा हो गया इमेजेस, वीडियोस, HTML पेजेस और ऑडियोज़। तो इफ वी हैव स्टैटिक डेटा तो
वी आर गोइंग टू यूज़ सीडीएन। और हमने देखा कि सीडीएन का यूज करके हम कैसे हमारे सिस्टम की लेटेंसी को कम कर सकते हैं। तो
यह था हमारा सिक्स्थ पॉइंट जहां हमने देखा सीडीएन और सीडीएन का भी हम यूज़ करते हैं इफ वी हैव ह्यूज नंबर ऑफ यूज़र्स। क्योंकि
नंबर ऑफ यूज़र्स बढ़ने का मतलब है कि अब जो हमारा ट्रैफिक है वह ग्लोबली आ रहा होगा अह फ्रॉम डिफरेंट रीजंस फ्रॉम डिफरेंट
अवेलेबिलिटी ज़ोंस। तो हम क्या करते हैं? डिफरेंट-डिफरेंट रीजंस में हमारे सीडीएन को होस्ट कर देते हैं और नियरेस्ट पॉसिबल
सीडीए यूजर की रिक्वेस्ट को सर्व करता है। तो ये था हमारा सिक्स्थ पॉइंट। अब जो हमारा नेक्स्ट पॉइंट है वो है मल्टीपल
डेटा सेंटर्स। तो अब इसे भी एक एग्जांपल के थ्रू समझते हैं। लेट्स से कि हमारे पास एक ग्लोबल एप्लीकेशन है Netflix जैसा। और
इस एप्लीकेशन के हमारे पास लेट्स से दो डेटा सेंटर्स हैं। एक है इंडिया में एंड एक है यूएसए में। अब लेट्स से कि बिकॉज़ ऑफ़
सम एक्स वzेड रीजन ये हमारा यूएसए वाला रीजन यूएसए रीजन का डेटा सेंटर लेट्स से फेल हो गया। तो इस केस में क्वेश्चन ये
आता है कि जो हमारे यूएसए के यूज़र्स हैं उनकी रिक्वेस्ट को हम कैसे फुलफिल करेंगे? तो अब इस केस में हमारे पास क्या है कि
हमारे पास सिर्फ दो डेटा सेंटर हैं। जिसमें से एक डाउन हो गया। जो हमारा यूएसए रीजन का डेटा सेंटर है वो ऑलरेडी डाउन हो
गया। तो अब इस केस में यूएसए के यूज़र्स की रिक्वेस्ट को यह इंडिया रीजन का डेटा सेंटर यूएसए के यूज़र्स की रिक्वेस्ट को
फुलफिल करेगा। तो यह काम होता है हमारे डेटा सेंटर्स का। हम बेसिकली एक रीजन के अंदर लेट्स से कि हमारा कोई एक इंडिया
रीजन है। तो हम इस इंडिया रीजन के अंदर मल्टीपल डाटा सेंटर्स रख सकते हैं। लेट से डाटा सेंटर वन, डाटा सेंटर टू, डाटा सेंटर
थ्री। तो ऐसे हमारे पास मल्टीपल डेटा सेंटर्स हो सकते हैं। अब लेट्स से कि यदि हमारा डेटा सेंटर वन फेल होता है या किसी
वजह से यह क्रैश कर जाता है तो हमारा डेटा सेंटर टू इंडिया के यूज़र्स की रिक्वेस्ट को फुलफिल करेगा। राइट? और यदि ये भी
क्रैश हो जाता है तो हमारे पास डेटा सेंटर थ्री है। तो ऐसे करके हमने हमारे सिस्टम की हाई अवेलेबिलिटी को मेंटेन किया। मतलब
यदि हमारे एकद डेटा सेंटर्स फेल भी हो जाते हैं तब भी हमारे पास और डेटा सेंटर्स अवेलेबल हैं। और यदि लेट्स से हमारे ये
तीनों डेटा सेंटर्स फेल हो जाते हैं तो हम कह सकते हैं कि यदि हमारा ये पूरा रीजन ही फेल हो जाता है तो फिर हमारे पास एक दूसरा
रीजन है यूएसए रीजन। इस यूएसए रीजन में भी हमारे पास मल्टीपल डेटा सेंटर्स हैं। डेटा सेंटर वन, डेटा सेंटर टू। तो यदि हमारे
पूरा इंडिया रीजन ही फेल हो जाता है तो फिर हम यूज़र्स की रिक्वेस्ट को इस यूएसए रीजन से यूज़र्स की रिक्वेस्ट को फुलफिल
करेंगे। तो ये था हमारा सेवंथ पॉइंट जहां हम देखते हैं मल्टी मल्टीपल डेटा सेंटर्स। अब जो हमारा नेक्स्ट पॉइंट है वो है
डेटाबेस शार्डिंग। तो डेटाबेस शार्डिंग में हम क्या करते हैं कि हम ह्यूज डेटा सेट को इसे हम एक एग्जांपल से समझते हैं
कि लेट्स से एक हमारे पास डेटाबेस है। डेटाबेस की कोई टेबल है लेट्स से यूजर टेबल और इस यूजर टेबल में लेट्स से 1
मिलियन रोज़ हैं। 1 मिलियन रोज़ हैं। राइट? अब लेट्स से कि हमें कोई सर्च ऑपरेशन परफॉर्म करना है। सर्च ऑपरेशन परफॉर्म
करना है। अब हमने देखा कि डेटाबेस क्वेरीज या डेटाबेस ऑपरेशंस जो होते हैं दे आर ऑलरेडी वेरी कॉस्टली। ऊपर से क्या है कि
अब हमें कोई सर्च ऑपरेशन परफॉर्म करने के लिए हम हमें पूरे के पूरे 1 मिलियन एंट्रीज पे आइट्रेट करना पड़ेगा। तो एक
ऑप्शन होता है वह होता है हमारे पास कि हम इंडेक्सिंग का यूज़ कर लें। लेकिन इंडेक्सिंग के भी कुछ हमें
डिसएडवांटेजेस या कुछ ड्रॉबैक्स होते हैं। वह इस वीडियो का पार्ट नहीं है। तो हम उसे डिस्कस नहीं करते हैं। लेकिन क्या होता है
कि सर्च क्वेरीज को और डेटाबेस परफॉर्मेंस को इंक्रीस करने के लिए हम एक और टॉपिक का यूज़ करते हैं। एक और कांसेप्ट का यूज़ करते
हैं जिसे हम डेटाबेस शार्डिंग बोलते हैं। अब इस डेटाबेस शार्डिंग में हम बेसिकली क्या करते हैं कि ह्यूज डेटा सेट को जैसे
यहां पे 1 मिलियन यूज़र्स का जो हमारे पास डेटा सेट है उसको हम स्मालस्मॉल पीसेस में डिवाइड करते हैं। और ईच पीस को लेट्स से
हमने 1 मिलियन रोज़ को फाइव ऐसे डिफरेंट पीसेस में डिवाइड कर लिया। तो हर पीस को हम क्या बोलते हैं? एक शार्ड बोलते हैं।
एक डिफरेंट शार्ड बोलते हैं। लेट से यह हो गया शार्ड वन शार्ड टू शार्ड थ्री ऐसे करके हमारे पास डिफरेंट
शार्ड्स हैं। तो अब यह शार्डिंग हमें कैसे डेटाबेस शार्डिंग हमें कैसे हेल्प करता है? तो इसको हम समझते हैं। लेट्स से कि
हमारे पास 1 मिलियन यूज़र्स का रिकॉर्ड है। तो हमारे पास 1 मिलियन रोज़ हैं। 1 मिलियन रोज़। अब हम क्या करते हैं? शार्डिंग में
इन रोज़ को मल्टीपल शार्ड्स में डिवाइड कर देते हैं। हम बेसिकली क्या करते हैं? लार्ज डेटा सेट को ऐसे डिफरेंट-डिफरेंट
शार्ड्स में डिवाइड कर देते हैं। लेट्स से ये हो गया हमारा शार्ड वन, ये हो गया हमारा शार्ड टू, ये हो गया हमारा शार्ड
थ्री। ऐसे करके हमारे डेटा सेट को डिफरेंट-डिफरेंट शार्ड्स में डिवाइड कर देते हैं। अब यहां पे ईच शार्ड इज़ एन
इंडिविजुअल डेटाबेस। यहां पे हर शार्ड एक इंडिविजुअल डेटाबेस की तरह काम करता है। तो अब हमारे पास लेट्स से 1 मिलियन रोज़
थी। तो ये जो हमारा S1 शार्ड है ये लेट्स से वन से लेके 1000 रोज़ को मैनेज कर रहा है। ये शार्ड टू टू 1000 से लेके लेट्स से
2000 रोज़ को मैनेज कर रहा है। ऐसे करके हमने हमारे डेटा सेट को डिफरेंट शार्ड्स में डिवाइड कर दिया। तो हर डेटा से हर श
यहां पे एक इंडिविजुअल डेटाबेस है और हम हर चार्ट के लिए एक इंडिविजुअल सर्वर भी कॉफ़िगर कर सकते हैं। बेसिकली हम कह सकते
हैं कि हमने यहां पे हॉरिजॉन्टली स्केल कर दिया। तो, यह काम है हमारे शार्डिंग का। और अब देखिए कि हमारे पास 1 मिलियन रोज़
में हमें आइट्रेट नहीं करना। हमें यदि कोई रिकॉर्ड फाइंड करना है, तो हम बेसिकली क्या करेंगे? रेलेवेंट चार्ट को कॉल कर
देंगे और उस रेलेवेंट चार्ट में अब नंबर ऑफ एंट्रीज कम होंगी। तो हम ईजीली उस शार्ड में डेटा को फाइंड कर सकते हैं। तो
ऐसे रेलेवेंट शार्ड को कॉल करके हम हमारे सर्च ऑपरेशंस को सर्च क्वेरीज को फास्ट बना सकते हैं। और ऐसे हमारा यह शार्डिंग
सिस्टम की परफॉर्मेंस में हेल्प करता है। तो ये था हमारा एट्थ पॉइंट जहां हमने डेटाबेस शार्डिंग को देखा। अब ये डेटाबेस
शार्डिंग हमारी नेम बेस्ड शार्डिंग भी हो सकती है। लेट्स से हमारे पास फ्रॉम ए टू जेड नेम्स हो सकते हैं किसी भी यूजर के।
राइट? तो हम ऐसा कर सकते हैं कि नेम बेस्ड शार्डिंग कर सकते हैं कि ए से आने वाले जो यूज़र्स होंगे उनको एक डिफरेंट शार्ड में
रख दिया। जिन यूज़र्स के नेम एस से स्टार्ट हो रहे हैं उनको हमने एक डिफरेंट शार्ड में रख दिया। तो ऐसे करके हम नेम बेस्ड
शार्डिंग कर सकते हैं। हम एज बेस्ड शार्डिंग कर सकते हैं। हम जी हम Jio बेस्ड या लोकेशन बेस्ड शार्डिंग कर सकते हैं। हम
हम जेंडर बेस्ड शार्डिंग कर सकते हैं। तो ऐसे हम शार्डिंग डिफरेंट-डिफरेंट पैराटर्स के बेसिस पे कर सकते हैं। और हमारे पास एक
शार्ड की होता है जिसके बेसिस पे हम फिगर आउट करते हैं कि कोई यदि हमारे पास डेटा है तो वो किस शार्ड को बिलॉन्ग करता है।
तो ये था हमारा डेटाबेस शार्डिंग। अब जो हमारा नेक्स्ट पॉइंट है वो है मैसेजिंग कज़। तो अब मैसेजिंग कज़ को आई हैव डिस्कस्ड
अ लॉट इन माय सिस्टम डिज़ वीडियोस जहां हमने Netflix सिस्टम डिज़ाइन में SWGI सिस्टम डिज़ ब्लिंकट सिस्टम डिज़ाइन इन सब
में हमने मैसेजिंग कज़ को काफका को बहुत डिस्कस किया। तो अब समझते हैं, देखते हैं कि कैसे मैसेजिंग कज़ हमें स्केल करने में
हेल्प करता है। बेसिकली ये डायरेक्ट स्केल करने में हेल्प तो नहीं करता पर इसकी वजह से हम हमारे सिस्टम की परफॉर्मेंस को
इंक्रीस कर लेते हैं और हम हमारे सिस्टम को क्रैश होने से भी बचाते हैं। तो अब समझते हैं इसे एक एग्जांपल से। लेट्स से
हमारे पास एक ई-कॉमर्स एप्लीकेशन है Amazon काइंड ऑफ। तो यदि उस एप्लीकेशन में हम मैसेजिंग क्यूज़ को यूज़ ना करें तो तब
क्या होता है? उसको एक बार समझते हैं। तो यदि हम हमारे एप्लीकेशन में मैसेजिंग कज़ को यूज़ ना करें तो सबसे पहले क्या होगा?
लेट्स से कोई यूजर ने प्लेस ऑर्डर पे क्लिक किया तो यह ऑर्डर सर्विस इनवोक होगी। अब ये ऑर्डर सर्विस इनवोक होगी। तो
सबसे पहले क्या होगा कि लेट्स से किसी यूजर ने लेट्स से पीनट बटर ऑर्डर किया। तो सबसे पहले हमें उसका इन्वेंटरी काउंट
डिक्रीज करना होगा। राइट? तो सबसे पहले हमारा इन इन्वेंटरी सर्विस इनवोक होगी। फिर हम पेमेंट सर्विस को कॉल करेंगे। तो
यह हो गया हमारा सेकंड सेकंड टास्क। फिर उसके बाद एक बार पेमेंट सक्सेसफुल हो जाएगी। फिर हम यह शिपमेंट सर्विस को कॉल
कर देंगे कि अब आगे कैसे प्रोडक्ट को शिप करना है। उसकी शिपिंग करना है। इसलिए हम शिपमेंट सर्विस को कॉल करेंगे। हम
नोटिफिकेशन सर्विस को भी कॉल कर देंगे कि यह यूजर को नोटिफाई करेगी और नोटिफिकेशन देगी कि ठीक है तुम्हारा ऑर्डर जो है यह
प्लेस हो गया है सक्सेसफुली और उसका जो भी लाइव ट्रैकिंग होगी तो उसका उस सब के लिए हम नोटिफिकेशन सर्विस यूज़ करेंगे। तो यदि
हम मैसेजिंग कज़ नहीं यूज़ करते हैं तो क्या होता है कि लेट्स से हमारे पास 10 मिलियन रिक्वेस्ट एक साथ आई। राइट?
लेट्स से कोई फेस्टिव सीजन चल रहा है तो या सेल चल रही है तो 10 मिलियन रिक्वेस्ट एक साथ आई इस ऑर्डर सर्विस के पास। अब
ऑर्डर सर्विस सबसे पहले क्या करेगा? इन्वेंटरी काउंट को कम करेगा। तो यह इन्वेंटरी काउंट के लिए इन्वेंटरी सर्विस
इनवोक होगी। तो एक साथ 10 मिलियन रिक्वेस्ट इस इन्वेंटरी सर्विस को भी हिट करेंगी। राइट? एक साथ 10 मिलियन रिक्वेस्ट
इस पेमेंट सर्विस को भी हिट करेंगी। एक साथ 10 मिलियन रिक्वेस्ट इस शिपमेंट को और इस नोटिफिकेशन सर्विस को भी हिट करेंगी।
अब इनमें से किसी एक के भी फेल हो जाने की वजह से क्या होगा कि पूरा ऑर्डर पूरा का पूरा ऑर्डर जो यूजर ने किया था वो फेल हो
जाएगा। वो क्रैश हो जाएगा। तो यह एक प्रॉब्लम आती है हमारे सिस्टम में इफ वी डोंट यूज़ मैसेजिंग क्यूज़। अब ऐसा क्यों
हो रहा है कि लेट्स से कि ये जो पेमेंट सर्विस है इसकी कैपेसिटी है केवल लेट्स से 1 मिलियन रिक्वेस्ट को हैंडल करने की एक
बार में और एक साथ यहां पे आ गई 10 मिलियन रिक्वेस्ट। तो इस केस में यह पेमेंट सर्विस जो होगी यह
ओवरवेल्म हो जाएगी और यहां पे यह इतना सारा ट्रैफिक को मैनेज नहीं कर पाएगी। तो ये हमारा पूरा सिस्टम को क्रैश कर सकती
है। अब मैसेजिंग कज़ के आने से क्या होता है कि इतनी सारी रिक्वेस्ट डायरेक्ट इन सर्विसेस को हिट नहीं करेंगी। अ लेट्स से
हमारे पास 1 मिलियन रिक्वेस्ट हैं। तो मैसेजिंग क्यूज़ के आने से अब ये इतनी सारी रिक्वेस्ट एक साथ डायरेक्ट इन सर्विसेज को
हिट नहीं करेंगी। क्या होगा सिंपली कि ये काफका मैसेजिंग क्यू में या कोई भी रैबिट एमक्यू मैसेजिंग क्यू एस क्यूएस इनमें
क्या करेंगे हम इन रिक्वेस्ट को अ स्टोर कर लेंगे इस मैसेजिंग क्यू में और हम यहीं से यूजर को नोटिफाई कर देंगे कि ओके योर
ऑर्डर हैज़ बीन प्लेस्ड और उसके बाद क्या होगा कि यह जो डिफरेंट सर्विसेस हैं यह अपनी कैपेसिटी के अकॉर्डिंग इन रिक्वेस्ट
को कंज्यूम करेंगे। लेट्स से पेमेंट सर्विस की कैपेसिटी है 100 रिक्वेस्ट पर सेकंड। 100 रिक्वेस्ट पर सेकंड। तो इस
मैसेजिंग क्यूस के आने से क्या हुआ कि अब यह अपनी कैपेसिटी के अकॉर्डिंग इन रिक्वेस्ट को लेगा और फिर उन्हें मैनेज
करेगा। उन पे काम करेगा। तो जब यह मैसेजिंग क्यों नहीं था तो क्या हो रहा था कि जितनी रिक्वेस्ट थी वह सारी एक साथ इस
पेमेंट सर्विस को हिट कर जा रही थी। लेकिन अब क्या हुआ? पेमेंट इस मैसेजिंग क्यू के आने से यह पेमेंट सर्विस अपने कैपेसिटी के
अकॉर्डिंग काम करेगा और एक अपनी नॉर्मल पेस पे चलेगा। जितनी रिक्वेस्ट वो हैंडल कर सकता है। लेट्स से 100 रिक्वेस्ट पर
सेकंड वो हैंडल कर सकता है। तो वो सिर्फ 100 रिक्वेस्ट पर सेकंड इस मैसेजिंग क्यू से लेगा। उन्हें प्रोसेस करेगा। उन पे काम
करेगा। देन फिर वह नेक्स्ट 100 पे काम करेगा। तो यह काम होता है हमारे मैसेजिंग क्यूज़ का। बेसिकली हम कह सकते हैं कि दिस
इज़ वन ऑफ द एडवांटेज या वन ऑफ द वर्क ऑफ मैसेजिंग कज़। और हां एक चीज और कि लेट्स से कि यदि ये नंबर ऑफ यूज़र्स और बढ़ जाते
हैं, नंबर ऑफ रिक्वेस्ट और बढ़ जाती हैं, तो हम पेमेंट सर्विस के और इंडिविजुअल इंस्टेंसेस यूज़ कर सकते हैं। बेसिकली हम
कह सकते हैं कि हम पेमेंट सर्विस को हॉरिजॉन्टली स्केल कर सकते हैं। यह हमने ऑलरेडी पिछले वीडियोस में भी काफी डिस्कस
किया है। तो, यह था हमारा नाइंथ पॉइंट जहां हमने देखा मैसेजिंग कज़। अब ये मैसेजिंग कज़ में हमारे पास प्रोड्यूसर
होता है जो बेसिकली एक इवेंट को ट्रिगर करता है। इस केस में इवेंट हो सकता है ऑर्डर कंफर्म्ड, ऑर्डर प्लेस्ड ऑर्डर रेडी
टू शिप्ड। तो ऐसे यह डिफरेंट इवेंट्स को यह ऑर्डर सर्विस प्रोड्यूस करेगा और यह फिर इवेंट जाएगा इस काफका में जहां यह
स्टोर होगा और फिर अकॉर्डिंग टू द वर्क यह डिफरेंट-डिफरेंट सर्विसेज उन इवेंट्स को कैप्चर करेंगी और फिर उन पे काम करेंगी।
तो, यह होता है हमारा नाइंथ पॉइंट जहां हमने देखा मैसेजिंग कज़ कि कैसे मैसेजिंग क्यूज़ हमें स्केल करने में मदद करता है
फ्रॉम जीरो टू मिलियन यूज़र्स। तो आई गेस आपको यह वीडियो पसंद आया होगा। एंड दिस इज ऑल फॉर दिस वीडियो। वी विल सी यू इन द
नेक्स्ट वीडियो। सो टिल देन बाय-ब शो सम लव। थैंक्स। [संगीत]
हे एवरीवन, वेलकम बैक। वेलकम टू दिस अल्टीमेट सिस्टम डिज़ प्लेलिस्ट सीरीज। और आज के इस वीडियो में हम बात करने वाले हैं
कैशिंग के बारे में कि कैशिंग होता क्या है? हमें कैशिंग की नीड क्या है? और हम देखेंगे कुछ पॉपुलर कैशिंग की स्ट्रेटजीस
को। तो स्टार्ट करते हैं और इस कैशिंग को समझते हैं हम एक एग्जांपल के थ्रू। तो लेट्स से कि आप एक ई-कॉमर्स एप्लीकेशन यूज़
कर रहे हैं Amazon, Flipkart जैसा। तो उस एप्लीकेशन में कुछ डेटा ऐसा होगा जो आप बहुत फ्रीक्वेंटली एक्सेस करेंगे। कॉमनली
आस्क्ड डेटा। उस डेटा में हमारा आ सकता है प्रोफाइल यूजर प्रोफाइल या हम किसी पर्टिकुलर आइटम की बार-बार हम उसका प्राइस
चेक करेंगे उस आइटम को सर्च करेंगे तो ऐसे हमारे वेबसाइट में कुछ कॉमनली आस्क्ड डेटा या फ्रीक्वेंटली आस्क्ड डेटा हो सकता है।
तो उस डेटा को हम एक्सेस कैसे करेंगे? यह हम पहले भी प्रीवियस वीडियोस में देख चुके हैं कि यह क्लाइंट रिक्वेस्ट करेगा और यह
रिक्वेस्ट सबसे पहले जाएगी सर्वर के पास। उसके बाद यह सर्वर डेटाबेस से क्वेरी करेगा उस डेटा को और डेटाबेस रिजल्ट या
रिस्पांस सेंड करेगा। फिर यह सर्वर उस रिस्पांस को सेंड कर देगा क्लाइंट को। अब लेट्स से कि ये क्लाइंट लेट्स से ये यूजर
ए है। ये यूजर ए है हमारा और ये यूजर ए अपनी प्रोफाइल को एक्सेस करना चाहता है। एक ई-कॉमर्स एप्लीकेशन में अपनी प्रोफाइल
को एक्सेस करना चाहता है। तो सबसे पहले यह रिक्वेस्ट जाएगी सर्वर के पास। तो लेट्स से कि क्लाइंट से सर्वर तक रिक्वेस्ट जाने
में 2 मिलीसे का टाइम लग रहा है। और फिर यह सर्वर क्या करेगा? यह सर्वर जाएगा इस डाटा पे डेटाबेस के पास इस यूजर ए की
प्रोफाइल को लेने के लिए या इस यूजर ए की प्रोफाइल को एक्सेस करने के लिए। तो लेट्स से कि सर्वर ए से सर्वर से डेटाबेस तक
जाने में हमें फिर से 2 मिलीसे का टाइम लगा क्योंकि ये एक नेटवर्क कॉल होगी। हम डेटाबेस तक जा रहे हैं। सो इट विल बी अ
नेटवर्क कॉल। तो यह हमें सर्वर से डेटाबेस तक जाने में लगा 2 मिलीसे का टाइम। अब लेट्स से कि वापस डेटाबेस
सर्वर को रिस्पांस सेंड करेगा। तो उसमें भी हमें लेट्स से 2 मिलीसे का टाइम लग रहा है। तो ये रिस्पांस आ गया सर्वर के पास।
उसके बाद ये सर्वर इस रिस्पांस को भेज देगा इस क्लाइंट को। तो लेट्स से इसमें भी हमें लग रहा है 2 मिलीसे का टाइम। तो यदि
हमारे पास कैश मेमोरी जैसा कुछ नहीं होता है तो एक रिक्वेस्ट को फुलफिल करने के लिए हमें 2 + 2 4 6 8 मिली सेकंड का टाइम लग
रहा है। 8 मिलीसे का टाइम यूजर की प्रोफाइल को एक्सेस करने के लिए। क्यों? क्योंकि यहां पे हमारे पास एक नेटवर्क कॉल
बढ़ जा रही है। डेटाबेस तक जाने के लिए नेटवर्क कॉल बढ़ जा रही है। उसके बाद क्या हो रहा है कि लेट्स से यूजर ने एक बार
प्रोफाइल एक्सेस कर ली। अब उसको लेट्स से फिर से अपनी प्रोफाइल एक्सेस करना है तो वो फिर से सेम स्टेप्स फॉलो करेगा। पहले
वो रिक्वेस्ट करेगा। रिक्वेस्ट जाएगी सर्वर के पास। फिर सर्वर डेटाबेस के पास जाएगा। उसकी रिक्वेस्ट लेके फिर डेटाबेस
यूजर की प्रोफाइल को सर्वर को सेंड करेगा। फिर सर्वर इस रिस्पांस को सेंड कर देगा क्लाइंट को। तो एव्री टाइम वी हैव टू
रिपीट द सेम स्टेप्स। तो बार-बार हमें डेटाबेस बार-बार हमें डेटाबेस को एक्सेस करना पड़ रहा है। इसकी वजह से क्या होगा
कि डेटाबेस पे लोड बढ़ जाएगा। डेटाबेस पे लोड बढ़ जाएगा। और जो हमारा डेटाबेस होता है, डेटाबेस ऑपरेशंस होते हैं, दे आर वेरी
कॉस्टली। और यह हमारे रिक्वेस्ट रिस्पांस टाइम को स्लो कर देते हैं। क्योंकि एक हम एक्स्ट्रा नेटवर्क कॉल बढ़ा देते हैं। और
सेम टास्क के लिए एक बार तो हमने प्रोफाइल एक्सेस कर ली कि अब हमें दोबारा करना है तो हम वापस से सेम चीजें रिपीट करते हैं।
तो इससे क्या होता है कि हम सेम काम के लिए डेटाबेस को बार-बार कॉल करते हैं। डेटाबेस सही से ऑप्टिमाइज नहीं हो पाता
है। हम हमारे रिसोर्सेज का सही से यूज़ नहीं करते। तो यहां पे डेटाबेस पे एक्स्ट्रा लोड बढ़ जाता है। क्योंकि यहां
पे तो सिर्फ एक ही यूजर था यूजर ए। लेट्स से सेम ऐसे ही 10,000 या 1 मिलियन यूज़र्स एक साथ आ गए। एंड दे दे आर आस्किंग फॉर
देयर प्रोफाइल बार-बार रिपीटेडली। तो एक सिंगल डे में हमें एक ऑपरेशन के लिए बेसिक से ऑपरेशन के लिए हर बार डेटाबेस को
क्वेरी करना पड़ेगा। व्हिच इज़ नॉट अ गुड थिंग। क्योंकि डेटाबेस ऑपरेशंस आर वेरी कॉस्टली। जहां पे हमारी एक एक्स्ट्रा
नेटवर्क कॉल बढ़ जाती है। तो यहां पे इफ वी आर नॉट यूज़िंग कैशिंग इफ वी डोंट हैव कैश कैश मेमोरी। तो एक हमारा नेटवर्क कॉल बढ़
गई। हमारा डेटाबेस पे लोड बढ़ गया। एंड डेटाबेस ऑपरेशंस आर वेरी कॉस्टली। तो जो हमारा एंटायर रिक्वेस्ट रिस्पांस टाइम
होता है वो उसको स्लो कर देते हैं। तो यहां पे एक सिंपल रिक्वेस्ट को सर्व करने के लिए 8 मिलीसे का टाइम लगा। अब लेट्स से
कि हमारे पास कैश मेमोरी है। तो कैश मेमोरी होने से हमें क्या फायदा है? तो सबसे पहले सेम यह रिक यूजर ए वांट्स टू
एक्सेस ह प्रोफाइल। तो यह रिक्वेस्ट जाएगी सर्वर के पास। अब लेट्स से सर्वर तक जाने में सर्वर तक रिक्वेस्ट जाने में 2 मिली
सेकंड का टाइम लगा। अब कैश मेमोरीज के होने से क्या फायदा है कि यह सर्वर यूजर ए की प्रोफाइल के लिए डेटाबेस के पास ना
जाकर इस कैश मेमोरी के पास जाएगा और पूछेगा कि डू यू हैव प्रोफाइल ऑफ यूजर ए? इफ कैश मेमोरी हैव द प्रोफाइल ऑफ यूजर ए?
तो वह सिंपली यहां से इस सर्वर को रिस्पांस रिटर्न कर देगा। अब ये जो कैश मेमोरी होती है इट इज वेरी फास्ट और ये
टेंपरेरी डेटा को स्टोर करती है। तो फास्ट होने की वजह से यहां पे रिक्वेस्ट रिस्पांस टाइम भी कम हो जाएगा। राइट? तो
सर्वर इस कैश मेमोरी से पूछेगा कि डू यू हैव प्रोफाइल ऑफ यूजर ए? तो कैश मेमोरी बोलेगी कि यस आई हैव अ प्रोफाइल ऑफ़ यूजर
ए। तो यहां पे लेट्स से कि सर्वर से कैश मेमोरी तक रिक्वेस्ट जाने में 1 मिलीसे का टाइम लगा। बिकॉज़ इट इज़ फास्ट। और यहां पे
कैश ने 1 मिलीसे में रिस्पांस दे दिया सर्वर को। यहां भी 1 मिलीसे का टाइम लगा। उसके बाद सर्वर से रिस्पांस जाने क्लाइंट
तक रिस्पांस जाने में लेट्स से 2 मिसे का टाइम लगा। तो यहां पे यदि हम कैलकुलेट करें तो इट वुड बी 2 + 2 4 5 6 तो अब यहां
पे 6 मिलीसे्स में 6 मिलीसे्स में हमने यूजर की रिक्वेस्ट को फुलफिल कर दिया। तो ये काम होता है हमारे कैश मेमोरी का।
बेसिकली ये एक स्टोरेज होता है टेंपरेरी स्टोरेज जो कि टेंपरेरी डेटा को स्टोर करने में हमारी हेल्प करता है और यह फास्ट
होता है क्योंकि ये इन मेमोरी सॉल्यूशन है। सो इफ वी हैव फ्रीक्वेंटली एक्सेस्ड डेटा, फ्रीक्वेंटली आस्क्ड डेटा तो हम उसे
टेंपरेरी स्टोर कर सकते हैं हमारे फास्ट स्टोरेज में व्हिच इज़ आवर कैश मेमोरी। तो अब कैशिंग के आने से हमने नेटवर्क कॉल्स
को अवॉइड कर दिया। जो हमारी डेटाबेस तक एक्स्ट्रा नेटवर्क कॉल आ रही थी उसको हमने हटा दिया। उसको हमने रिमूव कर दिया। अब
हमें चीजें रिकंप्यूट नहीं करना। लेट्स से कि हमने किसी यूजर की प्रोफाइल को एक बार एक्सेस कर लिया। तो हम उसे सिंपली कैश
मेमोरी में स्टोर कर देंगे। और फिर कैश मेमोरी से ही हम उस यूजर की रिक्वेस्ट को या प्रोफाइल को क्लाइंट को या यूजर को
बार-बार भेजते रहेंगे। तो हमें यहां चीजें रिकंप्यूट नहीं करना। हमने डेटाबेस पे जो एक्स्ट्रा लोड था उसे हटा दिया। उसे
रिड्यूस कर दिया। और ये सब की वजह से नेटवर्क कॉल्स रिमूव करने की वजह से, रिकंप्यूटेशन को अवॉइड करने से, डेटाबेस
लोड कम करने से हमारा रिक्वेस्ट रिस्पांस टाइम फास्ट हो गया। क्योंकि कैश मेमोरी इज़ अ इज़ इन मेमोरी सॉल्यूशन एंड इट इज़ फास्ट।
तो यहां पे जो रिक्वेस्ट डेटाबेस के थ्रू 2 मिली सेकंड में सर्व हो रही थी यहां पर वो 1 मिलीसे में सर्व हो जा रही है। तो ये
काम होता है हमारा कैशिंग का। अब एक बार कैशिंग का फ्लो देखते हैं। तो कैशिंग में सबसे पहले ये क्लाइंट लेट्स से यूजर ए
रिक्वेस्ट करता है। लेट्स से ही इज़ रिक्वेस्टिंग फॉर हिज प्रोफाइल। ही वांट्स टू एक्सेस हिज प्रोफाइल। तो ये रिक्वेस्ट
सबसे पहले जाएगी सर्वर के पास। उसके बाद यह सर्वर कैश में चेक करेगा कि कैश में वो यूजर की प्रोफाइल है या नहीं। यदि उस कैश
में यूजर की प्रोफाइल है तो इसे हम बोलते हैं कैश हिट। इसे हम बोलते हैं कैश हिट। यदि यूजर की प्रोफाइल कैश मेमोरी में है
तो यह कैश मेमोरी प्रोफाइल रिटर्न कर देगा सर्वर को और फिर सर्वर उस प्रोफाइल को यूजर को रिटर्न कर देगा या इस रिस्पांस को
प्रोफाइल के रिस्पांस को रिटर्न कर देगा। अब दूसरा केस यह आता है कि यदि कैश में यूजर की प्रोफाइल नहीं है तो इसे बोलते
हैं कैश मिस। कैश हिट और कैश मिस। तो यदि यूजर की प्रोफाइल कैश में नहीं है तो इसे हम
बोलेंगे कैश मिस। तो इस केस में सर्वर पहले कैश में मेमोरी में चेक करेगा कि यूजर की प्रोफाइल है या नहीं। अब उसकी
प्रोफाइल यदि कैश मेमोरी में नहीं है तो सर्वर वापस डेटाबेस के पास जाएगा। उससे यूजर ए की प्रोफाइल एक्सेस करेगा। उस
प्रोफाइल को क्लाइंट को भेजेगा और साथ ही साथ उस यूजर की प्रोफाइल को इस कैश मेमोरी में भी स्टोर कर देगा फॉर फ्यूचर रेफरेंस।
तो ये होता है हमारा कैशिंग और कैशिंग का फ्लो। अब यू माइट बी थिंकिंग कि कैशिंग यदि इतना ही अच्छा है तो व्हाई वी जस्ट
कैन नॉट स्टोर एवरीथिंग टू द कैश मेमोरी। फिर डेटाबेस में चीजें स्टोर ही क्यों करना है? जब कैश हमें इतनी सारी फैसिलिटीज
प्रोवाइड कर रहा है। तो कैशिंग कैश में हम सारा का सारा डेटा स्टोर नहीं कर सकते। यदि हम कैश में टन्स ऑफ डेटा रख दें या हम
कैश में बहुत सारा डेटा रख दें। बेसिकली हम कैश को ही ओवरलोड कर दें डेटा से तो इस केस में कैश से सर्च क्वेरी जो होंगी वह
स्लो हो जाएंगी। तो यहां पे इस केस में सर्च क्वेरीज स्लो हो जाएंगी और जो हमारा कैश होगा वो स्लो काम करने लगेगा। तो यस
वी जस्ट कैन नॉट पुट एवरीथिंग टू द कैश मेमोरी। जो हमारा इनफाइन इनफाइनाइट डेटा होगा वो हम डेटाबेस में स्टोर करेंगे और
कैश मेमोरी में हम सिर्फ रेलेवेंट डेटा को ही स्टोर करेंगे। तो ये होता है हमारा कैश मेमोरी। अब ये जो कैश है इट यूजुअली
एग्ज़िस्ट इनसाइड द सर्वर। तो ये कैश हमारा इन मेमोरी सॉल्यूशन है। तो इसे हम सर्वर के अंदर सर्वर की मेमोरी में प्लेस कर
सकते हैं। तो इसे हम बोलते हैं लोकल कैश। लोकल कैशिंग जहां पे हमारी कैश जो होता है वो सर्वर के अंदर या सर्वर की मेमोरी में
होता है। तो यस इट्स वन ऑफ़ अ वे टू प्लेस कैश कैश मेमोरी। तो लोकल कैशिंग इज गुड व्हेन वी हैव अ सिंगल एप्लीकेशन सर्वर। इस
एप्लीकेशन सर्वर में ही हमारे पास कैश मेमोरी होगी। इसके अंदर ही हमारी कैश मेमोरी होगी। तो क्लाइंट विल मेक अ
रिक्वेस्ट या यूजर रिक्वेस्ट करेगा। यह रिक्वेस्ट जाएगी एप्लीकेशन सर्वर के पास और फिर यह एप्लीकेशन सर्वर इस कैश के थ्रू
इस कैश के थ्रू यूजर की रिक्वेस्ट को फुलफिल कर देगा। पर लोकल कैशिंग में प्रॉब्लम क्या है कि लेट्स से इफ वी हैव
मल्टीपल एप्लीकेशन सर्वर्स हमने हमारे एप्लीकेशन को लेट्स से स्केल कर दिया। सो वी विल बी हैविंग मल्टीपल एप्लीकेशन
सर्वर्स। अब हर एप्लीकेशन सर्वर का अपना एक लोकल कैश होगा। राइट? इस ऐप सर्वर वन का एक अपना कैश होगा। इसका अपना कैश होगा।
इसका अपना कैश होगा। तो इस केस में हमारी डेटा डेटा इनकंसिस्टेंट हो सकता है। तो अब इसे एक एग्जांपल के थ्रू समझते हैं। लेट्स
से कि हमारा एक यूजर एक्स है। यह आता है एंड इट इज़ ही इज़ रिक्वेस्टिंग फॉर ह प्रोफाइल। इसे अपनी प्रोफाइल एक्सेस करना
है। अब यहां पे एक हमारा लोड बैलेंसर होगा। लोड बैलेंसर इज़ समथिंग जो हमने पुरानी प्रीवियस वीडियोस में ऑलरेडी
डिस्कस किया है। सो इफ यू वांट टू लर्न मोर अबाउट लोड बैलेंसर्स गो एंड वॉच दोज़ वीडियोस। तो क्या होगा कि ये यूजर एक्स को
अपनी प्रोफाइल एक्सेस करना है। सो ही विल मेक अ रिक्वेस्ट। अब ये जाएगी रिक्वेस्ट लोड बैलेंसर के पास और लोड बैलेंसर डिसाइड
करेगा वि सर्वर टू कनेक्ट विद। तो लेट्स से उसने डिसाइड किया कि मैं यूजर की रिक्वेस्ट को एप्लीकेशन सर्वर वन पे
फॉरवर्ड कर दूंगा। तो अब यह रिक्वेस्ट गई एप सर्वर वन के पास। अब एप सर्वर वन अह सबसे पहले यूजर की प्रोफाइल को इस कैश में
चेक करेगा। लेट्स से कि अभी यूजर ए यूजर एक्स की प्रोफाइल इस कैश मेमोरी में प्रेजेंट नहीं है। तो हम कह सकते हैं कि
हमारा कैश मिस हुआ। तो इस केस में एप्लीकेशन सर्वर वन जाएगा डेटाबेस के पास और यहां से वो यूजर एक्स की प्रोफाइल को
एक्सेस करेगा और उसे रिटर्न कर देगा इस क्लाइंट या यूजर एक्स को और उसके बाद इस यूजर एक्स की प्रोफाइल को वो कैश मेमोरी
में भी स्टोर कर देगा। सो यस हमने यहां पे यूजर को उसकी प्रोफाइल भी रिटर्न कर दी और इस यूजर एक्स की प्रोफाइल को हमने कैश में
स्टोर भी कर लिया। लेकिन लेट्स से कि कुछ देर बाद यह यूजर एक्स वापस आता है और यह फिर से अपनी प्रोफाइल एक्सेस करना चाहता
है। रिक्वेस्ट विल गो टू लोड बैलेंसर। अब इस केस में लेट्स से लोड बैलेंसर ने यूजर की रिक्वेस्ट को ऐप सर्वर टू पे राउट कर
दिया। अब ऐप सर्वर टू पर राउट कर दिया तो ऐप सर्वर टू का ये जो लोकल कैश है ये इनिशियली एंप्टी होगा। राइट? तो हमारा
यहां कैश मिस हो जाएगा। तो यहां पे कैश मिस हो जाने की वजह से अब ये एप सर्वर टू डेटाबेस के पास जाएगा और यहां से यूजर
एक्स की प्रोफाइल को लेके आएगा और यूजर एक्स को देगा और फिर यह एप सर्वर 2 के कैश में या लोकल कैश में यूजर x की प्रोफाइल
को स्टोर कर देगा। तो बेसिकली यहां हमने ऑलरेडी यूजर एक्स की प्रोफाइल को स्टोर कर दिया था या कैश कर लिया था। लेकिन स्टिल
यदि ये क्लाइंट या यूजर दोबारा रिक्वेस्ट करता है और यह रिक्वेस्ट किसी दूसरे ऐप सर्वर के पास चली जाती है तो इस केस में
हमें वापस से डेटाबेस के पास रिक्वेस्ट करना पड़ेगा क्योंकि यहां पे कैश टू में यूजर एक्स की प्रोफाइल नहीं थी। तो यह एक
प्रॉब्लम आती है लोकल कैश में। अब एक और प्रॉब्लम क्या आती है कि लेट्स से यूजर एक्स आता है और यह यूजर एक्स अपनी
प्रोफाइल अपडेट करना चाहता है। अब लेट्स से कि एप्लीकेशन सर्वर टू के कैश में इसके लोकल कैश में यूजर एक्स की प्रोफाइल
ऑलरेडी सेव्ड है। ऑलरेडी सेव्ड है। तो यह यूजर एक्स आया और इसको अब अपनी प्रोफाइल को अपडेट करना चाहता है। लेट्स से कि इस
केस में लोड बैलेंसर ने यूजर एक्स की रिक्वेस्ट को ऐप सर्वर थ्री पे राउट कर दिया। तो यहां पे ऐप सर्वर थ्री जाएगा
डेटाबेस के पास। यहां यह प्रोफाइल अपडेट करेगा। उसके बाद यह इस डेटा को स्टोर कर देगा कैश में। इस कैश 3 में या एप्लीकेशन
सर्वर 3 के कैश में। तो ठीक है। यूजर की प्रोफाइल तो हमने अपडेट कर दी। पर यदि लेट्स से कि यूजर एक्स कुछ देर बाद आता है
एंड ही वांट्स टू एक्सेस हिज प्रोफाइल वो रिक्वेस्ट करता है और लेट्स से कि इस केस में लोड बैलेंसर यूजर की रिक्वेस्ट को ऐप
सर्वर टू पे राउट कर देता है। तो अब इस केस में ऐप सर्वर टू के कैश में तो हमने पहले ही देखा कि पुराना डेटा था। पुराना
डाटा था। यहां पे प्रीवियस जो डाटा था वही बस था। अपडेटेड डाटा कहां पे था हमारे? इस ऐप सर्वर 3 के कैश में। तो यहां पर लोकल
कैश में यह हमारे पास एक डाटा इनकंसिस्टेंसी की प्रॉब्लम आती है। तो अब इस प्रॉब्लम को हम कैसे सॉल्व करते हैं?
तो इस प्रॉब्लम को सॉल्व करने के लिए हम डिस्ट्रीब्यूटेड कैश का यूज करते हैं। डिस्ट्रीब्यूटेड कैशिंग का यूज करते हैं।
अब डिस्ट्रीब्यूटेड कैशिंग में क्या होता है कि हम कैश को एक शेयर्ड लोकेशन पे रखते हैं। इस शेयरर्ड लोकेशन पे हम ग्लोबली इस
कैश को रखते हैं। और फिर क्या होता है कि हमारे सारे के सारे एप्लीकेशन सर्वर्स सेम कैश से यह हमारा रेडिश हो सकता है। तो
यहां पर सारे के सारे एप्लीकेशन सर्वर्स हमारे सेम कैश से सेम कैश मेमोरी से डेटा को फैच कर सकते हैं और अपडेटेड डेटा भी
देख सकते हैं। तो यहां पे यदि हम डिस्ट्रीब्यूटेड कैश का यूज़ करते हैं तो हम डेटा इनकंसिस्टेंसी की प्रॉब्लम
को सॉल्व कर सकते हैं। अब डिस्ट्रीब्यूटेड कैश का यूज़ करने से क्या होता है कि हम इस कैश मेमोरी को कैश को या रेडिस के
क्लस्टर्स को इंडिविजुअली भी स्केल कर सकते हैं। लेट्स से कि हमारा ये जो रेडिस है कैश है ग्लोबल कैश है इसमें ज्यादा लोड
पड़ रहा है। तो हम क्या कर सकते हैं कि इसे इंडिविजुअली स्केल भी कर सकते हैं। तो हमारे पास अब इस रेडिस के रेडिस क्लस्टर
के मल्टीपल इंस्टेंसेस हो जाएंगे। तो यहां पे ये सिंगल पॉइंट ऑफ फेलियर भी नहीं रह जाएगा। तो ऐसे करके हम डिस्ट्रीब्यूटेड
कैश का यूज करते हैं। डिस्ट्रीब्यूटेड कैश में बेसिकली हम एक शेयरर्ड लोकेशन पे हमारे कैश मेमोरी को रखते हैं ताकि सारे
के सारे एप्लीकेशन सर्वर्स उस सेम कैश मेमोरी से डेटा को एक्सेस कर पाएं। तो अब यह हमारा ग्लोबल कैश या डिस्ट्रीब्यूटेड
कैशिंग डाटा इनकंसिस्टेंसी की प्रॉब्लम को सॉल्व कर दे रही है। लेट्स से यूजर एक्स आएगा एंड ही वांट्स टू एक्सेस ह प्रोफाइल
तो रिक्वेस्ट जाएगी वन ऑफ द एप्लीकेशन सर्वर के पास। उसके बाद यह एप्लीकेशन सर्वर इस ग्लोबल कैश से डेटा को या यूजर
की प्रोफाइल को एक्सेस करने का ट्राई करेगा। एंड लेट्स से इफ डेटा इज़ प्रेजेंट इन दिस ग्लोबल कैश। तो हम इसे रिटर्न कर
देंगे एप्लीकेशन सर्वर को और फिर एप्लीकेशन सर्वर यूजर एक्स की प्रोफाइल को उसे रिटर्न कर देगा। अब यदि यूजर की
रिक्वेस्ट ऐप सर्वर टू पे भी आती है तो भी हम ग्लोबल कैश यूज़ कर रहे हैं। हमारा जो कैश है वह एक शेयरर्ड लोकेशन पे है। हम
सेम कैश मेमोरी यूज़ कर रहे हैं। तो ऐप सर्वर टू भी सेम कैश को सेम ग्लोबल कैश को ही एक्सेस करेगा। तो यह फायदा होता है
हमारे डिस्ट्रीब्यूटेड कैश का। तो यस डिस्ट्रीब्यूटेड कैश के आने से हमारे डेटा इनकंसिस्टेंसी की प्रॉब्लम सॉल्व हुई। सो
वी कैन से कि ये एक्यूरेट होता है। एक्यूरेट एक्यूरेट होता है। बट इट इज़ स्लो। अब ये स्लो क्यों क्यों है? क्योंकि
यहां पे हम इसे यहां हम ग्लोबली कैश का यूज़ कर रहे हैं। ग्लोबल कैश का यूज़ कर रहे हैं। तो यहां हमारी एक नेटवर्क कॉल बढ़
जाएगी। एक्स्ट्रा नेटवर्क कॉल बढ़ जाएगी। तो यह स्लो होता है क्योंकि हमारे पास एक्स्ट्रा नेटवर्क कॉल बढ़ जाती है। तो ये
होते हैं हमारे लोकल कैश एंड डिस्ट्रीब्यूटेड कैश। अब नेक्स्ट क्वेश्चन जो आता है वो यह है कि हमें कौन सा डेटा
इन कैश मेमोरी में रखना है? कौन सा डाटा हमें कैश मेमोरी में नहीं रखना। तो एक बार इसे समझते हैं। तो इसके लिए हम यूज़ करते
हैं कैश पॉलिसीज का। कैश पॉलिसीज का। अब कैश पॉलिसीज हमें बताती हैं कि कौन सा डाटा हमें कैश में लोड करना है। कौन सा
डाटा हमें कैश में रखना है और कौन सा डेटा हमें कैश से बाहर करना है। सो, कैश पॉलिसी टेल्स कि व्हिच डेटा वी हैव टू लोड टू द
कैश एंड व्हिच डेटा वी हैव टू अविक्ट आउट ऑफ द कैश। तो यह दो चीजें हमें कैश पॉलिसीज बताती हैं। और जो कैश की
परफॉर्मेंस होती है, वह सिंपली इन कैश पॉलिसीज पे ही डिपेंड करती है। अब हमारे पास दो कैश पॉलिसीज होती हैं। फर्स्ट होती
है हमारा कैश एिक्शन पॉलिसी। कैश एिक्शन पॉलिसी। तो, यह जो हमारी कैश एिक्शन पॉलिसी होती है, यह बताती है कि
कौन सा डाटा हमें एिक्ट करना है कैश से। तो यह बताएगी कि हमें कौन सा डाटा कैश से बाहर निकालना है। तो इसमें हमारे पास एक आ
जाती है लीस्ट रिसेंटली यूज्ड। एक हमारे पास आ जाती है फर्स्ट इन फर्स्ट आउट। फर्स्ट इन फर्स्ट आउट और एक हमारे पास आ
जाती है लीस्ट फ्रीक्वेंटली यूज्ड। तो अब एक-एक करके इन्हें समझते हैं। तो सबसे पहले हम देखते हैं FFO को फर्स्ट इन
फर्स्ट आउट। तो इसमें क्या होता है कि हमारे कैश में लेट्स से यह हमारा कैश है। कैश है। तो FFO में क्या होता है कि जो भी
डेटा पहले स्टोर किया गया कैश में जो भी डेटा कैश में पहले स्टोर किया गया फर्स्ट इन उसे ही हम पहले रिमूव करते हैं। लेट्स
से कि यहां पे हमारे पास डेटा इस ऑर्डर में आया ए सी लेट्स से ये एक डेटा है। ये एक डेटा है और यह एक डेटा है। और सेम
ऑर्डर में यह डेटा आया। 1 2 3 इस सेम ऑर्डर में यह डेटा आया। तो क्या होगा कि यह डाटा हम कैश में स्टोर करेंगे। अब
क्योंकि यह जो A है इसे हमने सबसे पहले कैश में स्टोर किया था तो इसे ही हम सबसे पहले कैश से रिमूव करेंगे। तो ये होता है
हमारा फर्स्ट एंड फर्स्ट आउट। अब ये फर्स्ट एंड फर्स्ट आउट में प्रॉब्लम क्या है कि ये फर्स्ट एंड फर्स्ट आउट इस बात पे
जोर नहीं देता कि ये डेटा कितने बार एक्सेस हो रहा है। लेट्स से कि ये जो डेटा ए है ये हर घंटे एक्सेस हो रहा है। लेट्स
से एव्री आवर एव्री आर ये डेटा एक्सेस हो रहा है। और ये जो डेटा है यह B और C है। यह लेट्स से फाइव डज़ के इंटरवल में हो रहा
है। 5 दिन में एक बार ये भी लेट्स से डेज में एक बार तो इस फीफो के लिए ये एक्सेस काउंट मैटर नहीं करता। भले ही यह डेटा ए
जो है वो भले ही हर घंटे एक्सेस हो रहा है बट स्टिल यह यदि पहले आया है तो यह FFO किसी नए डेटा के लिए लेट से अब हमें नया
डाटा डी ऐड करना है तो यह कैश क्या करेगा? FFO क्या करेगा? इस कैश से यू इस डाटा A को रिमूव कर देगा। क्योंकि यह पहले आया
था। भले ही वह डाटा हर घंटे एक्सेस हो रहा है, बट इट डज़ंट मैटर फॉर FFO. FFO हमेशा उसे रिमूव करेगा जो पहले आया। सो दैट्स
व्हाई वी कॉल दिस FFO फर्स्ट इन फर्स्ट आउट। अब जो हमारे पास नेक्स्ट है वो है लीस्ट रिसेंटली यूज़्ड। तो अब इसमें हम
क्या करते हैं? हम रिसेंटली यूज्ड एंट्रीज को टॉप पर रखते हैं। लेट्स से कि हमारे पास ऐसे थ्री डिफरेंट एंट्रीज हैं। लेट्स
से फाइव डिफरेंट एंट्रीज हैं ए, बी, सी, डी एंड ई। और जो हमारा ए, सी और डी है, यह रिसेंटली यूज़ हुआ है। लेट्स से ये हुआ है
फ्यू सेकंड्स एगो। यह हुआ है फ्यू सेकंड्स एगो। यह हुआ है फ्यू मिनट्स एगो। यह हुआ है फ्यू मिनट्स एगो। और यह हुआ है लेट्स
से फ्यू आवर्स एगो। तो क्या करते हैं? हम रिसेंटली यूज्ड एंट्रीज को टॉप पे रखते हैं। और जो हमारा लीस्ट रिसेंटली यूज्ड है
उनको हम बॉटम पे रखते हैं। सो व्हिच विल बी बी एंड ई। तो इन्हें हम बॉटम पे रखते हैं। और हम क्या करते हैं? लीस्ट रिसेंटली
यूज्ड में जो हमारी बॉटम मोस्ट एंट्रीज हैं। बॉटम मोस्ट एंट्रीज या लीस्ट रिसेंटली यूज़्ड एंट्रीज जो कि फ्यू डज़ बैक
यूज़ हुई हैं या मंथ्स बैक यूज़ हुई हैं। तो, हम क्या करते हैं कि बॉटम मोस्ट एंट्रीज को या लीस्ट रिसेंटली यूज़्ड
एंट्रीज को किक आउट कर देते हैं फ्रॉम कैश मेमोरी। तो, यह होता है हमारा लीस्ट रिसेंटली यूज्ड। अब लीस्ट रिसेंटली यूज्ड
के बाद हमारा आ जाता है लीस्ट फ्रीक्वेंटली यूज्ड। तो लेट्स से इसे भी सेम एग्जांपल से समझते हैं। लेट्स से
हमारे पास ऐसे थ्री डिफरेंट एंट्रीज हैं। ये एक एंट्री ए है, एंट्री B है, एंट्री C है। ये तीनों ही हमारे कैश मेमोरी में
स्टोर हैं। अब लीस्ट फ्रीक्वेंटली यूज़्ड में क्या होता है कि लेट्स से ये एंट्री A है। यह पांच बार एक्सेस की गई है। यह वाली
तीन बार और लेट्स से यह C एंट्री जो है यह केवल एक बार एक्सेस की गई है। तो लीस्ट फ्रीक्वेंटली यूज्ड में हम उस एंट्री को
रिमूव कर देते हैं जो बहुत कम यूज हुई हो। तो इस केस में यह जो सी एंट्री है इसका फ्रीक्वेंसी काउंट या एक्सेस काउंट केवल
एक है। तो ये लीस्ट फ्रीक्वेंटली एक्सेस्ड है। तो इसमें क्या करेंगे? हम लीस्ट फ्रीक्वेंटली एक्सेस्ड में हम सबसे कम
एक्सेस की गई एंट्री को रिमूव कर देंगे। तो इस केस में हम इस C को कैश से रिमूव कर देंगे। यदि कोई नया डेटा डी आता है तो इस
डी को इंसर्ट करने के लिए हम इस सी को एिक्ट कर देंगे फ्रॉम कैश मेमोरी। तो ये होता है हमारा लीस्ट फ्रीक्वेंटली यूज्ड।
तो ये देख ली हमने हमारी कैश पॉलिसीज जिसमें हमने देखा कैश इविक्शन पॉलिसी। अब हम देखते हैं हमारी सेकंड पॉलिसी को।
सेकंड कैश पॉलिसी को जिसे हम बोलते हैं कैश राइट पॉलिसीज। कैश राइट
राइट पॉलिसीज कैश राइट पॉलिसीज तो अब ये कैश राइट पॉलिसीज में एक हमारे पास आ जाती है राइट
थ्रू पॉलिसी राइट थ्रू पॉलिसी और एक हमारे पास आ जाती है राइट बैक
पॉलिसी राइट बैक पॉलिसी अब जो हमारी कैश पॉलिसी में हमने जो कैश इविक्शन पॉलिसी देखी की
इसका यूज़ हम कर क्यों कर रहे थे कि कैश हमारा लिमिटेड डेटा को स्टोर कर सकता है। करेक्ट इट्स अ इन मेमोरी सॉल्यूशन जो
टेंपरेरी डेटा को स्टोर करता है। तो टेंपरेरी स्टोर करता है और हमें टाइम टाइम टाइम टू टाइम डेटा को को रिमूव भी करना
पड़ेगा इस कैश से। राइट? तो इसके लिए हम कैश इविक्शन पॉलिसीज का यूज करते हैं। अब सिमिलरली राइट ऑपरेशंस के लिए या अपडेट के
लिए हम कैश राइट पॉलिसीज का यूज करते हैं। अब जब भी हम कोई डेटा अपडेट करते हैं तो सबसे बड़ा क्वेश्चन यह आता है कि कहां पे
हम डेटा सबसे पहले अपडेट करेंगे? कैश में या डेटाबेस में या दोनों जगह? तो इस क्वेश्चन का आंसर देती है हमारी यह कैश
राइट पॉलिसीज जिसमें हमारे पास है राइट थ्रू और राइट बैक जो हमें बताएगी कि कहां पे हमें पहले राइट करना है या कहां हमें
पहले डेटा अपडेट करना है कैश में या डेटाबेस में या दोनों में। तो सबसे पहले समझते हैं राइट थ्रू को। तो राइट थ्रू में
हम डेटा को कैश और डेटाबेस दोनों में सेम टाइम पर अपडेट करते हैं। लेट्स से कि यह हमारा कोई यूजर है और इस यूजर ने यूजर को
अपनी प्रोफाइल में लेट्स से फोन नंबर को चेंज करना है। तो इस केस में रिक्वेस्ट जाएगी ऐप सर्वर के पास। ऐप सर्वर के पास
और यहां पे होगा हमारा एक डिस्ट्रीब्यूटेड कैश। यहां हो गया हमारा कैश। और फिर यहां पर हो गया हमारा डेटाबेस। हमारा हो गया
यहां पर डेटाबेस। तो राइट थ्रू में सबसे पहले यह डेटा चेंज होगा कैश में। कैश मेमोरी में। लेट्स से यूजर को अपना फोन
नंबर, यूजर x को अपना फोन नंबर चेंज करना है। तो, यह चेंज होगा सबसे पहले कैश में। और फिर सेम टाइम पे ही यह चेंज हो जाएगा
डेटाबेस में। मतलब राइट थ्रू में राइट थ्रू पॉलिसी में कैश और डेटाबेस दोनों सेम टाइम पर अपडेट होते हैं। तो एक बार फ्लो
देखते हैं हमारे राइट थ्रू का। तो राइट थ्रू में यूजर सबसे पहले अपडेट करता है और यह अपडेट जाती है कैश में। यह अपडेट जाती
है कैश में। उसके बाद कैश इस अपडेट को इमीडिएटली डेटाबेस में रिफ्लेक्ट कर देता है। कैश राइट्स इट इमीडिएटली टू डेटाबेस।
उसके बाद बोथ कैश एंड डीबी आर ऑलवेज इन सिंक। लेट्स से कि यूजर x ने कैश में अपडेट की वैल्यू अपनी एज अपडेट की। लेट्स
से उसने 17 से अब 18 अपडेट की तो कैश में यह अपडेट आई। उसके बाद कैश तुरंत इस अपडेट को डेटाबेस में भी रिफ्लेक्ट करा देता है
या तुरंत इस राइट को डी डेटाबेस में भी अपडेट कर देता है। तो ये होता है हमारा राइट थ्रू। अब राइट थ्रू में क्योंकि हम
डेटाबेस को एक्सेस कर रहे हैं तो जो हमारा राइट्स होते हैं राइट्स होते हैं वह स्लो होते हैं। वो स्लो होते हैं। क्योंकि यहां
पे हम डेटाबेस को हिट कर रहे हैं। डेटाबेस कॉल कर रहे हैं। तो एक एक्स्ट्रा नेटवर्क कॉल जुड़ जा रही है। जिसकी वजह से राइट
थ्रू में हमारे राइट्स जो होते हैं वो स्लो होते हैं। लेकिन एक चीज एक चीज की यहां हमें गारंटी होती है वो है डेटा
कंसिस्टेंसी। तो यहां डेटा कंसिस्टेंसी की हमें गारंटी होती है क्योंकि कैश और डेटाबेस दोनों हमेशा सिंक में होते हैं।
तो यहां डेटा कंसिस्टेंसी हमें देखने को मिलती है। लेकिन जो हमारे राइट्स होते हैं वो स्लो होते हैं। अब देखते हैं हम राइट
बैक का फ्लो। राइट बैक पॉलिसी में क्या होता है? तो राइट बैक पॉलिसी में यूजर सबसे पहले कैश कैश को अपडेट करता है। जो
भी डाटा आएगा वह सबसे पहले कैश में अपडेट होगा। उसके बाद कैश एप्लीकेशन सर्वर को तुरंत रिस्पांस भेज देता है कि ठीक है
यूजर का डाटा अपडेट हो चुका है। तो एप्लीकेशन सर्वर यूजर को रिस्पांस भेज देगा कि ठीक है योर एज या फोन नंबर हैज़
बीन अपडेटेड। तो राइट बैक में यह यूजर रिक्वेस्ट करेगा। रिक्वेस्ट जाएगी ऐप सर्वर के पास। ऐप सर्वर के पास। उसके बाद
यहां हमारा होगा कैश। यहां हमारा होगा डेटाबेस। तो राइट बैक में कोई भी यूजर अपडेट करता
है या राइट ऑपरेशन परफॉर्म करता है लेट्स से एज चेंज करना तो यह रिक्वेस्ट जाएगी कैश में कैश में यहां यूजर की ऐज चेंज हो
जाएगी लेट्स से 17 से 18 हो जाएगी और उसके बाद यह कैश इमीडिएटली रिस्पांस सेंड कर देगा ऐप सर्वर को कि ठीक है यूजर्स ऐज हैज़
बीन चेंज्ड और फिर ऐप सर्वर इस इस रिस्पांस को भेज देगा इस यूजर को तो यह होता है हमारा राइट बैक में और उसके बाद
कैश कुछ टाइम बाद डेटाबेस में यह ऐज को चेंज कर देता है। यहां पे डेटाबेस में अभी ऐज 17 ही थी लेकिन कुछ टाइम बाद यह कैश इस
अपडेट को डेटाबेस में भी राइट कर देता है एसिंक्रोनसली जो कि बैकग्राउंड प्रोसेस होती है। तो बैकग्राउंड में अह डेटाबेस की
डेटाबेस में भी एंट्री अपडेट हो जाती है। तो यहां पे 17 से अब एंट्री 18 हो जाएगी। तो वही हमने देखा कि कैश राइट्स चेंजेस टू
डेटाबेस लेटर इन द बैकग्राउंड। बाद में एसिंक्रोनसली यह बैकग्राउंड प्रोसेस होती है। जहां ये डेटाबेस में भी इस राइट को
अपडेट कर देता है। तो ये देखा हमने राइट बैक। अब राइट बैक में हमारा डेटा इनकंसिस्टेंट हो जाता है। क्योंकि यहां पे
हमने कैश में अपडेट कर दी। कैश में ऐज हमारी 18 हो गई। लेकिन डेटाबेस में अभी भी हमारी ऐज कुछ टाइम तक 17 ही थी। तो राइट
बैक के केस में कुछ टाइम तक डेटा इनकंसिस्टेंट रह सकता है। तो यहां पे हमें कुछ टाइम तक डेटा इनकंसिस्टेंट देखने को
मिल सकता है। डेटा इनकंसिस्टेंट देखने को मिल सकता है। लेकिन यह जो हमारा राइट बैक होता है, इसमें जो हमारे राइट्स होते हैं,
राइट ऑपरेशन होते हैं, दे आर फास्ट। क्यों? क्योंकि हम इमीडिएटली डेटाबेस में चेंज नहीं कर रहे। हम सिर्फ कैश में सबसे
पहले चेंज करते हैं। कैश में अपडेट करते हैं और बाद में हम डेटाबेस में करते हैं। तो जो हमारा राइट बैक होता है वहां पे
राइट्स आर फास्ट। क्योंकि यहां हम सिर्फ कैश में पहले अपडेट करते हैं। डेटाबेस में नहीं करते। डेटाबेस में बाद कर बाद में
करते हैं। तो इस वजह से हमें डेटाबेस के लिए नेटवर्क कॉल नहीं करना पड़ता। नेटवर्क कॉल नहीं करना पड़ता। डेटाबेस को एक्सेस
नहीं करना पड़ता। इस वजह से जो हमारा राइट बैक होता है वो फास्ट होता है। तो, यह देखा हमने राइट अह कैश राइट पॉलिसीज़। हमने
कैश एिक्शन पॉलिसीज़ भी देखी। हमने उसमें एलआरयू, FFO, एलएफयू देखा। हमने कैश राइट पॉलिसीज़ में राइट्स थ्रू और राइट बैक
देखा। हमने डिस्ट्रीब्यूटेड कैश देखा। हमने कैशिंग देखा। और हमने देखा कि कैसे कैशिंग डिस्ट्रीब्यूटेड कैशिंग से डिफरेंट
है। हमारे लोकल कैशिंग में क्या प्रॉब्लम आ रही थी जिसकी वजह से हमें डिस्ट्रीब्यूटेड कैशिंग में जाना पड़ा। सो
आई थिंक दिस इज़ ऑल फॉर दिस वीडियो एंड वी विल सी यू इन द नेक्स्ट वीडियो। सो टिल देन ब-बाय। शो सम लव। थैंक्स।
[संगीत] हे एवरीवन वेलकम बैक वेलकम टू दिस अल्टीमेट सिस्टम डिज़ प्लेलिस्ट सीरीज और
आज के इस वीडियो में हम बात करने वाले हैं डिस्ट्रीब्यूटेड सिस्टम्स के बारे में कि ये डिस्ट्रीब्यूटेड सिस्टम्स होते क्या
हैं और हमें इनकी नीड क्या है? तो स्टार्ट करते हैं और सबसे पहले मैं अपनी वीडियो मिनिमाइज कर लेता हूं। सो दैट यू विल बी
एबल टू सी एंटायर स्क्रीन वेल। ओके। सो स्टार्ट करते हैं। तो पिछले कुछ वीडियोस में हमने लोड बैलेंसर्स को समझा।
हमने देखा कि लोड बैलेंसर्स क्या होते हैं? इनके हमने डिफरेंट टाइप्स देखे। हमने लोड बैलेंसिंग एल्गोरिदम्स को समझा। हमने
जस्ट लास्ट वीडियो में हॉरिजॉन्टल स्केलिंग को समझा कि हॉरिजॉन्टल स्केलिंग क्या होती है? हमने उसके पिछली वीडियोस
में देखा रीजंस और अवेलेबिलिटी ज़ोंस के बारे में कि हमारे रीजंस क्या होते हैं? अवेलेबिलिटी ज़ोन क्या होते हैं? इनकी हमें
नीड क्या है? तो ये सारे टॉपिक्स ये सारे कांसेप्ट हमने कवर किए थे। तो ये सारे के सारे कांसेप्ट ये लोड बैलेंसर, हॉरिजॉन्टल
स्केलिंग, रीजंस, अवेलेबिलिटी ज़ों्स दे ऑल आर अ पार्ट ऑफ डिस्ट्रीब्यूटेड सिस्टम्स। दे ऑल आर अ पार्ट ऑफ़ डिस्ट्रीब्यूटेड
सिस्टम्स। तो डिस्ट्रीब्यूटेड सिस्टम्स में क्या होता है कि हमारे पास मल्टीपल कंप्यूटरटर्स होते हैं। मल्टीपल
इंडिपेंडेंट कंप्यूटरटर्स होते हैं। लेट्स से कंप्यूटर वन, कंप्यूटर टू, कंप्यूटर थ्री। तो ऐसे हमारे पास मल्टीपल
इंडिपेंडेंट कंप्यूटरटर्स होते हैं। और ये मल्टीपल इंडिपेंडेंट कंप्यूटरटर्स सेम टास्क को सेम फीचर्स को प्रोवाइड कर रहे
होते हैं। लेट्स से कि आपका कोई एप्लीकेशन है। आपका लेट्स से कोई ई-कॉमर्स काइंड ऑफ़ एप्लीकेशन है और आपने उस एप्लीकेशन को इन
तीनों कंप्यूटरटर्स में होस्ट कर दिया। तो, यह हमारे तीनों इंडिपेंडेंट कंप्यूटरटर्स हैं। और यह तीनों
कंप्यूटरटर्स सेम फीचर, सेम फंक्शनैलिटी या सेम क्वालिटीज, सेम एस्पेक्ट्स प्रोवाइड करेंगे। और यहां पे यूजर को
लेट्स से कोई एक यू ये यूजर है तो इस यूजर को ये लगेगा कि ये केवल एक सिंगल कंप्यूटर उसकी फंक्शनैलिटी या उसके टास्क को फुलफिल
कर रहा है। जबकि यहां पे होंगे मल्टीपल कंप्यूटरटर्स एंड दे आर परफॉर्मिंग सेम टास्क। तो ये होते हैं हमारे
डिस्ट्रीब्यूटेड सिस्टम्स। डिस्ट्रीब्यूटेड सिस्टम्स का मतलब है कि हैविंग मल्टीपल इंडिपेंडेंट कंप्यूटरटर्स
एंड इट अपीयर्स ऐज़ अ सिंगल कंप्यूटर टू यूजर। तो ये एक डेफिनेशन होती है डिस्ट्रीब्यूटेड सिस्टम्स की। अब
डिस्ट्रीब्यूटेड सिस्टम्स का मतलब होता है मैनी कंप्यूटरटर्स कि हमारे पास मल्टीपल कंप्यूटरटर्स हैं
एंड दे आर वर्किंग टुगेदर। दे आर वर्किंग टुगेदर वर्किंग टुगेदर एंड दे आर ट्राइंग टू
सॉल्व अ लार्ज प्रॉब्लम। सो दे आर ट्राइंग टू सॉल्व अ लार्ज प्रॉब्लम। लार्ज प्रॉब्लम। तो, यहां पे मल्टीपल सर्वर्स
मल्टीपल कंप्यूटरटर्स साथ में काम करते हैं एंड दे ट्राई टु सॉल्व अ लार्ज प्रॉब्लम। और यूजर को यह लगता है कि जो भी
टास्क फुलफिल हो रहे हैं, वह एक सिंगल कंप्यूटर के थ्रू हो रहे हैं। तो, अब डिस्ट्रीब्यूटेड सिस्टम्स में हमने लोड
बैलेंसर्स को देखा था। लोड बैलेंसर्स का काम क्या था? कि यह ट्रैफिक को राउट करता है टू मल्टीपल सर्वर इंस्टेंसेस। मल्टीपल
सर्वर इंस्टेंसेस। लेट्स से यह हो गया हमारा सर्वर वन, सर्वर टू,
सर्वर थ्री। तो, यहां पे ऐसे हमारे पास मल्टीपल सर्वर्स थे और उन सर्वर्स में रिक्वेस्ट को डिस्ट्रीब्यूट करने का काम
कौन कर रहा था? लोड बैलेंसर। अब क्वेश्चन ये था कि हमारे पास मल्टीपल सर्वर्स क्यों थे? तो, इसके लिए भी हमने लास्ट वीडियो
में हॉरिजॉन्टल स्केलिंग देखा। अब हॉरिजॉन्टल स्केलिंग में हमने क्या देखा था कि लेट्स से यदि हमारे पास बहुत सारे
यूज़र्स आ जाते हैं। हम हमारे एप्लीकेशन को स्केल करते हैं और हमारे एप्लीकेशन में नंबर ऑफ यूज़र्स बढ़ जाते हैं। लेट्स से 1
मिलियन यूज़र्स आ जाते हैं। तो इस केस में एक लैपटॉप या एक कंप्यूटर या एक सर्वर की भी एक कैपेसिटी होगी। तो ऐसा हो सकता है
कि 1 मिलियन यूजर आने के बाद इस सर्वर की या इस कंप्यूटर की कैपेसिटी खत्म हो जाए। तो उसके बाद हमें या तो बड़ा कंप्यूटर
लाना पड़ेगा या हमें सेम ऐसे ही अलग-अलग कंप्यूटरटर्स लाने होंगे और उसमें हम हमारे एप्लीकेशन को होस्ट कर देंगे। तो
सेम कंप्यूटरटर्स लाने को, सेम कंप्यूटरटर्स लाने को और उसमें हमारे एप्लीकेशन को होस्ट करने को हमने देखा था
कि उसे हम हॉरिजॉन्टल स्केलिंग बोलते हैं। तो हॉरिजॉन्टल स्केलिंग में हमारे पास मल्टीपल एप्लीकेशन सर्वर्स होते हैं।
मल्टीपल सर्वर्स होते हैं। जहां हम हमारे एप्लीकेशन को होस्ट कर देते हैं। तो अब हॉरिजॉन्टल स्केलिंग हमें क्या फायदा दे
रहा था? पहला तो यही कि यदि हमारे एप्लीकेशन में 1 मिलियन रिक्वेस्ट एक साथ आती हैं तो अब केवल एक सर्वर पे लोड नहीं
पड़ेगा। यह लोड बैलेंसर के थ्रू हम रिक्वेस्ट को डिस्ट्रीब्यूट कर देंगे अमोंग मल्टीपल सर्वर इंस्टेंसेस। तो अब हर
सर्वर पे पड़ने वाला लोड कम हो जाएगा। तो ये काम हो गया था पहला हमारा हॉरिजॉन्टल स्केलिंग का। जो दूसरा एडवांटेज था वो ये
था कि सिंगल सर्वर के होने पे लेट्स से एक हमारा सिंगल सर्वर है। तो सिंगल सर्वर के होने पे क्या प्रॉब्लम थी कि यदि इस सर्वर
पे कुछ भी फौल्ट आता है। लेट्स से ये सर्वर बिकॉज़ ऑफ़ सम एक्स वzेड रीजन क्रैश हो जाता है। तो इस केस में हमारा पूरा
सिस्टम ही क्रैश हो जाएगा। क्योंकि अब हमारे पास कोई बैकअप सर्वर नहीं था। हमारे पास कोई बैकअप सर्वर नहीं था।
लेकिन हॉरिजॉन्टल स्केलिंग में हमने सर्वर्स मल्टीपल सर्वर्स लगा दिए। तो अब यदि हमारा एक सर्वर क्रैश भी हो जाता है
या बिकॉज़ ऑफ़ सम एक्स व जेड रीज़न ये डाउन हो जाता है तो हम यूज़र्स की रिक्वेस्ट को नए यूज़र्स की रिक्वेस्ट को इस दूसरे सर्वर
पे राउट कर देंगे। तो ये काम देखा था हमने अह हमारे हॉरिजॉन्टल स्केलिंग का। तो यस हॉरिजॉन्टल स्केलिंग, लोड बैलेंसर्स,
रीजंस, अवेलेबिलिटी ज़ोंस दे ऑल आर अ पार्ट ऑफ डिस्ट्रीब्यूटेड सिस्टम्स। तो बेसिकली डिस्ट्रीब्यूटेड सिस्टम्स का मतलब है कि
हमारे पास मल्टीपल नोड्स हैं। मल्टीपल नोड्स हैं। और यह हमारे पास मल्टीपल नोड्स क्यों हैं? ताकि हम अच्छे से स्केल कर
सकें। यदि हमारे एप्लीकेशन में नंबर ऑफ यूज़र्स बढ़ जाते हैं, तो हम ईजीली स्केल कर सकें। और दूसरा कि हमारे एप्लीकेशन में
कहीं भी सिंगल पॉइंट ऑफ फेलियर जैसा कुछ ना रहे कि एक सिंगल सर्वर के क्रैश होने से हमारा पूरा एप्लीकेशन या पूरा सिस्टम
क्रैश हो गया। उससे दैट गिव्स बैड यूजर एक्सपीरियंस टू यूजर। तो ये सब की वजह से वी हैव मल्टीपल नोड्स। और ये मल्टीपल नड्स
आपस में कम्युनिकेशन के लिए नेटवर्किंग प्रोटोकॉल्स का यूज करते हैं। नेटवर्किंग प्रोटोकॉल्स का यूज करते हैं। तो
नेटवर्किंग प्रोटोकॉल्स इज़ आल्सो समथिंग दैट वी हैव डिस्कस्ड इन आवर फ्यू इन आवर पास्ट वीडियोस। तो ये था हमारा
डिस्ट्रीब्यूटेड सिस्टम्स के बारे में। अब एक बार देख लेते हैं डिस्ट्रीब्यूटेड सिस्टम्स के कुछ एडवांटेजेस ऑलरेडी। ऑलदो
हमने यह डिस्कस कर लिए हैं। बट स्टिल लेट्स डिस्कस देम वन मोर टाइम। सो द क्वेश्चन इज व्हाई डिस्ट्रीब्यूटेड
सिस्टम्स। व्हाई डिस्ट्रीब्यूटेड सिस्टम्स? तो पहला रीजन है स्केलेबिलिटी। स्केलेबिलिटी
कि यदि हमारे एप्लीकेशन में नंबर ऑफ यूज़र्स बढ़ जाते हैं। नंबर ऑफ यूज़र्स बढ़ जाते हैं। तो पॉसिबल हो सकता है कि एक
सिंगल सर्वर उन सारे यूज़र्स की रिक्वेस्ट को फुलफिल ना कर पाए। तो इस केस में हम नंबर ऑफ सर्वर्स बढ़ा देंगे और फिर हम इन
यूज़र्स की रिक्वेस्ट को ईजीली हैंडल कर सकते हैं बाय डिस्ट्रीब्यूटिंग यूज़र्स रिक्वेस्ट टू मल्टीपल सर्वर इंस्टेंसेस।
तो ये था हमारा पहला पॉइंट। दूसरा है फौल्ट टॉलरेंस फौल्ट टॉलरेंस।
तो अब इसका क्या मतलब है? तो हमने देखा था कि यदि हमारे एप्लीकेशन में हमारे सिस्टम में एक सिंगल सर्वर होगा और यही क्रैश हो
जाए या किसी वजह से डाउन हो जाए तो सारे के सारे यूज़र्स की रिक्वेस्ट को हम फुलफिल नहीं कर पाएंगे। तो यह हमारा सर्वर सिंगल
पॉइंट ऑफ फेलियर बन जाएगा। तो सिंगल पॉइंट ऑफ फेलियर से बचने के लिए हम डिस्ट्रीब्यूटेड सिस्टम्स का यूज करते
हैं। जहां हम मल्टीपल सर्वर्स लगा देते हैं। तो अब यदि एक सर्वर क्रैश भी होता है तो हम यूज़र्स की रिक्वेस्ट को दूसरे सर्वर
पे राउट कर देते हैं। तो ये था हमारा दूसरा पॉइंट फॉल्ट टॉलरेंस या हम कह सकते हैं दूसरा एडवांटेज ऑफ डिस्ट्रीब्यूटेड
सिस्टम्स। जो थर्ड है हमारा वो है लो लेटेंसी। लो लेटेंसी। अब इसका क्या मतलब है? तो इसे
भी एक एग्जांपल के थ्रू समझते हैं। लेट्स से एक कोई यह यूजर है और यह google.com रिक्वेस्ट करता है तो यह रिक्वेस्ट जाएगी
google.com के सर्वर पे। अब लेट्स से कि यह जो सर्वर है यह इंडिया में होस्टेड है। लेट्स से यह इंडिया में होस्टेड है। अब
लेट्स से कि कोई यूजर फ्रॉम यूएसए वांट्स टू एक्सेस Google। सेम वह भी Google को एक्सेस करना चाहता है। तो इस केस में इस
यूजर की रिक्वेस्ट को फुलफिल करने के लिए हमें ज्यादा टाइम लगेगा। क्योंकि यूजर है यूएसए में और यह जो सर्वर है यह होस्टेड
है इंडिया में। तो यूजर की रिक्वेस्ट को इट इट्स रिक्वेस्ट विल हैव टू ट्रैवल अ लॉट। तो इस केस में हमारी लेटेंसी बढ़
जाती है। एंड दैट गिव्स बैड यूजर एक्सपीरियंस टू यूजर। क्योंकि यदि हाफ सेकंड का भी डिले होता है तो यूजर विल नॉट
फील गुड। तो यह था हमारा लो लेटेंसी। तो यहां हमारी लेटेंसी इनक्रीस हो जाती है। तो अब इन लेटेंसी को डिक्रीज करने के लिए
या लेटेंसी को कम करने के लिए हम क्या कर सकते हैं कि हम एक सर्वर हमारे एप्लीकेशन का एक सर्वर अह यूएसए में होस्ट कर सकते
हैं। लेट्स से अ ह्यूज ट्रैफिक इज़ कमिंग फ्रॉम यूएसए। तो हम क्या कर सकते हैं? एक सर्वर को यूएसए में ही होस्ट कर सकते हैं।
तो अब इस केस में जो यूएसए के यूज़र्स हैं उनकी रिक्वेस्ट यहां ना जाके इस वाले सर्वर पे जाएंगी और उनकी रिक्वेस्ट ईजीली
सर्व हो जाएंगी और यह हमारे सिस्टम की लेटेंसी को भी कम कर देगा। सो दिस इज़ अबाउट आवर थर्ड पॉइंट व्हिच इज़ लो
लेटेंसी। अब जो चौ चौथा पॉइंट है हमारा फोर्थ पॉइंट है वो है एग्रीमेंट। एग्रीमेंट। अब इसका क्या मतलब है? तो हमने
ऑलरेडी देखा कि हमारे पास डिस्ट्रीब्यूटेड सिस्टम्स में मल्टीपल सर्वर्स होते हैं। लेट्स से सर्वर वन, सर्वर टू,
सर्वर टू एंड लेट्स से सर्वर थ्री। अब लेट्स से कि ये तीनों सर्वर किसी ई-कॉमर्स एप्लीकेशन के हैं। और लेट्स से यहां पे दो
यूज़र्स आते हैं। यूजर एंड यूजर बी। यह दो यूज़र्स आते हैं। एंड दे वांट टू बाय लेट्स से iPhone। अब इस केस में यहां पे हमारा
है डेटाबेस और इस डेटाबेस में हमारे पास केवल एक iPhone का स्टॉक बचा है। एक iPhone का स्टॉक बचा हुआ है। अब लेट्स से
कि दोनों यूज़र्स सेम टाइम पे आते हैं। यूजर A हिट करता है सर्वर 2 को। यूजर B हिट करता है सर्वर 3 को। एंड दे बोथ वांट
टू बाय iPhone। और iPhone का कभी अभी हमारे पास केवल एक सिंगल स्टॉक बचा हुआ है। अब लेट्स से कि दे बोथ केम एट द सेम
टाइम। तो अब इस केस में किस यूजर की रिक्वेस्ट को फुलफिल करना है यह डिसाइड करना होता है हमें। तो इस केस में सारे के
सारे सर्वर्स को एक दूसरे पे ट्रस्ट करना होता है। दोनों सर्वर्स को यह सर्वर और यह सर्वर। अब ये दोनों ही बोलेंगे कि नहीं
मुझे यूजर ये बोलेगा मुझे यूजर ए की रिक्वेस्ट को फुलफिल करना है। ये बोलेगा मुझे यूजर बी की रिक्वेस्ट को फुलफिल करना
है। तो इस केस में दोनों ही सर्वर को एग्री होना पड़ता है विद इन मिलीसेकंड्स कि ठीक है यह वाले यूजर की रिक्वेस्ट को
फुलफिल होने देते हैं। तो सर्वर नीड नीड्स टू एग्री फास्ट। इट्स लाइक ऑक्शन बडिंग इन मिलीसेकंड्स। तो यहां पे सर्वर्स को फास्ट
एग्री करना पड़ता है कोई भी डिसीजन लेने से पहले। तो ये होता है हमारा फोर्थ पॉइंट जहां हमने देखा एग्रीमेंट।
अब डिस्ट्रीब्यूटेड सिस्टम्स में हमारे पास कैप थ्योरम भी होता है। तो कैप थ्योरम हम आगे आने वाली वीडियोस में देखेंगे।
जहां हम देखेंगे कि कैप थ्योरम बेसिकली एक शॉर्ट फॉर्म होता है। कंसिस्टेंसी, सी फॉर कंसिस्टेंसी, ए फॉर अवेलेबिलिटी। ए
फॉर अवेलेबिलिटी एंड पी फॉर पार्टीशन टॉलरेंस। तो हम देखेंगे कि वी जस्ट कैन नॉट हैव ऑल थ्री टुगेदर। तो ये हम देखेंगे
आगे आने वाली वीडियोस में जहां हम देखेंगे कि वी जस्ट कैन नॉट हैव कंसिस्टेंसी अवेलेबिलिटी एंड पार्ट पार्टीशन टॉलरेंस
ऑल एट वंस। तो ये था हमारा कैप थ्योरम के बारे में। एंड कैप थ्योरम इज़ आल्सो अ बिग पार्ट ऑफ़ डिस्ट्रीब्यूटेड सिस्टम्स। सो यस
आई गेस दिस इज़ ऑल फॉर दिस वीडियो। वी विल सी यू इन द नेक्स्ट वीडियो। सो टिल देन बय शो सम लव। थैंक्स।
[संगीत] हे एवरीवन वेलकम बैक। वेलकम टू दिस अल्टीमेट सिस्टम डिज़ प्लेलिस्ट सीरीज। और
आज के इस वीडियो में हम बात करने वाले हैं सीडीए के बारे में। तो स्टार्ट करते हैं और समझते हैं सीडीए को एक एग्जांपल की
हेल्प से। तो लेट्स से कि हम हमारे पास एक Netflix सिस्टम है और इस Netflix सिस्टम में हमारे पास यूज़र्स आ रहे हैं फ्रॉम
डिफरेंट ज्योग्राफीज़ डिफरेंट रीजंस। लेट्स से हमारे पास यूएसए से भी यूज़र्स आ रहे हैं इंडिया, जापान, यूके। तो हमारे पास
ऐसे डिफरेंट ज्योग्राफीज़ से यूज़र्स आ रहे हैं। एंड दे ऑल वांट टू एक्सेस Netflix। सो दे विल ट्राई टू कनेक्ट टू आवर सर्वर
राइट? तो बेसिकली वो www.netflix.com हमारी ये वेबसाइट को एक्सेस करने के लिए ट्राई करेंगे। अब यहां पे दिस इज़ आवर
डोमेन नेम राइट? Netflix इज़ आवर डोमेन नेम। तो बेसिकली सबसे पहले हम क्या करेंगे? हम डीएनएस की हेल्प से IP एड्रेस
को रॉल्व करेंगे और हम देखेंगे कि यह जो हमारा www.netflix.com है यह किस IP एड्रेस से मैप करता है। अब
लेट्स से कि हमें पता चला कि यह इस IP एड्रेस के साथ मैप्ड था। तो बेसिकली हमें यह IPपी एड्रेस मिला और अब यह हमारी
रिक्वेस्ट HTTP रिक्वेस्ट बनके जाएगी Netflix के सर्वर के पास। अब Netflix के सर्वर के पास जाएगी और Netflix के सर्वर
से अब हम मूवीज रिक्वेस्ट करेंगे। तो सारी की सारी वीडियोस या मूवीज या वेब सीरीज वो सारी कहां हमारे S3 स्टोरेज में स्टोर
होंगी। आई हैव मेड अ सेपरेट वीडियो ऑन Netflix सिस्टम डिज़ाइन। सो इफ यू वांट टू लर्न हाउ Netflix वर्क्स। सो प्लीज गो एंड
वॉच दैट वीडियो। तो ये Netflix सर्वर क्या करेगा कि S3 स्टोरेज से वीडियोस को फैच करेगा एंड देन इट विल सर्व दोज़ वीडियोस टू
यूजर। अब लेट्स से कि ये जो हमारा Netflix का सर्वर है और यह जो हमारा स्टोरेज है S3 स्टोरेज दे बोथ आर होस्टेड इन यूएसए। ठीक
है? हमारा S3 स्टोरेज और Netflix सर्वर यूएसए में होस्टेड है। अब क्या होगा कि सारे यूज़र्स यूज़र्स फ्रॉम यूएसए यूज़र्स
फ्रॉम इंडिया, जापान एंड यूके ये सारी अपनी रिक्वेस्ट करेंगे। ये रिक्वेस्ट जाएगी Netflix सर्वर के पास और सर्वर S3
स्टोरेज से वीडियो लाके इन यूज़र्स को दे देगा। ठीक है? हो गया। तो अब यहां पे प्रॉब्लम क्या आ रही है? अब यहां पे
प्रॉब्लम ये आ रही है कि ये सारे यूज़र्स डिफरेंट रीजंस में हैं, डिफरेंट ज्योग्राफीज़ में हैं। और ये जो हमारा
Netflix का सर्वर और S3 स्टोरेज है, यह यूएसए में होस्टेड है। तो यहां पे लेटेंसी की प्रॉब्लम आती है। लेटेंसी की यहां पे
प्रॉब्लम आती है। अब लेटेंसी की प्रॉब्लम कैसे आती है? तो हमारे पास एक यूजर है यूएसए से। हमारे पास यूजर है इंडिया से।
