← कोर्सच्या मुख्य पानाकडे परत

⏮️ आधी काय होते & फायदे-तोटे

प्रत्येक साधनाने काहीतरी वाईट गोष्ट बदलली — आणि तेच साधन कुठेतरी चुकीचे ठरते. प्रत्येक मोठ्या कल्पनेसाठी: आधी जीवन कसे होते, प्रामाणिक फायदे ✅ / तोटे ❌, आणि कुठे वापरावी 👍 विरुद्ध कुठे नाही 👎.

📈 Mean विरुद्ध percentiles (p50, p95, p99) — धडा 17

⏮️ Percentiles आधी

Dashboards सरासरी response time दाखवत. तो 19 ms सांगत असे, तर पंधरापैकी एक caller 150 ms वाट पाहत होता — तक्रारी खऱ्या होत्या आणि graph शांत होता.

✅ फायदे

  • p50 म्हणजे नेहमीचा caller; p95 आणि p99 म्हणजे दुर्दैवी callers — जे तक्रार करतात
  • प्रत्येक route चा percentile तो हळू endpoint शोधतो जो सर्व-routes चा आकडा लपवतो
  • SLOs percentiles मध्ये लिहिले जातात: "15 मिनिटांत p95 100 ms पेक्षा कमी"

❌ तोटे

  • वेगवेगळ्या servers चे percentiles सरासरी करता येत नाहीत — histograms किंवा distributions ठेवा आणि ते एका ठिकाणी काढा
  • p99 स्थिर होण्यासाठी पुरेसा traffic लागतो; मिनिटाला 20 requests असताना तो फक्त एक request असतो
  • bucket-आधारित percentiles (Prometheus) हे अंदाज आहेत, अचूक नाहीत

👍 वापरा जेव्हा

  • माणूस किंवा दुसरी service ज्याची वाट पाहते त्या कशाचीही latency
  • alerts आणि SLOs; capacity tests (धडा 16 ची load test)

👎 दोनदा विचार करा जेव्हा

  • latency साठी फक्त mean — तो tail लपवतो
  • अगदी वेगवेगळे routes असलेल्या संपूर्ण API साठी एकच latency आकडा

📡 Prometheus विरुद्ध Datadog विरुद्ध CloudWatch — धडा 17

⏮️ Metrics platforms आधी

API किती हळू आहे याचा अंदाज घेण्यासाठी engineers servers मध्ये SSH करून logs grep करत — तेही वापरकर्त्यांनी आधीच सांगितल्यानंतर.

✅ फायदे

  • Prometheus + Grafana: open source, /metrics pull करतो, मोफत, Kubernetes चा default
  • Datadog: hosted, agent + DogStatsD, metrics + traces + logs एकाच ठिकाणी, सुरू करायला जलद
  • CloudWatch: AWS मध्येच बांधलेले — Lambda, API Gateway, ALB आणि RDS आधीच त्याला report करतात; EMF log ओळींचे metrics बनवतो

❌ तोटे

  • Prometheus: तो तुम्हीच चालवता, साठवता आणि scale करता; दीर्घकालीन storage हे जादा काम आहे
  • Datadog: प्रत्येक host, प्रत्येक custom metric आणि प्रत्येक GB नुसार किंमत — high-cardinality tags महाग पडतात
  • CloudWatch: फक्त AWS, प्रत्येक metric आणि प्रत्येक alarm चा खर्च, query करणे अधिक अवघड

👍 वापरा जेव्हा

  • Kubernetes मध्ये Prometheus (Kubernetes शाळेचा धडा 26)
  • टीमला सगळ्यासाठी एकच सशुल्क पडदा हवा असेल तेव्हा Datadog
  • AWS-native stacks साठी CloudWatch (AWS शाळेचा धडा 18)

👎 दोनदा विचार करा जेव्हा

  • कारण नसताना त्याच आकड्यांसाठी त्यातले दोन चालवणे
  • user ids किंवा कच्चे URLs असलेले labels — तिन्हींमध्ये cardinality फुटते

🗄️ REST (विरुद्ध GraphQL, gRPC) — धडे 03, 11

⏮️ REST जिंकण्याआधी (2000 चे दशक)

प्रत्येक service ने स्वतःची remote-call शैली शोधली: SOAP envelopes, custom XML, URL मध्ये getStudentById सारखी RPC क्रियापदे. Caches मदत करू शकत नव्हते, प्रत्येक client ला खास library लागायची, आणि 'API' म्हणजे 40 पानांचे PDF.

✅ फायदे

  • नामे + प्रमाणित क्रियापदे: कोणताही HTTP client चालतो, caches समजतात
  • status codes आणि headers ला आधीच अर्थ आहे
  • document करायला (OpenAPI) आणि mock करायला सोपे

❌ तोटे

  • पाच resources लागणाऱ्या screen साठी अनेक फेऱ्या
  • over-fetching: एका field साठी अख्खा ड्रॉवर
  • 'RESTful' ही एक श्रेणी आहे — टीम्स शुद्धतेवर वाद घालतात

👍 वापरा जेव्हा

  • सार्वजनिक आणि भागीदार API, cache होणारे काहीही
  • स्पष्ट resources वरचे CRUD

👎 दोनदा विचार करा जेव्हा

  • एका UI ला त्याच data चे अनेक आकार लागतात → GraphQL
  • बडबडे, typed, अंतर्गत service-ते-service → gRPC

🪪 API keys विरुद्ध bearer tokens विरुद्ध OAuth — धडा 06

⏮️ प्रमाणित पास येण्याआधी

query strings मध्ये passwords, प्रत्येक script मध्ये चिकटवलेली सामायिक 'admin' गुपिते, आणि सगळ्यांना न मोडता एका client ला रद्द करण्याचा मार्ग नाही.

✅ फायदे

  • API key: सर्वात सोपा मशीन-पास, प्रत्येक ॲपला, रद्द करता येणारा
  • JWT: स्वयंपूर्ण, संपणारा, स्वाक्षरीत — प्रत्येक विनंतीला lookup नाही
  • OAuth/OIDC: वापरकर्ते password न देता मर्यादित प्रवेश देतात

❌ तोटे

  • keys गळतात (logs, URLs, repos) आणि स्वतःहून कधीच संपत नाहीत
  • deny-list शिवाय JWT मुदतीआधी रद्द करता येत नाहीत
  • OAuth flows म्हणजे खरे engineering; redirects चुकीचे लावणे सोपे

👍 वापरा जेव्हा

  • server-ते-server साठी keys, मर्यादित आणि फिरवलेल्या
  • user sessions साठी tokens; तिसरे ॲप वापरकर्त्यासाठी काम करते तेव्हा OAuth

👎 दोनदा विचार करा जेव्हा

  • browser ॲपमध्ये key — पाठवल्या क्षणी ती सार्वजनिक
  • स्वतः रचलेले crypto किंवा session logic — मानक वापरा

📚 Cursor विरुद्ध offset pagination — धडा 08

⏮️ Pagination आधी

'सगळे परत द्या' — 50 rows ला ठीक, 50,000 ला घातक: timeouts, memory, आणि कायम spinner दाखवणारे clients.

✅ फायदे

  • cursor: inserts असूनही स्थिर, index सह वेगवान, आधुनिक default
  • offset: अंमलात आणायला क्षुल्लक, पान N वर उडी

❌ तोटे

  • cursor: '40 पैकी पान 7' नाही, समजावायला अपारदर्शक tokens
  • offset: rows बदलल्या की गळती/दुप्पट; खोल पाने हळू होतात

👍 वापरा जेव्हा

  • feeds, logs, वाढणाऱ्या कशासाठीही cursor
  • पान-निवडक असलेल्या छोट्या admin तक्त्यांसाठी offset

👎 दोनदा विचार करा जेव्हा

  • लोक scroll करत असताना वाढणाऱ्या तक्त्यावर offset
  • उत्पादनाला खरोखर 'पान 12 वर उडी' लागते तेव्हा cursor

🔢 Path मधले विरुद्ध headers मधले versioning — धडा 09

⏮️ Versioning आधी

एका field चे नाव बदलले की प्रत्येक client एकदम मोडायचा — किंवा कोणी धाडस केले नाही म्हणून काहीच कधी बदलले नाही.

✅ फायदे

  • path मध्ये /v1: दिसणारे, cache होणारे, गेटवर route करायला सोपे
  • header/media-type आवृत्त्या: एक URL, स्वच्छ resources

❌ तोटे

  • path आवृत्त्या URL वाढवतात आणि मोठ्या पुनर्लेखनाचा मोह घालतात
  • header आवृत्त्या logs आणि links मध्ये अदृश्य
  • ठेवलेली प्रत्येक आवृत्ती म्हणजे test करावी लागणारी आवृत्ती

👍 वापरा जेव्हा

  • सार्वजनिक API साठी path आवृत्त्या; त्याच आवृत्तीवर additive बदल
  • तारखा आणि आकड्यांसह लिहिलेले deprecation धोरण

👎 दोनदा विचार करा जेव्हा

  • प्रत्येक field किंवा endpoint चे वेगळे versioning — गोंधळ
  • 'स्वच्छ दिसते म्हणून' clients गुपचूप मोडणे

⏱️ Rate limiting — धडा 10

⏮️ मर्यादांआधी

एक बेलगाम script अख्खे ऑफिस रिकामे करू शकायची: प्रत्येक पाहुणा थांबायचा, आणि उपाय म्हणजे फोन कॉल.

✅ फायदे

  • न्याय: एक गोंगाटी client बाकीच्यांना उपाशी ठेवू शकत नाही
  • clients पाळू शकतील असा स्पष्ट संकेत (429 + Retry-After)
  • रेकॉर्ड रूम आणि तुमचे बिल वाचवते

❌ तोटे

  • प्रामाणिक bursts ही नाकारले जातात — खऱ्या वापरानुसार bucket ठरवा
  • IP नुसार मर्यादा एका NAT मागच्या सगळ्यांना शिक्षा देतात
  • servers मध्ये सामायिक state लागते (gateway चे काम)

👍 वापरा जेव्हा

  • कोणतेही सार्वजनिक endpoint; bug हातोडा मारू शकेल असे काहीही
  • योजनांशी जोडलेल्या प्रत्येक key च्या मर्यादा

👎 दोनदा विचार करा जेव्हा

  • budget ची समस्या नसलेल्या तुमच्याच services मधले अंतर्गत कॉल
  • client मधला N+1 loop दुरुस्त करण्याला पर्याय म्हणून

📣 Webhooks विरुद्ध polling — धडा 11

⏮️ Webhooks आधी

clients दर काही सेकंदांनी 'काही नवे?' विचारायचे — हजारो रिकामी उत्तरे, आणि तरी उशीर.

✅ फायदे

  • events घडतात तेव्हाच येतात; एकही चिठ्ठी वाया नाही
  • एक नोंदणी polling loop ची जागा घेते

❌ तोटे

  • तुम्हाला पोहोचता येणारा receiver चालवावा (आणि सुरक्षित ठेवावा) लागतो
  • delivery फसू शकते: retries, क्रम आणि duplicates तुमची समस्या
  • debugging म्हणजे दोन systems चे logs

👍 वापरा जेव्हा

  • 'झाले की सांग' नाती: payments, CI निकाल, प्रवेश
  • तुम्हाला मोठ्या प्रमाणात poll करू न शकणाऱ्या भागीदारांशी integrations

👎 दोनदा विचार करा जेव्हा

  • तुमचा consumer URL उघडू शकत नाही — queue किंवा long polling वापरा
  • कडक क्रम किंवा exactly-once — event log वापरा

🚪 API gateway — धडा 12

⏮️ Gateways आधी

प्रत्येक API ने auth, rate limits, TLS, logging आणि routing पुन्हा लिहिले — पाच प्रती, पाच bugs.

✅ फायदे

  • auth, limits, routing, TLS, logs, WAF साठी एकच जागा
  • API छोटे राहतात; redeploy न करता धोरणे बदलतात
  • managed आवृत्त्या आहेत (AWS API Gateway, Kubernetes Ingress + plugins)

❌ तोटे

  • आणखी एक hop, चालवायची आणि पैसे द्यायची आणखी एक गोष्ट
  • config चा पसारा; gateway बंद = सगळ्यांचे बंद
  • business logic नको तिथे लपवणे सोपे

👍 वापरा जेव्हा

  • एकापेक्षा जास्त API, कोणतेही सार्वजनिक exposure, प्रत्येक client च्या योजना
  • केंद्रीय auth/limits/observability हवी

👎 दोनदा विचार करा जेव्हा

  • VPN मागची एक अंतर्गत service — एक library पुरेल
  • रूपांतरे आणि business नियम गेटमध्ये ठेवणे