Cum comunică componentele într-un sistem (API-uri)?

Question

Accepted Answer

Într-un sistem, componentele (servicii, clienți) comunică prin **API-uri** și diverse protocoale — sincrone (REST, gRPC) și asincrone (messaging/cozi). Înțelegerea modului în care componentele comunică este fundamentală pentru proiectarea sistemelor formate din mai multe părți.

## Comunicare sincronă (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
```

## Comunicare asincronă (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
```

## Alegerea și considerații

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

## De ce este important

Înțelegerea modului în care componentele comunică prin API-uri este fundamentală deoarece **sistemele sunt formate din mai multe părți care trebuie să comunice**, deci înțelegerea comunicării este esențială pentru a le proiecta.

Sistemele constau din servicii și clienți care interacționează, iar modul în care comunică este un aspect fundamental al proiectării sistemelor.

Înțelegerea **comunicării sincrone** (request/response în care apelantul așteaptă) — **REST** (abordarea HTTP/JSON omniprezentă), **gRPC** (RPC de înaltă performanță pentru serviciile interne), și GraphQL (interogări flexibile) — acoperă modalitățile comune prin care componentele efectuează apeluri directe așteptând un răspuns.

Înțelegerea **comunicării asincrone** (decuplată, non-blocantă) — **cozi de mesaje** (trimiterea mesajelor pentru procesare ulterioară), **streaming de evenimente** (Kafka), și pub/sub — este la fel de importantă, deoarece permite **decuplarea, reziliența (cozi tamponând sarcina), scalabilitate, și sisteme bazate pe evenimente**, cu cost de mai multă complexitate și consistență eventualității.

Înțelegerea **distincției sincron vs asincron și când să folosești fiecare** — sincron atunci când apelantul are nevoie de un răspuns imediat, asincron atunci când decuplarea, reziliența, sau procesarea în fundal contează — este o considerație cheie de proiectare care afectează semnificativ caracteristicile unui sistem.

Înțelegerea considerațiilor suplimentare (contracte API clare, versioning, tratarea erorilor, timeout-uri/reîncercări, autentificare, rate limiting) reflectă proiectarea unei comunicări robuste.

Deoarece sistemele sunt compuse din părți care comunică și modul în care comunică (sincron vs asincron, protocoalele, și considerațiile de proiectare) formează fundamental sistemul, și deoarece înțelegerea comunicării componentelor este esențială pentru proiectarea sistemelor cu mai multe componente, înțelegerea modului în care componentele comunică prin API-uri este cunoștințe esențiale și fundamentale de proiectare a sistemelor — fundamentală pentru proiectarea sistemelor formate din mai multe părți care interacționează, acoperind comunicarea sincronă și asincronă care conectează componentele, și centrală pentru arhitectarea sistemelor distribuite, bazate pe servicii, comune în zilele noastre.