Node.js

I keep three layers distinct: routes and controllers that translate HTTP into calls and back, services that hold the business workflow, and data access that knows about the database. Express doesn't enforce any of this, which is why so many Node codebases end up with SQL inside route handlers.

Errors flow through one handling path that maps known error types to status codes and one response shape. Unknown errors become a generic 500 with the details in the logs, not in the response.

async/await makes asynchronous code read sequentially, which hides an easy performance mistake: awaiting independent calls one after another. Independent work runs in parallel with Promise.all — or Promise.allSettled when one failure shouldn't discard the other results; dependent work stays sequential.

The failure modes to design out are unhandled rejections and forgotten awaits. Every promise is awaited or deliberately handled, and loops over large datasets process in batches rather than firing thousands of concurrent requests at a database or provider.

Express is deliberately minimal, so structure is your responsibility. Middleware handles cross-cutting concerns — authentication, request IDs, rate limiting, body parsing — in a predictable order; routers group endpoints by resource; controllers stay thin and call services; and one error middleware at the end turns thrown errors into consistent responses.

Async route handlers must forward rejected promises to that error middleware. Otherwise a failed request simply hangs until the client times out.

Every body, query string and route parameter is validated against a schema at the edge, before it reaches business logic, and the validated result is what the rest of the code uses. Validation errors return field-level details in the same format everywhere.

Sanitization depends on where data goes: escaping for HTML, parameterized queries for SQL, argument arrays for shell commands — not one generic “clean” function applied on the way in.

Session cookies suit first-party web apps on the same domain; short-lived tokens suit APIs used by other clients and services. Either way, authentication only answers “who is this?”. Authorization is a separate, explicit step that checks role and permission and, in multi-tenant systems, that the requested resource belongs to the caller's tenant.

Third-party APIs fail in every possible way: slow responses, rate limits, partial outages, changed payloads. Each integration gets a client with timeouts, retries with backoff for safe operations, and mapping from the provider's data model to ours, so their quirks don't leak into business logic.

Webhook handlers should assume events can be delayed, retried or delivered more than once. They verify the signature, acknowledge quickly and process asynchronously — idempotently wherever duplicate execution could cause side effects.

Work that's slow, external or retryable doesn't belong in the request cycle. The API validates the request, enqueues a job and returns; a worker picks it up, calls the external service and records the result. Workers run as separate processes, so a backlog can't slow user-facing requests.

Jobs are idempotent, retries use backoff, messages that keep failing land somewhere visible after a retry limit, and payloads carry identifiers and tenant context rather than large objects.

AWS Lambda suits Node.js well for event-driven and spiky workloads, but it changes the rules. Functions are short-lived and stateless: anything that must persist goes to a database, cache or storage, and in-memory state may or may not survive between invocations.

Cold starts grow with bundle size and initialization work, so dependencies stay lean and expensive clients are created once, outside the handler. Timeouts are set deliberately below upstream timeouts, concurrency limits protect downstream systems, and retries from asynchronous event sources mean handlers must be idempotent.

The data model chooses the database, not the language. Relational databases such as PostgreSQL and MySQL fit transactional business data with relationships and reporting needs. MongoDB fits documents read and written as a unit with a flexible structure. DynamoDB fits well-known access patterns at scale.

Whatever the store, queries are parameterized, connection pools are sized for the deployment model — a pool per Lambda instance behaves very differently from a pool per server — and migrations are versioned with the code.

Production debugging depends on what was logged before the incident. I log structured JSON with a correlation ID that follows a request through the API, queues and workers, plus tenant and user identifiers where appropriate — never secrets, and never full payloads containing personal data. Errors are logged once, with context, at the boundary that handles them.

Secrets come from the environment or a secret manager, never the repository. Inputs are validated; output to HTML, SQL and shell is encoded for its context. Dependencies are a real attack surface in the Node ecosystem, so the dependency list stays short, lockfiles are committed and audit warnings are reviewed rather than ignored.

Login, password reset and expensive endpoints get rate limits, and outbound calls go to allow-listed hosts rather than URLs taken from user input.

Node handles thousands of concurrent I/O operations on one thread because it never waits on them — and it stops handling anything while CPU-bound code runs. Image processing, large data transformations, encryption loops and report generation belong in worker threads, separate services or background jobs.

Large files and exports are streamed rather than loaded into memory, and memory that grows over time is treated as a bug to investigate, not something a restart hides.