Backend Developer Interview Questions: Reliability and Trade-Offs

Explain what must remain true when requests fail, overlap, or arrive twice. Backend interview answers become more useful when they name the data invariant, the failure case, and the test that would demonstrate correctness.

The following questions are original practice scenarios. They are not an employer's question bank or complete production architecture specifications.

1. Two database writes must succeed together. What do you do?

Start by identifying the invariant. In a fictional inventory service, creating a reservation and updating the available quantity must not leave a half-completed state.

PostgreSQL's transaction tutorial explains grouping database operations into an all-or-nothing transaction. Describe the transaction boundary, what happens on an error, and how concurrent requests are controlled. Merely saying "use a transaction" does not explain whether your isolation level or locking strategy prevents overselling.

Follow-up: Does that transaction also roll back an email or an external payment request? Not automatically. Those effects cross a boundary. Discuss a durable work record and retry/reconciliation approach appropriate to the system rather than claiming a local database transaction covers every service.

2. A client retries after a timeout. How do you avoid duplicate work?

A timeout does not prove the server did nothing. The operation may have completed before the response was lost.

Explain how the same logical request is identified, how concurrent duplicates are handled, and how the stored result is returned. A key that changes on every retry cannot identify retries of the original operation.

Stripe's idempotency documentation provides a concrete provider-specific example: results are associated with an idempotency key, with documented parameter and retention behavior. Do not assume every API has the same semantics.

Test a lost response after completion, two simultaneous requests with the same key, and a reused key with different input. State what your design guarantees and for how long.

3. A user changes an ID in the URL. What prevents unauthorized access?

Distinguish authentication from authorization. Knowing who the caller is does not establish that they can access every record.

Describe an ownership or permission check on the server for the requested resource. Include list, read, update, and delete paths rather than protecting only the visible page. Do not rely on a hidden button or an unpredictable identifier as the permission model.

For an interview example, test a legitimate user requesting another user's object and a user whose permissions changed. Explain how the application avoids leaking sensitive data in error details or logs.

4. An endpoint becomes slow as data grows. Where do you start?

Measure where time is spent before adding a cache. Inspect representative queries, result sizes, repeated database calls, and external dependencies. Compare the query plan and workload, not just a development database with a few rows.

If you propose an index, discuss the query it supports and the write/storage trade-off. If you propose caching, explain freshness requirements and invalidation. A fast stale answer is not automatically a correct answer.

5. A background job runs twice. Is that necessarily a bug?

Ask about the delivery and retry guarantees. Design the handler so repeated delivery does not create an unintended duplicate business effect. Record progress durably and distinguish a failed attempt from completed work whose acknowledgment was lost.

An illustrative answer should include how you would observe failures, recover incomplete work, and detect repeated processing. Avoid claiming "exactly once" without defining the boundary and supporting mechanism.

Prepare using the technical interview guide, then choose one scenario and walk through a failure timeline. The sequence of events often reveals gaps that a diagram of only the successful path misses.