एक सिस्टम में components कैसे संवाद करते हैं (APIs)?

Question

Accepted Answer

एक सिस्टम में, components (services, clients) **APIs** और विभिन्न protocols के माध्यम से संवाद करते हैं — synchronous (REST, gRPC) और asynchronous (messaging/queues)। components कैसे संवाद करते हैं यह समझना कई हिस्सों से बने सिस्टम डिज़ाइन करने के लिए बुनियादी है।

## Synchronous communication (request/response)

```text
The caller WAITS for a response (blocking):
  REST (HTTP) → most common; resources over HTTP (JSON) → simple, ubiquitous, web-friendly
  gRPC → high-performance RPC (binary, HTTP/2) → fast, typed; good for internal services
  GraphQL → flexible queries (client requests exactly what it needs)
→ for: direct request/response where the caller needs an answer now
```

## Asynchronous communication (messaging)

```text
The caller does NOT wait (decoupled, non-blocking):
  MESSAGE QUEUES (RabbitMQ, SQS) → send a message; a consumer processes it later
  EVENT STREAMING (Kafka) → publish events; consumers react
  PUB/SUB → broadcast events to subscribers
→ for: decoupling, background work, handling spikes, event-driven systems
  ✓ resilience (queue buffers), scalability, decoupling  ✗ more complexity, eventual consistency
```

## चुनना और विचारणीय बातें

```text
SYNC → when the caller needs an immediate response; simpler request/response
ASYNC → when decoupling, resilience, or background processing matters (don't block)
→ Also: API design (clear contracts), versioning, error handling, timeouts/retries,
  authentication, rate limiting → robust communication between components
```

## यह क्यों महत्वपूर्ण है

APIs के माध्यम से components कैसे संवाद करते हैं यह समझना बुनियादी है क्योंकि **सिस्टम कई हिस्सों से बने होते हैं जिन्हें संवाद करना होता है**, इसलिए संवाद को समझना उन्हें डिज़ाइन करने के लिए आवश्यक है।

सिस्टम services और clients से मिलकर बने होते हैं जो परस्पर क्रिया करते हैं, और वे कैसे संवाद करते हैं यह system design का एक बुनियादी पहलू है।

**synchronous communication** (request/response जहाँ caller प्रतीक्षा करता है) को समझना — **REST** (सर्वव्यापी HTTP/JSON दृष्टिकोण), **gRPC** (internal services के लिए high-performance RPC), और GraphQL (flexible queries) — उन सामान्य तरीकों को कवर करता है जिनसे components उत्तर की अपेक्षा करते हुए सीधी calls करते हैं।

**asynchronous communication** (decoupled, non-blocking) को समझना — **message queues** (बाद में processing के लिए messages भेजना), **event streaming** (Kafka), और pub/sub — समान रूप से महत्वपूर्ण है, क्योंकि यह **decoupling, resilience (queues द्वारा load बफ़र करना), scalability, और event-driven systems** को सक्षम करता है, अधिक जटिलता और eventual consistency की कीमत पर।

**sync बनाम async अंतर और प्रत्येक का उपयोग कब करें** यह समझना — synchronous जब caller को तत्काल response चाहिए, asynchronous जब decoupling, resilience, या background processing मायने रखता है — एक प्रमुख design विचार है जो सिस्टम की विशेषताओं को महत्वपूर्ण रूप से प्रभावित करता है।

अतिरिक्त विचारों (स्पष्ट API contracts, versioning, error handling, timeouts/retries, authentication, rate limiting) को समझना मज़बूत communication डिज़ाइन करने को दर्शाता है।

चूँकि सिस्टम संवाद करने वाले हिस्सों से बने होते हैं और वे कैसे संवाद करते हैं (sync बनाम async, protocols, और design विचार) सिस्टम को बुनियादी रूप से आकार देता है, और चूँकि component communication को समझना बहु-component सिस्टम डिज़ाइन करने के लिए आवश्यक है, APIs के माध्यम से components कैसे संवाद करते हैं यह समझना आवश्यक, बुनियादी system-design ज्ञान है — कई परस्पर क्रिया करने वाले हिस्सों से बने सिस्टम डिज़ाइन करने के लिए बुनियादी, components को जोड़ने वाले synchronous और asynchronous communication को कवर करना, और आज सामान्य distributed, service-based सिस्टम की architecture के केंद्र में।