Notes from https://www.hellointerview.com/learn/system-design/in-a-hurry/core-concepts

• Most important decision is choosing your communication protocol

  • Default to HTTP over TCP

    HTTP

    TCP

• HTTP handles 90% of use cases

• Require specific reason to use something else

• Websockets and Server-Sent Events (SSE) come up when you need real-time updates

  WebSockets

  Server-Sent Events (SSE)

  • Main difference
    • SSE is unidirectional
      • Client makes initial HTTP request to open connection
      • Server pushes data down that connection (live scores/notifications)
      • Client can’t send additional data over same SSE connection
    • WebSockets
      • Bidirectional communication
      • Both sides snedm essages freely (live chat/collaboration_
      • Simpler to implement
      • Works better with standard HTTP infrastructure
      • Necessary when clients need to push data back to the server frequently
  • Both are stateful connections
    • Can’t throw behind standard load balancer
    • Think about connection persistence
      • What happens when server goes down with thousands of active connections

• gRPC

  gRPC

  • Internal service-to-service communication when performance is critical
  • Uses binary serialization and HTTP/2, making it significantly faster than JSON over HTTP
  • Can’t use for public-facing APIs because browsers don’t natively support gRPC
    • gRPC-Web exists as workaround, but it requires a proxy and doesn’t support all gRPC features
  • Common pattern is REST for external APIs and gRPC internally

• Load balancing

  • Layer 7 (Application layer)
    • Can route based on the actual HTTP request content
    • Can send API calls to one service and web page requests to another
  • Layer 4 (Transport layer)
    • TCP level
    • Faster but dumber
    • Distribute connections without looking at the content
    • Need layer 4 balancing for WebSockets because you’re maintaining a persistent TCP connection

• Common mistake

  • Proposing WebSockets when HTTP with long polling or Server-Sent Events would work fine
  • WebSockets at significant complexity for maintaining stateful connections at scale
  • Only reach for them when you genuinely need bidirectional real-time connection, not just because “real-time” is mentioned

• Geography and latency

  • Request from New York to London has minimum latency of around 80ms just from the speed of light through fiber optic cables, before even processing anything
  • If system needs low latency globally

    • Need regional deployments

    • Data replicated or partitioned by geography

    • CDNs serve static content from edge servers close to users

      CDN

Notes from https://www.hellointerview.com/learn/system-design/core-concepts/networking-essentials