Protocols in System Design: How Applications Actually Talk to Each Other

At 8 PM, Aanya and Rohan's premium digital wedding invitation goes live. The WhatsApp message lands in family groups, college groups, office groups, and one very active cousins group. Thousands of guests tap the same link almost together. To a guest, it feels simple: phone opens link, invitation appears, RSVP works, gallery loads, venue map opens, and a live guest counter changes. To the system, that one tap starts a conversation between many machines.

This article is about protocols in system design: the rules that let applications talk to each other. If servers are people in a wedding planning team, protocols are the language, etiquette, delivery method, and trust rules they agree on before work can happen.

We will stay inside one story: a wedding invitation platform with a landing page, couple story, photo gallery, RSVP form, meal preference, venue map, live guest counter, family chat, shuttle bus location updates, admin dashboard, and backend services. Every protocol decision will answer one practical question: what kind of conversation is happening here?

The goal is not to memorize buzzwords. The goal is to look at a feature and say, calmly, 'This should be plain HTTPS and REST,' or 'This is one-way live data, so SSE is enough,' or 'This is internal service-to-service traffic where gRPC makes sense.' That is the kind of answer interviewers trust.

1. The Mental Model: Protocols Are Conversation Contracts

A protocol is a shared contract for communication. It answers questions such as: how does the connection start, how is data formatted, how does one side know the other understood, how are errors represented, how is privacy protected, and when can old data be reused?

Beginners often mix all protocols together. A better mental model is to separate layers. TCP and UDP move data between machines. TLS secures data in transit. HTTP gives the web a request-response language. REST is a style for designing APIs on top of HTTP. SSE and WebSockets change the timing model for live updates. GraphQL and gRPC solve API shape and service-contract problems.

A senior system design answer usually starts with this split. Do not say 'we use WebSockets' for everything real-time. Do not say 'GraphQL is better than REST' as if it is a universal law. First name the conversation. Then choose the protocol.

2. TCP and UDP: The Transport Layer Choice

Before HTTP, REST, WebSockets, or GraphQL can do useful work, bytes must move between machines. TCP and UDP are two foundational ways to do that. They are not competing brands; they are different tradeoffs.

TCP: reliable delivery for important conversations

TCP is connection-oriented. The client and server establish a connection, then TCP manages ordering, acknowledgements, retransmission, flow control, and congestion control. In simple terms, TCP tries to make unreliable networks feel like a reliable stream to the application.

For Aanya and Rohan's invitation platform, TCP is the default behind HTTPS traffic. When a guest submits an RSVP, you do not want half the JSON body to disappear. When the admin updates venue timing, you do not want the server to receive fields in a confusing order. When the gallery HTML loads, the browser expects complete data.

Client -> Server: SYN
Server -> Client: SYN-ACK
Client -> Server: ACK

After this, application data can move over the established TCP connection.

Line by line, the client first asks to begin. The server acknowledges and agrees. The client confirms. That tiny setup is why TCP has more overhead than UDP, but it also gives both sides a shared context for reliable delivery.

UDP: low-latency delivery when freshness matters more

UDP is connectionless. It sends datagrams without creating a reliable stream. It does not guarantee delivery, ordering, or retransmission. That makes it faster and simpler, but it moves responsibility upward: either the application tolerates loss, or the application builds its own reliability.

Imagine a shuttle bus sending location updates every second. If one update drops, the next one arrives soon. Retrying the old location may be less useful than showing the latest location. That is UDP-style thinking: when the newest state matters more than every historical state, lower latency can be worth the tradeoff.

Interview trap: do not say UDP is always better because it is faster. Faster is only useful if the product can handle loss. A missing RSVP is not acceptable. A missing location ping might be.

3. HTTP and HTTPS: The Web's Request-Response Language

When a guest opens the invitation link, the browser speaks HTTP. HTTP defines requests, responses, methods, status codes, headers, and bodies. It is the language of the web.

A raw HTTP request

GET /dev-diaries/protocols-in-system-design-how-applications-talk-to-each-other-1080.html HTTP/1.1
Host: blog.snigdhainvitations.com
Accept: text/html
User-Agent: Browser

The first line says the method is GET and the client wants a specific path. The Host header tells the server which site the browser is asking for. Accept tells the server what response formats the browser can handle. The blank line ends the headers.

A raw HTTP response

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Cache-Control: public, max-age=300

<html>...</html>

The response starts with a status code. Headers describe the body and caching behavior. The body contains the resource representation. This shape repeats for HTML pages, CSS, JavaScript, images, JSON APIs, redirects, and errors.

HTTP is stateless

HTTP does not automatically remember the previous request. If a guest loads the invitation page and then submits RSVP, those are separate requests. The application creates continuity using cookies, sessions, tokens, database records, and request identifiers.

Statelessness is a gift for scale. If the server does not rely on local memory from a previous request, a load balancer can send request one to server A and request two to server B, as long as shared state lives in a database, cache, or signed token.

HTTPS: HTTP with TLS protection

HTTPS is HTTP over TLS. It protects data from being read or modified in transit and helps the browser verify server identity. For a wedding platform, HTTPS protects guest names, phone numbers, RSVP choices, admin sessions, and payment redirects.

Methods and status codes

Caching: speed without lying

HTTP caching is one of the most practical performance tools in system design. Gallery images, CSS, fonts, and public invitation assets can be cached aggressively because they change rarely. Private RSVP data and admin dashboards should be cached carefully or not at all.

Cache-Control: public, max-age=31536000, immutable
ETag: "gallery-v12"

The first header says the response can be reused for a long time. The ETag gives the server and client a validator. The result is simple: returning guests do not download the same large assets again unless the version changes.

4. REST and RESTful API Design: Resources, Not Random Endpoints

REST is not a synonym for JSON over HTTP. REST is an architectural style. A RESTful API models the world as resources, gives those resources stable URLs, uses HTTP methods consistently, keeps requests stateless, and makes responses cacheable where appropriate.

Think in nouns first

For the wedding platform, the nouns are invitation, guest, RSVP, meal preference, gallery photo, venue, shuttle, message, and notification. Once the nouns are clear, endpoints become predictable.

GET    /api/invitations/{invitationId}
GET    /api/invitations/{invitationId}/guests?status=confirmed&limit=50
POST   /api/invitations/{invitationId}/rsvps
PATCH  /api/rsvps/{rsvpId}
DELETE /api/gallery-photos/{photoId}

Notice that the URLs are nouns. The verbs are HTTP methods. That one habit prevents many messy APIs like /getGuests, /makeRsvp, /updateFoodNow, and /deletePhotoPlease.

Problem: the RSVP form should be retry-safe

A guest taps Submit, the network flickers, and the browser does not know whether the server received the RSVP. If the client retries blindly, you might create duplicate RSVP records. The protocol-level idea you need is idempotency.

POST /api/invitations/inv_123/rsvps HTTP/1.1
Idempotency-Key: guest_456_rsvp_2026_06_30
Content-Type: application/json

{
  "guestId": "guest_456",
  "attending": true,
  "mealPreference": "vegetarian"
}

The Idempotency-Key tells the backend that repeated attempts with the same key represent the same logical operation. The first request creates the RSVP. A duplicate retry should return the original result instead of creating another row.

Errors should be boring and useful

HTTP/1.1 422 Unprocessable Content
Content-Type: application/json

{
  "error": {
    "code": "INVALID_MEAL_PREFERENCE",
    "message": "Meal preference is not available for this event.",
    "field": "mealPreference"
  }
}

Good REST errors help the frontend show the right message, help logs group similar failures, and help interviewers see that you understand client-server contracts. Bad REST errors hide everything behind 200 OK or a vague 500.

Pagination is not optional

Every list endpoint should be paginated. A wedding invitation can begin with 50 guests and later grow to 50,000 viewers if the link goes viral. Returning every guest, every RSVP, or every notification by default is a scalability bug disguised as convenience.

GET /api/invitations/inv_123/guests?limit=50&cursor=eyJjcmVhdGVkQXQiOiIyMDI2...

Cursor pagination works well for changing datasets because it continues from a stable position instead of relying only on offset numbers that can shift as new records arrive.

5. Real-Time Communication: Polling, Long Polling, SSE, and WebSockets

Real-time is not one protocol. It is a product requirement: the user should see updates soon after they happen. The correct technical approach depends on direction, frequency, latency expectations, infrastructure, and failure behavior.

Polling: simple and often good enough

Polling means the browser asks every few seconds, 'Anything new?' It is easy to build and debug, and it works through almost every network path. The cost is wasted requests when nothing changes.

Every 15 seconds:
GET /api/invitations/inv_123/rsvp-summary

If nothing changed, server still returns a response.

Use polling when freshness can be relaxed. A planner dashboard that updates every 30 seconds may not need a persistent socket. A simple design that is reliable is often better than a complex design that nobody can operate.

Long polling: request-response stretched longer

Long polling keeps a request open until data changes or the server times out. The client then sends the next long poll. It reduces empty responses compared with simple polling, but it still uses repeated HTTP requests.

Server-Sent Events: one-way live updates

GET /api/invitations/inv_123/events HTTP/1.1
Accept: text/event-stream

HTTP/1.1 200 OK
Content-Type: text/event-stream

event: guest-count
data: {"confirmed": 218, "declined": 17}

SSE is excellent when the server needs to push updates and the browser mostly listens. Live RSVP totals, notification feeds, build progress, and admin alerts fit well. The browser EventSource API also gives helpful reconnection behavior.

WebSockets: two-way persistent conversation

GET /chat HTTP/1.1
Host: invitations.example
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: random-client-key
Sec-WebSocket-Version: 13

The connection starts as HTTP, then upgrades. After the server accepts, both sides can send messages anytime. That is why WebSockets are a natural fit for family chat, live presence, collaborative planning, and two-way event controls.

Scaling WebSockets

A single WebSocket server is straightforward. Many WebSocket servers need shared coordination. If cousin Meera sends a chat message while connected to server A, cousin Arjun might be connected to server C. Server C still needs the message. This is where Redis pub/sub, Kafka, NATS, or another broker enters the design.

Client A -> WebSocket Server 1 -> publish chat.room.123
Message broker -> WebSocket Server 2 -> Client B
Message broker -> WebSocket Server 3 -> Client C

Interviewers love this point because it separates toy WebSocket answers from production answers. Long-lived connections create load-balancer, timeout, heartbeat, reconnection, authorization, and fan-out problems.

6. Beyond REST: GraphQL and gRPC

REST is a strong default, but not every application conversation is best shaped as resources plus methods. Two common alternatives are GraphQL and gRPC. They solve different problems.

GraphQL: the client asks for the exact shape

The wedding planner dashboard may need invitation title, confirmed guest count, meal breakdown, venue coordinates, latest chat messages, and payment status on one screen. With REST, the frontend might call several endpoints or receive too much data from one large endpoint. GraphQL lets the client request exactly the fields it needs.

query PlannerDashboard($invitationId: ID!) {
  invitation(id: $invitationId) {
    title
    couple { names }
    rsvpSummary { confirmed declined pending }
    mealSummary { vegetarian vegan nonVegetarian }
    venue { name mapUrl }
  }
}

The result mirrors the query shape. That makes GraphQL friendly for complex frontend screens. The tradeoff is that backend teams must manage query cost, authorization per field, resolver performance, caching, and schema evolution.

gRPC: typed contracts for internal services

Now move inside the backend. The RSVP service needs to tell the notification service that a guest confirmed attendance. The analytics service needs aggregated events. The payment service needs a strict request and response contract. This is where gRPC can be attractive.

syntax = "proto3";

service RsvpService {
  rpc ConfirmRsvp (ConfirmRsvpRequest) returns (ConfirmRsvpResponse);
}

message ConfirmRsvpRequest {
  string invitation_id = 1;
  string guest_id = 2;
  string meal_preference = 3;
}

message ConfirmRsvpResponse {
  string rsvp_id = 1;
  bool confirmation_sent = 2;
}

The .proto file becomes the contract. Generated clients and servers know the fields and types. This is powerful for internal service-to-service systems because both sides can share a strongly typed agreement.

The mature answer is not 'replace REST.' The mature answer is 'use REST at the public edge, GraphQL where product screens need flexible data, and gRPC where internal services need fast typed contracts.'

7. Choosing the Right Protocol for the Wedding Platform

Let us map real features to communication choices. This is the part to practice for interviews because it shows judgment, not just definitions.

Notice how often the answer is not exotic. Most product features should stay on boring HTTPS with REST or carefully cached HTTP. Real-time and beyond-REST tools are powerful when a specific communication pattern justifies them.

8. Interview Answer Framework

When an interviewer asks about protocols, use this framework instead of reciting definitions:

1. Name the product behavior: read, write, live update, two-way chat, internal service call, or telemetry.

2. Name the communication direction: client to server, server to client, both directions, or service to service.

3. Name the correctness requirement: can data be lost, retried, cached, delayed, or reordered?

4. Choose the protocol and explain the tradeoff.

5. Add scaling and failure details: load balancer, cache, retry, idempotency, reconnection, pub/sub, or schema contract.

For example: 'For RSVP submission I would use HTTPS with a REST POST endpoint, validation, structured errors, and an idempotency key. I would not use WebSockets because this is a reliable write, not an ongoing two-way conversation.' That answer is simple, but it sounds senior because it is shaped by product behavior.

9. End-to-End Walkthrough: One Guest Opens the Invitation

Now let us put the protocols together in one full journey. Priya receives the wedding invitation link on her phone at 8 PM. She taps it from a chat app. The phone has a URL, not an IP address, so the browser and operating system first need to locate the server. DNS resolution happens before the web request can reach the right destination. If the domain answer is cached locally or by a resolver, the lookup is fast. If not, the resolver walks the DNS chain until it finds the authoritative answer.

Once the browser knows where to connect, it opens a secure connection. For normal HTTPS traffic, the underlying transport is TCP, and the browser establishes a connection before TLS secures it. TLS then helps the browser verify that it is really talking to the right site and creates encrypted communication. Only after that foundation exists does HTTP begin carrying page requests and responses.

The first visible feature is the invitation page. The browser sends a GET request for the route. The edge layer or CDN may already have a cached version of public page assets. HTML might come from the application server, while images, fonts, CSS, and JavaScript are served from a nearby CDN edge. This is why a well-designed public page can survive traffic spikes better than a page that forces every asset through the origin server.

When Priya scrolls the photo gallery, HTTP caching becomes important. The platform can serve optimized images with long cache lifetimes if filenames are content-hashed. If Aanya and Rohan later replace a gallery image, the system can publish a new asset URL rather than forcing every browser to guess whether the old URL changed. This is a protocol-aware content strategy, not just a frontend trick.

Next Priya submits her RSVP. This is not a cacheable read; it is a reliable state-changing write. The frontend sends a POST request over HTTPS to a REST endpoint. The server validates guest identity, checks whether the RSVP window is open, validates meal preference, writes the result in a transaction, and returns a structured success response. If the browser times out and retries, an idempotency key can prevent duplicate RSVP creation.

After the RSVP is saved, the admin dashboard should show the new confirmed count. There are several choices. If the dashboard only needs fresh data every 15 or 30 seconds, polling is fine. If the planner wants immediate one-way updates, SSE is a clean fit. If the dashboard also allows collaborative comments, presence, or live chat between planners, WebSockets may be justified. Notice that the same product area can contain more than one communication pattern.

Then Priya opens the family chat to ask about the dress code. This is a different problem. The browser and server both need to send messages whenever something happens. WebSockets fit because the connection stays open and supports bidirectional messages. But production design does not stop at the socket. The system must authenticate the connection, authorize the room, send heartbeats, reconnect safely, persist message history, and broadcast across multiple servers.

Later, the wedding shuttle starts moving from the hotel to the venue. The location stream is freshness-heavy. If an update from five seconds ago is lost, retrying it may be less valuable than sending the current position. A native mobile app might use UDP-based protocols or a telemetry pipeline; a browser implementation might still receive processed updates through SSE or WebSockets. The deeper lesson is that product semantics guide the protocol, not the protocol name.

Inside the backend, the RSVP service may call a notification service, analytics service, and audit service. These are not browser-facing conversations. If the team controls both sides and wants typed contracts, gRPC can work well. If the notification does not need to happen inline, an asynchronous message queue can decouple the RSVP write from email or WhatsApp delivery. Protocol choice and architecture choice meet here.

By the time Priya closes the page, a single tap has involved DNS, TCP, TLS, HTTP, caching, REST, maybe SSE, maybe WebSockets, and maybe gRPC behind the scenes. A beginner sees many names. A system designer sees a sequence of communication needs: locate, connect, secure, request, cache, write, push, converse, broadcast, and coordinate.

10. Common Protocol Mistakes Beginners Make

Mistake 1: choosing WebSockets for every live-looking feature

WebSockets are useful, but they are not free. They create long-lived connections, require heartbeat logic, need reconnection behavior, and complicate load balancing. If the feature is a live counter that only moves from server to browser, SSE may be simpler. If the feature can tolerate delay, polling may be even better.

Mistake 2: treating REST as any endpoint that returns JSON

An endpoint named /processRsvpAndSendEverything can return JSON, but that does not make the API RESTful. REST asks you to model resources, use HTTP methods intentionally, keep requests stateless, and represent errors clearly. The resource model is the design discipline.

Mistake 3: forgetting idempotency on unreliable networks

Networks fail in boring ways: a request succeeds on the server but the response never reaches the browser. Without idempotency, retrying payment, RSVP, booking, or notification requests can create duplicate state. Senior engineers design retries before failures happen.

Mistake 4: using UDP because it sounds faster

UDP can be faster because it avoids reliability overhead, but speed without correctness is not a win for important writes. Use UDP-style designs when the product can tolerate loss or replace old information with new information. Do not use it for data that must be recorded exactly once.

Mistake 5: ignoring caching rules

Caching can make a system feel instant, but incorrect caching can leak private data or show stale business state. Public gallery assets and static page bundles can be cached aggressively. Admin data, personalized pages, and RSVP state need stricter controls.

Mistake 6: confusing authentication with authorization

Authentication answers who the user is. Authorization answers what that user can do. Protocols carry cookies, tokens, headers, and requests, but the application must still enforce permissions. A logged-in guest should not become an admin just because the request format looks valid.

Mistake 7: forgetting load balancers in real-time design

A local WebSocket demo connects to one server and works beautifully. Production usually has many servers. The load balancer must support upgrades and timeouts, and the backend needs a broadcast layer so messages reach users connected to different instances.

Mistake 8: assuming GraphQL removes backend complexity

GraphQL can simplify frontend data fetching, but it can move complexity into resolvers, permissions, query planning, and caching. A single flexible query can become an expensive backend fan-out if the schema is not designed carefully.

Mistake 9: exposing gRPC directly just because services use it internally

gRPC is excellent for controlled internal systems, but public browser clients and third-party integrations often need simpler HTTP-friendly contracts. A gateway, BFF, REST layer, or GraphQL layer can protect internal service design from public API constraints.

Mistake 10: answering protocol questions without product context

Interviewers are not only checking definitions. They are checking judgment. A good answer names latency, reliability, direction, payload shape, cacheability, failure mode, and operational cost. The correct protocol is the one that fits those constraints.

11. Interview-Ready Scenario Answers

The fastest way to sound confident in a system design interview is to convert a product feature into a protocol decision out loud. Below are sample answers you can adapt. Notice that each answer names the feature, the communication shape, the protocol choice, and the tradeoff.

Scenario: design RSVP submission

I would use HTTPS with a REST POST endpoint for initial RSVP submission and PATCH for later edits. The request is a reliable client-to-server write, so I want TCP-backed HTTPS rather than a lossy transport. I would validate fields at the API boundary, write state transactionally, return structured errors, and use an idempotency key so browser retries do not create duplicate RSVPs. I would not use WebSockets here because the client is not having an ongoing two-way conversation; it is sending a specific command and waiting for a result.

Scenario: design a live RSVP counter

For a live RSVP counter, I would first ask how fresh it needs to be. If a delay of 15 or 30 seconds is acceptable, polling keeps the system simple. If planners want updates almost immediately and the data flows only from server to browser, I would use Server-Sent Events. SSE is simpler than WebSockets for one-way updates and works naturally over HTTP. I would include reconnect behavior and event IDs if missing an update would confuse the dashboard.

Scenario: design family chat

For family chat, I would use WebSockets because both client and server need to send messages at unpredictable times. The connection should be authenticated during setup and authorized for a specific invitation or chat room. At small scale, one WebSocket server can handle the room. At larger scale, multiple WebSocket servers need a shared pub/sub or message broker so users connected to different servers still receive the same messages. Message history should be persisted separately from the live socket path.

Scenario: design the admin planner dashboard

For the dashboard, I would compare REST and GraphQL. If the dashboard has a few stable panels, REST endpoints such as /summary, /meal-counts, and /recent-rsvps are easy to cache and reason about. If the dashboard has many configurable widgets that need different nested fields, GraphQL may reduce over-fetching and under-fetching. I would add query cost limits, authorization at field or resolver boundaries, and metrics for slow resolvers.

Scenario: design internal service communication

Inside the backend, I would consider gRPC for synchronous service-to-service calls where teams control both sides and want typed contracts. For example, the RSVP service can call a notification service using a protobuf-defined method. But if notification delivery can happen later, I might prefer an asynchronous queue so RSVP writes are not blocked by email or WhatsApp delays. The interview point is to separate public API protocol from internal service protocol.

Scenario: design shuttle tracking

For shuttle tracking, I would identify whether every location point must be preserved. Usually the latest position matters more than old positions, so low latency and freshness matter. Native apps may use UDP-based approaches, while browser clients might receive processed updates through SSE or WebSockets. I would store periodic snapshots for history, drop stale updates, and design the UI to show last-updated time so users understand freshness.

Scenario: choose between REST, GraphQL, and gRPC

My answer would be: REST is the public default for resources and broad compatibility, GraphQL is useful when client screens need flexible nested data, and gRPC is strong for internal typed service contracts. I would not frame them as a ladder from old to new. Mature systems often combine them: REST or GraphQL at the edge, gRPC or queues inside, and HTTP caching or CDN behavior for static public content.

These scenario answers are not scripts to memorize word for word. They are patterns. Start from the user experience, describe the communication shape, choose the protocol, and then name the failure behavior. That is how you move from definition-level answers to system-design-level answers.

In real interviews, this product-first framing also helps you recover when you forget a definition. You can reason from reliability, latency, direction, and ownership, then land on the protocol with confidence.

TCP and UDP Interview Questions

What is TCP in simple words?

TCP is a transport protocol that tries hard to deliver data completely, in order, and without silent corruption. In the invitation story, TCP is what you want for login, RSVP submission, payment confirmation, gallery metadata, and admin actions. The application can trust that if the connection succeeds, bytes arrive in a controlled stream rather than random fragments.

Why does TCP need a connection?

TCP creates shared state between client and server before real data moves. That state tracks sequence numbers, acknowledgements, retransmission, congestion behavior, and flow control. This setup costs a little time, but it is exactly what makes TCP useful when losing a request would create wrong business state, such as recording the wrong meal preference.

What is the TCP three-way handshake?

The handshake is SYN, SYN-ACK, ACK. The client asks to start, the server agrees and acknowledges, and the client confirms. Interviewers ask this because it proves you know that reliable communication is not magic; it starts with both sides agreeing that a connection exists and that future bytes belong to that connection.

How does TCP provide reliability?

TCP numbers bytes, asks for acknowledgements, retransmits missing data, checks integrity, and controls how much data can be in flight. If a packet disappears on the way to the RSVP service, TCP can recover below the application layer. Your REST handler does not need to reassemble raw packets; it receives a stream.

What does ordered delivery mean in TCP?

Ordered delivery means the application receives data in the same logical sequence in which it was sent. If parts of a request arrive out of order at the network level, TCP waits and reorders before handing the stream upward. This matters when request bodies, uploads, or response payloads must be interpreted from start to finish.

What is UDP in simple words?

UDP is a lightweight transport protocol that sends datagrams without creating a reliable connection first. It does not promise delivery, ordering, or retransmission. That sounds scary until you remember that some features value freshness more than completeness, such as live bus location pings where a newer location replaces an old one.

Why is UDP faster than TCP?

UDP avoids the connection setup, acknowledgements, ordering guarantees, and retransmission behavior that make TCP reliable. Less coordination means lower overhead and often lower latency. The tradeoff is that the application, or the product experience, must tolerate missing or out-of-order updates.

When should I choose TCP over UDP?

Choose TCP when correctness matters more than the absolute lowest latency. Authentication, checkout, RSVP writes, admin dashboards, content delivery, API calls, database connections, and most web browsing use TCP because users expect complete and consistent results.

When should I choose UDP over TCP?

Choose UDP when timely delivery is more important than guaranteed delivery and the system can tolerate loss. Voice, video, game state, telemetry, DNS lookups, and live location updates often fit this pattern. In the wedding platform, UDP-like thinking fits a shuttle location dot better than a payment receipt.

Does HTTP use TCP or UDP?

Traditional HTTP/1.1 and HTTP/2 run over TCP. HTTP/3 runs over QUIC, which uses UDP while adding reliability, streams, encryption, and congestion behavior above UDP. In interviews, keep the answer precise: HTTP itself is an application protocol; the transport below it depends on the HTTP version.

Why does DNS often use UDP?

DNS queries are usually small request-response messages, so UDP keeps lookup latency low. DNS can use TCP when responses are large or for zone transfers. This is a good example of protocol choice matching payload size, latency goals, and reliability needs rather than one protocol always winning.

Can UDP be made reliable?

Yes, an application can build acknowledgements, retries, ordering, or forward error correction above UDP. QUIC is the famous modern example. But once you add reliability yourself, you must own the complexity. That is why many application features simply use TCP unless they have a strong reason not to.

What is packet loss?

Packet loss means data sent across the network never reaches the destination, often because of congestion, routing issues, wireless problems, or overloaded devices. TCP hides many losses through retransmission. UDP exposes loss unless the application has its own recovery strategy.

How do firewalls affect TCP and UDP?

Firewalls can allow, block, inspect, or rate-limit traffic by protocol, port, direction, and policy. TCP is often easier for middleboxes to track because it has connection state. UDP can be more restricted in corporate networks, which is one reason fallback planning matters for real-time systems.

HTTP and HTTPS Interview Questions

What is HTTP?

HTTP is an application-layer protocol that defines how clients request resources and how servers respond. A browser asks for a page, image, script, or API result; the server answers with status, headers, and a body. HTTP gives web traffic a common language.

Why is HTTP called stateless?

HTTP is stateless because each request is independent at the protocol level. The server does not automatically remember the previous request. Applications create continuity with cookies, sessions, tokens, databases, and caches. That separation is why web systems can scale horizontally across many servers.

What is HTTPS?

HTTPS is HTTP protected with TLS. The request-response shape is still HTTP, but the connection adds encryption, identity verification, and integrity protection. For RSVP data, guest names, phone numbers, admin logins, and payment flows, HTTPS is not an optional polish; it is a baseline.

What are HTTP methods?

HTTP methods describe the intent of a request. GET reads, POST creates or triggers processing, PUT replaces, PATCH partially updates, and DELETE removes. Good API design uses methods consistently so clients can reason about safety, idempotency, retries, and caching.

What are HTTP status codes?

Status codes are compact result signals. 2xx usually means success, 3xx means redirect, 4xx means the client request has a problem, and 5xx means the server failed. A clean system uses status codes and response bodies together so failures are debuggable.

What is the difference between 401 and 403?

401 means the client is not authenticated or the credentials are missing or invalid. 403 means the server understands who the user is but refuses the action. In the wedding platform, a guest without login might get 401, while a logged-in guest trying to open admin analytics might get 403.

What is the difference between 301 and 302?

301 indicates a permanent redirect, while 302 indicates a temporary redirect. Permanent redirects influence caches and search engines more strongly. For article slug changes, use permanent redirects only when you are confident the old URL should permanently point to the new URL.

How does HTTP caching work?

HTTP caching uses headers such as Cache-Control, ETag, Last-Modified, Expires, and validators to decide whether a stored response can be reused. For gallery assets and static invitation themes, caching saves bandwidth and improves perceived speed. For RSVP status, caching must be conservative.

What are cookies used for?

Cookies store small pieces of browser-side state that are sent with matching requests. They commonly carry session identifiers, preferences, or security tokens. Cookies need careful flags such as HttpOnly, Secure, SameSite, domain, and expiration because they sit in the path of authentication.

What are common HTTP security risks?

Common risks include sending sensitive data without HTTPS, weak cookies, CSRF, XSS, broken authorization, insecure CORS, leaking tokens in URLs, and overly permissive caching. Protocol knowledge helps because many security bugs are really misunderstandings of request boundaries and browser behavior.

REST and RESTful API Design Interview Questions

What is REST?

REST is an architectural style for designing networked applications around resources, representations, stateless requests, and a uniform interface. In practice, RESTful APIs usually expose URLs for nouns such as guests and RSVPs, then use HTTP methods to perform actions on those resources.

What is the difference between REST and RESTful?

REST is the style and set of constraints. RESTful describes an API that follows those constraints well enough in real implementation. An API can use HTTP and JSON but still feel un-RESTful if every endpoint is a verb tunnel such as /doThing or /processEverything.

What are the main REST constraints?

The classic constraints include client-server separation, statelessness, cacheability, uniform interface, layered system, and optional code on demand. Most interview conversations focus on the first five because they directly affect API design, scaling, caching, and operational boundaries.

What is a resource in REST?

A resource is a thing the API exposes, such as an invitation, guest, RSVP, menu option, venue, gallery photo, or notification. The client interacts with resource representations, usually JSON. Thinking in resources keeps the API stable as backend internals evolve.

How should REST endpoints be named?

Use nouns, plural collections, predictable nesting, and clear identifiers. For example, /invitations/{id}/guests reads better than /getGuestList. The URL should describe the resource; the HTTP method should describe the action.

When should I use GET?

Use GET for safe reads that do not change server state. GET is cache-friendly, bookmarkable, and retry-friendly. A guest viewing an invitation, fetching venue details, or loading the gallery should usually use GET.

When should I use POST?

Use POST to create a subordinate resource or trigger processing when the result is not naturally idempotent. Submitting a new RSVP, creating a comment, or starting a payment intent often uses POST because each request may produce new server-side state.

When should I use PUT?

Use PUT when the client replaces a resource representation at a known URL. PUT is normally idempotent: sending the same full replacement twice should leave the resource in the same final state. It is less common in UI-heavy apps than PATCH, but useful for clear replacements.

When should I use PATCH?

Use PATCH for partial updates. If a guest changes only meal preference from vegetarian to vegan, PATCH lets the client send the changed field instead of replacing the entire RSVP. This is common for forms and profile-like resources.

When should I use DELETE?

Use DELETE to remove or deactivate a resource. In production systems, DELETE might perform a soft delete for audit and recovery rather than physically removing the row. The API contract should make the expected behavior clear.

What is idempotency?

An operation is idempotent when repeating it produces the same final state. GET, PUT, and DELETE are expected to be idempotent in HTTP semantics. POST is not automatically idempotent, so payment and RSVP submissions often use idempotency keys to make retries safe.

How should REST APIs handle errors?

Use the right status code and return a structured body with a stable error code, human message, and field details when needed. Do not make every error a 200 response. Clean errors help frontend teams, mobile apps, observability tools, and interviewers trust your API design.

How should REST APIs handle validation?

Validate input at the boundary before business logic mutates state. Return 400 or 422 depending on your API convention, and include field-level messages. For an RSVP form, invalid phone number, missing guest name, or unsupported meal option should fail before writing partial state.

How should pagination work in REST?

Large collections should be paginated with page-based, offset-based, or cursor-based patterns. Cursor pagination is strong for changing datasets because it avoids duplicates and skips caused by inserts. A guest list with thousands of entries should never return everything by default.

How should filtering and sorting work?

Filtering and sorting usually belong in query parameters: /guests?status=confirmed&sort=createdAt_desc. Keep names stable and documented. Avoid letting arbitrary database fields pass through unchecked because that can create performance and security problems.

How should REST APIs be versioned?

Common approaches include URL versioning, header versioning, or compatibility-first evolution without explicit versions for small changes. The best answer depends on client diversity and release control. Public APIs often need clearer versions than tightly controlled internal APIs.

How does authentication work in REST APIs?

REST APIs commonly use session cookies, bearer tokens, OAuth flows, or signed service tokens. Authentication proves identity; authorization checks whether that identity can perform the requested action. Do not confuse the two in interviews.

Can REST responses be cached?

Yes, especially GET responses that are public or safely reusable. Use Cache-Control, ETags, and validation strategies. But private guest data, admin dashboards, and fast-changing RSVP counts need stricter cache rules to prevent stale or leaked information.

What is HATEOAS?

HATEOAS means the response includes links or actions that tell the client what it can do next. Many modern APIs do not fully implement it, but the idea is useful: clients should not have to guess every possible transition. It can be helpful in workflow-heavy systems.

What is REST over-fetching?

Over-fetching happens when a REST endpoint returns more data than a client needs. A mobile RSVP screen might need guest name and status, but the endpoint returns full invitation, gallery, venue, and audit data. Over-fetching wastes bandwidth and can leak unnecessary fields.

What is REST under-fetching?

Under-fetching happens when the client must call many endpoints to assemble one screen. A dashboard might need invitation stats, meal counts, bus status, and recent messages. If REST endpoints are too tiny, the frontend pays with extra latency and coordination.

How do REST and SOAP differ?

SOAP is a protocol with strict XML messaging, formal contracts, and standards around security and transactions. REST is an architectural style commonly implemented with HTTP and JSON. REST is often simpler for web APIs, while SOAP still appears in legacy enterprise integrations.

Is REST always the best API choice?

No. REST is a strong default for public resource APIs, CRUD workflows, and broad compatibility. But GraphQL may fit flexible client-driven reads, gRPC may fit internal high-performance services, and WebSockets may fit two-way real-time experiences.

Real-Time Communication Interview Questions

What is polling?

Polling means the client asks the server at regular intervals whether something changed. It is simple and works almost everywhere, but it can waste requests when nothing changes. Use it for low-frequency updates where a few seconds of delay is acceptable.

What is long polling?

Long polling means the client sends a request and the server holds it open until there is new data or a timeout. After a response, the client immediately opens another request. It feels more real-time than simple polling but still uses request-response mechanics.

What is Server-Sent Events?

Server-Sent Events, or SSE, is a browser-friendly way for the server to push a stream of text events to the client over HTTP. It is one-way: server to browser. It is great for live counters, notifications, progress updates, and dashboard feeds that do not need client-to-server chat.

What are WebSockets?

WebSockets create a persistent, full-duplex connection after an HTTP upgrade handshake. Both client and server can send messages whenever they need. This fits chat, collaboration, live games, presence, and other features where two-way low-latency communication matters.

When should I choose SSE over WebSockets?

Choose SSE when updates are mostly one-way from server to client and you want simpler browser behavior, automatic reconnection, and normal HTTP infrastructure. A live RSVP count or event progress stream is a better SSE candidate than a family chat room.

When should I choose WebSockets over SSE?

Choose WebSockets when both sides need to send messages independently or very frequently. Family chat, collaborative editing, live support, multiplayer interactions, and bidirectional control channels are natural fits. The cost is connection management and scaling complexity.

How does a WebSocket handshake work?

A browser starts with an HTTP request asking to upgrade the connection. If the server accepts, the connection switches from normal HTTP request-response to the WebSocket protocol. This is why WebSockets still begin in familiar web infrastructure but behave differently afterward.

How do load balancers affect WebSockets?

WebSockets are long-lived, so load balancers must support connection upgrades and timeouts. Some systems use sticky sessions so one client stays on one server. Larger systems usually add shared pub/sub or message brokers so any server can broadcast events consistently.

How do real-time systems handle reconnection?

Clients need backoff, retry limits, and a way to resume from the last known event when possible. Servers need heartbeats, timeout cleanup, and idempotent handling. A real-time feature is not complete just because the happy-path socket opens once.

How do you scale real-time chat?

You typically run multiple WebSocket servers behind a load balancer and connect them through Redis pub/sub, Kafka, NATS, or another broker. Presence, message ordering, authorization, history persistence, and replay strategy become part of the design.

Is real-time always necessary?

No. Real-time adds operational cost. If a user only needs fresh data every 30 seconds, polling may be enough. The senior answer is to match freshness requirements to product value instead of adding WebSockets because they sound advanced.

Beyond REST Interview Questions

What is GraphQL?

GraphQL is a query language and runtime for APIs where the client asks for the exact data shape it needs. Instead of calling many REST endpoints, a planner dashboard can request invitation title, guest counts, meal breakdowns, and venue summary in one query.

Why do teams use GraphQL?

Teams use GraphQL to reduce over-fetching and under-fetching, support multiple clients with different data needs, and evolve API fields more flexibly. It is especially useful when frontend screens need nested data from many backend sources.

What are GraphQL drawbacks?

GraphQL can make caching, authorization, rate limiting, and query cost control harder than simple REST. A flexible query surface is powerful, but it needs depth limits, complexity limits, observability, schema discipline, and careful resolver performance.

What is gRPC?

gRPC is a high-performance RPC framework that usually uses Protocol Buffers to define service contracts and messages. It works well for internal service-to-service communication where teams control both client and server and value strict contracts and speed.

What are Protocol Buffers?

Protocol Buffers, or protobuf, are a compact language-neutral way to define structured messages. A .proto file becomes the contract. Code generators create client and server types so services agree on fields and types before runtime.

Why is gRPC fast?

gRPC commonly uses HTTP/2, binary protobuf payloads, multiplexed streams, and generated clients. That combination reduces payload size and improves service-to-service efficiency. The speed benefit matters most at internal scale, not necessarily for every public browser endpoint.

Why is gRPC not usually called directly from browsers?

Browsers do not expose the full low-level HTTP/2 control that native gRPC expects. Teams use gRPC-Web, gateways, or a BFF layer when browser clients need access. Public web products often keep REST or GraphQL at the edge and gRPC behind it.

REST vs GraphQL vs gRPC: which should I choose?

Use REST for broad resource APIs and simple compatibility, GraphQL for flexible client-driven reads, and gRPC for internal high-performance service contracts. A real architecture can use all three in different places. The right comparison is by use case, not popularity.

Can GraphQL replace REST?

GraphQL can replace some REST read endpoints, especially for complex screens, but it does not automatically replace every API need. File uploads, webhooks, simple public resources, cache-heavy pages, and operational endpoints may still be clearer with REST.

Can gRPC replace REST?

gRPC can replace REST inside a controlled backend, but it is not always ideal for public browser APIs or simple integrations. A common architecture is REST or GraphQL at the public edge and gRPC between internal services.

Final Cheat Sheet

The best protocol is not the newest one. It is the one that matches the conversation. If you remember only one line from this article, remember this: system design is not about picking advanced tools; it is about choosing the right contract between moving parts.

Official References Checked

• https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Overview

• https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Caching

• https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods

• https://developer.mozilla.org/en-US/docs/Web/HTTP/Status

• https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events

• https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API

• https://graphql.org/learn/

• https://grpc.io/docs/what-is-grpc/introduction/

• https://protobuf.dev/overview/

• https://www.rfc-editor.org/rfc/rfc9293

• https://www.rfc-editor.org/rfc/rfc768

• https://www.rfc-editor.org/rfc/rfc6455

• https://www.rfc-editor.org/rfc/rfc9110