Application Development and Programming
Application Development and Programming tests whether your code survives production: concurrency, failure handling, configuration, and runtime resource limits. Expect questions on retries, idempotency, graceful shutdown, and why a green unit test still fails at 3 a.m.
Runtime and concurrency rules
- Never block the event loop in an async runtime; offload CPU-bound work and blocking I/O to a worker pool.
- Bound every queue, pool, and cache. Unbounded growth converts a slow dependency into an OOM kill.
- Propagate deadlines and cancellation downstream; a timeout at the edge is useless if the inner call waits forever.
- Size pools from arithmetic, not guesswork: connections ≈ throughput × average latency (Little's law).
Failure handling
- Retry only idempotent operations, with exponential backoff and jitter, and at exactly one layer.
- Persist an idempotency key alongside the side effect so a replay returns the original result rather than charging twice.
- Fail fast on configuration errors at startup; never default a missing secret to an empty string.
Twelve-factor hygiene
Config from the environment, one immutable build artifact promoted unchanged, structured logs to stdout, and graceful shutdown: on SIGTERM stop accepting new work, drain in-flight requests, then exit.
Worked example
An order API calls inventory, payment, and notification, and each layer retries three times. One user click can therefore produce 3⁴ = 81 attempts when everything fails together - a retry storm that keeps a struggling dependency down. Fix: retry only at the API edge (three attempts at 100 ms, 200 ms, 400 ms plus jitter), set an 800 ms client timeout, and require an idempotency key on POST /orders so repeats are safe. Worst-case attempts drop from 81 to 3, and the dependency sees a slow trickle instead of a flood.
Traps
- Catching the broad base exception, logging it, and returning success.
- Retrying a non-idempotent POST after a timeout that may actually have succeeded.
- Using the caller's clock for expiry or ordering decisions.
- Writing secrets or PII into logs and stack traces.
- Treating a passing build as evidence of correctness without a test that exercises the failure path.