Microservices Communication — Vocabulary

Synchronous (REST, gRPC): caller blocks waiting for a response — simple to reason about but creates temporal coupling (both services must be available simultaneously). Asynchronous (Kafka, RabbitMQ, SQS): caller publishes a message to a broker and continues — receiver processes it when ready. Async decouples availability but adds complexity (message ordering, at-least-once delivery, consumer lag).

Request-reply over messaging: the caller publishes a request with a correlation ID and a reply-to address (queue/topic). The receiver processes the request and publishes the response to the reply-to address with the same correlation ID. The caller consumes from its reply queue and matches responses by correlation ID. This gives request-reply semantics with async decoupling.

Pub-sub (Kafka topics, SNS, Google Pub/Sub): producers publish events to a topic; multiple independent consumers subscribe. Each subscriber sees all messages (or a filtered subset). The producer has no knowledge of subscribers. This enables fan-out: OrderPlaced event can trigger inventory reservation, email notification, and analytics ingestion all independently, with no coupling between those consumers.

Idempotency is essential for reliable messaging: since 'at-least-once delivery' means messages can arrive more than once, consumers must handle duplicates safely. Techniques: idempotency keys (store processed message IDs in a deduplication table; skip if already seen), natural idempotency (PUT /orders/123 with full state is idempotent; POST /orders is not). Design APIs and consumers to be idempotent by default.

Delivery semantics: at-most-once (may lose messages, never duplicates), at-least-once (never loses messages, may duplicate — most common), exactly-once (no loss, no duplicates — hardest to achieve). Kafka provides exactly-once semantics (EOS) via idempotent producers + transactional APIs, but at significant complexity cost. In practice, most systems use at-least-once + idempotent consumers.