Backend Developer interview questions

Keep URLs shallow and fetch deep relations separately.

• Nest only one level deep, like /orders/{id}/items, and avoid /users/{id}/orders/{id}/items.
• For deeper links, return related resource IDs and let the client fetch them.
• Or offer an ?include= query param that triggers a server-side join.
• Define naming, verb, and error-payload conventions before the first endpoint.

The N+1 problem is one query for N records plus one extra query per record.

• It results in N+1 total queries instead of one.
• In an ORM, fix it with eager loading via JOIN includes or a batch loader like DataLoader.
• In raw SQL, rewrite it as a single JOIN or IN query, then reassemble in code.

They differ in whether you lock the row up front.

• Optimistic assumes rare conflicts: read with a version, check it on update, roll back if it changed.
• Pessimistic locks the row at read time, blocking other writers until commit.
• Use optimistic for low-contention writes like profile updates.
• Use pessimistic for high-contention ones like reserving limited inventory.

Choose a document database when data is naturally hierarchical or polymorphic.

• Good fit for nested or polymorphic shapes that would need many JOIN tables in SQL.
• Also when the schema evolves fast and shared-table columns would be disruptive.
• Relational wins for multi-row ACID transactions, complex ad-hoc queries, and strict referential integrity.
• The decision hinges on access patterns, not just data shape.

Use a client-supplied Idempotency-Key to dedupe requests.

• The client generates a unique key, usually a UUID, and sends it with the request.
• The server stores the key and response in a short-lived cache like Redis before processing.
• On a duplicate key, return the cached response without re-running the side effect.
• Set a TTL, usually 24 hours, and document the client retry window.

Connection pooling reuses open database connections across requests.

• It avoids a new TCP connection and TLS handshake on every query.
• Without it, a service under load can exhaust connection limits and add hundreds of ms per request.
• Tune min and max pool sizes from concurrency, the database max_connections, and average query duration.

Confirm the leak, then snapshot the heap to find what is retained.

• Confirm with a heap usage metric that trends up instead of returning to baseline after GC.
• Take heap snapshots over time with --inspect and Chrome DevTools or clinic.js, then diff them.
• Look for unremoved event listeners, closures holding large buffers, and unbounded module-level caches.

A circuit breaker tracks a dependency's error rate and fails fast when it spikes.

• It tracks errors over a rolling window.
• When the error rate crosses a threshold, it opens and calls fail fast without hitting the dependency.
• After a timeout it goes half-open, letting one probe through; success closes it again.
• Apply it to synchronous external calls where slow failures would exhaust thread pools or queues.

A B-tree index gives O(log n) lookups but adds write cost.

• It stores sorted keys in a balanced tree, finding rows in O(log n) instead of a full scan.
• It speeds reads but slows every INSERT, UPDATE, and DELETE because the tree updates too.
• Add one when plans show sequential scans on large tables with selective filters.
• Review unused indexes with pg_stat_user_indexes and drop the dead weight.

CAP says a distributed store guarantees at most two of consistency, availability, and partition tolerance.

• Partitions are unavoidable, so the real choice is CP versus AP.
• CP example: PostgreSQL with synchronous replication.
• AP example: Cassandra or DynamoDB.
• Use it to frame whether a service tolerates stale reads or needs linearizable reads.

Use the expand-contract pattern for zero-downtime schema changes.

• First deploy a migration that adds new columns or tables without removing old ones.
• Deploy app code that writes to both old and new structures.
• Backfill existing data, then deploy a final migration that drops the old structure.
• Avoid locking DDL by using concurrent index builds in PostgreSQL.

Vertical adds resources to one machine; horizontal adds more instances.

• Vertical adds CPU or RAM to one machine: simple but limited and a single point of failure.
• Horizontal adds instances behind a load balancer, requiring stateless apps or externalized state.
• Default to horizontal for stateless API services.
• Accept vertical for managed databases until read replicas or sharding is needed.

Event sourcing stores state as an ordered log of immutable events.

• The current state is derived by replaying events from the start or a snapshot.
• It fits when you need a full audit trail, history replay, or multiple read models.
• Costs are complex read paths, eventual consistency between projections, and more storage.

Use a Redis-backed token bucket or sliding window keyed by client.

• Key it by API key or IP address.
• On each request, atomically decrement and check the limit, returning 429 with Retry-After when exceeded.
• Configure per-key limits for client tiers and expose X-RateLimit-Remaining.
• Consider moving the logic to a gateway layer to keep service code clean.

Find the conflicting locks, then enforce a consistent lock order.

• Query pg_locks and pg_stat_activity or the error log to see who holds and waits on what.
• Deadlocks usually come from acquiring locks in different orders.
• Fix it by acquiring locks in a consistent order, often by sorting resource IDs first.
• Set a reasonable lock_timeout so a stuck transaction fails fast.

Keep transactions local and use sagas across services.

• Design around bounded contexts so each transaction is local to one service.
• For cross-service operations use the saga pattern via choreography events or an orchestrator.
• Accept eventual consistency across service boundaries as the practical reality.
• Design the UX for it, such as a pending state while an async operation completes.

A queue delivers each message to one consumer; pub-sub broadcasts to all subscribers.

• Queue: one consumer takes a message and it is removed, good for distributing work.
• Pub-sub: every current subscriber gets the message, good for broadcasting events.
• Kafka blurs this: consumer groups act like queues, independent groups replay the same log.
• Choose by whether a message is processed once or by many independent systems.

Use stateless JWTs for authentication and middleware checks for authorization.

• Issue a short-lived access token and a longer refresh token on login; send the access token in Authorization.
• Store roles or fine-grained permissions in the DB and check them in middleware before the handler.
• Keep auth logic out of business logic.
• Rotate signing keys, set strict expiry, and use HTTPS to prevent token theft.

Denormalization stores redundant data to avoid expensive JOINs.

• Example: copy a user's display name into the orders table.
• It helps when a read-heavy endpoint hits the same JOIN millions of times.
• The trade-off is propagating updates to copies, adding write complexity and stale-data risk.
• Introduce it only after profiling confirms the JOIN is a real bottleneck.

Cache data that is expensive, changes rarely, and is read far more than written.

• Cache it at the layer closest to the consumer.
• For shared data across instances use Redis with an explicit TTL and invalidation on write.
• Guard against cache stampede with probabilistic early expiry or a mutex on cold cache.
• Keep keys narrow and prefer TTL expiry over event-driven invalidation for simple cases.