Understanding Communication Fundamentals
1. Understanding Synchronous Communication
| Property | Detail |
|---|---|
| Definition | Caller blocks until callee responds |
| Protocols | HTTP/REST, gRPC, GraphQL, SOAP |
| Coupling | Temporal (both must be available) |
| Latency | Sum of all calls in chain |
| Use When | Immediate response needed; query operations |
| Avoid When | Long chains; high-volume fanout |
Example: Synchronous REST Call (Java + Spring)
@RestController
public class OrderController {
private final RestClient paymentClient;
@PostMapping("/orders")
public OrderResponse create(@RequestBody OrderRequest req) {
// Blocking call to Payment Service
PaymentResult result = paymentClient.post()
.uri("/payments")
.body(req.toPayment())
.retrieve()
.body(PaymentResult.class);
return new OrderResponse(result.orderId(), result.status());
}
}2. Understanding Asynchronous Communication
| Property | Detail |
|---|---|
| Definition | Sender does not wait; consumer processes later |
| Mechanisms | Message queues, event streams, webhooks |
| Coupling | Temporal decoupling via broker |
| Reliability | Broker persists messages until consumed |
| Use When | Long-running ops, fanout, decoupling |
| Avoid When | Caller needs immediate result |
Example: Async Publishing (Java + Kafka)
@Service
public class OrderService {
private final KafkaTemplate<String, OrderEvent> kafka;
public void placeOrder(Order order) {
orderRepo.save(order);
kafka.send("orders.placed", order.id(),
new OrderEvent(order.id(), order.items(), order.total()));
// Returns immediately; downstream services react asynchronously
}
}3. Understanding Communication Protocols
| Protocol | Style | Format | Best For |
|---|---|---|---|
| HTTP/REST | Sync, request/response | JSON | Public APIs, broad compatibility |
| gRPC | Sync/streaming | Protobuf | Internal high-perf service-to-service |
| GraphQL | Sync, query | JSON | BFF, flexible client queries |
| WebSocket | Bi-directional stream | Any | Real-time UI updates |
| AMQP (RabbitMQ) | Async messaging | Any | Work queues, routing |
| Kafka Protocol | Async log/stream | Avro/Protobuf/JSON | Event streaming, replay |
| MQTT | Async pub/sub (lightweight) | Binary | IoT, low bandwidth |
| NATS | Async pub/sub (high perf) | Any | Cloud-native messaging |
4. Synchronous vs Asynchronous Communication
| Scenario | Choose |
|---|---|
| User-facing GET (need result now) | Sync REST/gRPC |
| Order placed → notify shipping/billing | Async event |
| Multi-step business workflow | Async + Saga |
| Real-time data stream | Async streaming (Kafka) |
5. Understanding Message Brokers
| Broker | Model | Strength |
|---|---|---|
| Apache Kafka | Log-based, partitioned | High throughput, replay, streaming |
| RabbitMQ | Queue + exchange routing (AMQP) | Flexible routing, work queues |
| AWS SQS | Managed queue | Simplicity, integrated with AWS |
| AWS SNS | Pub/sub fanout | Notification fanout |
| NATS / NATS JetStream | Pub/sub, streams | Low latency, cloud-native |
| Apache Pulsar | Tiered storage, multi-tenant | Geo-replication, large scale |
| Redis Streams | In-memory log | Simple, fast, with consumer groups |
6. Understanding RPC Patterns
| RPC Variant | Description | Tooling |
|---|---|---|
| Unary RPC | One request, one response | gRPC, Thrift |
| Server Streaming | One request, stream of responses | gRPC |
| Client Streaming | Stream of requests, one response | gRPC |
| Bi-directional Streaming | Both sides stream | gRPC, WebSocket |
| JSON-RPC | Lightweight RPC over HTTP | Various |
Example: gRPC Service (Protobuf)
syntax = "proto3";
service PaymentService {
rpc Charge(ChargeRequest) returns (ChargeResponse);
rpc StreamReceipts(StreamRequest) returns (stream Receipt);
}
message ChargeRequest { string order_id = 1; int64 amount_cents = 2; }
message ChargeResponse { string status = 1; string txn_id = 2; }7. Understanding Event-Driven Architecture
| Concept | Description |
|---|---|
| Event | Immutable record of something that happened |
| Producer | Service that emits events; owns the schema |
| Consumer | Service that reacts; multiple consumers per event |
| Broker | Durable transport (Kafka, Pulsar, RabbitMQ) |
| Topic / Stream | Named channel partitioning events by type |
| Choreography | Services react to events; no central controller |
Event Flow
[Order Service] --OrderPlaced--> [Kafka topic: orders]
↓
┌───────────────────────┼────────────────────┐
↓ ↓ ↓
[Payment Service] [Inventory Service] [Notification Svc]
8. Understanding Pub/Sub Model
| Element | Role |
|---|---|
| Publisher | Sends message to topic; unaware of subscribers |
| Topic | Logical channel; multiple subscribers receive copies |
| Subscriber | Independent consumer of topic |
| Subscription | Durable cursor (Kafka consumer group, SNS sub) |
| Delivery Semantics | At-least-once typical; exactly-once with effort |
9. Understanding Request/Reply Model
| Mode | How | Example |
|---|---|---|
| Sync Request/Reply | HTTP request → HTTP response | REST call |
| Async Request/Reply | Send to request queue, listen on reply queue (correlation ID) | RabbitMQ RPC, JMS |
| Callback | Sender provides callback URL/queue | Webhooks |
Example: Async Request/Reply with Correlation ID
String correlationId = UUID.randomUUID().toString();
rabbit.convertAndSend("requests", request, msg -> {
msg.getMessageProperties().setCorrelationId(correlationId);
msg.getMessageProperties().setReplyTo("replies." + serviceId);
return msg;
});
// Consumer matches correlationId to deliver response back to caller10. Understanding Push vs Pull Communication
| Model | Mechanism | Pros | Cons |
|---|---|---|---|
| Push | Broker delivers to consumer (e.g., webhooks, RabbitMQ) | Low latency | Can overwhelm consumer; needs backpressure |
| Pull | Consumer fetches at its pace (e.g., Kafka, SQS poll) | Natural backpressure, simple scaling | Polling overhead, latency |
| Long Polling | Consumer holds connection until data ready | Reduces empty polls | Connection management cost |