HTTP internals, gRPC, and TCP vs UDP

Know the layers cold enough to debug them:

• TCP: connection (3-way handshake), ordered reliable byte stream, congestion control (slow start → AIMD), head-of-line blocking within a connection. UDP: datagrams, no handshake, no ordering — the base for DNS, QUIC, video.
• HTTP/1.1: keep-alive avoids per-request handshakes; one request per connection at a time → browsers open ~6 parallel connections → HOL blocking at the app layer. HTTP/2: one connection, binary frames, multiplexed streams (fixes app-layer HOL, inherits TCP HOL), header compression (HPACK), server push (dead). HTTP/3: QUIC over UDP — moves reliability into the protocol, kills transport HOL, 0/1-RTT handshake. (Browsers → your sites already speak H2/H3 at the CDN edge; your origin servers are H1.1 — fine.)
• REST (your choice, both projects): resource-oriented, cacheable, debuggable with curl, ubiquitous tooling. gRPC: HTTP/2 + protobuf IDL, typed stubs, bidirectional streaming, built-in deadline/cancel propagation — the standard for internal service-to-service at scale. Costs: binary payloads (hard to debug without tooling), codegen per language, browser-unfriendly (needs grpc-web proxy).

Why zoth is HTTP/JSON internally, and why that's correct: three services, ~1 rps, one team. gRPC's wins (typed contracts, streaming, deadline propagation) matter at 50 services and 50 teams. The emitter doesn't even call the API over HTTP — they coordinate through Postgres + RabbitMQ (the strongest answer to "why not gRPC": no synchronous inter-service calls exist to optimize). One legit future gRPC site: zlink connectors to platform APIs — but those are external REST APIs; you don't get to choose.

Your HTTP details worth knowing cold

Zoth:

• 15 s read/write timeouts on http.Server (slowloris defense; goroutine leak prevention).
• otelhttp middleware wraps every request in a span; W3C traceparent propagates via the composite TraceContext+Baggage propagator.
• Health checks dial RabbitMQ with a raw TCP dial — not an AMQP handshake — deliberately cheap.
• tokenTransport in the GitHub zlink wraps http.RoundTripper to inject Authorization: Bearer — the idiomatic Go pattern for per-client auth (know it: it's how you'd add retries/metrics to any SDK).

Traverse:

• express.json({limit:'10mb', verify: rawBody}) — the raw bytes are kept so Razorpay's webhook HMAC can be verified against the exact body (re-stringified JSON would break the signature — a classic production bug you avoided by design).
• trust proxy 1 — exactly one proxy hop assumed, so req.ip unwraps X-Forwarded-For once; setting it to true blindly would let clients spoof IPs past your rate limiter (validate: xForwardedForHeader: false in the limiter config).
• APNs push over raw HTTP/2 with jose (src/lib/apns.ts) — ES256 provider JWT, sessions pooled per origin, because sandbox + production coexist per-token. That's you already using HTTP/2 deliberately.
• Webhooks return 200-always (Razorpay) to stop provider retries — idempotency absorbs re-delivery instead.

TCP-vs-UDP interview questions, answered like an owner

"Why is DNS UDP?" — single small question/response fits one datagram; TCP handshake would triple latency; fallback to TCP for >512 B or zone transfers.

"Your WebSocket would use which?" — TCP (HTTP/1.1 Upgrade) — you'd never hand-roll reliability on UDP; QUIC is the modern exception.

"When is UDP right in backend systems?" — telemetry fire-and-forget, live video, game state — anywhere late > lost. Your suspicious-activity events are effectively fire-and-forget at-least-once over TCP — correct, because they're rare and cheap; a metrics firehose would justify UDP.