6a:T4e0,**Synchronous communication** is a communication paradigm in which the sender of a message waits for a response from the receiver before continuing execution. The term "synchronous" derives from the Greek *syn-* (together) and *chronos* (time)—the sender and receiver are temporarily coupled, operating in lockstep during the communication. **Formal Definition:** In the context of distributed systems, synchronous communication can be defined as follows: > A communication pattern is **synchronous** if the sender blocks (or logically waits) until the operation completes and a response is received (or a timeout occurs). This definition has several important implications: 1. **Temporal Coupling**: The sender cannot proceed with subsequent operations until the current communication completes. This creates a direct dependency chain. 2. **Request-Response Semantics**: Synchronous communication typically follows a request-response pattern where the sender initiates, the receiver processes, and control returns to the sender only after a response is available. 3. **Failure Propagation**: If the receiver fails, the sender is immediately impacted. The failure cannot be deferred or handled asynchronously without additional mechanisms.6b:T523,The **request-response pattern** is the archetypal synchronous communication pattern. It consists of four distinct phases: **Phase 1: Request Preparation** The client (sender) prepares a request message. This includes: - Constructing the message payload (headers, body) - Serializing data according to the protocol (JSON, Protocol Buffers, etc.) - Establishing or reusing a connection to the server - Setting request metadata (timeout, authentication tokens, tracing headers) **Phase 2: Request Transmission** The request is transmitted over the network: - Data is written to the socket - The network stack handles packetization and routing - The request traverses the physical network infrastructure - Load balancers or proxies may intercept and forward the request **Phase 3: Server Processing** The server (receiver) processes the request: - Connection acceptance and request parsing - Request routing to the appropriate handler - Business logic execution (may involve further downstream calls) - Response construction and serialization **Phase 4: Response Transmission and Client Reception** The response travels back to the client: - Server writes response to the socket - Network transports the response - Client receives and deserializes the response - Client resumes execution with the response data6c:Tbe5,// Illustrating the request-response lifecycle programmatically interface RequestContext { requestId: string; timestamp: Date; timeout: number; // milliseconds metadata: Record; } interface Response { data: T; status: number; latencyMs: number; headers: Record; } interface RequestLifecycleMetrics { connectionTime: number; // Time to establish/acquire connection requestSerializeTime: number; networkLatency: number; // Time in network transit (both directions) serverProcessingTime: number; responseDeserializeTime: number; totalTime: number; // End-to-end latency } class SynchronousClient { private connectionPool: ConnectionPool; private serializer: Serializer; private timeout: number; async executeRequest( endpoint: string, payload: unknown, context: RequestContext ): Promise<{ response: Response; metrics: RequestLifecycleMetrics }> { const startTime = performance.now(); const metrics: Partial = {}; // Phase 1: Request Preparation const connStart = performance.now(); const connection = await this.connectionPool.acquire(endpoint); metrics.connectionTime = performance.now() - connStart; const serializeStart = performance.now(); const serializedPayload = this.serializer.serialize(payload); metrics.requestSerializeTime = performance.now() - serializeStart; // Phase 2 & 3: Transmission + Server Processing // From client perspective, these are observed as network latency const networkStart = performance.now(); const responsePromise = connection.send(serializedPayload, { timeout: context.timeout, headers: { 'X-Request-ID': context.requestId, 'X-Timestamp': context.timestamp.toISOString(), ...context.metadata, }, }); // THIS IS WHERE SYNCHRONOUS WAITING HAPPENS // The await semantically blocks until response arrives const rawResponse = await responsePromise; metrics.networkLatency = performance.now() - networkStart; metrics.serverProcessingTime = rawResponse.serverTiming?.processingMs ?? 0; // Phase 4: Response Processing const deserializeStart = performance.now(); const data = this.serializer.deserialize(rawResponse.body); metrics.responseDeserializeTime = performance.now() - deserializeStart; metrics.totalTime = performance.now() - startTime; // Return connection to pool this.connectionPool.release(connection); return { response: { data, status: rawResponse.status, latencyMs: metrics.totalTime, headers: rawResponse.headers, }, metrics: metrics as RequestLifecycleMetrics, }; } }6d:Td15,package synchronous import ( "context" "encoding/json" "fmt" "net/http" "time" ) // RequestContext holds metadata for request tracking type RequestContext struct { RequestID string Timestamp time.Time Timeout time.Duration Metadata map[string]string } // Response represents a typed response type Response[T any] struct { Data T Status int LatencyMs float64 Headers http.Header } // RequestLifecycleMetrics captures timing breakdown type RequestLifecycleMetrics struct { ConnectionTime time.Duration RequestSerializeTime time.Duration NetworkLatency time.Duration ServerProcessingTime time.Duration ResponseDeserializeTime time.Duration TotalTime time.Duration } // SynchronousClient demonstrates request-response lifecycle type SynchronousClient struct { httpClient *http.Client baseURL string } // ExecuteRequest performs a synchronous request-response cycle func (c *SynchronousClient) ExecuteRequest( ctx context.Context, endpoint string, payload interface{}, reqCtx RequestContext, ) (*Response[map[string]interface{}], *RequestLifecycleMetrics, error) { startTime := time.Now() metrics := &RequestLifecycleMetrics{} // Phase 1: Request Preparation serializeStart := time.Now() body, err := json.Marshal(payload) if err != nil { return nil, nil, fmt.Errorf("serialize: %w", err) } metrics.RequestSerializeTime = time.Since(serializeStart) // Create request with timeout context timeoutCtx, cancel := context.WithTimeout(ctx, reqCtx.Timeout) defer cancel() req, err := http.NewRequestWithContext( timeoutCtx, "POST", c.baseURL+endpoint, bytes.NewReader(body), ) if err != nil { return nil, nil, fmt.Errorf("create request: %w", err) } // Set tracking headers req.Header.Set("X-Request-ID", reqCtx.RequestID) req.Header.Set("X-Timestamp", reqCtx.Timestamp.Format(time.RFC3339)) for k, v := range reqCtx.Metadata { req.Header.Set(k, v) } // Phase 2 & 3: Transmission + Server Processing // This is where SYNCHRONOUS BLOCKING occurs in Go networkStart := time.Now() resp, err := c.httpClient.Do(req) // Blocks until response if err != nil { return nil, nil, fmt.Errorf("request failed: %w", err) } defer resp.Body.Close() metrics.NetworkLatency = time.Since(networkStart) // Extract server processing time if available if serverTiming := resp.Header.Get("Server-Timing"); serverTiming != "" { // Parse Server-Timing header for processing time metrics.ServerProcessingTime = parseServerTiming(serverTiming) } // Phase 4: Response Processing deserializeStart := time.Now() var data map[string]interface{} if err := json.NewDecoder(resp.Body).Decode(&data); err != nil { return nil, nil, fmt.Errorf("deserialize: %w", err) } metrics.ResponseDeserializeTime = time.Since(deserializeStart) metrics.TotalTime = time.Since(startTime) return &Response[map[string]interface{}]{ Data: data, Status: resp.StatusCode, LatencyMs: float64(metrics.TotalTime.Milliseconds()), Headers: resp.Header, }, metrics, nil }6e:T520,**Temporal coupling** is the defining characteristic of synchronous communication. When Service A makes a synchronous call to Service B, both services are bound together in time—A cannot proceed until B responds. This coupling has profound implications for system design. **The Chain of Dependency:** Consider a typical e-commerce checkout flow: ``` Client → API Gateway → Order Service → Inventory Service → Payment Service → Notification Service ``` If each arrow represents a synchronous call, the total latency experienced by the client is: ``` T_total = T_gateway + T_order + T_inventory + T_payment + T_notification + Network_overhead ``` This is known as **latency accumulation**. Each synchronous hop adds to the overall response time, creating a system where end-to-end latency is at least the sum of all individual service latencies. **The Availability Multiplication Problem:** Temporal coupling also impacts availability. If each service in our chain has 99.9% availability, the system availability for the complete checkout path is: ``` A_total = 0.999 × 0.999 × 0.999 × 0.999 × 0.999 = 0.995 (99.5%) ``` With five services at "three nines," we achieve only "two and a half nines" for the end-to-end flow. Adding more synchronous dependencies further degrades availability.6f:T439,**Mitigating Temporal Coupling:** While synchronous communication inherently creates temporal coupling, several strategies can mitigate its impact: 1. **Parallelization**: When dependencies are independent, make concurrent requests rather than sequential ones. If inventory check and fraud check are independent, execute them in parallel. 2. **Timeout Discipline**: Strict timeouts prevent a slow downstream service from blocking the caller indefinitely. Better to fail fast with a clear error than to hang. 3. **Circuit Breakers**: When a downstream service is unhealthy, stop calling it temporarily to prevent cascade failures and allow it to recover. 4. **Caching**: Cache responses from downstream services when appropriate to reduce the number of synchronous calls. 5. **Async Boundaries**: Identify operations that don't require immediate response and move them to asynchronous patterns (covered in later chapters). 6. **Service Consolidation**: Sometimes the answer to excessive synchronous hops is to consolidate services, reducing the number of network round-trips.70:Td25,// Demonstrating parallelization to reduce accumulated latency interface CheckoutDependencies { inventoryResult: InventoryCheckResult; fraudResult: FraudCheckResult; pricingResult: PricingResult; } async function processCheckoutSynchronous(order: Order): Promise { // SEQUENTIAL APPROACH (BAD) // Total time = T_inventory + T_fraud + T_pricing // If each takes 100ms, total = 300ms const inventoryResult = await inventoryService.check(order.items); const fraudResult = await fraudService.check(order.customer, order.paymentMethod); const pricingResult = await pricingService.calculate(order.items, order.customer); return { inventoryResult, fraudResult, pricingResult }; } async function processCheckoutParallel(order: Order): Promise { // PARALLEL APPROACH (BETTER) // Total time = max(T_inventory, T_fraud, T_pricing) // If each takes 100ms, total = ~100ms const [inventoryResult, fraudResult, pricingResult] = await Promise.all([ inventoryService.check(order.items), fraudService.check(order.customer, order.paymentMethod), pricingService.calculate(order.items, order.customer), ]); return { inventoryResult, fraudResult, pricingResult }; } async function processCheckoutParallelWithTimeout( order: Order, timeout: number = 500 ): Promise { // PARALLEL WITH TIMEOUT (PRODUCTION-READY) // Fails fast if any dependency exceeds timeout const timeoutPromise = new Promise((_, reject) => setTimeout(() => reject(new TimeoutError('Checkout dependencies timeout')), timeout) ); const dependenciesPromise = Promise.all([ inventoryService.check(order.items), fraudService.check(order.customer, order.paymentMethod), pricingService.calculate(order.items, order.customer), ]); const [inventoryResult, fraudResult, pricingResult] = await Promise.race([ dependenciesPromise, timeoutPromise.then(() => { throw new TimeoutError(); }), ]) as [InventoryCheckResult, FraudCheckResult, PricingResult]; return { inventoryResult, fraudResult, pricingResult }; } // Even better: Use Promise.allSettled for partial success handling async function processCheckoutResilient(order: Order): Promise { const results = await Promise.allSettled([ inventoryService.check(order.items), fraudService.check(order.customer, order.paymentMethod), pricingService.calculate(order.items, order.customer), ]); const [inventoryResult, fraudResult, pricingResult] = results; // Inventory is required - fail if it failed if (inventoryResult.status === 'rejected') { throw new CheckoutError('Inventory check failed', inventoryResult.reason); } // Fraud check is required - fail if it failed if (fraudResult.status === 'rejected') { throw new CheckoutError('Fraud check failed', fraudResult.reason); } // Pricing can fall back to cached prices const pricing = pricingResult.status === 'fulfilled' ? pricingResult.value : await getCachedPricing(order.items); return { inventory: inventoryResult.value, fraud: fraudResult.value, pricing, }; }71:T6a9,A critical distinction in understanding synchronous communication is the difference between **blocking I/O** and **non-blocking I/O**. While synchronous communication semantics require waiting for a response, *how* the waiting happens at the system level varies significantly. **Blocking I/O (Synchronous at Thread Level):** In blocking I/O, the calling thread is suspended by the operating system until the I/O operation completes. The thread cannot do any other work during this time. ``` Thread 1: [Make Request] → [BLOCKED - waiting] → [Process Response] ^ | Thread suspended by OS Cannot do other work ``` This model is simple to reason about—one thread handles one request at a time. However, it's resource-intensive because: - Each concurrent request requires its own thread - Threads consume memory (typically 1-8 MB stack per thread) - Thread context switching has CPU overhead - Thread creation/destruction is expensive **Non-Blocking I/O (Asynchronous at Thread Level):** In non-blocking I/O, the calling thread initiates the I/O operation and immediately returns, registering a callback or returning a future/promise. The thread is free to handle other work until the I/O completes. ``` Thread 1: [Make Request A] → [Make Request B] → [Make Request C] → [Event Loop] ↓ ↓ ↓ ↓ [pending A] [pending B] [pending C] [Handle completed I/O] ``` This model allows a small number of threads to handle many concurrent requests, dramatically improving resource efficiency.72:T60b,// Traditional blocking I/O in Java public class BlockingHttpClient { public String makeRequest(String url) throws IOException { // Thread blocks here until response is received // No other work can happen on this thread HttpURLConnection conn = (HttpURLConnection) new URL(url).openConnection(); conn.setRequestMethod("GET"); // BLOCKING: Thread suspended during network read BufferedReader reader = new BufferedReader( new InputStreamReader(conn.getInputStream()) ); StringBuilder response = new StringBuilder(); String line; // BLOCKING: Each readline blocks until data available while ((line = reader.readLine()) != null) { response.append(line); } return response.toString(); } // To handle multiple requests concurrently, you need multiple threads public List fetchAllBlocking(List urls) throws Exception { ExecutorService executor = Executors.newFixedThreadPool(10); List> futures = urls.stream() .map(url -> executor.submit(() -> makeRequest(url))) .collect(Collectors.toList()); // Each request consumes a thread from the pool return futures.stream() .map(f -> { try { return f.get(); } catch (Exception e) { throw new RuntimeException(e); } }) .collect(Collectors.toList()); } }73:T78b,// Non-blocking I/O with async/await in Node.js import { performance } from 'perf_hooks'; async function makeRequest(url: string): Promise { // Thread is NOT blocked during fetch // The event loop can handle other work while waiting const response = await fetch(url); // Thread is NOT blocked during text parsing const text = await response.text(); return text; } // Single thread handles ALL requests concurrently async function fetchAllNonBlocking(urls: string[]): Promise { // All requests initiated immediately, no thread blocking // Event loop handles I/O completion callbacks const results = await Promise.all( urls.map(url => makeRequest(url)) ); return results; } // Demonstration of non-blocking nature async function demonstrateEventLoop() { console.log('1. Starting requests'); // Start slow request (doesn't block) const slowPromise = fetch('https://httpbin.org/delay/5'); // These execute IMMEDIATELY, don't wait for slow request console.log('2. Slow request initiated, thread not blocked'); console.log('3. Can do other work...'); // Do other work while slow request is pending for (let i = 0; i < 1000000; i++) { // CPU-bound work on same thread } console.log('4. CPU work completed'); // Only now wait for the slow request const result = await slowPromise; console.log('5. Slow request completed'); } // Resource comparison function compareResourceUsage() { // Blocking model (Java-style): // 10,000 concurrent requests = 10,000 threads // Memory: 10,000 × 2MB stack = 20GB // CPU: Significant context switching overhead // Non-blocking model (Node.js): // 10,000 concurrent requests = 1 thread (+ worker pool) // Memory: ~58KB per connection (mostly buffers) // CPU: Minimal overhead, no context switching }74:T6b7,package main import ( "fmt" "io" "net/http" "sync" "time" ) // Go's goroutines provide the best of both worlds: // - Simple, sequential code (like blocking) // - Efficient runtime scheduling (like non-blocking) func makeRequest(url string) (string, error) { // This looks like blocking code... resp, err := http.Get(url) if err != nil { return "", err } defer resp.Body.Close() // ...but goroutines are multiplexed onto OS threads // The Go runtime suspends this goroutine during I/O // and schedules other goroutines on the same thread body, err := io.ReadAll(resp.Body) return string(body), err } func fetchAllConcurrent(urls []string) []string { results := make([]string, len(urls)) var wg sync.WaitGroup for i, url := range urls { wg.Add(1) go func(idx int, u string) { defer wg.Done() // Each goroutine is ~2-8KB (vs 1-2MB for OS thread) // 100,000 goroutines use only ~800MB result, _ := makeRequest(u) results[idx] = result }(i, url) } wg.Wait() return results } // Goroutine resource efficiency func goroutineScaling() { // Can easily run 100,000+ goroutines // All multiplexed onto small number of OS threads (GOMAXPROCS) start := time.Now() var wg sync.WaitGroup for i := 0; i < 100000; i++ { wg.Add(1) go func(id int) { defer wg.Done() // Simulate work time.Sleep(1 * time.Millisecond) }(i) } wg.Wait() fmt.Printf("100K goroutines completed in %v ", time.Since(start)) // Output: ~1-2 seconds (not 100 seconds!) }75:T6f2,Synchronous communication manifests in several practical models, each with distinct characteristics suited to different use cases. **1. HTTP Request-Response (REST)** The most common form of synchronous communication in web services. A client sends an HTTP request and blocks (logically) until receiving an HTTP response. - **Transport**: HTTP/1.1, HTTP/2, or HTTP/3 over TCP or QUIC - **Serialization**: JSON, XML, or binary formats - **Semantics**: Stateless, cacheable, uniform interface - **Use Cases**: Web APIs, microservices, mobile backends **2. Remote Procedure Call (RPC)** RPC abstracts remote communication to look like local function calls. The caller invokes a method, and the RPC framework handles serialization, transport, and deserialization. - **Protocols**: gRPC (HTTP/2 + Protocol Buffers), Thrift, JSON-RPC - **Serialization**: Typically binary (efficient) or JSON (readable) - **Semantics**: Strongly typed, often streaming capable - **Use Cases**: Internal service communication, high-performance systems **3. Database Queries** Although not often considered "communication," database queries follow synchronous request-response semantics. The application sends a query and waits for results. - **Protocols**: Database-specific (PostgreSQL wire protocol, MySQL protocol, etc.) - **Semantics**: ACID transactions, connection pooling - **Use Cases**: Data persistence, complex queries, transactions **4. Synchronous Message Passing** Some messaging patterns are synchronous, where the sender waits for acknowledgment that the message was processed (not just received). - **Protocols**: Request-reply pattern over message queues - **Semantics**: Guaranteed processing, explicit acknowledgment - **Use Cases**: When fire-and-forget is insufficient76:T5f0,Despite its constraints, synchronous communication is often the correct choice. Understanding when to use it—and when not to—is a key architectural skill. **Synchronous Communication is Appropriate When:** 1. **Immediate Response is Required** - User authentication: The UI cannot proceed without knowing if credentials are valid - Payment authorization: The checkout flow needs an immediate accept/reject - Real-time validation: Form validation needs instant feedback 2. **Strong Consistency is Needed** - Financial transactions: Balance must be accurately debited before confirming - Inventory reservation: Stock must be confirmed before accepting order - Uniqueness checks: Username availability must be checked before registration 3. **Failure Must Be Immediately Surfaced** - Error handling: When the caller must handle failures in the request context - Retry decisions: When immediate retry logic is required - User feedback: When users need immediate success/failure notification 4. **Operations are Naturally Sequential** - Multi-step workflows: Where each step depends on the previous - Data dependencies: Where output of one call is input to the next - Transaction coordination: Where multiple operations must succeed or fail together 5. **Latency is Acceptable** - Interactive operations: Where sub-second response is achievable - Simple operations: Where downstream calls are fast and reliable - Low-frequency operations: Where the overhead is amortized63:{"json":{"id":"seed_87b08e80fbaf89e159e9a3f31a20d42a","slug":"request-response-pattern","category":"System Design (HLD)","topic":"Request-Response Pattern","title":"Request-Response Pattern","description":"Master the request-response communication paradigm that underpins most service-to-service interactions. Understand synchronous communication models, HTTP protocol evolution from HTTP/1.1 through HTTP/3, request lifecycles, and connection management strategies essential for building performant distributed systems.","difficulty":"INTERMEDIATE","estimatedMinutes":75,"pages":[{"id":"seed_6fab9ba6c87fa6d0ad2ad7fffb65a8c5","title":"Synchronous Communication Model","order":0,"content":[{"id":"opening-hook","title":"The Foundation of Service Communication","content":[{"data":{"content":"When one service needs data from another—when your web application needs to fetch user profile information, when your payment service needs to validate a credit card, when your inventory system needs to confirm stock availability—something fundamental must happen: **a request must be sent, and a response must be received**.\n\nThis seemingly simple pattern—the request-response model—is the backbone of virtually all synchronous communication in distributed systems. It is so ubiquitous that engineers often take it for granted, yet understanding its mechanics, constraints, and implications is essential for designing systems that are both performant and reliable.\n\nIn this page, we will deeply explore the synchronous communication model: what it means for a caller to wait for a response, how this relates to blocking and non-blocking paradigms, and why understanding synchronous communication is foundational before we can appreciate asynchronous alternatives."},"type":"text"},{"data":{"icon":"Target","title":"What You Will Learn","content":"By the end of this page, you will understand the formal definition of synchronous communication, its relationship with blocking and non-blocking I/O, the temporal coupling it creates between services, and the fundamental trade-offs inherent in request-response patterns. You'll gain the conceptual foundation necessary to make informed decisions about when synchronous communication is appropriate and when alternatives should be considered.","variant":"info"},"type":"callout"}]},{"id":"defining-synchronous-communication","title":"Defining Synchronous Communication","content":[{"data":{"content":"$6a"},"type":"text"},{"data":{"icon":"Info","title":"Synchronous vs. Blocking: A Subtle Distinction","content":"While often used interchangeably, 'synchronous' and 'blocking' are not identical. **Synchronous** describes the communication semantics (waiting for response). **Blocking** describes how the calling thread behaves (suspended until I/O completes). You can have synchronous semantics with non-blocking I/O (async/await patterns), where the logical wait is preserved but the thread is freed for other work.","variant":"note"},"type":"callout"},{"data":{"rows":[["Temporal Coupling","Sender waits for receiver's response","Creates latency-sensitive dependency chain"],["Immediate Response","Response is available when call returns","Simplifies application logic and error handling"],["Failure Visibility","Failures are immediately observable","Enables straightforward error propagation"],["Resource Consumption","Resources held during wait period","Requires careful capacity planning"],["Ordering Guarantees","Operations complete in invocation order","Natural ordering simplifies state management"]],"caption":"Synchronous Communication Characteristics","headers":["Characteristic","Description","Implication"]},"type":"table"}],"titleType":"number","titleNumber":1},{"id":"request-response-pattern","title":"The Request-Response Pattern","content":[{"data":{"content":"$6b"},"type":"text"},{"data":{"fileName":"request-response-lifecycle.ts","languages":[{"code":"$6c","label":"TypeScript","value":"typescript"},{"code":"$6d","label":"Go","value":"go"}]},"type":"code"}],"titleType":"number","titleNumber":2},{"id":"temporal-coupling-implications","title":"Temporal Coupling and Its Implications","content":[{"data":{"content":"$6e"},"type":"text"},{"data":{"icon":"AlertCircle","title":"The Multiplication of Failures","content":"In synchronous chains, failures multiply rather than add. A chain of 10 services each with 99.9% availability yields only 99% system availability—ten times more downtime than any individual service. This is why synchronous communication requires careful service dependency analysis.","variant":"warning"},"type":"callout"},{"data":{"rows":[["1","99.9%","8.76 hours"],["3","99.7%","26.28 hours"],["5","99.5%","43.80 hours"],["10","99.0%","87.60 hours"],["15","98.5%","131.40 hours"]],"caption":"Availability Impact of Synchronous Chains (Each Service at 99.9%)","headers":["Number of Services","Chain Availability","Annual Downtime"]},"type":"table"},{"data":{"content":"$6f"},"type":"text"},{"data":{"fileName":"parallel-requests.ts","languages":[{"code":"$70","label":"TypeScript","value":"typescript"}]},"type":"code"}],"titleType":"number","titleNumber":3},{"id":"blocking-nonblocking-io","title":"Blocking vs Non-Blocking I/O","content":[{"data":{"content":"$71"},"type":"text"},{"data":{"left":[{"data":{"items":["**Thread-per-request model**: Each connection requires a dedicated thread","**Simple programming model**: Sequential code, easy to debug","**Memory intensive**: 1000 threads × 2MB = 2GB just for stacks","**Context switching overhead**: OS scheduler must manage many threads","**Natural in C, Java (traditional), Python (threading)**","**Limited concurrency**: Practical limit of thousands of connections"],"title":{"icon":"Target","text":"Blocking I/O Characteristics","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"}],"right":[{"data":{"items":["**Event-loop model**: Few threads handle many connections","**Complex programming model**: Callbacks, promises, or async/await","**Memory efficient**: Single thread can handle 100K+ connections","**Minimal context switching**: Application manages state, not OS","**Natural in Node.js, Go (goroutines), Rust (async)**","**High concurrency**: 100K-1M+ connections practical"],"title":{"icon":"Zap","text":"Non-Blocking I/O Characteristics","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"}]},"type":"two-column"},{"data":{"icon":"Lightbulb","title":"Same Semantics, Different Mechanics","content":"A key insight is that **async/await patterns provide synchronous-looking code over non-blocking I/O**. When you write 'const result = await fetch(url)', the code reads sequentially, but the underlying thread is not blocked—it's freed to handle other work. The synchronous *semantics* (waiting for response) are preserved while avoiding blocking I/O's resource costs.","variant":"tip"},"type":"callout"},{"data":{"fileName":"blocking-vs-nonblocking.ts","languages":[{"code":"$72","label":"Blocking (Java)","value":"java"},{"code":"$73","label":"Non-Blocking (Node.js)","value":"typescript"},{"code":"$74","label":"Goroutines (Go)","value":"go"}]},"type":"code"}],"titleType":"number","titleNumber":4},{"id":"synchronous-communication-models","title":"Synchronous Communication Models in Practice","content":[{"data":{"content":"$75"},"type":"text"},{"data":{"rows":[["REST/HTTP","HTTP/1.1, HTTP/2","10-500ms typical","Public APIs, web services, CRUD operations"],["gRPC","HTTP/2 + Protobuf","1-50ms typical","Internal services, streaming, high throughput"],["GraphQL","HTTP/1.1, HTTP/2","20-200ms typical","Flexible queries, client-driven data needs"],["Database","Various","0.1-100ms typical","Data persistence, complex queries, ACID"],["Sync Messaging","AMQP, etc.","5-100ms typical","Guaranteed processing acknowledgment"]],"caption":"Comparison of Synchronous Communication Models","headers":["Model","Protocol","Latency Profile","Best For"]},"type":"table"}],"titleType":"number","titleNumber":5},{"id":"when-synchronous-is-right","title":"When Synchronous Communication is the Right Choice","content":[{"data":{"content":"$76"},"type":"text"},{"data":{"icon":"AlertCircle","title":"When to Avoid Synchronous Communication","content":"Consider asynchronous alternatives when: (1) The operation takes a long time (video processing, report generation), (2) The caller doesn't need the result immediately (audit logging, analytics), (3) You need to decouple services for independent scaling, (4) High availability requirements exceed what synchronous chains can provide, or (5) Traffic patterns are highly variable and buffering would help.","variant":"warning"},"type":"callout"},{"data":{"items":["**Does the user need an immediate response?** → Yes = Synchronous","**Can the operation proceed if downstream is slow/unavailable?** → No = Synchronous","**Is the operation part of a multi-step transaction?** → Yes = Synchronous","**Does the operation take more than a few seconds?** → Yes = Asynchronous","**Is fire-and-forget acceptable?** → Yes = Asynchronous","**Do you need to buffer traffic spikes?** → Yes = Asynchronous"],"title":{"icon":"CheckCircle","text":"Decision Framework: Sync vs Async","type":"icon","color":"primary","variant":"outline-circle"},"variant":"glass"},"type":"list"}],"titleType":"number","titleNumber":6},{"id":"summary","title":"Summary: The Synchronous Communication Model","content":[{"data":{"content":"We've established the foundational understanding of synchronous communication—the request-response paradigm that underpins most service interactions. Let's consolidate the key concepts:"},"type":"text"},{"data":{"type":"ordered","items":["**Synchronous communication** means the sender waits for a response before continuing—creating temporal coupling between services.","**The request-response pattern** consists of four phases: preparation, transmission, processing, and response—each contributing to overall latency.","**Temporal coupling** causes latency accumulation and availability multiplication—understand these effects before designing synchronous chains.","**Blocking vs non-blocking I/O** are implementation details—synchronous semantics can be achieved with either, but non-blocking scales better.","**Multiple communication models** exist (REST, RPC, database)—each optimized for different use cases and latency profiles.","**Use synchronous when** immediate response is needed, strong consistency is required, or failures must be immediately surfaced."],"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 synchronous communication model conceptually, we'll dive into the **HTTP protocol evolution**—from HTTP/1.1 through HTTP/2 to HTTP/3—understanding how each version addresses the limitations of its predecessor and what this means for request-response communication at the wire level."},"type":"text"},{"data":{"icon":"CheckCircle","title":"Page Complete","content":"You now understand the fundamentals of synchronous communication: its definition, the request-response lifecycle, temporal coupling implications, and when to choose synchronous over asynchronous patterns. This foundation prepares you to understand HTTP protocol mechanics and make informed decisions about communication protocols in distributed systems.","variant":"success"},"type":"callout"}],"titleType":"number","titleNumber":7}],"isLocked":false},{"id":"seed_208ef2d4f08b0fe02d3090f5f954424c","title":"HTTP/1.1 vs HTTP/2 vs HTTP/3","order":1,"content":null,"isLocked":true},{"id":"seed_6fd384ba976e52c50e9da3a00fbe533c","title":"Request Lifecycle","order":2,"content":null,"isLocked":true},{"id":"seed_4a4b3ed5c1293860e3d310377ac3efdf","title":"Connection Management","order":3,"content":null,"isLocked":true}]}}