API Gateway Patterns and Best Practices for Modern Applications

एपीआई गेटवे सभी एंटरप्राइज़ ट्रैफ़िक का औसतन 83% संभालते हैं, क्लाइंट अनुप्रयोगों के लिए एकल प्रवेश बिंदु के रूप में कार्य करते हैं। एक अच्छी तरह से डिज़ाइन किया गया एपीआई गेटवे क्लाइंट-सर्वर संचार को सरल बनाता है, सुरक्षा नीतियों को लागू करता है, और सभी सेवाओं में अवलोकन प्रदान करता है। एक ख़राब डिज़ाइन एक बाधा और विफलता का एकमात्र बिंदु बन जाता है।

यह मार्गदर्शिका वेब अनुप्रयोगों, ईआरपी सिस्टम और ईकॉमर्स प्लेटफार्मों के लिए एपीआई गेटवे आर्किटेक्चर पैटर्न, प्रौद्योगिकी चयन और कार्यान्वयन सर्वोत्तम प्रथाओं को शामिल करती है।

मुख्य बातें

• एपीआई गेटवे सेवाओं में दोहराव को खत्म करने के लिए क्रॉस-कटिंग चिंताओं (ऑथ, रेट लिमिटिंग, लॉगिंग) को केंद्रीकृत करते हैं
• गेटवे स्तर पर दर सीमित करना बैकएंड सेवाओं को ट्रैफ़िक स्पाइक्स और दुरुपयोग से बचाता है
• डाउनस्ट्रीम सेवाएं अस्वस्थ होने पर सर्किट ब्रेकर पैटर्न कैस्केडिंग विफलताओं को रोकते हैं
• गेटवे के माध्यम से एपीआई संस्करण आपके एपीआई सतह के पिछड़े-संगत विकास को सक्षम बनाता है

---

कोर गेटवे पैटर्न

पैटर्न 1: रूटिंग का अनुरोध करें

गेटवे रूट यूआरएल पथ, हेडर या अन्य अनुरोध विशेषताओं के आधार पर उचित बैकएंड सेवा के लिए अनुरोध करता है।

# Nginx as API gateway
upstream api_service {
    server api-1:3001;
    server api-2:3001;
}

upstream auth_service {
    server auth:9000;
}

upstream web_service {
    server web:3000;
}

server {
    listen 443 ssl;
    server_name api.example.com;

    location /api/v1/ {
        proxy_pass http://api_service;
    }

    location /auth/ {
        proxy_pass http://auth_service;
    }

    location / {
        proxy_pass http://web_service;
    }
}

पैटर्न 2: प्रमाणीकरण और प्राधिकरण

प्रत्येक सेवा में इसे लागू करने से बचने के लिए प्रमाणीकरण को गेटवे पर केंद्रीकृत करें।

// NestJS middleware for JWT validation at the gateway level
@Injectable()
export class GatewayAuthMiddleware implements NestMiddleware {
  constructor(private readonly jwtService: JwtService) {}

  async use(req: Request, res: Response, next: NextFunction) {
    // Skip public endpoints
    if (this.isPublicEndpoint(req.path)) {
      return next();
    }

    const token = this.extractToken(req);
    if (!token) {
      throw new UnauthorizedException('Missing authentication token');
    }

    try {
      const payload = await this.jwtService.verifyAsync(token);
      req['user'] = payload;
      next();
    } catch {
      throw new UnauthorizedException('Invalid token');
    }
  }

  private extractToken(req: Request): string | undefined {
    // Check cookie first, then Authorization header
    return req.cookies?.ecosire_auth
      || req.headers.authorization?.replace('Bearer ', '');
  }

  private isPublicEndpoint(path: string): boolean {
    const publicPaths = ['/health', '/api/v1/products', '/api/v1/blog'];
    return publicPaths.some(p => path.startsWith(p));
  }
}

पैटर्न 3: दर सीमित करना

// Rate limiting configuration per endpoint type
const rateLimits = {
  public: { windowMs: 60000, max: 100 },     // 100 req/min for public APIs
  authenticated: { windowMs: 60000, max: 500 }, // 500 req/min for authenticated users
  admin: { windowMs: 60000, max: 1000 },       // 1000 req/min for admin
  webhooks: { windowMs: 60000, max: 50 },       // 50 req/min for webhooks
};

पैटर्न 4: सर्किट ब्रेकर

जब कोई डाउनस्ट्रीम सेवा विफल हो जाती है, तो सर्किट ब्रेकर कैस्केडिंग विफलताओं को रोकता है:

[Closed] --> (failures exceed threshold) --> [Open] --> (timeout expires) --> [Half-Open]
    ^                                                                            |
    |                                        (success)                           |
    +--------------------------------------------------------------------<-------+
    |                                        (failure)                           |
    |                                           +-------->  [Open]

राज्य:

• बंद: अनुरोध सामान्य रूप से पास होते हैं। ट्रैक विफलता गिनती.
• खुला: सेवा पर कॉल किए बिना सभी अनुरोध तुरंत विफल हो जाते हैं। कैश्ड/फ़ॉलबैक प्रतिक्रिया लौटाएँ।
• आधा खुला: एक अनुरोध की अनुमति दें। यदि यह सफल हो तो सर्किट बंद कर दें। यदि यह विफल रहता है, तो पुनः खोलें।

पैटर्न 5: रिस्पांस कैशिंग

# Cache GET responses for public endpoints
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=api_cache:10m max_size=1g inactive=60m;

location /api/v1/products {
    proxy_pass http://api_service;
    proxy_cache api_cache;
    proxy_cache_valid 200 5m;
    proxy_cache_valid 404 1m;
    proxy_cache_key "$scheme$request_method$host$request_uri";
    add_header X-Cache-Status $upstream_cache_status;
}

---

एपीआई संस्करण रणनीतियाँ

सिफारिश: यूआरएल पथ संस्करण। यह गेटवे स्तर पर सबसे स्पष्ट, सबसे डिबग करने योग्य और रूट करने में सबसे आसान है।

ब्रेकिंग बनाम नॉन-ब्रेकिंग परिवर्तन

---

गेटवे प्रौद्योगिकी तुलना

अधिकांश SMBs के लिए: Nginx पर्याप्त है। यह रूटिंग, एसएसएल समाप्ति, दर सीमित करने और सब-मिलीसेकंड ओवरहेड के साथ कैशिंग को संभालता है। जब आपको उन्नत प्लगइन क्षमताओं (OAuth2, अनुरोध परिवर्तन, विश्लेषण) की आवश्यकता हो तो कोंग में अपग्रेड करें।

---

गेटवे पर अवलोकनशीलता

लॉगिंग का अनुरोध करें

log_format gateway '$remote_addr - $remote_user [$time_local] '
                   '"$request" $status $body_bytes_sent '
                   '"$http_referer" "$http_user_agent" '
                   '$request_time $upstream_response_time '
                   '$http_x_request_id';

access_log /var/log/nginx/gateway.log gateway;

मेट्रिक्स संग्रह

गेटवे स्तर पर इन मेट्रिक्स को ट्रैक करें:

• अनुरोध दर समापन बिंदु, विधि और स्थिति कोड द्वारा
• विलंबता वितरण (पी50, पी95, पी99) समापन बिंदु तक
• त्रुटि दर समापन बिंदु और त्रुटि प्रकार के अनुसार
• ग्राहक द्वारा दर सीमा प्रभावित
• एंडपॉइंट द्वारा कैश हिट अनुपात
• अपस्ट्रीम प्रतिक्रिया समय बनाम कुल प्रतिक्रिया समय

---

गेटवे पर त्रुटि प्रबंधन

लगातार त्रुटि प्रतिक्रियाएँ

गेटवे को विभिन्न बैकएंड सेवाओं से त्रुटि प्रतिक्रियाओं को सामान्य करना चाहिए:

{
  "error": {
    "code": "SERVICE_UNAVAILABLE",
    "message": "The requested service is temporarily unavailable",
    "requestId": "req_abc123",
    "timestamp": "2026-03-16T14:32:01Z"
  }
}

पुनः प्रयास करें और टाइमआउट कॉन्फ़िगरेशन

location /api/ {
    proxy_pass http://api_service;

    # Timeout configuration
    proxy_connect_timeout 5s;
    proxy_send_timeout 30s;
    proxy_read_timeout 30s;

    # Retry on connection errors only (not on 5xx)
    proxy_next_upstream error timeout;
    proxy_next_upstream_tries 2;

    # Custom error pages
    error_page 502 503 504 /api-error.json;
}

शोभायमान पतन

जब एक गैर-महत्वपूर्ण बैकएंड सेवा बंद हो जाती है, तो गेटवे त्रुटियाँ लौटाने के बजाय कैश्ड प्रतिक्रियाएँ या फ़ॉलबैक डेटा प्रदान कर सकता है:

---

गेटवे सुरक्षा पैटर्न

सत्यापन का अनुरोध करें

बैकएंड सेवाओं को अग्रेषित करने से पहले अनुरोध संरचना को मान्य करें:

• अज्ञात सामग्री प्रकार वाले अनुरोधों को अस्वीकार करें
• प्रति समापन बिंदु पर अधिकतम अनुरोध बॉडी आकार लागू करें
• आवश्यक हेडर सत्यापित करें (एपीआई संस्करण, सामग्री प्रकार)
• संदिग्ध हेडर को हटा दें (हॉप-बाय-हॉप हेडर, सर्वर-आंतरिक हेडर)

एडमिन एंडपॉइंट के लिए आईपी अनुमति सूची

location /api/admin/ {
    allow 203.0.113.0/24;  # Office IP range
    allow 10.0.0.0/8;      # Internal network
    deny all;

    proxy_pass http://api_service;
}

परिवर्तन का अनुरोध करें

गेटवे अग्रेषित करने से पहले हेडर जोड़, संशोधित या हटा सकता है:

location /api/ {
    proxy_pass http://api_service;

    # Add security headers
    proxy_set_header X-Request-ID $request_id;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Real-IP $remote_addr;

    # Remove internal headers from responses
    proxy_hide_header X-Powered-By;
    proxy_hide_header Server;
}

---

अक्सर पूछे जाने वाले प्रश्न

क्या हमें एक मोनोलिथिक एप्लिकेशन के लिए एपीआई गेटवे की आवश्यकता है?

हाँ, लेकिन एक सरल। यहां तक ​​कि एक मोनोलिथ के लिए, Nginx एक रिवर्स प्रॉक्सी के रूप में SSL समाप्ति, दर सीमित करना, स्थिर फ़ाइल सेवा और सुरक्षा हेडर प्रदान करता है। आपको मोनोलिथ के लिए कोंग या एडब्ल्यूएस एपीआई गेटवे की आवश्यकता नहीं है, लेकिन आपको इंटरनेट और आपके एप्लिकेशन सर्वर के बीच कुछ की आवश्यकता है।

हम एपीआई गेटवे विफलता को कैसे संभालते हैं?

क्लाउड लोड बैलेंसर (AWS ALB, Cloudflare) के पीछे एकाधिक गेटवे इंस्टेंस चलाएँ। यदि एक गेटवे इंस्टेंस विफल हो जाता है, तो लोड बैलेंसर ट्रैफ़िक को स्वस्थ इंस्टेंस पर रूट कर देता है। Nginx के लिए, सक्रिय स्वास्थ्य जांच और अस्वस्थ अपस्ट्रीम को स्वचालित रूप से हटाने का उपयोग करें।

क्या एपीआई गेटवे को प्रमाणीकरण संभालना चाहिए या प्रत्येक सेवा को?

गेटवे को प्रमाणीकरण संभालना चाहिए (सत्यापित करना कि टोकन वैध है)। व्यक्तिगत सेवाओं को प्राधिकरण को संभालना चाहिए (यह जांचना कि प्रमाणित उपयोगकर्ता के पास विशिष्ट कार्रवाई के लिए अनुमति है या नहीं)। यह पृथक्करण गेटवे को हल्का रखता है और सेवाओं को सूक्ष्म पहुंच नियंत्रण निर्णय लेने की अनुमति देता है।

हम एपीआई गेटवे पर सीओआरएस को कैसे संभालते हैं?

सभी सेवाओं में CORS हेडर की नकल से बचने के लिए गेटवे स्तर पर CORS कॉन्फ़िगर करें। अपने विशिष्ट फ्रंटएंड डोमेन पर Access-Control-Allow-Origin सेट करें (क्रेडेंशियल्स के साथ उत्पादन में कभी भी * का उपयोग न करें)। बैकएंड सेवाओं पर भार कम करने के लिए गेटवे पर प्रीफ़्लाइट विकल्प अनुरोधों को संभालें।

---

आगे क्या आता है

एपीआई गेटवे आपके बुनियादी ढांचे का मुख्य द्वार है। इसे दृश्यता के लिए निगरानी, सुरक्षा के लिए सुरक्षा सख्त और क्षमता नियोजन के लिए लोड परीक्षण के साथ जोड़ें।

एपीआई आर्किटेक्चर परामर्श के लिए ECOSIRE से संपर्क करें, या संपूर्ण बुनियादी ढांचे के रोडमैप के लिए हमारे DevOps गाइड को देखें।

---

ECOSIRE द्वारा प्रकाशित - व्यवसायों को स्केलेबल एपीआई इंफ्रास्ट्रक्चर बनाने में मदद करना।