سسٹم میں کمپوننٹس کیسے ایک دوسرے سے بات چیت کرتے ہیں (APIs)؟

Question

Accepted Answer

سسٹم میں، کمپوننٹس (سروسز، کلائنٹس) **APIs** اور مختلف پروٹوکولس کے ذریعے بات چیت کرتے ہیں — ہم وقت (synchronous) (REST، gRPC) اور غیر ہم وقت (asynchronous) (messaging/queues)۔ کمپوننٹس کیسے بات چیت کرتے ہیں اس کو سمجھنا متعدد حصوں سے بنے سسٹمز کو ڈیزائن کرنے کے لیے بنیادی ہے۔

## ہم وقت بات چیت (درخواست/جواب)

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

## غیر ہم وقت بات چیت (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 کے ذریعے کیسے بات چیت کرتے ہیں بنیادی ہے کیونکہ **سسٹمز متعدد حصوں سے بنے ہوتے ہیں جنہیں بات چیت کرنی ہوتی ہے**، اس لیے بات چیت کو سمجھنا ان کو ڈیزائن کرنے کے لیے ضروری ہے۔

سسٹمز سروسز اور کلائنٹس پر مشتمل ہوتے ہیں جو آپس میں تعامل کرتے ہیں، اور وہ کیسے بات چیت کرتے ہیں یہ سسٹم ڈیزائن کا ایک بنیادی پہلو ہے۔

**ہم وقت بات چیت** (درخواست/جواب جہاں کال کنندہ انتظار کرتا ہے) — **REST** (ہر جگہ استعمال ہونے والا HTTP/JSON انداز)، **gRPC** (اندرونی سروسز کے لیے اعلیٰ کارکردگی والا RPC)، اور GraphQL (لچکدار سوالات) — کو سمجھنا عام طریقوں کو کور کرتا ہے جس سے کمپوننٹس براہ راست کالز کرتے ہیں جواب کی توقع میں۔

**غیر ہم وقت بات چیت** (منفصل، غیر مسدود) — **message queues** (بعد میں پروسیسنگ کے لیے پیغامات بھیجنا)، **event streaming** (Kafka)، اور pub/sub — کو سمجھنا برابر اہم ہے، کیونکہ یہ **منفصل کاری، لچک (queues بوجھ کو محفوظ کرتے ہیں)، توسیع پذیری، اور event-driven سسٹمز** کو فعال کرتا ہے، زیادہ پیچیدگی اور بالآخر مطابقت کی قیمت پر۔

**ہم وقت بمقابلہ غیر ہم وقت میں فرق اور ہر ایک کب استعمال کریں** کو سمجھنا — ہم وقت جب کال کنندہ کو فوری جواب کی ضرورت ہو، غیر ہم وقت جب منفصل کاری، لچک، یا پس منظر میں پروسیسنگ اہم ہو — ایک اہم ڈیزائن غور و خوض ہے جو سسٹم کی خصوصیات کو نمایاں طور پر متاثر کرتا ہے۔

اضافی غور و خوض کو سمجھنا (واضح API معاہدے، ورژن بندی، غلطی سے نمٹنا، timeouts/retries، توثیق، rate limiting) مضبوط بات چیت کو ڈیزائن کرنے کو ظاہر کرتا ہے۔

کیونکہ سسٹمز بات چیت کرنے والے حصوں پر مشتمل ہیں اور وہ کیسے بات چیت کرتے ہیں (ہم وقت بمقابلہ غیر ہم وقت، پروٹوکولس، اور ڈیزائن غور و خوض) سسٹم کو بنیادی طور پر تشکیل دیتے ہیں، اور کیونکہ کمپوننٹ بات چیت کو سمجھنا متعدد کمپوننٹ سسٹمز کو ڈیزائن کرنے کے لیے ضروری ہے، کمپوننٹس کیسے APIs کے ذریعے بات چیت کرتے ہیں یہ سمجھنا ضروری، بنیادی سسٹم-ڈیزائن علم ہے — متعدد تعامل کنندہ حصوں سے بنے سسٹمز کو ڈیزائن کرنے کے لیے بنیادی، کمپوننٹس کو جوڑنے والی ہم وقت اور غیر ہم وقت بات چیت کا احاطہ کرتے ہوئے، اور آج کے عام distributed، service-based سسٹمز کو تعمیر کرنے میں مرکزی۔