Backend fundamentals, field-manual style

This is one of the most common "walk me through it" openers. Interviewers use it to check whether you understand the system your code runs inside, not just the code itself.

1. DNS resolution — the domain (api.ionicwealth.com) is resolved to an IP, usually cached by the OS/browser/resolver.
2. TCP + TLS handshake — a connection is opened and, for HTTPS, encrypted (certificate exchange, key negotiation). HTTP/2 and keep-alive let this be reused across requests instead of paying this cost every time.
3. Load balancer — sits in front of your app servers, picks one instance (round-robin, least-connections, etc.), and can also terminate TLS.
4. Application server — the framework's router matches method + path to a handler, runs middleware (auth, logging, body parsing, validation), then your business logic.
5. Data layer — the handler talks to a database, cache, or another internal service to do the actual work.
6. Response — status code + headers + body are serialized and sent back down the same connection.

Five properties define a REST API in practice:

• Resource-based URLs — /users/42/orders, not /getUserOrders?id=42. The URL identifies a "thing", the method says what to do to it.
• Statelessness — every request carries everything the server needs to understand it (auth token, params). The server keeps no per-client session in memory between requests — this is exactly what lets you run 10 identical app server instances behind a load balancer.
• Uniform interface — the same verbs (GET/POST/PUT/PATCH/DELETE) mean the same thing on every resource.
• Client–server separation — frontend and backend evolve independently as long as the contract (the API shape) holds.
• Cacheable — responses declare whether they can be cached (via headers like Cache-Control), so intermediaries can skip round trips.

Safe means the method doesn't change server state — a GET should never have side effects (that's also why browsers/crawlers/proxies feel free to re-issue GETs). Idempotent means calling it once has the same end-state as calling it 5 times — covered in depth next, because it's asked constantly on its own.

The classic PUT vs PATCH mix-up: PUT /users/42 with a partial body should, strictly, wipe out any fields you didn't send (it's a full replace). PATCH /users/42 with {"name": "Yash"} changes only name and leaves everything else untouched.

This matters because networks are unreliable. If a client sends a request and the connection drops before the response arrives, the client doesn't know if it succeeded — so it retries. If the operation isn't idempotent, that retry can double-charge a card, create two orders, or send two emails.

The fix: idempotency keys. The client generates a unique key (a UUID) per logical operation and sends it in a header. The server stores "key → result" the first time, and on any retry with the same key, returns the stored result instead of re-executing.

The one pair that trips people up: 401 Unauthorized vs 403 Forbidden. 401 really means "unauthenticated" — you have no valid identity (missing/expired token). 403 means "I know who you are, and you're not allowed to do this." Say it exactly like that; it's a favorite gotcha.

Also worth having ready: 409 Conflict (the request clashes with current state — e.g. two updates racing, or a duplicate unique key) and 422 Unprocessable Entity (syntactically valid JSON, but semantically invalid — e.g. an email field that isn't an email).

CORS is enforced by the browser, not the server — it exists to protect users, not APIs. Without it, any malicious site you visit could silently use your logged-in cookies to call your bank's API from JavaScript running in your tab.

Versioning — put it in the URL (/v1/orders) or a header (Accept: application/vnd.ionic.v2+json). URL versioning is more common and easier to debug/cache; header versioning is "more correct" REST but harder to explore in a browser.

Pagination — never return an unbounded list.

• Offset-based: ?page=3&limit=20. Simple, but slow on large tables (the DB still has to skip all prior rows) and unstable if rows are inserted mid-scroll.
• Cursor-based: ?after=order_88231&limit=20. Uses an indexed column (often the ID or timestamp) as a bookmark — O(1) instead of scanning, and stable under concurrent writes. What most fintech/feed APIs use in practice.

Filtering & sorting: query params — GET /orders?status=filled&sort=-created_at.

Consistent envelope: a predictable response shape, e.g. { "data": ..., "meta": { "next_cursor": ... } } for lists, and a consistent error shape (see input validation below) for failures.

Four algorithms come up repeatedly:

Validate at the edge (middleware, before the handler runs), using a schema library rather than hand-rolled if chains — it's declarative, reusable, and gives you consistent error responses for free.

In a typical backend, authentication is a middleware that verifies a token/session and attaches req.user. Authorization is a second, separate check — often role-based (RBAC: admin/editor/viewer) or permission-based — run per-route or per-action, using that req.user.

Why not SHA-256? It's designed to be fast — great for checksums, terrible for passwords, because it lets an attacker who steals your DB try billions of guesses per second on cheap GPU hardware. Bcrypt/argon2 are deliberately slow and tunable (a "cost factor"), so cracking scales in your favor as hardware improves — you just raise the cost.

Salting: a random value added per-password before hashing, stored alongside the hash. It defeats rainbow tables (precomputed hash lookup tables) and ensures two users with the same password get different hashes. Bcrypt generates and embeds the salt for you automatically.

If email is set to ' OR '1'='1, the vulnerable query becomes WHERE email='' OR '1'='1' — always true, returning every row (or worse, chained with ; DROP TABLE users;--).

The fix is parameterized queries / prepared statements — the driver sends the SQL template and the values separately, so the database never interprets user data as SQL syntax. It's not "escaping smartly," it's a fundamentally different wire protocol.

Defense in depth (say all of these, not just one):

• Parameterized queries / an ORM that does this for you by default (Prisma, TypeORM, SQLAlchemy).
• Least-privilege DB users — the app's DB role shouldn't be able to DROP TABLE.
• Input validation as an earlier layer of defense (reject obviously malformed input before it's near a query).
• The same class of bug exists for NoSQL (NoSQL injection — e.g. passing a MongoDB operator object like { "$gt": "" } in a field expected to be a string) and shell commands (command injection) — same root cause, same fix: never let raw user input become executable syntax.

The honest interview answer is never "NoSQL is faster" in the abstract — it's about what invariant you need. Money movement needs ACID transactions — that's a hard requirement for SQL. A high-volume, loosely-structured event log or a product catalog with wildly varying attributes per item tolerates a looser model, and gains write scalability from it.

Indexes speed up WHERE, JOIN ON, and ORDER BY on the indexed column(s) — but every INSERT/UPDATE/DELETE now also has to update the index, so over-indexing hurts write throughput. Index columns that are frequently filtered/joined on and selective (many distinct values) — indexing a boolean is_active column rarely helps much.

Composite indexes cover multiple columns, but column order matters: an index on (user_id, created_at) speeds up queries filtering on user_id alone or on both, but not on created_at alone (left-prefix rule).

RIGHT JOIN is the mirror of LEFT (rarely used — people just swap table order and use LEFT). FULL OUTER JOIN keeps unmatched rows from both sides. A good one-liner if asked "when would you use LEFT over INNER": "whenever the absence of a match is itself meaningful information" — e.g. "find users who have never placed an order" is a LEFT JOIN with WHERE o.id IS NULL.

Opening a DB connection is expensive (TCP + auth handshake). Without pooling, every request pays that cost. A pool keeps, say, 10 warm connections open and hands them out and back — a request borrows one, runs its query, returns it.

Sizing it isn't "bigger is always better." Postgres has a hard max_connections limit (default 100), shared across every app instance talking to it. If you run 20 app instances × pool size 20, that's 400 potential connections against a DB that allows 100 — connections start getting refused. This is exactly why tools like PgBouncer exist: a proxy that pools connections at the infrastructure level, in front of many app instances.

A normalized schema stores a user's address once in a users table and references it by user_id everywhere; a denormalized one might copy the shipping address onto every order row so reading an order never needs a join — at the cost of updating N rows if the address changes, and the risk of them drifting out of sync. OLTP systems (transactional, like Postgres for orders) lean normalized; read-heavy analytics/reporting systems lean denormalized on purpose.

To actually diagnose a slow query, run EXPLAIN ANALYZE — it shows whether Postgres used an index (Index Scan) or scanned every row (Seq Scan), plus real vs. estimated row counts and time per step. This is the concrete, checkable version of "check for missing indexes."

$lookup is the aggregation stage that performs a left-outer-join-style merge against another collection — the closest MongoDB gets to a SQL JOIN, and worth naming if asked "does MongoDB support joins."

Postgres (single primary) is effectively CP-leaning for writes. Many NoSQL stores (Cassandra, DynamoDB) default to AP — favoring "always answer, maybe slightly stale" over refusing to answer. This is why "eventual consistency" shows up so often in the NoSQL column of §3.1's table — it's a direct consequence of choosing availability.

Invalidation is the hard part ("there are only two hard things in computer science: cache invalidation and naming things"). Two common approaches: a TTL (expire after N seconds — simple, tolerates some staleness) and explicit invalidation (delete/update the cache key the moment the underlying data changes — fresher, but easy to miss a code path and leave stale data).

What to cache: read-heavy, rarely-changing, expensive-to-compute data — a user's permission set, a computed dashboard aggregate, a market-data snapshot. Not: data that must always be perfectly fresh for correctness (an account balance mid-transaction).

Common distribution strategies: round-robin (cycle through servers), least connections (send to whichever has the fewest active requests — better when requests vary in cost), IP hash (same client always hits the same server — useful for in-memory session affinity, though that itself conflicts with the "stateless" REST principle from §1.2, which is exactly why sessions belong in Redis, not server memory).

Also a health-check mechanism: it pings each instance and stops routing to ones that fail, which is how a rolling deploy or a crashed instance doesn't take the whole service down.

Stateless application servers scale horizontally easily. The database is usually the harder part to scale horizontally — which is exactly why replication and sharding (next) exist.

Use it when a request shouldn't have to wait on slow/non-critical work: sending an email, generating a report, updating a search index. The API handler publishes a message and returns immediately; a worker processes it separately, and can retry on failure without the user ever seeing an error.

Kafka is a distributed log — many consumers can independently read the same stream at their own pace, messages persist for a configurable time, great for high-throughput event streaming (fits Ionic Wealth's market-data-adjacent domain). SQS is a simpler point-to-point queue — a message is typically consumed once and removed, good for task/job queues.

Treat this as a checklist question — name the layers in order, from cheapest/most-likely to most invasive:

Almost every Node.js standard-library and DB-driver method has a non-blocking (async) form — using the sync form (anything ending in Sync) inside a request handler is a classic performance bug, because it blocks every other in-flight request on the same process while it runs.

Skim this in the elevator, not before. Every line links back to its full section above.