Prerequisite Assessment

Q1. Checked = compiler-enforced, must be caught or declared; unchecked extends RuntimeException. For a downstream 503 (a transient, retryable condition the caller can act on) either is defensible, but modern Spring code overwhelmingly uses an unchecked custom exception (e.g. PaymentUnavailableException) mapped to a response via @ControllerAdvice. Looking for: you know the distinction and don't think exceptions are just for bugs.

Q2. (a) Issue the three calls concurrently (CompletableFuture, a TaskExecutor, or reactive composition) since they're independent; (b) cache results that are stable; (c) make the whole thing asynchronous — return 202 Accepted and complete out of band. Looking for: concurrency vs asynchrony are distinguished.

Q3. Stateless = any instance can serve any request; nothing needed to serve request N+1 lives only in the instance that served request N. Accidental state: in-memory sessions, a local HashMap cache assumed to be shared, in-process scheduled jobs, files written to local disk, sticky counters/rate limiters.

Q4. A bounded set of pre-opened DB connections reused across requests. When exhausted, new requests block on acquisition until timeout, then fail. The important insight: pool exhaustion shows up as application latency and errors, not database errors — the database may look completely healthy.

Q5. 401 = not authenticated (no/invalid credentials); 403 = authenticated but not authorized. 502 = the gateway got an invalid/failed response from upstream; 504 = the gateway got no response in time (upstream timeout). This distinction is load-bearing all through Days 4–5 and Day 13.

Q6. GET, HEAD, PUT, DELETE, OPTIONS, TRACE are idempotent by spec; POST and PATCH are not. It matters because a retried non-idempotent request can duplicate an effect (two orders, two charges).

Q7. Client and server agree on a cipher suite; the server presents a certificate chain; the client validates it against a trusted CA and checks the hostname; keys are exchanged (ephemeral DH in TLS 1.3) and a symmetric session key is derived. The server's identity is proved to the client (client identity is proved only with mTLS).

Q8. Unknown — the request may have been fully processed with the response lost. The client should retry; the server must make creation idempotent (idempotency key, conditional write, or dedupe on a natural key) for the retry to be safe. If you got this one, the entire Day 8 idempotency section will land easily.

Q9. An auxiliary data structure (usually a B-tree) making lookups on some column(s) sublinear. Costs: extra storage, slower writes (every insert/update maintains it), and it can be chosen badly by the planner. Looking for: you name the write cost.

Q10. Atomicity — all or nothing. Consistency — the transaction moves the DB between valid states w.r.t. constraints. Isolation — concurrent transactions don't observe each other's partial work (to the degree the isolation level promises). Durability — once committed, it survives a crash.

Q11. Hypothesis: no usable index — likely no composite index on (customer_id, created_at), so the DB filters by customer then sorts a large intermediate result. Confirm with EXPLAIN (ANALYZE) and look for a sequential scan or an explicit sort node.

Q12. A read replica serves read traffic and is asynchronously (usually) behind the primary — it exists for scale, and reading from it can return stale data. A standby exists for availability: it is usually synchronously replicated, serves no traffic, and is promoted on failure. Conflating these two is one of the traps in the Day 6 material.

Q13. Sync: caller blocks, gets the result, and shares the callee's availability and latency. Async: caller hands work off and returns; the result arrives later or never observed directly. What gets worse: end-to-end observability, error surfacing, ordering guarantees, and reasoning about consistency — you've traded coupling for uncertainty.

Q14. Thread-pool exhaustion / cascading failure (a resource-exhaustion cascade). Limited by timeouts, bounded pools, bulkheads, circuit breakers, and load shedding.

Q15. Every message is delivered one or more times; duplicates are normal, not exceptional. The consumer must be idempotent — processing the same message twice must produce the same end state as processing it once.

Q16. DNS resolution (stub resolver → cache → recursive resolver → authoritative) → TCP connect (3-way handshake) to the resolved IP on port 443 → TLS handshake → HTTP request serialized and sent over the encrypted connection. Looking for: DNS and TCP and TLS are three separate things happening in order.

Q17. Private ranges (RFC 1918: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) are not routable on the public Internet and are reused inside every private network; public addresses are globally unique and routable. You can't reach 10.0.3.47 because no Internet router will forward toward it — you need to be inside that network, or reach it through something that is (a load balancer, a VPN, a bastion). This is the single most load-bearing answer for Day 2.

Q18. Elastic capacity without capital expenditure and procurement lead time; pay-per-use; managed services replacing undifferentiated operational work; global footprint on demand. Harder: cost becomes a variable engineering concern rather than a fixed asset, security becomes identity-centric and easy to get wrong, and you gain a dependency on a provider's failure modes you cannot inspect.