Backend Developer Interview Questions & Answers (with Model Answers)

Model Answer

I start from the consumer's use cases and design resource-oriented, predictable endpoints with consistent naming and error formats. I version the API so I can evolve it without breaking existing clients, and I prefer additive changes over breaking ones. I document the contract clearly, often with an OpenAPI spec, and validate inputs strictly while being lenient about what I accept where safe. I also think about pagination, rate limiting, and idempotency from the start.

Model Answer

An endpoint was timing out under load and I traced it to an N+1 query pattern using our APM tooling. Each request fired hundreds of small queries inside a loop. I rewrote it to use a single batched query with a join and added an index on the filtered column. Response time dropped from seconds to tens of milliseconds and the timeouts disappeared.

Model Answer

I first ask whether strong consistency is truly required or whether eventual consistency is acceptable, because that drives the design. For cross-service operations I avoid distributed transactions and prefer patterns like the saga with compensating actions, or an outbox to publish events reliably. I make operations idempotent so retries are safe. I monitor for divergence and build reconciliation jobs where needed.

Model Answer

I distinguish between expected errors, which I handle gracefully with clear responses, and unexpected ones, which I log with enough context to debug. I emit structured logs, metrics, and traces so I can answer who, what, and where during an incident. I set up alerts on symptoms users feel, like error rate and latency, rather than noisy internal metrics. This means I find out about problems before customers do.

Model Answer

I apply defence in depth, starting with authentication and authorisation on every endpoint and never trusting client input. I validate and sanitise inputs to prevent injection, use parameterised queries, and store secrets in a vault rather than in code. I enforce least privilege on database and service accounts and keep dependencies patched. I also add rate limiting and audit logging for sensitive actions.

ACID stands for Atomicity, Consistency, Isolation, and Durability. Atomicity means a transaction fully completes or fully rolls back, consistency keeps the database in a valid state, isolation prevents concurrent transactions from interfering, and durability guarantees committed data survives crashes. Together they make multi-step operations safe under concurrency and failure.

A message queue decouples producer and consumer so the producer does not block on the consumer's availability or speed. It is useful for asynchronous work, smoothing load spikes, and retrying failed processing without losing the request. A direct call is better when you need an immediate response and tight coupling is acceptable.

Pessimistic locking locks a record when read so others cannot modify it until released, which prevents conflicts but can hurt throughput. Optimistic locking assumes conflicts are rare, checks a version number at write time, and fails the update if the record changed. Optimistic locking scales better for read-heavy systems with infrequent contention.

Caching stores frequently accessed data closer to the consumer to reduce latency and load on the source. The main risks are serving stale data and cache invalidation complexity, which is famously hard. Good strategies include setting sensible TTLs, invalidating on write, and choosing between cache-aside and write-through based on consistency needs.

An idempotent operation produces the same result whether it is performed once or many times. It matters because networks are unreliable and clients retry, so a non-idempotent payment or create endpoint could double-charge or duplicate records. Using idempotency keys lets the server detect and de-duplicate retried requests safely.

I ran a migration that added a non-null column without a default on a large table, which locked it and stalled writes. I aborted the migration to release the lock and restored service quickly. I rewrote it to add the column nullable, backfill in batches, then add the constraint. I added a checklist for safe migrations that the whole team now follows.

A marketing campaign drove ten times normal traffic and our service started shedding requests. I quickly scaled out the stateless instances and added a short-lived cache in front of the hottest read endpoint. I also enabled rate limiting to protect the database. The service stabilised and we later load-tested for that scenario so it would not surprise us again.

We needed to integrate a payment provider whose docs were incomplete and partly wrong. I built a small sandbox harness to probe the real behaviour and captured the actual responses. I wrapped the provider behind our own interface so quirks were isolated in one adapter. The integration shipped on time and the adapter made later provider changes painless.

Our service was over-provisioned and the database was the biggest line item. I analysed query patterns, added missing indexes, and moved cold data to cheaper storage. I right-sized the compute based on real utilisation metrics rather than guesses. Monthly costs dropped by roughly a third with no impact on latency.