पाठ 25 / 26

केस स्टडी: Orders Platform के लिए Edge डिज़ाइन

E-commerce orders platform के लिए gateway और mesh नीति डिज़ाइन करें।

डिज़ाइन

सार्वजनिक traffic cloud load balancer में आता है, फिर API gateway (zones भर में दो या अधिक instances) जो TLS terminate करता है, API keys या JWTs validate करता है, प्रति-client rate limits लगाता है (Retry-After के साथ 429), request ID बनाता है, आंतरिक headers हटाता है और path से orders, users और payments की ओर route करता है। नए releases mirrored-traffic परीक्षण के बाद weighted canaries (5%, फिर 25%, 50%, 100%) उपयोग करते हैं, error-दर या p99 बिगड़ने पर स्वचालित rollback के साथ। Cluster के भीतर mesh अल्पकालिक पहचानों के साथ mTLS, default-deny authorisation (सिर्फ़ billing payments को बुला सकती है), गहराई के साथ घटते timeouts, mesh परत पर सिर्फ़ idempotent calls के retries, circuit breaking और outlier detection, और trace propagation के साथ golden signals का telemetry देता है। सारा config Git में रहता है, CI में validate होता है और क्रमिक रूप से rollout होता है, परखे हुए आपातकालीन bypass और हर तिमाही विफलता अभ्यास के साथ।

सुरक्षित, देखे जा सकने वाला प्रवेश-बिंदु

Routing, auth, सीमाएँ, resilience और telemetry मिलकर भरोसेमंद edge और विश्वसनीय mesh बनाते हैं।

चार परतें: edge, नीति, resilience, observability।
चित्र 8.1 — Edge, नीति, resilience और observability।

एक पन्ने पर डिज़ाइन

हर पंक्ति इस कोर्स के एक खंड से जुड़ती है।

Edge        LB -> 2+ gateways, TLS termination, request IDs      (Sec 1-2)
Routing     path routes, header opt-in canary, weighted 5/25/50/100  (Sec 2)
Security    API key/JWT at edge, per-client rate limits, WAF/CORS   (Sec 3)
Resilience  timeouts shrink with depth, retries at ONE layer,       (Sec 4)
            circuit breaker + outlier detection, consistent hashing
Mesh        mTLS identities, default-deny authz, telemetry + traces  (Sec 5)
Ops         config in Git + validation, staged rollouts, bypass,     (Sec 6)
            failure drills; no mesh unless the scale needs it
Delivery    mirror -> canary -> promote/rollback automatically       (Sec 7)

त्वरित जाँच: डिज़ाइन में retries कहाँ किए जाते हैं और क्यों?

  • कहीं नहीं
  • अधिकतम सुरक्षा के लिए हर परत पर
  • एक परत पर, सिर्फ़ idempotent calls के लिए, amplification से बचने को
  • सिर्फ़ browser में
Answer

एक परत पर, सिर्फ़ idempotent calls के लिए, amplification से बचने को — एक परत और केवल idempotent retries, retry storms और दोहरे side effects से बचाते हैं।