Episode 1 — Fundamentals / 1.2 — Client Server Architecture

Interview Questions: Client-Server Architecture

Practice questions with model answers for client-server, HTTP, frontend/backend, hosting, and related topics commonly asked in software engineering interviews.

How to use this material (instructions)

Read lessons in order — README.md, then 1.2.a → 1.2.g.
Practice out loud — aim for 1–2 minutes per question, then compare to the model answer.
Structure answers — definition → example → trade-off/security note.
Pair with exercises — 1.2-Exercise-Questions.md.
Quick review — 1.2-Quick-Revision.md.

Beginner (Q1–Q8)

Q1. What is client-server architecture?

Why interviewers ask: Tests whether you understand the most basic pattern that powers the web.

Model answer:

Client-server architecture is a distributed computing model where work is split between two roles:

Clients initiate requests — they ask for data, pages, or actions (e.g. a browser, a mobile app, a CLI tool).
Servers listen for those requests, process them (auth, business logic, database queries), and send back responses.

The client and server communicate over a network using protocols like HTTP/HTTPS. Many clients can connect to the same server; one client can talk to many servers over time. The most common architecture on the web is 3-tier: client → application server → database.

ASCII summary:

Client (browser/app)  ──request──►  Server (API/logic)  ──query──►  Database
                     ◄──response──                     ◄──data───

Q2. What is the difference between a client and a server?

Model answer:

Aspect	Client	Server
Role	Initiates requests; displays UI	Listens, processes, responds
Location	User's device (laptop, phone)	Datacenter, cloud, managed platform
Software	Browser, mobile app, CLI	Nginx, Express, Django, database processes
Who initiates?	Client always starts the conversation	Server responds (may push via WebSockets/SSE)
Trust level	Untrusted — user can inspect/modify anything	Trusted — enforces rules, holds secrets
Examples	Chrome loading a page	Nginx + Node.js API + PostgreSQL

Key distinction: The client is for experience (what the user sees); the server is for truth (who you are, what you're allowed to do, what data exists).

Q3. What is HTTP and how does the request/response cycle work?

Why interviewers ask: HTTP is the backbone of the web — this checks foundational knowledge.

Model answer:

HTTP (HyperText Transfer Protocol) is the application-layer protocol that browsers and servers use to exchange data. It is:

Stateless — each request is independent; the server doesn't remember previous requests
Text-based (HTTP/1.x) — human-readable headers
Request–response — client sends a request; server returns one response

The cycle:

Client builds an HTTP request: method (GET/POST/PUT/DELETE), URL path, headers (Host, Accept, Cookie, Authorization), optional body
Request travels over TCP (+ TLS for HTTPS)
Server receives, parses, and processes the request (routing, auth, DB query, template rendering)
Server sends an HTTP response: status code (200, 404, 500), headers (Content-Type, Cache-Control, Set-Cookie), body (HTML, JSON, image)
Client handles the response — renders HTML, processes JSON, displays errors

Browser                               Server
   │                                     │
   │── GET /api/users HTTP/1.1 ────────►│
   │   Host: api.example.com            │
   │   Accept: application/json          │
   │                                     │  query DB, build response
   │◄── HTTP/1.1 200 OK ────────────────│
   │    Content-Type: application/json   │
   │    {"users": [...]}                 │

Q4. What happens when you type a URL in the browser and press Enter?

Why interviewers ask: The single most common "whole stack" question. Tests whether you can connect DNS, TCP, TLS, HTTP, and rendering.

Model answer (structured walkthrough):

URL parsing — Browser splits the URL into scheme, host, path, query, fragment. Checks HSTS to force HTTPS if needed.
DNS resolution — Resolve hostname to IP: browser cache → OS cache → router → ISP recursive resolver → root → TLD → authoritative nameserver.
TCP connection — Three-way handshake: SYN → SYN-ACK → ACK (1 RTT).
TLS handshake — If HTTPS: ClientHello → ServerHello + certificate + key exchange → encrypted channel (1 additional RTT with TLS 1.3).
HTTP request — GET /path HTTP/1.1 with Host, cookies, Accept headers.
Server processing — Route request → auth → business logic → DB query → build response.
HTTP response — Status 200 + headers + HTML body (compressed with gzip/brotli).
Parsing & rendering — HTML → DOM; CSS → CSSOM; DOM + CSSOM → Render Tree → Layout → Paint → Composite.
Subresource loading — CSS, JS, images, fonts discovered during parsing → each triggers its own HTTP cycle.
JavaScript execution — Scripts run; event listeners attached; API calls fired; page becomes interactive.

Total time: ~100–500ms on a fast connection; 3–8 seconds on slow 3G.

Q5. What is the difference between front-end and back-end?

Model answer:

Dimension	Front-end	Back-end
Also called	Client-side	Server-side
What it does	UI, interactions, animations, client validation	Business logic, auth, database, API, security enforcement
Runs where	Browser (or native app)	Server, container, serverless function
Languages	HTML, CSS, JavaScript/TypeScript	Python, Node.js, Java, Go, Ruby, PHP, C#, Rust
Frameworks	React, Vue, Angular, Svelte	Express, Django, Spring Boot, Rails, Laravel, FastAPI
Security	XSS, token leaks, dependency supply chain	SQL injection, auth bypass, secret management, SSRF

Restaurant analogy: Front-end is the dining room (ambiance, menu card, how the waiter speaks). Back-end is the kitchen (recipes, ingredients, food safety). The API is the waiter carrying orders and plates.

Full-stack means working across both — owning features from UI to database.

Q6. What is the difference between a static website and a dynamic website?

Model answer:

	Static Website	Dynamic Website
HTML produced	Pre-built files served as-is	Generated per request from code + data
Server work	File lookup only	Code execution, DB queries, template rendering
Personalization	None at origin (can add via client JS or APIs)	Natural (sessions, roles, per-user content)
Speed	Very fast (CDN-friendly, predictable)	Variable (depends on server processing)
Cost	Cheap at scale (no compute per request)	Compute + DB costs scale with traffic
Content updates	Redeploy/rebuild	Update data in DB, instant
Examples	Portfolio, docs, blog, landing page	Social feed, dashboard, e-commerce, SaaS

Modern spectrum: SSG (build-time static) → ISR (static + background regen) → SSR (per-request) → CSR (browser-rendered from API). Many sites mix models per route.

Q7. What is web hosting?

Model answer:

Web hosting is the service of storing your website's files and code on a server connected to the internet 24/7 so anyone can access them. The hosting provider gives you:

Server space (disk/SSD for files and databases)
Compute (CPU/RAM for server-side code)
Bandwidth (data transfer capacity)
Public IP (so the internet can reach your server)
Uptime guarantee (e.g. 99.9% = ~8.7 hours downtime/year)
Security (firewalls, DDoS protection, SSL certificates)

Types of hosting:

Type	One-liner
Shared	Many sites on one server; cheapest; limited control
VPS	Virtual machine with guaranteed resources; root access
Dedicated	Entire physical machine; maximum performance
Cloud	Pool of virtual servers; scales on demand; pay-as-you-go
Static hosting	Files only, served via CDN (Vercel, Netlify, GitHub Pages)
PaaS	Platform manages infrastructure; you deploy code (Render, Heroku)
Serverless	Functions run on demand; no idle cost (Lambda, Cloudflare Workers)

Domain + Hosting: A domain name (example.com) is the address; hosting is the building. DNS records (A, CNAME) connect the address to the building.

Q8. What is an API?

Model answer:

An API (Application Programming Interface) is a contract between two pieces of software — it defines what you can ask for and what format the answers come in. In web development, it usually means an HTTP API where the front-end sends requests to the back-end and receives structured data (usually JSON).

Common API styles:

Style	Key idea
REST	Resources as URLs, standard HTTP methods, stateless, JSON responses
GraphQL	Single endpoint; client specifies exactly what data it wants; schema-driven
gRPC	Binary protocol (Protocol Buffers); fast; strong typing; used for service-to-service
WebSocket	Persistent two-way connection; real-time updates (chat, live feeds)

Intermediate (Q9–Q15)

Q9. What is the difference between HTTP and HTTPS?

Model answer:

HTTP sends data in plain text — anyone on the network path can read or alter it (man-in-the-middle attack).
HTTPS is HTTP over TLS — it provides encryption (confidentiality), integrity (tamper detection), and authentication (server proves identity via X.509 certificate).

The server needs a TLS certificate (often from Let's Encrypt, free). HSTS forces HTTPS even if the user types http://. Modern browsers mark HTTP-only sites as "Not Secure."

Q10. Explain the most common HTTP status codes.

Model answer:

Code	Name	Meaning
200	OK	Success; body contains the result
201	Created	Resource created successfully; often includes `Location` header
204	No Content	Success; no body (e.g. delete succeeded)
301	Moved Permanently	Resource has a new permanent URL (SEO: update links)
302	Found	Temporary redirect
304	Not Modified	Cached copy is still valid; use it
400	Bad Request	Malformed request (missing fields, bad syntax)
401	Unauthorized	Authentication required or failed ("who are you?")
403	Forbidden	Authenticated but not allowed ("I know who you are; you can't")
404	Not Found	Resource doesn't exist
429	Too Many Requests	Rate limited; often includes `Retry-After`
500	Internal Server Error	Server bug/crash
502	Bad Gateway	Proxy/gateway got invalid response from upstream
503	Service Unavailable	Overload or maintenance

401 vs 403: 401 = authentication problem (missing/invalid credentials). 403 = authorization problem (credentials are valid but you're not allowed).

Q11. What is CORS?

Model answer:

CORS (Cross-Origin Resource Sharing) is a browser-enforced security mechanism based on the Same-Origin Policy. Browsers block JavaScript from reading responses from a different origin unless the server explicitly allows it.

An "origin" is defined by: scheme + host + port (e.g. https://app.example.com:443).

How it works:

Browser sends request with Origin header
For "non-simple" requests (custom headers, PUT/DELETE, etc.), browser sends an OPTIONS preflight first
Server responds with Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Headers
If the response headers allow the origin, browser lets JavaScript access the response

Key point: CORS is a browser constraint. curl, Postman, and server-to-server calls are not restricted by CORS.

Q12. What is the difference between cookies, localStorage, and sessionStorage?

Model answer:

	Cookies	localStorage	sessionStorage
Size	~4KB per cookie	~5–10MB	~5–10MB
Sent with requests	Yes (automatically via `Cookie` header)	No (must be sent manually in JS)	No
Expiration	`Expires`/`Max-Age` or session	Never (persists until cleared)	Tab/window close
Accessible from	Server (via headers) + client (JS, unless `HttpOnly`)	Client JS only	Client JS only
Use case	Sessions, auth tokens, tracking	User preferences, cached data	Temporary form data

Security: Cookies with HttpOnly cannot be accessed by JavaScript (protects against XSS). Always use Secure (HTTPS only) and SameSite (CSRF protection).

Q13. Explain the browser rendering pipeline.

Model answer:

When the browser receives HTML, it goes through the critical rendering path:

Parse HTML → Build DOM (Document Object Model) tree
Parse CSS → Build CSSOM (CSS Object Model) tree
Combine DOM + CSSOM → Render Tree (only visible elements)
Layout (Reflow) → Calculate size and position of every element
Paint → Fill in pixels: colors, text, borders, shadows, images
Composite → Assemble painted layers; send final frame to screen (GPU-accelerated)

Blocking resources:

CSS is render-blocking — browser won't paint until CSSOM is built
JS (without async/defer) is parser-blocking — HTML parsing stops while script downloads and executes

Q14. What is the difference between SSR, CSR, SSG, and ISR?

Model answer:

Approach	HTML produced	Freshness	Best for
SSR (Server-Side Rendering)	Per request on server	High (live data)	Dynamic pages, SEO + personalization
CSR (Client-Side Rendering)	In the browser via JS	Depends on API calls	SPAs, authenticated app interiors
SSG (Static Site Generation)	At build time	Stale until rebuild	Docs, blogs, marketing pages
ISR (Incremental Static Regen)	Static + background revalidation	Tunable	Mostly-static with occasional updates

Modern meta-frameworks (Next.js, Nuxt, SvelteKit) let you choose per route.

Q15. What is a CDN and how does it improve performance?

Model answer:

A CDN (Content Delivery Network) is a network of servers distributed worldwide. Your files are copied to edge locations so users are served from the nearest server.

How it helps:

Lower latency — shorter physical distance = shorter RTT
Offload origin — fewer requests reach your actual server
Caching — static assets served from edge without origin work
DDoS absorption — distributed infrastructure absorbs attacks
TLS termination at edge — handshake with nearby server

Without CDN: User in Tokyo → crosses ocean → US server → 200ms RTT. With CDN: User in Tokyo → nearby Tokyo edge → 10ms RTT.

Advanced (Q16–Q20)

Q16. What are WebSockets, and how do they differ from HTTP?

Model answer:

WebSockets provide a persistent, full-duplex communication channel over a single TCP connection. Unlike HTTP's request-response model, both client and server can send messages at any time without the other asking.

	HTTP	WebSocket
Model	Request → Response (client initiates)	Full-duplex (both sides send freely)
Connection	Short-lived (or keep-alive for reuse)	Long-lived (stays open)
Overhead	Headers on every request/response	Minimal framing after initial handshake
Use case	CRUD, page loads, APIs	Chat, live feeds, gaming, real-time dashboards

How it starts: A WebSocket begins as an HTTP request with Upgrade: websocket header. If the server agrees (101 Switching Protocols), the connection upgrades to WebSocket protocol.

Alternative: Server-Sent Events (SSE) — one-way server → client push over HTTP. Simpler than WebSockets when you only need server-to-client updates.

Q17. How would you design the architecture for a web application that needs to handle 10 million users?

Model answer (framework):

CDN at the edge for static assets + DDoS protection
Load balancer distributing traffic across multiple app servers
Stateless app servers (horizontal scaling; session state in Redis, not in memory)
Database layer: primary + read replicas; sharding for write scale; connection pooling
Caching: Redis/Memcached for hot data (user sessions, feed results, config)
Async processing: Message queues (Kafka, RabbitMQ, SQS) for emails, notifications, analytics
Search: Elasticsearch/Typesense for full-text search
Monitoring: Metrics (Prometheus), logs (ELK), tracing (Jaeger), alerting
Auto-scaling: Scale app servers by CPU/latency; scale workers by queue depth

Users → CDN → Load Balancer → App Servers (stateless)
                                    │
                          ┌─────────┼─────────┐
                          ▼         ▼         ▼
                        Cache    Primary DB  Message Queue
                        (Redis)  (+ replicas)    │
                                                 ▼
                                            Async Workers

Q18. What is the difference between monolithic and microservices architecture?

Model answer:

	Monolith	Microservices
Structure	One codebase, one deployment unit	Many small, independent services
Deployment	Deploy everything together	Deploy each service independently
Scaling	Scale the entire app	Scale individual services
Communication	In-process function calls	Network calls (HTTP, gRPC, message queues)
Complexity	Simpler to start; harder to scale	Harder to start; easier to scale
Team structure	One team can own it all	Service per team (Conway's Law)
Best for	MVPs, small teams, early stage	Large orgs, complex domains, independent scaling needs

Key insight: Start monolithic; extract services when you have a clear reason (scaling bottleneck, team independence, deployment isolation). Premature microservices add network complexity, debugging difficulty, and operational overhead.

Q19. What is REST, and what makes an API "RESTful"?

Model answer:

REST (Representational State Transfer) is an architectural style for APIs, defined by Roy Fielding. A RESTful API typically follows these conventions:

Principle	What it means
Resources as URLs	`/users/42`, `/products`, `/orders/99/items`
Standard HTTP methods	GET = read, POST = create, PUT = replace, PATCH = update, DELETE = remove
Stateless	Each request contains all info needed; server doesn't store client state between requests
Representations	Resources can have multiple formats (JSON, XML); client uses `Accept` header
HATEOAS (ideal)	Responses include links to related actions (rarely implemented fully in practice)

Example:

GET    /api/users         → list users
GET    /api/users/42      → get user 42
POST   /api/users         → create a user (body: JSON)
PUT    /api/users/42      → replace user 42
PATCH  /api/users/42      → partially update user 42
DELETE /api/users/42      → delete user 42

Q20. How do you secure a web application? Name at least 5 security practices.

Model answer:

Practice	What it prevents
HTTPS everywhere	Eavesdropping, tampering, MITM attacks
Input validation + parameterized queries	SQL injection, command injection
Output encoding	XSS (Cross-Site Scripting)
CSRF tokens	Cross-Site Request Forgery
Authentication (bcrypt, OAuth, MFA)	Unauthorized access
Authorization checks on every request	Privilege escalation, IDOR
HttpOnly + Secure + SameSite cookies	Cookie theft via XSS, CSRF
Rate limiting	Brute force, abuse
CORS configuration	Unauthorized cross-origin access
Dependency scanning	Supply chain attacks
Content Security Policy (CSP)	Inline script injection
Secrets management (never in client code)	API key / credential leakage

Rule of thumb: Never trust the client. Validate on the server. Defense in depth.

Quick-Fire (Yes / No + one line)

Question	Answer	One-line rationale
Can a machine be both client and server?	Yes	Local dev: browser (client) talks to `localhost` server on same machine.
Is HTTP stateless?	Yes	Each request is independent; state is added via cookies/tokens/sessions.
Does CORS apply to `curl` or Postman?	No	CORS is enforced by browsers only.
Is 403 always "you're logged in but forbidden"?	No	Some APIs misuse 403 for unauthenticated; RFC prefers 401 for that.
Can a static site have interactive features?	Yes	Client-side JS + external API calls; the initial document is static.
Is serverless really "no servers"?	No	Servers exist; you just don't manage them.
Should you validate input on the client AND server?	Yes	Client for UX; server for security (client can be bypassed).
Is GraphQL a replacement for REST?	No	It's an alternative with different trade-offs (flexibility vs complexity).

Interview Tips

Start high-level, then drill down. Offer a skeleton answer first; ask if they want more depth on a specific part.
Use real examples. "When I load Twitter..." is more convincing than abstract descriptions.
Draw diagrams. Even in a text-based interview, describe what you would draw: "Imagine the browser on the left, server on the right, arrows for request and response."
Name the trade-offs. "Static sites are fast and cheap but lack personalization" shows depth.
Mention security. For any client-server question, note that the server is the trust boundary. "Never trust the client" is always a good line.
Know HTTP status codes. 200, 201, 301, 304, 400, 401, 403, 404, 500, 502, 503 — memorize these.
Understand the rendering pipeline. DOM → CSSOM → Render Tree → Layout → Paint → Composite. This shows you understand how browsers actually work.

Use this alongside the 1.2 Exercise Questions for hands-on practice and deeper review.