Software Engineering Fundamentals

2 · What happens when you hit Enter on a URL

This is the single most common systems interview question. Click each step.

https://api.example.com:443/v1/users/42?fields=name#bio
└scheme┘   └──── host ────┘ └port┘└── path ──┘└── query ──┘└frag┘

client ──── SYN ────────▶ server
client ◀─── SYN-ACK ──── server
client ──── ACK ───────▶ server   (connection established)

GET /v1/users/42 HTTP/1.1
Host: api.example.com
User-Agent: Mozilla/5.0 ...
Accept: application/json
Authorization: Bearer eyJhbGciOi...
Cookie: session=abc123
(blank line ends headers; body would follow)

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Content-Length: 74
Cache-Control: private, max-age=60
ETag: "a3f9c1"

{"id":42,"name":"Ada Lovelace","email":"ada@example.com"}

3 · HTTP essentials

HTTP is a stateless, text-based request/response protocol. Stateless means the server remembers nothing between requests — that's why cookies and tokens exist.

Methods

Safe = doesn't change state. Idempotent = doing it 5 times leaves the same state as doing it once. This is why a retried PUT is fine but a retried POST may double-charge a card — hence idempotency keys.

Status codes — click one

The classes: 1xx informational · 2xx success · 3xx redirect · 4xx you messed up · 5xx the server messed up.

Headers that matter

Caching, concretely

# First request
GET /logo.png            →  200 OK
                              Cache-Control: max-age=86400
                              ETag: "v3"

# Within 24h: no request at all — served from local cache

# After expiry: revalidate cheaply
GET /logo.png
If-None-Match: "v3"       →  304 Not Modified  (no body, tiny)

Cookies

Set-Cookie: session=abc123; HttpOnly; Secure; SameSite=Lax; Path=/; Max-Age=1209600

• HttpOnly — JavaScript can't read it → blunts XSS token theft
• Secure — only sent over HTTPS
• SameSite=Lax|Strict|None — controls cross-site sending → the main CSRF defense

REST in one screen

GET    /users          list
POST   /users          create        → 201 + Location: /users/42
GET    /users/42       read          → 200 or 404
PUT    /users/42       full replace
PATCH  /users/42       partial update
DELETE /users/42       remove        → 204
GET    /users/42/posts nested resource

Principles: nouns not verbs, plural collections, statelessness, correct status codes, use the query string for filtering/sorting/pagination (?page=2&limit=20&sort=-created_at).

HTTP versions

When request/response isn't enough

4 · Backend architecture

The standard shape of a web system

Each piece, and why it exists

Scaling: vertical vs horizontal

SQL vs NoSQL

CAP theorem

When a network Partition happens, a distributed system must choose:

• CP — refuse requests rather than serve stale data (banking ledgers, etcd, ZooKeeper)
• AP — keep answering, reconcile later (shopping carts, DNS, Cassandra)

Since partitions will happen, in practice CAP is a choice between consistency and availability.

Monolith vs microservices

Reliability vocabulary

• Idempotency key — client-supplied ID so retrying a POST doesn't double-charge
• Rate limiting — token bucket / leaky bucket; returns 429 with Retry-After
• Circuit breaker — stop calling a failing dependency for a while instead of piling up timeouts
• Retry with exponential backoff + jitter — retry, but don't stampede
• Graceful degradation — serve stale cache or a reduced feature set instead of a 500
• Observability — structured logs, metrics (p50/p95/p99 latency, error rate), distributed traces

5 · Authentication, authorization, and security

Sessions vs JWTs

// A JWT is three base64url parts joined by dots:
header.payload.signature

{"alg":"HS256","typ":"JWT"}                // header
{"sub":"42","role":"admin","exp":1790000000} // payload — readable by anyone!
HMACSHA256(base64(header)+"."+base64(payload), secret) // signature

Common pattern: short-lived access token (5–15 min) + long-lived refresh token stored in an HttpOnly cookie, rotated on each use.

OAuth 2.0 + OIDC ("Sign in with Google")

Key points: the app never sees the user's Google password. OAuth 2.0 = authorization (delegated access to an API); OpenID Connect layers authentication on top by adding an id_token (a JWT describing the user). Public clients (SPAs, mobile) must use PKCE. The state parameter prevents CSRF on the callback.

Password storage

• Never store plaintext. Never use plain MD5/SHA-256 — they're built to be fast, which helps attackers.
• Use a slow, memory-hard KDF: bcrypt, scrypt, or Argon2id.
• A per-user salt (built into these algorithms) defeats rainbow tables.
• Compare hashes in constant time; rate-limit login attempts; support MFA.

Attacks you should be able to name

// bad
"SELECT * FROM u WHERE id=" + id
// good
"SELECT * FROM u WHERE id=$1", [id]

CORS — why the browser blocks your fetch

The same-origin policy stops JavaScript on a.com from reading responses from b.com. An origin = scheme + host + port; all three must match. CORS is the server's way of opting in:

# Browser preflight for a non-simple request
OPTIONS /api/data
Origin: https://app.example.com
Access-Control-Request-Method: PUT

# Server permits it
204 No Content
Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Methods: GET, PUT, POST
Access-Control-Allow-Credentials: true

6 · Check yourself

Nine questions covering the material. Click an answer.