Networking

Networking is the backbone of all distributed systems, enabling communication between different services, clients, and servers across the internet. Understanding networking protocols, patterns, and technologies is crucial for designing scalable, reliable, and performant systems. From simple HTTP requests to real-time bidirectional communication, networking decisions shape how your application behaves under load and how users experience your product.

Networking Technologies

HTTP/HTTPS

The foundational protocol of the web, supporting request-response communication with methods like GET, POST, PUT, and DELETE for RESTful APIs.

gRPC

High-performance RPC framework using Protocol Buffers, supporting streaming and efficient binary communication for microservice architectures.

GraphQL

Query language and runtime for APIs that allows clients to request exactly the data they need, reducing over-fetching and under-fetching.

WebRTC

Real-time communication technology enabling peer-to-peer audio, video, and data sharing directly between browsers without intermediary servers.

Core Networking Concepts

Understanding networking fundamentals is like learning the alphabet before writing—you need these building blocks to design any distributed system effectively. These concepts apply whether you're building a simple web app or a complex microservice architecture.

Modern applications rarely use just one networking pattern. You might use HTTP for your REST API, WebSockets for real-time features, and gRPC for internal service communication. The key is knowing when each approach makes sense and how they can work together in a cohesive system.

Protocol: Rules governing how data is transmitted between network entities (HTTP, TCP, UDP, WebSockets)
Latency: Time delay between sending a request and receiving a response, critical for user experience
Throughput: Amount of data transmitted per unit of time, important for high-volume applications
Connection Management: How connections are established, maintained, and terminated between clients and servers
Load Balancing: Distributing network traffic across multiple servers to prevent overload
SSL/TLS: Security protocols that encrypt data in transit to protect against eavesdropping and tampering

HTTP and RESTful APIs

HTTP remains the foundation of web communication, powering everything from simple web pages to complex API ecosystems. Understanding HTTP deeply is essential because even modern protocols like gRPC often run over HTTP/2.

The beauty of HTTP is its simplicity and statelessness. Each request contains all the information needed to process it, making systems easier to scale and debug. However, this simplicity comes with trade-offs—HTTP's request-response model isn't ideal for real-time applications where you need immediate updates.

HTTP Methods: GET (retrieve), POST (create), PUT (update/replace), PATCH (partial update), DELETE (remove)
Status Codes: 2xx (success), 3xx (redirection), 4xx (client errors), 5xx (server errors)
Headers: Metadata that provides context about requests and responses (authentication, content type, caching)
REST Principles: Stateless communication, resource-based URLs, standard HTTP methods
HTTP/2 Features: Multiplexing, server push, header compression for improved performance

Asynchronous Communication: WebSockets

WebSockets solve the fundamental limitation of HTTP's request-response model by enabling full-duplex communication. This means both the client and server can send messages at any time, making it perfect for real-time applications.

Think of WebSockets as upgrading from sending letters (HTTP) to having a phone conversation (WebSockets). Once the connection is established, both parties can talk whenever they want without waiting for a response. This is why chat applications, live gaming, and real-time collaboration tools rely heavily on WebSockets.

The main trade-off with WebSockets is connection management complexity. Unlike HTTP requests that are stateless and can be load-balanced easily, WebSocket connections are persistent and stateful. This means you need to think carefully about how to handle connection failures, reconnections, and scaling across multiple servers.

Key Features:

Persistent Connection: Single TCP connection remains open for the duration of the communication
Full-Duplex: Both client and server can initiate message sending at any time
Low Latency: No HTTP overhead after initial handshake, enabling sub-millisecond communication
Real-time Updates: Perfect for live chat, gaming, financial tickers, collaborative editing

Common Use Cases:

Chat Applications: WhatsApp, Slack, Discord for instant messaging
Live Gaming: Real-time multiplayer games requiring immediate response
Trading Platforms: Stock price updates, order book changes
Collaborative Tools: Google Docs, Figma for simultaneous editing

Asynchronous Communication: Long Polling

Long polling is a clever workaround for HTTP's limitations that bridges the gap between simple polling and WebSockets. Instead of making repeated requests, the client makes a request and the server holds it open until there's new data to send.

It's like calling a restaurant and instead of hanging up and calling back every few minutes to check if your table is ready, you stay on the line while they check and only hang up when they have an answer. This dramatically reduces unnecessary network requests while still using standard HTTP.

Long polling works particularly well when you need real-time-ish updates but don't want the complexity of WebSocket connection management. It's easier to implement with existing HTTP infrastructure and plays nicely with load balancers and proxies.

How It Works:

Extended Timeout: Server holds the request open for an extended period (30-60 seconds)
Immediate Response: When data becomes available, server responds immediately
Automatic Reconnection: Client immediately makes a new long-poll request after receiving a response
Graceful Degradation: Falls back to regular polling if long polling fails

Advantages Over Regular Polling:

Reduced Server Load: Eliminates unnecessary requests when no data is available
Lower Latency: Near real-time updates without constant polling overhead
HTTP Compatible: Works with existing infrastructure, firewalls, and load balancers
Simpler Than WebSockets: No need for connection state management

Common Use Cases:

Social Media Feeds: Facebook, Twitter for new post notifications
Email Applications: Gmail for new message alerts
Chat Systems: As a fallback when WebSockets aren't available
Live Updates: Sports scores, news feeds, status dashboards

Asynchronous Communication: gRPC Streaming

gRPC streaming takes remote procedure calls to the next level by supporting continuous data flows between services. Unlike traditional RPC where you send a request and get a single response, gRPC streaming allows you to send and receive multiple messages over a single connection.

Think of regular gRPC calls like ordering a single item from a restaurant, while streaming is like having a conversation with the chef where you can make requests and receive updates throughout the cooking process. This makes gRPC streaming incredibly powerful for microservice architectures where services need to exchange ongoing streams of data.

gRPC uses HTTP/2 under the hood, which means you get all the benefits of multiplexing, flow control, and efficient binary protocol. This makes it significantly more efficient than trying to achieve similar functionality with multiple HTTP requests.

Types of Streaming:

Server Streaming: Client sends one request, server sends multiple responses (like downloading a large file in chunks)
Client Streaming: Client sends multiple requests, server sends one response (like uploading multiple files)
Bidirectional Streaming: Both client and server can send multiple messages (like real-time chat between services)

Technical Advantages:

Protocol Buffers: Efficient binary serialization, smaller payloads than JSON
HTTP/2 Foundation: Multiplexing, header compression, flow control
Code Generation: Auto-generated client and server code from proto definitions
Backpressure: Built-in flow control prevents overwhelming slower consumers

Common Use Cases:

Microservice Communication: Internal service-to-service streaming data
Real-time Analytics: Streaming metrics and events between services
File Transfer: Efficient large file uploads/downloads with progress tracking
Live Data Feeds: Stock prices, IoT sensor data, log streaming
Chat Services: Real-time messaging between backend services

Other Asynchronous Communication Patterns

Beyond the big three, there are several other patterns worth understanding for different scenarios.

Server-Sent Events (SSE) provide a simple way to stream data from server to client over HTTP. They're lighter weight than WebSockets but only support one-way communication. Perfect for live notifications, real-time dashboards, or any scenario where you need to push updates to browsers but don't need client-to-server streaming.

Message Queues enable asynchronous communication between services using brokers like RabbitMQ, Apache Kafka, or AWS SQS. They're essential for building resilient systems where services can communicate without being online simultaneously.

Webhooks let your application receive real-time notifications from external services by providing a callback URL. Services like GitHub, Stripe, and Slack use webhooks to notify your application when events occur.

Real-Time Communication Protocols

Real-time communication requirements vary dramatically depending on your application. Understanding the trade-offs helps you choose the right approach for your specific needs.

The key insight is that "real-time" means different things to different applications. A chat app might need sub-second message delivery, while a social media feed might be fine with updates every few seconds. Your choice of protocol should match your actual requirements, not just what sounds most advanced.

Low-Latency Requirements:

Gaming: Sub-50ms for competitive games, UDP often preferred for speed
Financial Trading: Microsecond precision, custom protocols over TCP/UDP
Video Calling: WebRTC for peer-to-peer, sub-100ms for acceptable quality
Live Streaming: Adaptive bitrate streaming with 1-3 second delays

Moderate Real-Time:

Chat Applications: WebSockets for instant messaging, 100-500ms acceptable
Collaborative Editing: Operational transforms over WebSockets
Live Sports Updates: Server-Sent Events or long polling, 1-2 second delays fine
Social Media Feeds: Long polling or WebSockets, several second delays acceptable

Protocol Selection Criteria:

Latency Requirements: How fast do updates need to reach users?
Bi-directional Needs: Does the client need to send real-time data back?
Infrastructure Compatibility: What do your load balancers and proxies support?
Connection Volume: How many concurrent connections do you need to handle?
Reliability Requirements: Can you afford dropped messages or do you need guarantees?

Network Security and Performance

Security and performance considerations are critical when designing networking systems. Modern applications need to balance security with performance, especially when handling sensitive data or high-volume traffic.

SSL/TLS encryption is no longer optional—it's a requirement for any production system. The performance overhead is minimal with modern hardware, and the security benefits are essential. HTTP/2 and HTTP/3 provide significant performance improvements while maintaining security.

TLS Termination: Where in your architecture you decrypt SSL traffic affects performance and security
Connection Pooling: Reusing connections reduces overhead for high-volume applications
Compression: gzip, Brotli, and protocol-specific compression reduce bandwidth usage
CDN Integration: Edge caching and geographic distribution improve global performance
Rate Limiting: Protecting APIs from abuse while maintaining good user experience

API Design Patterns

Well-designed APIs make the difference between systems that are joy to use and maintain versus those that become maintenance nightmares. The key is consistency and predictability.

RESTful design principles provide a solid foundation, but don't be dogmatic about them. Sometimes a more RPC-style approach makes more sense for your specific use case. GraphQL can be excellent for frontend-driven development but adds complexity. The best API is the one that solves your specific problems clearly and consistently.

REST API Best Practices:

Resource-Based URLs: /users/123/orders instead of /getUserOrders?userId=123
Consistent Naming: Use plural nouns, lowercase with hyphens
Proper HTTP Status Codes: 201 for creation, 404 for not found, 422 for validation errors
Pagination: Limit response sizes with cursor or offset-based pagination
Versioning: URL versioning (/v1/users) or header-based versioning

GraphQL Considerations:

Query Flexibility: Clients request exactly the data they need
Single Endpoint: All operations go through one URL
Strong Type System: Schema-first development with automatic documentation
N+1 Problem: Careful resolver implementation needed to avoid performance issues
Caching Complexity: Query variation makes caching more challenging than REST

gRPC for Internal APIs:

Efficient Serialization: Protocol Buffers are faster and smaller than JSON
Service Contracts: Proto files serve as formal API contracts
Streaming Support: Built-in support for real-time data flows
Multi-Language: Generated clients for multiple programming languages
HTTP/2 Benefits: Multiplexing and header compression improve performance

How to Use Networking in System Design Interviews

When discussing networking in interviews, demonstrate understanding of both protocols and real-world trade-offs. Interviewers want to see that you can choose the right networking approach for specific requirements, not just memorize protocol details.

The key is showing that you understand the implications of your networking choices. If you choose WebSockets for a chat application, explain how you'll handle connection failures and scaling. If you choose HTTP for an API, discuss caching strategies and rate limiting.

Here are key points to mention:

Protocol Selection: Explain why you chose HTTP vs WebSockets vs gRPC based on specific requirements. For example, describe how Slack uses WebSockets for real-time messaging but HTTP APIs for less time-sensitive operations like user management.
Scalability Considerations: Discuss how different protocols scale. WhatsApp handles billions of WebSocket connections by using efficient connection pooling and load balancing strategies.
Real-Time Requirements: Differentiate between different types of real-time needs. Explain how Google Docs uses WebSockets for collaborative editing requiring immediate updates, while Gmail might use long polling for less critical email notifications.
Security and Performance: Address how networking choices affect security and performance. Mention how companies like Cloudflare terminate SSL at the edge to improve performance while maintaining security.
Fallback Strategies: Discuss graceful degradation. Explain how modern chat applications often implement WebSockets with long polling fallback for network environments that don't support persistent connections.
Cross-Service Communication: In microservice architectures, explain when to use gRPC for internal communication versus HTTP for external APIs.

Example System Design Problems

Here are examples where networking choices are crucial to the system's success:

Design WhatsApp: Implement WebSockets for real-time messaging, HTTP APIs for user management, and gRPC for internal service communication. Handle billions of persistent connections with efficient load balancing.
Design Google Docs: Use WebSockets for real-time collaborative editing with operational transforms, HTTP APIs for document management, and implement conflict resolution for simultaneous edits.
Design Uber: Implement real-time location tracking using WebSockets or Server-Sent Events, HTTP APIs for ride booking, and gRPC for internal microservice communication with low latency requirements.
Design Discord: Build voice/video chat with WebRTC for peer-to-peer communication, WebSockets for text messaging, and HTTP APIs for server management and user authentication.
Design Trading Platform: Use WebSockets for real-time price feeds, gRPC streaming for order processing, and HTTP APIs for account management with ultra-low latency requirements.

DeepSWE Recommendation

Master gRPC for Modern System Design

Here's what most system design resources won't tell you: while HTTP and REST APIs are still important, the industry is rapidly moving toward gRPC for internal service communication. If you're interviewing at companies that use microservices (which is basically every major tech company now), understanding gRPC will set you apart.

Why gRPC Matters for Interviews: gRPC isn't just another protocol—it represents how modern distributed systems actually communicate internally. Companies like Google, Netflix, and Uber use gRPC extensively because it solves real problems that HTTP/JSON APIs struggle with: efficiency, type safety, and streaming.

What Makes gRPC Interview-Relevant:

Protocol Buffers: Much more efficient than JSON, which matters at scale
Streaming: Enables real-time communication patterns that are essential for modern applications
Service Contracts: Proto files act as formal API contracts, making microservice integration more reliable
Performance: Binary protocol with HTTP/2 multiplexing delivers significantly better performance than REST

Focus Areas for System Design Success:

How gRPC streaming enables real-time features without WebSocket complexity
When to use gRPC internally vs HTTP for external APIs
How Protocol Buffers reduce bandwidth and improve performance
gRPC's role in service mesh architectures like Istio

Real-World Application: When you mention gRPC in system design interviews, you're showing that you understand how companies actually build distributed systems today, not just textbook examples. You can explain how services stream data efficiently, handle backpressure, and maintain type safety across team boundaries.

Learning Path: Start with understanding Protocol Buffers and service definitions, then practice implementing streaming patterns. Focus on understanding when gRPC makes sense versus other protocols—this decision-making ability is what interviewers really want to see.

The investment in learning gRPC pays off immediately. Once you understand it, you'll also understand service meshes, efficient microservice communication, and modern distributed system patterns that are essential for senior engineering roles.