Service Communication

Synchronous Communication

Synchronous communication blocks the caller until the response is received.

Characteristics

Synchronous Flow:

Client → Request → Server
Client ← Response ← Server
       (blocks until response)

- Immediate response
- Tight coupling
- Simple to implement
- Latency = client latency

HTTP/REST

import requests

# Synchronous HTTP call
def get_user(user_id):
    response = requests.get(f'http://api/users/{user_id}')
    return response.json()  # Blocks until response

# Timeouts
response = requests.get(url, timeout=5)  # 5 second timeout

gRPC

import grpc

# Synchronous gRPC call
channel = grpc.insecure_channel('api:50051')
stub = UserServiceStub(channel)

# Blocks until response
user = stub.GetUser(GetUserRequest(id='123'))

When to Use

Use Case	Why Sync
User queries	Need immediate response
CRUD operations	Simple request-response
Real-time data	Fresh data required
Low latency needs	No async overhead

Downsides

• Blocks caller
• Cascading failures
• Timeout propagation
• No buffering

Asynchronous Communication

Asynchronous communication doesn't block the caller; response comes later.

Characteristics

Asynchronous Flow:

Client → Message → Queue → Server
Client ← Ack ← Queue
        (continues immediately)
        Server processes later

- Non-blocking
- Decoupled
- Buffered
- Eventual response

Message Queues

# Async with message queue
def create_order(order_data):
    # Send to queue, don't wait
    queue.send({
        'type': 'order.created',
        'data': order_data
    })
    
    # Return immediately
    return {'status': 'processing'}

# Worker processes later
def process_order_worker():
    while True:
        message = queue.receive()
        process_order(message['data'])

Event-Driven

# Event-based async
class EventBus:
    def __init__(self):
        self.subscribers = {}
    
    def publish(self, event_type, data):
        for subscriber in self.subscribers.get(event_type, []):
            subscriber(data)  # Async notification
    
    def subscribe(self, event_type, handler):
        if event_type not in self.subscribers:
            self.subscribers[event_type] = []
        self.subscribers[event_type].append(handler)

When to Use

Use Case	Why Async
Long processing	Don't block user
Fire-and-forget	No response needed
Event broadcasting	Multiple consumers
High throughput	Buffer bursts

Benefits

• Non-blocking
• Decoupled services
• Buffering
• Fault tolerance

Protocol Choices

Protocol Comparison

Protocol Options:

1. HTTP/REST:
   - Simple, widely supported
   - Text-based (JSON)
   - Stateless
   - Good for CRUD

2. gRPC:
   - Binary (Protocol Buffers)
   - HTTP/2 based
   - Streaming support
   - Strong typing

3. GraphQL:
   - Query language
   - Client specifies data
   - Single endpoint
   - Flexible

4. WebSocket:
   - Full-duplex
   - Real-time
   - Persistent connection
   - Low latency

5. Message Queue:
   - Async
   - Decoupled
   - Buffered
   - Reliable

Decision Matrix

Factor	HTTP/REST	gRPC	GraphQL	WebSocket	MQ
Complexity	Low	Medium	Medium	Medium	High
Performance	Medium	High	Medium	High	High
Real-time	No	Yes	No	Yes	Yes
Type safety	No	Yes	Yes	No	No
Streaming	No	Yes	Yes	Yes	Yes

When to Use Each

Use Case	Protocol
Simple CRUD	REST
Internal services	gRPC
Flexible queries	GraphQL
Real-time updates	WebSocket
Async processing	Message Queue
High throughput	gRPC or MQ

Protocol Selection

def choose_protocol(requirements):
    if requirements['simple_crud']:
        return 'REST'
    if requirements['internal_communication']:
        return 'gRPC'
    if requirements['flexible_queries']:
        return 'GraphQL'
    if requirements['real_time']:
        return 'WebSocket'
    if requirements['async_processing']:
        return 'Message Queue'
    return 'REST'  # Default