7a:T40e,**Synchronous communication** is the model most programmers understand intuitively because it mirrors traditional function calls. Service A sends a request to Service B and **waits** for a response before continuing execution. This blocking behavior defines the synchronous paradigm. ### The Mechanics of Synchronous Calls When Service A makes a synchronous call to Service B: 1. **Request Initiation**: Service A opens a network connection and sends a request (typically HTTP/HTTPS or gRPC) 2. **Blocking Wait**: Service A's thread blocks, waiting for Service B to respond 3. **Processing**: Service B receives the request, processes it, and computes a response 4. **Response Return**: Service B sends the response back over the same connection 5. **Continuation**: Service A receives the response and continues its execution During step 2, Service A is consuming resources (thread, memory, connection) while doing no productive work. This is the core characteristic of synchronous communication—and both its strength and weakness.7b:T674,// Synchronous call with timeout and retry interface OrderService { createOrder(userId: string, items: CartItem[]): Promise; } class PaymentService { private readonly orderClient: OrderService; private readonly timeout: number = 5000; // 5 second timeout private readonly maxRetries: number = 3; async processPayment(paymentRequest: PaymentRequest): Promise { // Synchronous call to Order Service - we BLOCK until response const order = await this.withRetry( () => this.orderClient.createOrder( paymentRequest.userId, paymentRequest.items ), this.maxRetries ); // We cannot proceed until order is confirmed // This is the essence of synchronous communication if (!order.id) { throw new Error('Order creation failed'); } // Continue with payment processing return this.chargeUser(order); } private async withRetry( fn: () => Promise, retries: number ): Promise { for (let attempt = 1; attempt <= retries; attempt++) { try { const controller = new AbortController(); const timeoutId = setTimeout( () => controller.abort(), this.timeout ); try { const result = await fn(); clearTimeout(timeoutId); return result; } finally { clearTimeout(timeoutId); } } catch (error) { if (attempt === retries) throw error; // Exponential backoff: 100ms, 200ms, 400ms... await this.delay(100 * Math.pow(2, attempt - 1)); } } throw new Error('All retries exhausted'); } }7c:T740,// Synchronous call with context timeout and retry type PaymentService struct { orderClient OrderServiceClient timeout time.Duration maxRetries int } func NewPaymentService(client OrderServiceClient) *PaymentService { return &PaymentService{ orderClient: client, timeout: 5 * time.Second, maxRetries: 3, } } func (ps *PaymentService) ProcessPayment( ctx context.Context, req PaymentRequest, ) (*PaymentResult, error) { // Synchronous call - goroutine blocks until response or timeout order, err := ps.callWithRetry(ctx, func(ctx context.Context) (*Order, error) { // Create timeout context for this specific call callCtx, cancel := context.WithTimeout(ctx, ps.timeout) defer cancel() return ps.orderClient.CreateOrder(callCtx, &CreateOrderRequest{ UserId: req.UserId, Items: req.Items, }) }) if err != nil { return nil, fmt.Errorf("order creation failed: %w", err) } // Cannot proceed until order confirmed - synchronous dependency return ps.chargeUser(ctx, order) } func (ps *PaymentService) callWithRetry( ctx context.Context, fn func(context.Context) (*Order, error), ) (*Order, error) { var lastErr error for attempt := 1; attempt <= ps.maxRetries; attempt++ { result, err := fn(ctx) if err == nil { return result, nil } lastErr = err // Don't retry if context is cancelled if ctx.Err() != nil { return nil, ctx.Err() } // Exponential backoff backoff := time.Duration(100*math.Pow(2, float64(attempt-1))) * time.Millisecond time.Sleep(backoff) } return nil, fmt.Errorf("all retries exhausted: %w", lastErr) }7d:T450,**Asynchronous communication** fundamentally changes the interaction model between services. Instead of Service A waiting for Service B's response, Service A sends a message and continues its work. Service B processes the message independently, and any response (if needed) arrives later through a separate channel. ### The Mechanics of Asynchronous Communication When Service A communicates asynchronously with Service B: 1. **Message Production**: Service A publishes a message to a message broker (Kafka, RabbitMQ, SQS, etc.) 2. **Immediate Return**: The publish operation returns quickly—Service A can continue processing 3. **Message Persistence**: The broker stores the message durably, guaranteeing delivery 4. **Independent Consumption**: Service B retrieves and processes the message at its own pace 5. **Optional Response**: If a response is needed, Service B publishes to a separate topic/queue The key insight is **temporal decoupling**—Service A and Service B don't need to be running simultaneously. Service B can be down for maintenance, and messages simply queue until it returns.7e:T557,### Asynchronous Communication Patterns There are several distinct patterns within asynchronous communication: **1. Fire-and-Forget (Commands)** Send a message and assume it will be processed eventually. No response expected. - *Example*: User registration → welcome email sent (eventually) - *Guarantee*: At-least-once delivery - *Risk*: No confirmation of successful processing **2. Publish-Subscribe (Events)** Publish facts about what happened; multiple subscribers independently decide how to react. - *Example*: `OrderPlaced` event → Inventory service decrements stock, Notification service emails customer, Analytics service records sale - *Guarantee*: All interested subscribers receive the event - *Risk*: Subscriber failures don't affect publisher **3. Request-Reply (Async RPC)** Send a request message, then wait for a response on a separate reply queue. - *Example*: Credit check request → response arrives in dedicated response queue - *Guarantee*: Eventual response (with timeout) - *Risk*: Combines complexity of async with blocking semantics **4. Event Sourcing** Store all state changes as an immutable log of events; current state is derived by replaying events. - *Example*: Bank account balance = sum of all transactions - *Guarantee*: Complete audit trail and temporal queries - *Risk*: Increased complexity for simple CRUD operations7f:T442,### Message Broker Semantics The choice and configuration of message broker significantly impacts system behavior: **Delivery Guarantees**: - **At-most-once**: Message might be lost but never duplicated (unreliable but fast) - **At-least-once**: Message guaranteed to arrive but might be duplicated (requires idempotent consumers) - **Exactly-once**: Message delivered exactly once (expensive coordination; often illusory) **Ordering Guarantees**: - **No ordering**: Messages may arrive in any order - **Partition ordering**: Messages in same partition arrive in order (Kafka) - **Global ordering**: All messages arrive in global order (severe scalability impact) **Retention Policies**: - **Transient**: Messages deleted after consumption (RabbitMQ default) - **Time-based**: Messages retained for N days (Kafka) - **Permanent**: Events stored forever (event sourcing) These guarantees have profound implications for application design. At-least-once delivery means every consumer must be idempotent—processing the same message twice must have the same effect as processing it once.80:T98a,// Asynchronous event-driven communication interface EventBus { publish(topic: string, event: DomainEvent): Promise; subscribe(topic: string, handler: EventHandler): void; } interface DomainEvent { eventId: string; // For deduplication eventType: string; // For routing timestamp: Date; // For ordering correlationId: string; // For tracing payload: unknown; } class OrderService { constructor( private readonly eventBus: EventBus, private readonly orderRepository: OrderRepository ) { // Subscribe to payment events this.eventBus.subscribe('payments', this.handlePaymentEvent.bind(this)); } async placeOrder(request: PlaceOrderRequest): Promise<{ orderId: string }> { // Create order in local database const order = await this.orderRepository.create({ userId: request.userId, items: request.items, status: 'PENDING_PAYMENT' }); // Publish event and return IMMEDIATELY // We don't wait for payment to complete await this.eventBus.publish('orders', { eventId: crypto.randomUUID(), eventType: 'OrderPlaced', timestamp: new Date(), correlationId: request.correlationId, payload: { orderId: order.id, userId: request.userId, items: request.items, totalAmount: order.totalAmount } }); // Return immediately - caller doesn't wait for downstream processing return { orderId: order.id }; } // Handle payment completion asynchronously private async handlePaymentEvent(event: DomainEvent): Promise { // Idempotency check - have we processed this event? if (await this.isEventProcessed(event.eventId)) { console.log(`Duplicate event ${event.eventId} - skipping`); return; } if (event.eventType === 'PaymentCompleted') { const { orderId, transactionId } = event.payload as PaymentPayload; await this.orderRepository.update(orderId, { status: 'PAID', paymentTransactionId: transactionId }); // Publish order confirmed event await this.eventBus.publish('orders', { eventId: crypto.randomUUID(), eventType: 'OrderConfirmed', timestamp: new Date(), correlationId: event.correlationId, payload: { orderId, transactionId } }); } // Mark event as processed (idempotency) await this.markEventProcessed(event.eventId); } }81:Tb70,// Asynchronous event-driven communication with Kafka type DomainEvent struct { EventID string `json:"eventId"` EventType string `json:"eventType"` Timestamp time.Time `json:"timestamp"` CorrelationID string `json:"correlationId"` Payload json.RawMessage `json:"payload"` } type OrderService struct { producer *kafka.Producer consumer *kafka.Consumer orderRepo OrderRepository processedDB ProcessedEventsStore // For idempotency } func (os *OrderService) PlaceOrder( ctx context.Context, req PlaceOrderRequest, ) (*PlaceOrderResponse, error) { // Create order in local database order, err := os.orderRepo.Create(ctx, &Order{ UserID: req.UserID, Items: req.Items, Status: OrderStatusPendingPayment, }) if err != nil { return nil, fmt.Errorf("failed to create order: %w", err) } // Prepare event payload, _ := json.Marshal(OrderPlacedPayload{ OrderID: order.ID, UserID: req.UserID, Items: req.Items, TotalAmount: order.TotalAmount, }) event := DomainEvent{ EventID: uuid.NewString(), EventType: "OrderPlaced", Timestamp: time.Now().UTC(), CorrelationID: req.CorrelationID, Payload: payload, } // Publish and return IMMEDIATELY // Kafka producer is async - this returns after message is queued if err := os.publishEvent(ctx, "orders", event); err != nil { // Decide: fail the order or proceed with degraded functionality? log.Printf("Failed to publish event: %v", err) } // Return immediately - no waiting for downstream services return &PlaceOrderResponse{OrderID: order.ID}, nil } // Run as separate goroutine - processes payment events func (os *OrderService) StartPaymentEventConsumer(ctx context.Context) { for { select { case <-ctx.Done(): return default: msg, err := os.consumer.ReadMessage(ctx) if err != nil { continue } var event DomainEvent if err := json.Unmarshal(msg.Value, &event); err != nil { log.Printf("Failed to unmarshal event: %v", err) continue } // Idempotency check processed, _ := os.processedDB.IsProcessed(ctx, event.EventID) if processed { continue } if err := os.handlePaymentEvent(ctx, event); err != nil { log.Printf("Failed to handle event: %v", err) // Don't commit - will retry continue } os.processedDB.MarkProcessed(ctx, event.EventID) os.consumer.CommitMessages(ctx, msg) } } }82:T646,// Circuit Breaker for synchronous calls class CircuitBreaker { private failures = 0; private lastFailure: Date | null = null; private state: 'CLOSED' | 'OPEN' | 'HALF_OPEN' = 'CLOSED'; constructor( private readonly failureThreshold: number = 5, private readonly resetTimeout: number = 30000, // 30 seconds ) {} async execute(fn: () => Promise): Promise { if (this.state === 'OPEN') { if (this.shouldAttemptReset()) { this.state = 'HALF_OPEN'; } else { throw new CircuitOpenError('Circuit breaker is OPEN'); } } try { const result = await fn(); this.onSuccess(); return result; } catch (error) { this.onFailure(); throw error; } } private onSuccess(): void { this.failures = 0; this.state = 'CLOSED'; } private onFailure(): void { this.failures++; this.lastFailure = new Date(); if (this.failures >= this.failureThreshold) { this.state = 'OPEN'; console.warn('Circuit breaker OPENED after', this.failures, 'failures'); } } private shouldAttemptReset(): boolean { if (!this.lastFailure) return true; return Date.now() - this.lastFailure.getTime() >= this.resetTimeout; } } // Usage const inventoryCircuit = new CircuitBreaker(5, 30000); async function checkInventory(productId: string): Promise { return inventoryCircuit.execute(async () => { const response = await fetch(`/api/inventory/${productId}`); if (!response.ok) throw new Error('Inventory service failed'); return response.json(); }); }83:T8d8,// Idempotent consumer for asynchronous processing type IdempotentConsumer struct { processedStore ProcessedEventsStore handler EventHandler } // ProcessedEventsStore tracks which events have been processed type ProcessedEventsStore interface { IsProcessed(ctx context.Context, eventID string) (bool, error) MarkProcessed(ctx context.Context, eventID string) error } func (c *IdempotentConsumer) Handle(ctx context.Context, event DomainEvent) error { // Step 1: Check if already processed (idempotency) processed, err := c.processedStore.IsProcessed(ctx, event.EventID) if err != nil { return fmt.Errorf("failed to check processed status: %w", err) } if processed { log.Printf("Event %s already processed, skipping", event.EventID) return nil // Success - already handled } // Step 2: Process the event if err := c.handler(ctx, event); err != nil { // Don't mark as processed - will retry return fmt.Errorf("handler failed: %w", err) } // Step 3: Mark as processed (should be atomic with step 2 ideally) if err := c.processedStore.MarkProcessed(ctx, event.EventID); err != nil { // Event processed but not marked - will reprocess (must be idempotent!) log.Printf("Failed to mark event %s as processed: %v", event.EventID, err) } return nil } // Dead Letter Queue handling type DeadLetterHandler struct { dlq *kafka.Producer dlqTopic string } func (h *DeadLetterHandler) HandlePoisonMessage( ctx context.Context, msg *kafka.Message, err error, ) { // Send to DLQ for manual investigation dlqMsg := &kafka.Message{ TopicPartition: kafka.TopicPartition{ Topic: &h.dlqTopic, }, Headers: append(msg.Headers, kafka.Header{Key: "error", Value: []byte(err.Error())}, kafka.Header{Key: "original-topic", Value: []byte(*msg.TopicPartition.Topic)}, kafka.Header{Key: "failed-at", Value: []byte(time.Now().Format(time.RFC3339))}, ), Value: msg.Value, } if err := h.dlq.Produce(dlqMsg, nil); err != nil { log.Printf("Failed to send to DLQ: %v", err) // Last resort: log the message } }84:T4a7,Real-world systems rarely use pure synchronous or pure asynchronous communication. Hybrid patterns leverage the strengths of both: ### Pattern 1: Sync for Commands, Async for Events The most common hybrid approach: - User-facing operations use synchronous calls for immediate feedback - State changes publish asynchronous events for downstream consumers - Best of both worlds: responsive UX with decoupled side effects ``` User → [sync] → Order Service → {OrderPlaced event} → [async] → Email Service → {OrderPlaced event} → [async] → Inventory Service → {OrderPlaced event} → [async] → Analytics Service ``` ### Pattern 2: Command Query Responsibility Segregation (CQRS) - Commands (writes) go through a specific service synchronously - Queries (reads) hit read-optimized projections built from async events - Allows independent scaling of read and write paths ### Pattern 3: Saga Pattern for Distributed Transactions - Orchestrator uses sync calls to coordinate multi-service transactions - Each step publishes events for rollback/compensation - Combines transactional guarantees with fault isolation85:T86a,// Hybrid: Synchronous command with asynchronous events class CheckoutService { constructor( private readonly paymentService: PaymentService, // Sync private readonly inventoryService: InventoryService, // Sync private readonly eventBus: EventBus, // Async private readonly orderRepository: OrderRepository ) {} async checkout(cart: Cart): Promise { // PHASE 1: Synchronous validations (user must wait) // These are "queries" - we need answers before proceeding const inventoryCheck = await this.inventoryService.checkAvailability( cart.items ); if (!inventoryCheck.allAvailable) { return { success: false, reason: 'ITEMS_UNAVAILABLE' }; } // PHASE 2: Synchronous command (user must wait for payment) const paymentResult = await this.paymentService.processPayment({ amount: cart.total, customerId: cart.userId, paymentMethod: cart.paymentMethod }); if (!paymentResult.success) { return { success: false, reason: 'PAYMENT_FAILED' }; } // PHASE 3: Create the order (local database) const order = await this.orderRepository.create({ userId: cart.userId, items: cart.items, paymentId: paymentResult.transactionId, status: 'CONFIRMED' }); // PHASE 4: Asynchronous events (user doesn't wait) // Fire-and-forget for downstream systems await Promise.all([ this.eventBus.publish('orders', { eventType: 'OrderConfirmed', eventId: crypto.randomUUID(), correlationId: order.id, timestamp: new Date(), payload: { order, payment: paymentResult } }), // This event goes to: // - Email service (send confirmation) // - Inventory service (decrement stock) // - Shipping service (start fulfillment) // - Analytics service (record sale) // - Loyalty service (award points) ]); // Return immediately - downstream processing happens async return { success: true, orderId: order.id, estimatedDelivery: '3-5 business days' // Fulfillment is async }; } }72:{"json":{"id":"seed_2a588a6221f758c7a81fa8a909292580","slug":"inter-service-communication","category":"System Design (HLD)","topic":"Inter-Service Communication","title":"Inter-Service Communication","description":"Master the art of service-to-service communication in distributed systems. Learn synchronous vs asynchronous patterns, API contract design, protocol selection, cross-service error handling, and versioning strategies that enable teams to evolve microservices independently.","difficulty":"ADVANCED","estimatedMinutes":90,"pages":[{"id":"seed_f4a2b1060dacf321f281d36a64e5bff9","title":"Sync vs Async Communication","order":0,"content":[{"id":"opening-hook","title":"The Foundation of Microservices Communication","content":[{"data":{"content":"In a monolithic application, method calls between components are instant, reliable, and consistent—a function call either succeeds or throws an exception, and the calling code proceeds accordingly. When you decompose that monolith into microservices, those simple method calls transform into **network requests between independent processes**, and everything changes.\n\nThe decision between **synchronous** and **asynchronous** communication is perhaps the most consequential architectural choice you'll make when designing inter-service interactions. This single decision influences your system's latency profile, fault tolerance characteristics, scalability ceiling, operational complexity, and even your team's deployment velocity. Get it wrong, and you'll build a distributed monolith—all the complexity of microservices with none of the benefits."},"type":"text"},{"data":{"icon":"Target","title":"What You Will Master","content":"By the end of this page, you will understand the fundamental mechanics of synchronous and asynchronous communication, their respective strengths and weaknesses, the failure modes unique to each, and how to make principled decisions about when to use which pattern. You'll see how these choices cascade through your entire architecture—affecting everything from database design to team structure.","variant":"info"},"type":"callout"}]},{"id":"synchronous-communication","title":"Synchronous Communication: The Request-Response Model","content":[{"data":{"content":"$7a"},"type":"text"},{"data":{"icon":"Lightbulb","title":"The Real Cost of Blocking","content":"In a high-concurrency environment, blocked threads become a critical constraint. If Service A has a thread pool of 200 threads, and each synchronous call to Service B takes 100ms, Service A can only handle 2,000 requests per second to Service B—regardless of its own processing capacity. This 'thread pool exhaustion' pattern is one of the most common production failures in synchronous microservices.","variant":"tip"},"type":"callout"},{"data":{"content":"### Common Synchronous Protocols\n\nThe two dominant protocols for synchronous inter-service communication are:\n\n**HTTP/REST**: The ubiquitous choice, using standard HTTP verbs (GET, POST, PUT, DELETE) with JSON payloads. REST is human-readable, universally supported, and requires no special tooling. However, HTTP/1.1 is relatively inefficient due to connection overhead, and HTTP/2 support varies across infrastructure components.\n\n**gRPC**: Google's high-performance RPC framework using Protocol Buffers for serialization and HTTP/2 for transport. gRPC offers:\n- Binary serialization (3-10x faster than JSON)\n- Bidirectional streaming\n- Built-in code generation for type-safe clients\n- Multiplexed connections reducing connection overhead\n\nBoth protocols share the fundamental blocking characteristic of synchronous communication."},"type":"text"},{"data":{"rows":[["Simplicity","Easy to reason about; familiar programming model","Blocking model limits concurrency"],["Consistency","Immediate feedback; response confirms operation","Tight temporal coupling between services"],["Debugging","Stack traces span request lifecycle","Distributed tracing required for full picture"],["Data Freshness","Always get current data from source","No caching benefits; repeated queries"],["Error Handling","Immediate error notification to caller","Caller must handle all downstream failures"]],"caption":"Synchronous Communication Trade-offs","headers":["Aspect","Advantage","Disadvantage"]},"type":"table"},{"data":{"content":"### The Cascade Failure Problem\n\nSynchronous communication creates **temporal coupling**—Service A depends on Service B being available *right now*. This coupling compounds across call chains:\n\n- If A → B → C → D, then A's availability depends on B, C, and D all being up\n- If each service has 99.9% availability, the chain has 99.9%^4 = 99.6% availability\n- That's 3.5x more downtime than any individual service\n\nThis multiplicative effect is why synchronous microservices often exhibit worse availability than the monoliths they replaced—a phenomenon known as **distributed fragility**."},"type":"text"},{"data":{"fileName":"sync-communication-example","languages":[{"code":"$7b","label":"TypeScript","value":"typescript"},{"code":"$7c","label":"Go","value":"go"}]},"type":"code"}],"titleType":"number","titleNumber":1},{"id":"asynchronous-communication","title":"Asynchronous Communication: The Event-Driven Model","content":[{"data":{"content":"$7d"},"type":"text"},{"data":{"icon":"Info","title":"The Mindset Shift","content":"Asynchronous communication requires a fundamental shift in how you think about operations. Instead of 'call this function and get a result,' you think in terms of 'publish this fact and trust that interested parties will react.' This shift from imperative commands to declarative events is the conceptual foundation of event-driven architecture.","variant":"note"},"type":"callout"},{"data":{"content":"$7e"},"type":"text"},{"data":{"rows":[["Availability","Services operate independently; no cascade failures","Need message broker infrastructure (another component to fail)"],["Scalability","Natural load leveling; spikes absorbed by queues","Queue depth monitoring required; backpressure handling complex"],["Decoupling","Services evolve independently; loose coupling","Eventual consistency; hard to reason about system state"],["Debugging","Events provide audit trail","Distributed debugging is complex; correlation IDs essential"],["Latency","Producer returns immediately","End-to-end latency unpredictable; depends on queue depth"]],"caption":"Asynchronous Communication Trade-offs","headers":["Aspect","Advantage","Disadvantage"]},"type":"table"},{"data":{"content":"$7f"},"type":"text"},{"data":{"fileName":"async-communication-example","languages":[{"code":"$80","label":"TypeScript","value":"typescript"},{"code":"$81","label":"Go","value":"go"}]},"type":"code"}],"titleType":"number","titleNumber":2},{"id":"comparing-models","title":"Direct Comparison: When to Use Each Model","content":[{"data":{"content":"The choice between synchronous and asynchronous communication isn't binary—most systems use both patterns for different interactions. The art lies in recognizing which pattern fits each use case.\n\n### Decision Framework\n\nAsk these questions to guide your decision:"},"type":"text"},{"data":{"items":["**Does the caller need an immediate response to proceed?** If yes → synchronous. If no → asynchronous.","**What's the acceptable latency?** Sub-100ms requirements → synchronous. Seconds or minutes acceptable → asynchronous.","**What happens if the downstream service is slow or unavailable?** If operation must fail → synchronous. If operation can queue → asynchronous.","**Is the operation idempotent?** Async requires idempotent consumers for at-least-once delivery.","**Are there multiple consumers of this information?** Fan-out patterns favor pub-sub (async).","**Is strong consistency required?** Synchronous provides immediate confirmation; async means eventual consistency."],"title":{"icon":"Target","text":"Pattern Selection Criteria","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"left":[{"data":{"items":["User is waiting for immediate feedback (UI response)","Operation requires immediate consistency","Workflow cannot proceed without downstream response","Transaction semantics are required","Simple request-response fits the domain","Downstream service latency is predictably low","Failure should immediately abort the operation"],"title":{"icon":"CheckCircle","text":"Use Synchronous When","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"}],"right":[{"data":{"items":["Background processing is acceptable","Multiple services need to react to the same event","Load leveling is needed to handle traffic spikes","Services should evolve independently","Downstream processing time is unpredictable","Fault isolation is critical","Audit trail of all state changes is required"],"title":{"icon":"CheckCircle","text":"Use Asynchronous When","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"}]},"type":"two-column"},{"data":{"content":"### Real-World Examples\n\nConsider an e-commerce platform:\n\n**Synchronous Operations:**\n- Checking inventory availability (user expects immediate answer)\n- Authenticating user credentials (can't proceed without result)\n- Calculating shipping costs (needed before checkout completion)\n- Processing payment (must confirm before fulfillment)\n\n**Asynchronous Operations:**\n- Sending order confirmation email (user doesn't wait for it)\n- Updating search indices (eventual consistency acceptable)\n- Generating analytics events (decoupled from user flow)\n- Notifying warehouse for fulfillment (minutes delay acceptable)\n- Sending to recommendation engine (completely decoupled)"},"type":"text"},{"data":{"icon":"AlertCircle","title":"The Hybrid Reality","content":"Most production systems use both patterns. A single user operation might use synchronous calls for the critical path (payment processing) while firing asynchronous events for side effects (notifications, analytics). The key is consciously choosing which interactions require immediate consistency and which can be eventually consistent.","variant":"warning"},"type":"callout"}],"titleType":"number","titleNumber":3},{"id":"failure-modes","title":"Failure Modes and Resilience Patterns","content":[{"data":{"content":"Both communication models have distinct failure modes. Understanding these is essential for building resilient systems.\n\n### Synchronous Failure Modes\n\n**Timeout Failures**\nWhen downstream services don't respond in time:\n- Connection timeout (couldn't establish connection)\n- Read timeout (connection established but response too slow)\n- Both result in uncertainty: did the operation succeed?\n\n**Circuit Breaker Triggers**\nWhen error rates exceed thresholds:\n- System stops calling failing service\n- Fast-fail prevents cascade\n- But legitimate requests are rejected\n\n**Thread Pool Exhaustion**\nWhen all threads are blocked waiting:\n- Service can't accept new requests\n- Appears \"hung\" even though healthy\n- One slow downstream brings down upstream"},"type":"text"},{"data":{"content":"### Asynchronous Failure Modes\n\n**Broker Unavailability**\nMessage broker itself fails:\n- Producers can't publish\n- Need local buffering or fail operations\n- Recovery requires special handling (replay, deduplication)\n\n**Consumer Lag**\nConsumers can't keep up with production:\n- Queue depth grows unbounded\n- Processing latency increases unpredictably\n- Old messages may become stale/irrelevant\n\n**Poison Messages**\nMessages that always fail processing:\n- Consumer crashes repeatedly\n- Dead letter queues fill up\n- Manual intervention required\n\n**Out-of-Order Processing**\nMessages processed in wrong order:\n- Update before create\n- Delete before update\n- Requires careful event design or ordering guarantees"},"type":"text"},{"data":{"rows":[["Circuit Breaker","Essential - prevents cascade failures","Less critical - broker provides isolation"],["Retry with Backoff","Essential - handle transient failures","Often built into broker; consumer retry policies"],["Timeout Management","Explicit timeouts on every call","Consumer processing timeouts; visibility timeouts"],["Bulkhead","Thread pool isolation per downstream","Consumer concurrency limits per topic"],["Idempotency","Nice to have for retries","Absolutely essential (at-least-once)"],["Dead Letter Handling","N/A","Critical - handle unprocessable messages"],["Rate Limiting","Client-side throttling","Broker handles backpressure naturally"]],"caption":"Resilience Patterns by Communication Model","headers":["Pattern","Synchronous","Asynchronous"]},"type":"table"},{"data":{"fileName":"resilience-patterns","languages":[{"code":"$82","label":"TypeScript","value":"typescript"},{"code":"$83","label":"Go","value":"go"}]},"type":"code"}],"titleType":"number","titleNumber":4},{"id":"architectural-implications","title":"Architectural Implications and System Design","content":[{"data":{"content":"The choice of communication model has far-reaching implications beyond the immediate service interaction. It shapes your entire system architecture."},"type":"text"},{"data":{"items":["**Synchronous**: Can rely on distributed transactions (with performance cost). Foreign keys across service boundaries impossible but joins can be done with multiple calls.","**Asynchronous**: Must embrace eventual consistency. Data duplication often necessary. Events become source of truth. CQRS patterns emerge naturally."],"title":{"icon":"Target","text":"Database Design Implications","type":"icon","color":"primary","variant":"outline-circle"},"variant":"glass"},"type":"list"},{"data":{"items":["**Synchronous**: Deployment order matters. Breaking API changes require coordinated deployments or careful versioning.","**Asynchronous**: Services deploy independently. Event schema evolution requires backward compatibility but temporal decoupling provides flexibility."],"title":{"icon":"Target","text":"Deployment Implications","type":"icon","color":"primary","variant":"outline-circle"},"variant":"glass"},"type":"list"},{"data":{"items":["**Synchronous**: Integration tests can verify end-to-end behavior. Contract testing validates API compatibility.","**Asynchronous**: Testing requires simulating eventual consistency. Must test idempotency. Event replay testing essential."],"title":{"icon":"Target","text":"Testing Implications","type":"icon","color":"primary","variant":"outline-circle"},"variant":"glass"},"type":"list"},{"data":{"items":["**Synchronous**: Request latency is the primary metric. Error rates directly observable. Distributed tracing shows request path.","**Asynchronous**: Queue depth and consumer lag are primary metrics. End-to-end latency hard to measure. Correlation IDs essential for tracing."],"title":{"icon":"Target","text":"Monitoring Implications","type":"icon","color":"primary","variant":"outline-circle"},"variant":"glass"},"type":"list"},{"data":{"icon":"Lightbulb","title":"Team Structure Impact","content":"Conway's Law applies here too. Synchronous services require teams to coordinate frequently—API changes need alignment. Asynchronous services allow teams to work more independently—as long as event schemas are stable. This has profound implications for organizational design.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":5},{"id":"hybrid-patterns","title":"Hybrid Patterns: Combining Both Models","content":[{"data":{"content":"$84"},"type":"text"},{"data":{"fileName":"hybrid-pattern-example","languages":[{"code":"$85","label":"TypeScript","value":"typescript"}]},"type":"code"},{"data":{"icon":"Info","title":"The Sync-Async Boundary","content":"The boundary between synchronous and asynchronous should align with the boundary between what the user cares about immediately and what can happen in the background. Users care that payment succeeded; they don't need to wait for the confirmation email to be sent.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":6},{"id":"summary","title":"Summary: Making the Right Choice","content":[{"data":{"content":"The choice between synchronous and asynchronous communication is one of the most impactful decisions in microservices architecture. Let's consolidate the key insights:"},"type":"text"},{"data":{"type":"ordered","items":["**Synchronous communication** provides immediate consistency and simple mental models, but creates temporal coupling that can cascade failures across services.","**Asynchronous communication** provides fault isolation and natural load leveling, but requires embracing eventual consistency and designing idempotent consumers.","**Neither pattern is universally better**—the right choice depends on latency requirements, consistency needs, and acceptable failure modes.","**Hybrid patterns** are the norm—use synchronous for the critical user-facing path and asynchronous for decoupled side effects.","**Failure modes differ fundamentally**—synchronous fails fast but cascades; asynchronous absorbs failures but delays detection.","**The choice shapes everything**—from database design to deployment strategy to team structure. Choose deliberately."],"title":{"icon":"CheckCircle","text":"Key Takeaways","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"**What's next:**\n\nNow that we understand the fundamental communication models, we'll explore how to define and maintain the contracts between services. API contracts ensure that services can evolve independently while maintaining compatibility—the foundation of true microservices independence."},"type":"text"},{"data":{"icon":"CheckCircle","title":"Page Complete","content":"You now understand the fundamental choice between synchronous and asynchronous inter-service communication. You can analyze when each pattern is appropriate, understand their failure modes, and recognize how to combine them effectively. Next, we'll dive into API contract design—ensuring services can communicate reliably across versions and teams.","variant":"success"},"type":"callout"}],"titleType":"number","titleNumber":7}],"isLocked":false},{"id":"seed_d7c8748d12c4470cb952c6e242ef025e","title":"API Contracts","order":1,"content":null,"isLocked":true},{"id":"seed_fab6afd22117c6eaecafad05f4c5e127","title":"Protocol Selection","order":2,"content":null,"isLocked":true},{"id":"seed_8e884de6445a5e22ee1ad0b7d3a3843f","title":"Error Handling Across Services","order":3,"content":null,"isLocked":true},{"id":"seed_30a4b07fa0c226979573aee63f1e938d","title":"Service Versioning","order":4,"content":null,"isLocked":true}]}}