Service Communication

7 pages · ~5 min✓ Reviewed

Builds on Fundamentals and Decomposition. Next up: Data and Consistency.

MicroservicesPage 1

Sync vs Async Mental Model

1. Two ways to talk

	Sync request/response	Async messaging
Caller	blocks until reply	publishes to broker, moves on
Callee	must be up now	processes later
Coupling	time + availability	decoupled in time

Callerwaits
Calleereplies

Producerpublish
Brokerstores
Consumerlater

2. Availability math

Sync chain of N services at 99.9% each ≈ 99.9%^N overall
10 services in a chain ≈ 99.0%, so more downtime
A broker absorbs downstream outages: messages wait
Latency of a sync chain adds up hop by hop

3. Which one to pick

Pick	When	Examples
Sync	caller needs the answer now	reads, auth checks
Async	work can finish later	emails, billing, fan-out

Common mistake

Chaining sync calls across many services causes cascading failures and added latency. Fix: timeouts, circuit breakers, or async events.

MicroservicesPage 2

REST vs gRPC vs Message Broker

1. REST and gRPC

	REST	gRPC
Transport	HTTP/1.1	HTTP/2
Payload	JSON, human readable	Protobuf, binary, smaller
Contract	resource URLs + verbs	`.proto` file
Strengths	cache friendly, public APIs	multiplexing, streaming

REST verbs: GET, POST, PUT, DELETE on resource URLs
gRPC streaming: unary, server, client, bidirectional

2. Which One to Pick

REST

browsers

public clients

gRPC

internal

low-latency service-to-service

Broker

MicroservicesPage 3

API Gateway, Service Discovery and Load Balancing

1. Gateway and Discovery

API gateway = single entry point for clients
Routing, auth, rate limiting, TLS termination
Request aggregation, protocol translation (REST to gRPC)
Service discovery: services register with a registry
Registries: Consul, Eureka, etcd, Kubernetes DNS
Heartbeats remove dead instances: no hardcoded IPs

2. Client-side vs Server-side Discovery

	Client-side	Server-side
Who picks instance	The client	Load balancer / DNS
Client asks	Registry	A stable name
Example	Eureka	Kubernetes Service

Clientpublic
API gatewayauth, limits
Load balancerpicks instance
Service podsregistered

3. Load Balancing

MicroservicesPage 4

Idempotency and Safe Retries

1. Idempotent Operations

Idempotent = N repeats leave the same end state as one
GET, PUT, DELETE are idempotent
POST is not idempotent by default

2. Idempotency Key

Client sends a unique Idempotency-Key header
Server stores key + response
On a repeat: return the stored result, no reprocessing
Insert key with a unique constraint in the same transaction as the side effect
Concurrent duplicates fail instead of both running

3. Consumers

Brokers deliver at-least-once, so duplicates arrive
Dedupe by message ID
Or use naturally idempotent writes: upsert, SET status='paid'

4. Common Mistakes

MicroservicesPage 5

Event-Driven Architecture and Pub/Sub

1. Events and Pub/Sub

	Event	Command
Says	Immutable fact, already happened	Request to do something
Name	Past tense: `OrderPlaced`	Imperative: `PlaceOrder`
Receivers	Any number	One intended

Pub/sub: publisher sends to a topic, every subscribed consumer group gets a copy
Queue: each message goes to exactly one competing consumer

2. Log and Reliability

Topic is split into partitions
Ordering holds only within a partition
Pick the key, e.g. orderId, to keep one order in sequence
Consumer groups track offsets and can replay

Transactional outbox

1One DB transactiondata + event row
2Relayreads outbox
3Brokerpublish

MicroservicesPage 6

Communication Patterns Cheat Sheet

1. Pick the Style

Need	Use
Answer now	REST or gRPC
Finish later, or fan out	Broker
Public clients	REST via gateway
Internal hot path	gRPC

2. Resilience Defaults

Set a timeout on every call
Retry with exponential backoff + jitter
Add a circuit breaker per dependency
Cap retries so they never storm a struggling service

Delivery rule

At-least-once + idempotent consumers = effectively exactly-once

3. Queue vs Topic

Queue	Topic	Kafka
One consumer gets each message

MicroservicesPage 7

Check yourself

A consumer runs balance += 50 for each message from an at-least-once broker. It crashes before acking. What happens?

The broker redelivers the message, so the balance is credited twice.
Fix: save the message ID under a unique constraint in the same transaction, or use an idempotent write.

Three sync services each have 99.9% availability. Roughly how available is the chain?

About 99.7% (0.999^3), which is worse than any single link.
A broker lets the caller keep accepting work during a downstream outage.

Events for order 7 go to a 3-partition topic with random keys. Why can OrderPaid arrive before OrderPlaced?

Kafka guarantees ordering only within one partition.
Key by orderId so all events for that order share a partition.

Delivery	Risk	Note
at-most-once	may lose messages
at-least-once	may duplicate	usual default
exactly-once	costly	= at-least-once + idempotent consumers

Algorithm	Picks
Round robin	Next in turn
Weighted round robin	More to bigger nodes
Least connections	Fewest active
IP hash / consistent hash	Same client, same node (sticky)

Service Communication

Sync vs Async Mental Model

1. Two ways to talk

2. Availability math

3. Which one to pick

REST vs gRPC vs Message Broker

1. REST and gRPC

2. Which One to Pick

API Gateway, Service Discovery and Load Balancing

1. Gateway and Discovery

2. Client-side vs Server-side Discovery

3. Load Balancing

Idempotency and Safe Retries

1. Idempotent Operations

2. Idempotency Key

3. Consumers

4. Common Mistakes

Event-Driven Architecture and Pub/Sub

1. Events and Pub/Sub

2. Log and Reliability

Communication Patterns Cheat Sheet

1. Pick the Style

2. Resilience Defaults

3. Queue vs Topic

Check yourself

3. Common Mistakes

4. Common Mistakes

3. Common Mistakes

4. Infrastructure Recap