Learn vocabulary for synchronous vs. asynchronous communication, request-reply, publish-subscribe, idempotency, and exactly-once delivery in microservices.
0 / 5 completed
1 / 5
What distinguishes synchronous from asynchronous communication in microservices 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).
2 / 5
What is the 'request-reply' pattern in microservices communication vocabulary?
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.
3 / 5
What is the 'publish-subscribe' (pub-sub) pattern in microservices vocabulary?
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.
4 / 5
What is 'idempotency' in microservices communication vocabulary?
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.
5 / 5
What does 'exactly-once delivery' mean in microservices messaging vocabulary?
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.