Communication Protocols in System Design

1. TCP: The reliable one

TCP (Transmission Control Protocol) delivers data reliably and in order. If a piece gets lost, TCP resends it. If pieces arrive out of order, TCP puts them back in order before your program sees them.

Before sending data, TCP does a three-way handshake: the client says "hello" (SYN), the server replies (SYN-ACK) and the client confirms (ACK). That costs one round trip before any real data flows.

Client                         Server
  │ ──── SYN ────────────────► │
  │ ◄─── SYN-ACK ───────────── │      1 round trip of setup
  │ ──── ACK + data ─────────► │
  │ ◄─── data ──────────────── │

TCP also controls speed. It slows down when the network looks congested, so it doesn't make things worse for everyone. Most of the internet runs on TCP: web pages, APIs, databases, email.

One thing beginners often miss: TCP is a stream of bytes, not a stream of messages. If you send "hello" and then "world," the other side might read "helloworld" in one go or "hel" and then "loworld." Application protocols on top of TCP (like HTTP) add their own rules for where one message ends and the next begins. This is called framing.

2. UDP: The fast one

UDP (User Datagram Protocol) sends individual packets with no handshake, no delivery guarantee and no ordering. It's fast and simple and it's up to the application to deal with loss.

That sounds worse, but it's exactly right for some jobs:

• Live video calls and online games: a late packet is useless. If a voice packet from 200 ms ago arrives now, playing it would only make things worse. Better to skip it.
• DNS lookups: one small question, one small answer. A handshake would double the time. If the answer doesn't come, just ask again. (DNS also uses TCP when a response is too large for UDP and for copying whole zones between servers and newer options like DNS over HTTPS and DNS over TLS run over encrypted connections.)
• Building new protocols: QUIC is built on UDP so it can add its own smarter reliability.

TCP vs UDP comparison

3. QUIC: Reliability on top of UDP

QUIC is a newer transport protocol that runs on top of UDP but gives you TCP-like reliability, built-in encryption and faster connection setup. It started at Google and was standardized by the IETF as RFC 9000 in 2021. It's the transport underneath HTTP/3.

Why build on UDP instead of fixing TCP? TCP lives inside operating systems and network equipment all over the world, so changing it takes many years. UDP is a blank canvas: QUIC can be updated in the app or browser itself.

What QUIC improves:

• Faster setup: QUIC combines the connection handshake and the TLS encryption handshake. A new connection usually needs one round trip before data flows and reconnecting to a server it has seen before can send data immediately ("0-RTT," with some security trade-offs).
• No cross-stream blocking: if one packet is lost, only the request it belongs to waits. Other requests on the same connection keep going (more on this below).
• Connection migration: when your phone switches from Wi-Fi to mobile data, a QUIC connection can survive the change of IP address, instead of starting over.

1. HTTP/1.1: one request at a time per connection

With HTTP/1.1, a connection handles one request at a time. If a page needs 50 files, the browser either waits for each file before asking for the next or opens several connections in parallel. Browsers typically open only about six connections per host, so the rest wait in line.

This waiting is called head-of-line blocking: one slow response holds up everything behind it, like a single slow customer at the only open billing counter.

2. HTTP/2: many requests on one connection

HTTP/2 (first published in 2015, now RFC 9113) splits each request and response into small frames and lets many of them share one connection at the same time. This is called multiplexing. It also compresses headers, which helps because headers like cookies repeat on every request.

But HTTP/2 still runs on TCP and TCP delivers bytes in order. If one TCP packet is lost, every stream on that connection waits until it's resent, even streams whose data already arrived. So HTTP/2 fixed head-of-line blocking at the HTTP level but not at the TCP level. On a clean network that rarely matters. On a lossy mobile network, it can.

3. HTTP/3: HTTP over QUIC

HTTP/3 (RFC 9114, 2022) keeps HTTP's meaning (methods, headers, status codes) but runs on QUIC instead of TCP. Since QUIC handles each stream separately, a lost packet only delays the one stream it belongs to.

HTTP/1.1          HTTP/2                         HTTP/3
one request       many streams, one TCP conn     many streams, one QUIC conn
at a time         ┌ stream 1 ───┐                ┌ stream 1 ───┐
per connection    ├ stream 2 ───┤ one lost       ├ stream 2 ─X─┤ only stream 2
                  └ stream 3 ───┘ packet blocks  └ stream 3 ───┘ waits for the
                                  ALL streams                    resend

You usually don't pick HTTP versions in your application code. Your load balancer, CDN and client libraries negotiate the best version both sides support. What you do choose is whether to enable HTTP/2 and HTTP/3 on your edge and whether your internal services (for example, gRPC) need HTTP/2.

Real-world trade-off: the HTTP/2 Rapid Reset attack (2023)

Multiplexing is HTTP/2's best feature and in 2023 attackers turned it into a weapon. In a coordinated disclosure, Google, Amazon and Cloudflare described an attack called Rapid Reset (tracked as CVE-2023-44487). The attacker opens a stream, immediately cancels it with a reset frame and repeats, very fast. The server does the work of starting each request, but the attacker's cost is tiny and because the streams are cancelled, normal limits on how many streams can be open at once don't help.

The numbers were record-breaking: Google reported a peak above 398 million requests per second, Cloudflare above 201 million and Amazon about 155 million (Google, Cloudflare). Web servers and proxies shipped patches that track and limit excessive stream resets.

The takeaway for system designers: every protocol feature has a cost model. A feature that saves honest clients work can let dishonest clients create work. Keep your edge software (load balancers, proxies, web servers) patched and prefer managed edges that track these issues for you.

1. REST

REST (Representational State Transfer) organizes an API around resources, like /orders/9812 and uses standard HTTP methods to act on them: GET to read, POST to create, PUT or PATCH to update, DELETE to remove. The idea comes from Roy Fielding's 2000 doctoral dissertation.

GET    /orders/9812          → read one order
POST   /orders               → create an order
PATCH  /orders/9812          → change part of an order
DELETE /orders/9812/items/3  → remove an item

Why people like it: it's simple, it works everywhere (any language, any browser, curl), responses can be cached by browsers and CDNs and HTTP status codes (200, 404, 429, 503) already mean something to every tool.

Where it struggles: a screen might need data from five resources, so the app makes five calls (under-fetching) or one endpoint returns far more data than a small screen needs (over-fetching). Text formats like JSON are also bigger and slower to process than binary formats.

2. GraphQL

GraphQL is a query language for APIs. The client sends one request describing exactly which fields it wants and the server returns exactly that shape. It was developed at Facebook in 2012 and open-sourced in 2015.

query {
  order(id: "9812") {
    status
    total
    items { name quantity }
    restaurant { name phone }
  }
}

One request replaces several REST calls and the client gets only the fields it asked for. That's great for mobile apps on slow networks and for teams where the frontend changes faster than the backend.

The costs: caching is harder (requests are usually POSTs to a single /graphql endpoint, so a CDN can't cache them by URL without extra setup); a single clever query can ask for a huge amount of data, so servers need query depth and cost limits; and naive resolvers can cause the N+1 problem, where fetching 50 orders triggers 50 separate database calls for their restaurants. Tools like DataLoader batch those calls.

3. gRPC

gRPC is a high-performance remote procedure call (RPC) framework. You define services and messages in a .proto file and gRPC generates client and server code in many languages. It sends compact binary Protocol Buffers messages over HTTP/2. Google open-sourced it in 2015.

syntax = "proto3";

service OrderService {
  rpc GetOrder (GetOrderRequest) returns (Order);
  rpc WatchOrder (GetOrderRequest) returns (stream OrderStatus);  // server streaming
}

message GetOrderRequest { int64 order_id = 1; }
message Order {
  int64  order_id     = 1;
  string user_id      = 2;
  int64  amount_paise = 3;
}
message OrderStatus { string status = 1; }

Calling a remote service then looks like calling a local function: orderClient.getOrder(request). gRPC supports four kinds of calls: one request and one response (unary), server streaming, client streaming and two-way (bidirectional) streaming.

Why teams choose it: small, fast messages; a strict contract checked at compile time; generated clients in many languages; built-in streaming and deadlines. It's especially popular for service-to-service traffic inside a company.

The costs: browsers can't call gRPC directly (you need gRPC-Web and a proxy); binary messages are harder to inspect by eye than JSON; and HTTP/2 connections are long-lived, so basic connection-level load balancing can send everything to one server unless you balance per request (for example, with Envoy or client-side load balancing).

Real-world example: LinkedIn's move from JSON to Protobuf, then to gRPC

LinkedIn ran its services on its own REST framework, Rest.li, with JSON as the format. In 2023, LinkedIn's engineering team described switching the encoding from JSON to Protocol Buffers while keeping the REST framework. They reported up to 60% lower latency for services with large payloads and about 8% better resource utilization. In a later interview with InfoQ, LinkedIn engineers explained that they were moving from Rest.li to gRPC, citing reasons such as gRPC's broad multi-language support.

What makes this example useful is how it splits two decisions people often mix up: the API style (REST vs gRPC) and the data format (JSON vs Protobuf). LinkedIn got a big win just by changing the format, before changing the API style.

REST vs GraphQL vs gRPC comparison

There's no universal winner. A very common setup is: REST or GraphQL at the edge for browsers, mobile apps and partners and gRPC inside between services.

1. Short polling

The client asks every few seconds: "Anything new?" Usually the answer is "no."

It's simple, works everywhere and is fine for things that change slowly. But it wastes requests and adds delay: with a 5-second interval, an update can wait up to 5 seconds. And at scale, a million users polling every 5 seconds means 200,000 requests per second, mostly asking for nothing.

2. Long polling

The client asks and the server holds the request open until there's news (or a timeout, say 30 seconds). Then the client immediately asks again. Updates arrive almost instantly, with far fewer empty responses. It works over plain HTTP, which made it popular before WebSockets were widely supported. The downside is that each waiting client ties up a connection on the server and the constant reconnects add overhead.

3. Server-Sent Events (SSE)

Server-Sent Events let a server push a stream of text events to the client over one long-lived HTTP response. Browsers support it natively through the EventSource API, which also reconnects automatically and can tell the server the last event it received (with the Last-Event-ID header), so the server can resume.

SSE is one-way: server to client. That's enough for a surprising number of features: order tracking, notifications, live dashboards, progress bars and streaming responses from AI chat tools.

The Java program below is a tiny SSE server that pushes order status updates, plus a client that prints each event as it arrives:

import com.sun.net.httpserver.HttpServer;
import java.io.*;
import java.net.InetSocketAddress;
import java.net.URI;
import java.net.http.*;
import java.nio.charset.StandardCharsets;

// Server-Sent Events: one long HTTP response, the server pushes events down it as they happen.
public class SseDemo {
    public static void main(String[] args) throws Exception {
        HttpServer server = HttpServer.create(new InetSocketAddress(8081), 0);
        server.createContext("/orders/9812/status", ex -> {
            ex.getResponseHeaders().set("Content-Type", "text/event-stream");
            ex.getResponseHeaders().set("Cache-Control", "no-cache");
            ex.sendResponseHeaders(200, 0);                       // 0 = streamed body, length unknown
            try (Writer w = new OutputStreamWriter(ex.getResponseBody(), StandardCharsets.UTF_8)) {
                String[] steps = {"PLACED", "PACKED", "OUT_FOR_DELIVERY"};
                for (int i = 0; i < steps.length; i++) {
                    w.write("id: " + (i + 1) + "\nevent: status\ndata: " + steps[i] + "\n\n");  // blank line ends an event
                    w.flush();
                    Thread.sleep(300);                            // pretend time passes between updates
                }
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            }
        });
        server.start();

        HttpClient client = HttpClient.newHttpClient();
        HttpRequest req = HttpRequest.newBuilder(URI.create("http://localhost:8081/orders/9812/status"))
                .header("Accept", "text/event-stream").build();
        long start = System.currentTimeMillis();
        client.send(req, HttpResponse.BodyHandlers.ofLines()).body()
              .filter(line -> line.startsWith("data: "))
              .forEach(line -> System.out.printf("+%4d ms  %s%n", System.currentTimeMillis() - start, line));

        server.stop(0);
    }
}

Output from one run (exact timings vary by machine):

+ 265 ms  data: PLACED
+ 532 ms  data: PACKED
+ 834 ms  data: OUT_FOR_DELIVERY

The client made one request and received three updates as they happened, roughly 300 ms apart. With short polling, it would have needed a request for every check. One limit to know: over HTTP/1.1, browsers cap open connections per domain (around six) and each SSE stream uses one. Over HTTP/2, many streams share one connection, so this limit mostly goes away.

4. WebSockets

A WebSocket is a long-lived, two-way connection between a client and a server. Either side can send a message at any time. The protocol (RFC 6455, 2011) starts as a normal HTTP request asking to "upgrade," then switches to its own lightweight message frames on the same TCP connection.

WebSockets fit features where both sides talk often: chat, multiplayer games, collaborative editing, live trading screens. Discord's real-time "Gateway," for example, is documented as a WebSocket connection that clients keep open to receive events like new messages.

What makes WebSockets harder in production:

• Stateful connections. Each server holds thousands of open connections. Scaling out means you need a way to send a message to a user connected to a different server, usually through a pub/sub layer like Redis or Kafka.
• Load balancers and deploys. Connections can last hours. Deploying new server versions means draining connections gracefully and clients must reconnect with backoff.
• You rebuild some HTTP features yourself: authentication on connect, message acknowledgements, retries and ordering are now your job.
• Proxies and firewalls occasionally interfere, so you need heartbeats (ping/pong) to detect dead connections.

WebRTC (briefly)

For video and voice calls, browsers use WebRTC, which can send media directly between users (peer-to-peer), typically over UDP, with helper servers (STUN and TURN) to get through home routers and firewalls. You'd use it for calling features, not for regular app data.

Choosing a real-time option

A practical rule: if only the server needs to push, start with SSE. Reach for WebSockets when the client also needs to send frequent messages over the same channel.

1. Always set timeouts

A call with no timeout can hang forever, holding a thread, a connection and memory. Under load, those pile up until your service falls over, even though the real problem was a different service. Set a timeout on every network call, based on how long that call normally takes (for example, a bit above its 99th-percentile latency), not a random large number. gRPC calls this a deadline and it can pass the remaining time along to downstream calls automatically.

2. Retry carefully: backoff and jitter

Retrying a failed request is often the right move. But if a service struggles and every client retries immediately, the retries become a flood that keeps it down. This is called a retry storm.

Two fixes, both described in the AWS Builders' Library article "Timeouts, retries and backoff with jitter":

• Exponential backoff: wait longer after each failure (1 s, 2 s, 4 s, 8 s).
• Jitter: add randomness to the wait, so clients don't all retry at the same moment.

The simulation below has 1,000 clients that all fail at the same instant and retry four times. It measures the busiest 100 ms window the server sees:

import java.util.*;
// 1,000 clients all fail at t=0 (a brief outage) and retry up to 4 times.
// Compare retry timing strategies by the busiest 100 ms window the server sees.
public class RetryStorm {
    static final int CLIENTS = 1_000, RETRIES = 4;
    static final long BASE_MS = 1_000, CAP_MS = 30_000;

    interface Strategy { long delay(int attempt, Random rnd); }

    static int busiestWindow(Strategy s, Random rnd) {
        Map<Long, Integer> perWindow = new HashMap<>();
        for (int c = 0; c < CLIENTS; c++) {
            long t = 0;
            for (int attempt = 0; attempt < RETRIES; attempt++) {
                t += s.delay(attempt, rnd);
                perWindow.merge(t / 100, 1, Integer::sum);   // bucket each retry into a 100 ms window
            }
        }
        return Collections.max(perWindow.values());
    }

    public static void main(String[] args) {
        Strategy fixed = (a, r) -> 1_000;                                         // retry every second
        Strategy expo  = (a, r) -> Math.min(CAP_MS, BASE_MS << a);                // 1 s, 2 s, 4 s, 8 s
        Strategy full  = (a, r) -> (long) (r.nextDouble() * Math.min(CAP_MS, BASE_MS << a)); // random 0..expo

        System.out.println("busiest 100 ms window (out of " + CLIENTS * RETRIES + " retries):");
        System.out.println("fixed 1 s delay:              " + busiestWindow(fixed, new Random(1)));
        System.out.println("exponential backoff:          " + busiestWindow(expo, new Random(1)));
        System.out.println("exponential + full jitter:    " + busiestWindow(full, new Random(1)));
    }
}

Output:

busiest 100 ms window (out of 4000 retries):
fixed 1 s delay:              1000
exponential backoff:          1000
exponential + full jitter:    151

This result surprises many people. Exponential backoff alone didn't reduce the peak at all. All 1,000 clients still retried at exactly 1 s, then exactly 3 s and so on, in perfect sync, because they all failed at the same moment. Backoff spreads retries out over time for each client, but only jitter spreads clients out from each other. With jitter, the busiest window dropped from 1,000 requests to 151, about 6.6 times lower.

Also limit how many retries happen. Retry only errors that might succeed next time (timeouts, 503, 429 with a Retry-After header), not errors like 400 Bad Request. And avoid retrying at every layer: if the app, the service and the database client each make three attempts, one failed request can turn into 27 calls at the bottom layer (3 × 3 × 3).

3. Make writes idempotent

A timeout doesn't tell you whether the request failed. The server might have processed it and the response got lost. If the client retries a "charge ₹1,499" request, the customer might be charged twice.

The standard fix is an idempotency key: the client generates a unique ID for each operation and sends it with every attempt. The server remembers which keys it has already processed and returns the same result for repeats instead of doing the work again. Stripe's API documents exactly this with an Idempotency-Key header. GET, PUT and DELETE are idempotent by design in HTTP; POST needs this extra help.

Circuit breakers

If a service keeps failing, stop calling it for a short time instead of piling on. A circuit breaker watches failures and, past a threshold, "opens" and fails fast (or returns a fallback) for a while, then lets a few test requests through to see if the service has recovered. This protects both your callers and the struggling service.

1. No timeouts on network calls. One slow dependency can exhaust threads and take down healthy services.

2. Retrying without jitter or limits. As the simulation showed, backoff alone keeps clients in sync. Add jitter, cap attempts and retry at one layer.

3. Retrying non-idempotent writes. Without idempotency keys, retries create duplicate orders and double charges.

4. Using WebSockets when SSE would do. If only the server pushes, SSE is simpler and reconnects for you.

5. Short polling at scale. It looks harmless with 100 users and becomes a huge, mostly empty request load with a million.

6. Treating TCP as message-based. TCP is a byte stream. Without framing, messages merge or split.

7. Assuming async means reliable. Brokers deliver at least once. Without idempotent consumers and dead-letter queues, duplicates and poison messages cause chaos.

8. Exposing gRPC directly to browsers and partners. Use REST or gRPC-Web with a proxy at the edge; keep gRPC for internal traffic.

9. Skipping webhook signature checks. A public URL will receive fake requests eventually.

10. "It's internal, so no TLS." Internal networks get breached. Encrypt service-to-service traffic.

11. Choosing protocols by hype. gRPC, GraphQL and Kafka are great tools, but each adds complexity. Use them where they solve a real problem.

Beginner

Q1. What is a communication protocol?

A set of rules two systems follow to exchange data: how messages are formatted, in what order they're sent and how errors are handled. HTTP, TCP, UDP, WebSocket and MQTT are examples.

Q2. What's the difference between TCP and UDP?

TCP sets up a connection, guarantees delivery and keeps data in order, so it's used for web pages, APIs and databases. UDP has no handshake and no delivery or ordering guarantees, so it's faster and used for video calls, games, DNS and as the base for QUIC.

Q3. What's the difference between HTTP and HTTPS?

HTTPS is HTTP sent over TLS. TLS encrypts the data, protects it from being changed and proves the server's identity with a certificate.

Q4. What is a WebSocket?

A long-lived, two-way connection where both client and server can send messages at any time. It starts as an HTTP request and upgrades. It's used for chat, games and collaborative apps.

Intermediate

Q5. REST vs gRPC: when would you use each?

REST with JSON is simple, works in browsers and is easy to cache and debug, so it suits public APIs and simple services. gRPC uses Protobuf over HTTP/2, so it's faster, strongly typed and supports streaming, which suits high-volume internal service-to-service calls. Many systems use REST at the edge and gRPC inside.

Q6. What problem does HTTP/2 solve and what problem remains?

HTTP/2 lets many requests share one connection at the same time (multiplexing) and compresses headers, fixing HTTP/1.1's one-request-at-a-time limit. But it runs on TCP, so a single lost packet still blocks all streams on that connection. HTTP/3 fixes that by running on QUIC.

Q7. How would you push live updates from server to client?

Use Server-Sent Events if only the server sends updates, since it's simple and reconnects automatically. Use WebSockets if the client also sends frequent messages. Long polling is a fallback; short polling works only for slow-changing data or small scale.

Q8. What's the difference between a message queue and pub/sub?

In a queue, each message goes to one consumer, which is good for distributing work. In pub/sub, each message goes to every subscriber group, which is good for events that many services need to react to.

Advanced

Q9. Why does gRPC need special load balancing?

gRPC uses long-lived HTTP/2 connections that carry many requests. A connection-level (layer 4) load balancer assigns a whole connection to one server, so all requests on it go there and load becomes uneven. Use request-level (layer 7) balancing, such as Envoy or client-side load balancing.

Q10. How do you design retries that don't make an outage worse?

Retry only errors that may succeed later, cap the number of attempts, use exponential backoff with jitter so clients don't retry in sync, retry at only one layer, respect Retry-After, add a circuit breaker and make write operations idempotent with keys.

Q11. What does "exactly-once delivery" really mean?

Networks can't guarantee a message is delivered exactly once in general, because a lost acknowledgement looks the same as a lost message. Systems like Kafka offer exactly-once processing within their own boundaries using transactions. End to end, the practical approach is at-least-once delivery with idempotent consumers.

Q12. What was the HTTP/2 Rapid Reset attack and what does it teach?

Attackers opened HTTP/2 streams and immediately cancelled them, over and over, making servers do work for requests that were thrown away. Google, Cloudflare and Amazon reported record request rates in 2023. It teaches that protocol features have cost models attackers can exploit, so edge software must be patched and protected with limits.

Q13. Why can adding more synchronous dependencies hurt availability?

Because the availabilities multiply. A request that needs five services, each 99.9% available, succeeds only about 99.5% of the time. Reduce the chain by calling independent services in parallel, moving non-essential work to asynchronous events, caching and using fallbacks when a dependency fails.

Scenario-based

Q14. Design the communication for a ride-hailing app's live driver location.

Drivers send GPS updates every few seconds over a lightweight channel (MQTT or a WebSocket) to an ingestion service, which publishes them to a stream like Kafka partitioned by region or ride. A location service keeps the latest position in memory or Redis. Riders watching a trip receive updates over SSE or WebSockets. Use small binary messages, drop stale updates instead of retrying them and handle reconnects with backoff.

Q15. A payment provider sometimes sends the same webhook twice and some orders were marked paid twice. How do you fix it?

Verify the signature, then store the provider's event ID with a unique constraint before processing, inside the same transaction as the order update. If the event ID already exists, return 200 and do nothing. Also make the "mark as paid" update conditional (only if the order is currently unpaid).

Q16. Checkout is slow because the order service calls five other services one after another. What would you change?

Keep only what the user must wait for in the synchronous path (stock check, payment authorization) and call independent services in parallel with timeouts. Move everything else (email, SMS, loyalty points, analytics) to an asynchronous "OrderPlaced" event using the outbox pattern, so checkout finishes as soon as the order and event are saved.

1. What are communication protocols in system design?

Communication protocols are the rules systems use to exchange data. In system design, they include transport protocols like TCP, UDP and QUIC; web protocols like HTTP and WebSockets; API styles like REST, GraphQL and gRPC; and messaging systems like Kafka, RabbitMQ (AMQP) and MQTT. Choosing them well affects speed, reliability, cost and security.

2. What is the difference between TCP and UDP in simple words?

TCP is like registered post: it confirms delivery, resends lost pieces and keeps everything in order, but it takes a moment to set up. UDP is like a loudspeaker announcement: it's instant, but there's no confirmation and no repeat. TCP suits web pages and APIs; UDP suits live video, games and DNS.

3. Is HTTP a TCP or UDP protocol?

HTTP/1.1 and HTTP/2 run over TCP. HTTP/3 runs over QUIC, which is built on top of UDP but adds its own reliability, ordering per stream and encryption. So the answer depends on the HTTP version.

4. Which is better, REST or gRPC?

Neither is better everywhere. REST is simpler, works natively in browsers and is easy to cache and debug, which makes it a good default for public APIs. gRPC is faster and more strictly typed, with built-in streaming, which makes it a strong choice for internal service-to-service communication.

5. When should I use WebSockets instead of HTTP?

Use WebSockets when the client and server both need to send messages frequently and with low delay, such as chat, multiplayer games or collaborative editing. If only the server needs to push updates, Server-Sent Events are usually simpler. For normal request-and-response actions, plain HTTP is best.

6. What is the difference between SSE and WebSockets?

Server-Sent Events are one-way, from server to client, over a normal HTTP response, with automatic reconnection built into browsers. WebSockets are two-way and use their own message format after an HTTP upgrade. SSE is simpler for notifications and live updates; WebSockets suit interactive, two-way features.

7. What is a webhook?

A webhook is an HTTP request one system sends to another when an event happens, like a payment succeeding or code being pushed. Instead of repeatedly asking for updates, you give the provider a URL to call. Webhooks should be verified with signatures and handled idempotently, because duplicates happen.

8. What is the difference between synchronous and asynchronous communication?

In synchronous communication, the caller waits for a response before continuing, as with a REST or gRPC call. In asynchronous communication, the caller sends a message, usually through a broker like Kafka or RabbitMQ and continues without waiting. Async improves resilience and scalability but makes data eventually consistent and debugging harder.

9. What is the difference between async I/O and asynchronous communication?

Async (non-blocking) I/O frees your thread while you wait for another service, but that service still has to be up and answer right away. Asynchronous communication sends the message to a broker so the receiver can process it later, even if it's down when you send. The key difference is whether both sides must be available at the same time.

10. What is the request-reply pattern in messaging?

It's a way to get a response over a message broker. The caller sends a request with a reply-to queue and a unique correlation ID, the worker sends the result back to that queue with the same ID and the caller matches replies to requests by ID. Always wait with a timeout and ignore unknown or late replies.

11. What is MQTT used for?

MQTT is a lightweight publish/subscribe protocol designed for small devices and unreliable networks. It's widely used for IoT sensors, smart home devices, vehicle telemetry and other cases where messages are small and connections are weak or expensive.

12. Why is Protobuf faster than JSON?

Protobuf is a binary format that doesn't send field names and stores numbers compactly, so messages are smaller and quicker to parse. In the example in this article, the same order took 46 bytes in Protobuf and 118 bytes in JSON. JSON is still easier to read and debug, so many teams use JSON for public APIs and Protobuf internally.

13. How do I explain communication protocols in a system design interview?

Name the protocol for each interaction and justify it: REST or GraphQL for client APIs, gRPC between services, SSE or WebSockets for live updates, webhooks for third-party events and a message broker for background work. Then mention reliability (timeouts, retries with jitter, idempotency) and security (TLS, authentication). Interviewers care most about why each choice fits.

• A protocol is an agreed set of rules for exchanging data. Protocols stack in layers and a failure low in the stack (like BGP and DNS in the Facebook outage) breaks everything above it.
• TCP is reliable and ordered; UDP is fast and unguaranteed; QUIC brings reliability and built-in encryption on top of UDP and powers HTTP/3.
• HTTP/2 multiplexes requests on one connection; HTTP/3 removes the remaining TCP-level blocking.
• REST is the simple default, GraphQL fits varied client screens and gRPC shines between services. API style and data format are separate choices.
• Protobuf messages are smaller and faster than JSON, but harder to read.
• For live updates, start with SSE; use WebSockets when both sides talk often.
• Webhooks must be signed, verified, fast to acknowledge and idempotent.
• Synchronous calls are simple but add latency and multiply failure risk across a chain; asynchronous messaging removes temporal coupling and absorbs spikes, at the cost of eventual consistency and harder debugging. Non-blocking code is not the same as asynchronous communication.
• Async messaging needs plans for duplicates, ordering per entity and failed messages (dead-letter queues).
• Timeouts, retries with jitter and idempotency keys matter more than which protocol you choose.

• Facebook Engineering, "More details about the October 4 outage", 2021.
• Google Cloud, "How it works: The novel HTTP/2 'Rapid Reset' DDoS attack", 2023.
• Cloudflare, "HTTP/2 Rapid Reset: deconstructing the record-breaking attack", 2023.
• LinkedIn Engineering, "LinkedIn Integrates Protocol Buffers With Rest.li for Improved Microservices Performance", 2023.
• InfoQ, "Why LinkedIn chose gRPC+Protobuf over REST+JSON", 2023.
• AWS Builders' Library, "Timeouts, retries and backoff with jitter".
• Stripe API documentation, "Idempotent requests".
• RabbitMQ, "Remote procedure call (RPC)" tutorial, on request-reply with reply_to and correlation_id.
• GitHub Docs, "Validating webhook deliveries".
• Protocol Buffers documentation, "Encoding".
• IETF, RFC 9000: QUIC (2021), RFC 9113: HTTP/2 (2022), RFC 9114: HTTP/3 (2022), RFC 6455: The WebSocket Protocol (2011).
• Roy Thomas Fielding, "Architectural Styles and the Design of Network-based Software Architectures," doctoral dissertation, University of California, Irvine, 2000.
• W3C, "Trace Context" recommendation.