एक प्रणालीमा कम्पोनेन्टहरू कसरी संचार गर्छन् (APIs)?

Question

Accepted Answer

एक प्रणालीमा, कम्पोनेन्टहरू (सेवाहरू, क्लाइन्टहरू) **APIs** र विभिन्न प्रोटोकलहरू — सिङ्क्रोनस (REST, gRPC) र असिङ्क्रोनस (मेसेजिङ/queues) को माध्यमबाट संचार गर्छन्। कम्पोनेन्टहरू कसरी संचार गर्छन् भन्ने कुरा बुझ्न सिस्टेमहरू डिजाइन गर्नको लागि मौलिक छ जो धेरै भागहरूबाट बनेका हुन्छन्।

## 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
```

## Choosing and considerations

```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 मार्फत कसरी संचार गर्छन् भन्ने कुरा बुझ्न आधारभूत छ किनभने **सिस्टेमहरू धेरै भागहरूबाट बनेका हुन्छन् जो संचार गर्नु पर्छ**, त्यसैले संचार बुझ्न प्रणाली डिजाइन गर्नको लागि आवश्यक छ।

सिस्टेमहरू सेवाहरू र क्लाइन्टहरूबाट बनेका हुन्छन् जो अन्तरक्रिया गर्छन्, र तिनीहरू कसरी संचार गर्छन् यो सिस्टेम डिजाइनको एक मौलिक पक्ष हो।

**Synchronous communication** बुझ्न (request/response जहाँ कलर प्रतीक्षा गर्छ) — **REST** (ubiquitous HTTP/JSON दृष्टिकोण), **gRPC** (आन्तरिक सेवाहरूका लागि उच्च-प्रदर्शन RPC), र GraphQL (लचकदार queries) — सामान्य तरिकाहरू कभर गर्छ जहाँ कम्पोनेन्टहरूले सीधा कलहरू गरी जवाफको लागि प्रतीक्षा गर्छन्।

**Asynchronous communication** बुझ्न (decoupled, non-blocking) — **message queues** (पछिको प्रशोधनका लागि मेसेजहरू पठाउने), **event streaming** (Kafka), र pub/sub — समान रूपमा महत्त्वपूर्ण छ, किनभने यसले **decoupling, resilience (queues ले लोड buffer गर्छ), scalability, र event-driven systems** सक्षम गर्छ, अधिक जटिलता र eventual consistency को मूल्यमा।

**Sync बनाम async distinction र कहिले प्रत्येक प्रयोग गर्ने** बुझ्न — synchronous जब कलरलाई तत्काल जवाफ चाहिन्छ, asynchronous जब decoupling, resilience, वा पार्श्वभूमि प्रशोधन महत्त्वपूर्ण छ — प्रमुख डिजाइन विचार हो जो सिस्टेमको विशेषताहरूलाई महत्त्वपूर्ण रूपमा असर गर्छ।

अतिरिक्त विचारहरू (स्पष्ट API contracts, versioning, error handling, timeouts/retries, authentication, rate limiting) बुझ्न मजबूत संचार डिजाइन गरी प्रतिबिम्बित हुन्छ।

सिस्टेमहरू संचार गर्ने भागहरूबाट बनेका हुन्छन् र तिनीहरू कसरी संचार गर्छन् (sync बनाम async, प्रोटोकलहरू, र डिजाइन विचारहरू) सिस्टेमको विशेषताहरूलाई मौलिक रूपमा आकार दिन्छ, र कम्पोनेन्ट संचार बुझ्न बहु-कम्पोनेन्ट सिस्टेमहरू डिजाइन गर्नको लागि आवश्यक छ, त्यसैले कम्पोनेन्टहरू APIs मार्फत कसरी संचार गर्छन् भन्ने कुरा बुझ्न आवश्यक, आधारभूत प्रणाली-डिजाइन ज्ञान हो — कम्पोनेन्टहरू बनाएको बहु-कम्पोनेन्ट अन्तरक्रिया गर्ने भागहरूको सिस्टेमहरू डिजाइन गर्नको लागि मौलिक, synchronous र asynchronous संचार कभर गर्दै जो कम्पोनेन्टहरूलाई जोडेर, र आजको वितरित, service-based सिस्टेमहरूको आर्किटेक्चर गर्नमा केन्द्रीय।