292: Node.js, HTTP, API, Authentication, and Backend Interview Review

Learning outcomes

By the end of this lesson, you should be able to:

explain and apply the Node runtime in a realistic implementation;
explain and apply HTTP contracts in a realistic implementation;
explain and apply authentication in a realistic implementation;
explain and apply authorization in a realistic implementation;
explain and apply reliability practices in a realistic implementation.

Prerequisites and retrieval

This lesson assumes that you have completed the earlier 01–06 foundation and the preceding lessons in this module. Before you read, retrieve one concrete example from an earlier project in which one of these concerns appeared. It might be an endpoint, a login flow, a background task, or a production bug. You are not trying to recite terminology from memory. You are trying to connect the terminology to a decision you can defend in a realistic full-stack interview loop, where your explanation, trade-offs, debugging approach, code, and project evidence should all tell the same story.

Terminology

Node runtime: Review the event loop, microtasks, libuv, streams and backpressure, buffers, EventEmitter, worker threads and processes, errors, modules, signals, and memory and profiling from the Node module. These topics explain both what a Node program can do efficiently and where it can stall or fail.
HTTP contracts: Be ready to explain methods, status codes, and headers; idempotency; caching; validation; pagination; CORS; cookies; CSRF; content types; timeouts; and stable error responses. An API contract is more than a route name: it defines what callers may send, what they receive, and how failure is represented.
Authentication: Compare server sessions, access and refresh tokens, OAuth/OIDC, cookie security, password hashing, rotation and revocation, and the threat models around credential storage. The question is not which mechanism is fashionable; it is which credentials exist, where they live, and how they can be invalidated or stolen.
Authorization: Explain RBAC, ABAC, resource ownership, and tenant scoping, along with why server-side enforcement and negative tests are mandatory. A user being authenticated says who they are; it does not say which resource they may change.
Reliability: Cover graceful shutdown, readiness, connection draining, retries and timeouts, queues and outbox patterns, structured logs, metrics and tracing, process and container deployment, and dependency failures. Reliability is about controlled behavior when the normal path is interrupted.
Security: Discuss injection, SSRF, the XSS/CSRF boundary, rate limiting, secret handling, dependency risk, file-upload limits, and least privilege. Do not claim that one framework middleware solves the whole security problem; security is a set of boundaries and enforced assumptions.

Mental model

Treat Node.js, HTTP, API, Authentication, and Backend Interview Review as a design problem with observable inputs, outputs, invariants, and failure modes. Backend interviews are not only tests of Express routing syntax. They combine runtime behavior with API design, security, and operations. A strong answer reasons about failure, concurrency, validation, and the production lifecycle instead of describing only the happy path.

The implementation should make its assumptions visible, reduce uncertainty at system boundaries, and leave evidence that the design is safe. That evidence might be tests, types, constraints, metrics, logs, or a diagram. The medium is less important than being able to show why the behavior is correct.

A useful sequence for both interviews and production work is:

requirement -> constraints -> model -> implementation -> failure analysis -> verification

Do not jump from a requirement straight to a library call. First state what must remain true. Then choose the mechanism that enforces that invariant and decide how you will verify it. This keeps a familiar framework from hiding an assumption you have not actually resolved.

Deep dive

1. Node runtime

Review the event loop, microtasks, libuv, streams and backpressure, buffers, EventEmitter, worker threads and processes, errors, modules, signals, and memory and profiling from the Node module. In an interview, connect each item to behavior you can observe: for example, whether work blocks the event loop, whether a stream can outpace its consumer, or whether a failure is handled locally or terminates the process.

Decision rule: Use the Node runtime deliberately when it makes the contract or invariant easier to prove. If a runtime feature only reduces typing while hiding an important assumption, prefer the more explicit design.

2. HTTP contracts

Explain methods, status codes, and headers; idempotency; caching; validation; pagination; CORS; cookies; CSRF; content types; timeouts; and stable error responses. The useful distinction is between an implementation detail and a promise made to a caller. A caller should be able to know whether a request was accepted, rejected, retried, or already applied without reverse-engineering server behavior.

Decision rule: Use HTTP contracts deliberately when they make the contract or invariant easier to prove. If a convenience abstraction only reduces typing while hiding an assumption, prefer the more explicit design.

3. Authentication

Compare server sessions, access and refresh tokens, OAuth/OIDC, cookie security, password hashing, rotation and revocation, and the threat models for credential storage. Explain where a credential is presented, how it is protected in transit and at rest, how it expires, and what happens after compromise. Those details matter more than simply naming a strategy.

Decision rule: Use authentication mechanisms deliberately when they make the contract or invariant easier to prove. If the mechanism only reduces typing while hiding an assumption, prefer the more explicit design.

4. Authorization

Explain RBAC, ABAC, resource ownership, and tenant scoping, and be clear about which decision is made for each request. Authorization must be enforced on the server, close to the operation that changes or reveals the resource. Client-side hiding can improve the user experience, but it cannot protect data. Negative tests that prove a forbidden user is denied are therefore part of the feature, not optional polish.

Decision rule: Use authorization deliberately when it makes the contract or invariant easier to prove. If it only reduces typing while hiding an assumption, prefer the more explicit design.

5. Reliability

Cover graceful shutdown, readiness, connection draining, retries and timeouts, queues and outbox patterns, structured logs, metrics and tracing, process and container deployment, and dependency failures. A service that works only while every dependency is healthy is not a reliable service. Explain what happens to in-flight requests, new requests, queued work, and partial writes during a deploy or outage.

Decision rule: Use reliability mechanisms deliberately when they make the contract or invariant easier to prove. If they only reduce typing while hiding an assumption, prefer the more explicit design.

6. Security

Discuss injection, SSRF, the XSS/CSRF boundary, rate limiting, secret handling, dependency risk, file-upload limits, and least privilege. Treat client-controlled and network input as untrusted, and identify the boundary at which each value is validated or constrained. A framework can provide useful defaults, but no single middleware component proves that the whole system is secure.

Decision rule: Use security controls deliberately when they make the contract or invariant easier to prove. If a control only reduces typing while hiding an assumption, prefer the more explicit design.

Worked example

Consider a realistic full-stack interview loop where your explanations, trade-offs, debugging, coding, and project evidence all need to agree. Start by writing the requirement in one sentence. Then list the input and output contracts and identify which concept owns each failure mode. This prevents a common mistake: putting every concern in the route handler because the happy-path demo is shorter.

Keep the boundaries separate. Parsing and validation belong at the boundary. Domain rules belong in the domain or service layer. Persistence rules belong in the database or repository. Presentation rules belong in the client. The layers can cooperate, but mixing their responsibilities makes edge cases harder to reason about and makes it unclear where a guarantee is actually enforced.

Prompt -> clarify -> state assumptions -> solve -> test edge cases -> explain trade-offs

Walk through at least four cases:

the normal path;
an empty or missing value;
a duplicate, retry, or concurrent path where that behavior is relevant;
a dependency failure.

For every case, state which layer detects the problem and what the caller observes. That level of precision is what a senior code review or technical interview is looking for. It also gives you a practical debugging map: if the caller sees a malformed success response, inspect the boundary and presentation contract; if two requests create conflicting state, inspect the domain and persistence guarantees instead.

Production perspective

Production correctness is broader than “the code works on my machine.” Ask how the design behaves during deploys, retries, partial failures, stale clients, concurrent requests, malformed data, schema changes, and high-cardinality telemetry. Prefer explicit contracts, bounded resource usage, structured errors, and measurable behavior. Optimize only after you can identify the bottleneck or risk with evidence.

When an external dependency is involved, define both a timeout and a cancellation strategy. When persistence is involved, define transaction and consistency expectations. When the feature exposes user-visible state, define loading, empty, error, stale, and success states. When security is involved, assume the client can be modified and all network input is untrusted.

Guided lab

Run a backend mock in which you design and review a secure order API, diagnose one event-loop blocking problem, implement one stream or asynchronous flow, reason about authentication and tenant authorization, and explain graceful shutdown together with observability. Treat each task as an opportunity to connect a design choice to an observable result.

Complete the lab with this discipline:

Write the requirement and two non-requirements. Non-requirements keep the solution from quietly expanding beyond what you are trying to prove.
List the input, output, and error contracts before implementation.
Implement the smallest correct vertical slice.
Add at least one invalid-input test and one edge-case test.
Instrument or inspect the behavior instead of guessing.
Refactor one hidden assumption into an explicit type, constraint, function, or configuration value.
Explain one alternative design and why you did not choose it.
Record a short “what would break at 10× scale?” note.

Edge cases and failure modes

Node runtime: Test absent and malformed input, duplicates, ordering and concurrency where applicable, and behavior at the smallest and largest credible sizes. Also ask whether CPU-heavy work or unbounded buffering can block other requests.
HTTP contracts: Test absent and malformed input, duplicates, ordering and concurrency where applicable, and behavior at the smallest and largest credible sizes. Verify status codes, error shapes, timeout behavior, and retry safety rather than checking only a successful response.
Authentication: Test absent and malformed credentials, duplicates, ordering and concurrency where applicable, and behavior at the smallest and largest credible sizes. Include expiration, rotation, revocation, and safe handling of invalid credentials.
Authorization: Test absent and malformed identity or resource data, duplicates, ordering and concurrency where applicable, and behavior at the smallest and largest credible sizes. Include ownership and cross-tenant access attempts, especially requests the client interface would normally hide.
Reliability: Test absent and malformed dependency responses, duplicates, ordering and concurrency where applicable, and behavior at the smallest and largest credible sizes. Include timeouts, partial failure, shutdown, and recovery behavior.

Common mistakes and debugging

Several mistakes recur across backend interviews and real systems:

Solving the example instead of the requirement. A copied pattern can be syntactically correct and still be architecturally wrong for the actual constraints.
Hiding uncertainty with assertions, broad exception handlers, permissive schemas, or “temporary” any values. These can make the immediate error disappear while making the real invariant harder to locate.
Testing only the happy path, which means discovering the contract only after integration.
Optimizing before measuring, or selecting a scalable mechanism without a scale requirement.
Letting client-side behavior stand in for server-side authorization, validation, or persistence guarantees.

For debugging, reproduce the smallest failing case first. Inspect the actual value or execution plan, trace the boundary where the invariant first becomes false, and fix the layer that owns the guarantee instead of adding a downstream patch. A normal result should be defined before you interpret an abnormal one; otherwise logs and symptoms are easy to misread.

Interview questions

What problem does the Node runtime solve, and what trade-off or failure mode would make you choose a different approach?
What problem do HTTP contracts solve, and what trade-off or failure mode would make you choose a different approach?
What problem does authentication solve, and what trade-off or failure mode would make you choose a different approach?
What problem does authorization solve, and what trade-off or failure mode would make you choose a different approach?
What problem does reliability solve, and what trade-off or failure mode would make you choose a different approach?

Checkpoint

Without notes, explain Node.js, HTTP, API, Authentication, and Backend Interview Review to another developer in five minutes. Your explanation must include one invariant, one edge case, one production failure mode, and one alternative design. Then implement a small example without copying the lesson code. If you cannot explain where the invariant is enforced or how you would observe a failure, the design is not ready to defend yet.

Mastery checklist

I can define the core terms precisely.
I can choose a design from requirements instead of from habit.
I can implement and test the normal path and edge cases.
I can explain the runtime, storage, or complexity cost.
I can identify which layer owns validation, errors, and recovery.
I can compare at least two reasonable alternatives.
I can explain how the design changes at larger scale or under stricter reliability requirements.