# आम जाल और विफलता अभ्यास — API Gateway और Service Mesh

Source: https://www.geekswithgeeks.com/hi/api-gateway-service-mesh/o-pitfalls

> आम ग़लतियाँ पहचानें: gateway में तर्क, retry storms, चुपचाप नीति की कमियाँ और sidecar की हैरानियाँ।

## आम तौर पर क्या बिगड़ता है

(1) **Gateway में व्यावसायिक तर्क**: वह परखने में कठिन monolith बन जाता है। (2) **Retry storms**: कई परतों के retries outage में बोझ गुणा करते हैं। (3) **Timeouts ग़ायब या उलटे**: भीतरी timeouts बाहरी से लंबे। (4) `X-User-Id` जैसे **client headers पर भरोसा**। (5) **नीति की कमियाँ**: ग़लत क्रम में नियम जुड़ने से कोई route authentication छोड़ देता है। (6) **Sidecar की हैरानियाँ**: proxy तैयार होने से पहले शुरू होने वाले apps, rebalancing अनदेखी करने वाले लंबे connections, या protocol पहचान की समस्याएँ। (7) metrics labels में **असीमित cardinality**। (8) **bypass या rollback योजना का न होना**। Staging में विफलता अभ्यास करें: upstream मारें, एक को धीमा करें, certificate तोड़ें, pool खाली करें, और जाँचें कि alerts चलते हैं और व्यवहार अपेक्षा से मेल खाता है।

## विफलता अभ्यास की checklist

Demo परिवेश इन अभ्यासों के लिए एकदम सही है: `gwg-orders-v1` रोकें, gateway को 502/504 लौटाते देखें, फिर बहाल करें।

```text
Drill                         Expect
stop one upstream             retries to a healthy peer; no client errors (if idempotent)
stop ALL upstreams            fast 502/503 (not a hang); circuit opens; alert fires
slow upstream (3 s)           gateway timeout (504) at the configured limit
expired / wrong certificate   mTLS handshake fails; calls rejected; alert on cert errors
burst of 100 requests         429 beyond rate+burst; backends stay healthy
bad config pushed             validation rejects it; or staged rollout catches it
```

**Quiz:** Gateway का आम anti-pattern कौन-सा है?

- [ ] Rate limiting
- [ ] वहाँ TLS terminate करना
- [ ] Request IDs जोड़ना
- [x] Gateway में व्यावसायिक तर्क रखना

*Answer:* Gateway में व्यावसायिक तर्क रखना. Gateways को पतली नीति रखनी चाहिए, application नियम नहीं।
