Backend Developer interview questions and answers

I would model posts and comments as resources with noun URLs. GET /posts lists posts with pagination, for example ?limit=20&cursor=abc, and supports filters like ?author=5. POST /posts creates a post and returns 201 Created with the new post. GET /posts/{id} returns one post or 404 if it does not exist. PATCH /posts/{id} updates some fields and DELETE /posts/{id} removes it, returning 204. Comments are nested: GET /posts/{id}/comments and POST /posts/{id}/comments. I would validate input and return 400 with a consistent JSON error body such as { error: { code, message, fields } }. Writes need authentication, so 401 for no token and 403 when the user is not the author. I would also version the API, for example /v1, and document it with OpenAPI.

I start from the data and the queries. If the data is structured and related, like users, orders and payments, and I need joins and ACID transactions, a relational database like PostgreSQL is usually the best default. It also handles JSON columns well, so it covers many semi-structured cases. I would pick NoSQL when the access pattern fits it better: a document store like MongoDB for flexible, nested records read as a whole; a key-value store like Redis for caching and sessions; a wide-column store like Cassandra or DynamoDB for huge write volumes with known key-based queries; or a graph database for relationship-heavy queries. NoSQL often trades joins and strict consistency for easier horizontal scaling. Many real systems use both, for example PostgreSQL as the source of truth and Redis as a cache.

Authentication answers who you are; authorization answers what you can do. For authentication, the user logs in with email and password, I check the password against a bcrypt or Argon2 hash, and then issue either a session cookie (HttpOnly, Secure) or a short-lived JWT with a refresh token. Middleware validates this on each request and attaches the user to the request. If it is missing or invalid, I return 401. For authorization, I check permissions on the server for every protected action, for example role-based access where only admins can delete users, plus ownership checks so a user can edit only their own posts. If the user is known but not allowed, I return 403. I never trust the frontend to hide buttons as the only protection.

The client first resolves the domain through DNS and opens a TCP connection with TLS. The request usually reaches a load balancer or reverse proxy like Nginx, which forwards it to one of the app instances. The framework parses the method, URL, headers and body, then runs middleware such as logging, CORS, rate limiting and authentication. The router matches the URL to a handler. The handler validates input, runs business logic, and reads or writes data in the database or cache, possibly calling other services. It then builds the response with a status code, headers like Content-Type and caching headers, and a JSON body. Error-handling middleware turns exceptions into proper error responses. Finally, the request is logged with its duration and status, and metrics and traces are recorded for monitoring.

An index is a separate data structure, usually a B-tree, that keeps column values sorted with pointers to rows. Instead of a full table scan, the database can seek directly to matching rows, which makes WHERE filters, joins and ORDER BY much faster. The costs are extra disk and memory, and slower writes, because every INSERT, UPDATE and DELETE must also update each index. So I do not index every column. I look at the slow and frequent queries, check them with EXPLAIN or EXPLAIN ANALYZE, and index columns used in filters and joins, especially foreign keys. Columns with high selectivity, like email, benefit most. For queries that filter on several columns I use a composite index with the most commonly filtered column first. Then I confirm with EXPLAIN that the plan really uses the index.

A transaction is a group of database operations that succeed or fail together. ACID describes its guarantees. Atomicity means all or nothing: if anything fails, the whole transaction rolls back. Consistency means the database moves from one valid state to another, so constraints like foreign keys and unique keys still hold. Isolation means concurrent transactions do not see each other's half-finished work; the isolation level, such as read committed or serializable, controls how strict that is. Durability means that once COMMIT returns, the data survives a crash, usually thanks to a write-ahead log. A classic example is a bank transfer: debiting one account and crediting another must happen together, or money disappears. Another is placing an order, where I insert the order rows and decrease stock in one transaction so they never disagree.

They are the three main signals of observability. Logs are records of single events, like "payment failed for order 9". I write them as structured JSON with fields such as level, user id and request id, so I can search and filter them. Metrics are numbers over time, such as request rate, error rate, latency percentiles and queue depth. They are cheap to store and are what I build dashboards and alerts on, for example alerting when p99 latency or the 5xx rate goes above a threshold. Traces follow one request through every service, showing how long each step took, so I can see that a slow request spent most of its time in one database query. I use OpenTelemetry to produce traces and put the trace id in every log line. Then an alert leads me to a trace, and the trace leads me to the exact logs.

I would follow the testing pyramid. First, unit tests for the pure logic, like calculating totals, applying discounts and validating input, with dependencies replaced by fakes. Next, integration tests that run the repository code against a real PostgreSQL in a container, so I know the SQL and constraints work. Then a few API tests that send real HTTP requests to the app and check the full behaviour: 201 with the new order and a Location header for valid input, 400 with clear field errors for bad input, 401 without a token, 403 for another user's resources, and 409 when stock runs out. External services like payments would be mocked or pointed at a sandbox. I make tests independent, with fresh data for each, and run them all in CI on every pull request so bugs are caught before merging.

Docker packages the app with its runtime and dependencies into an image, so the same artifact runs the same way on a laptop, in CI and in production. That removes "works on my machine" problems and makes deployments and rollbacks simple, because you just run a different image tag. It also lets developers start dependencies like PostgreSQL and Redis with one compose file. A good Dockerfile uses a small, pinned base image, and a multi-stage build so build tools do not end up in the final image. I copy the dependency manifests first and install them before copying the source, so that layer stays cached. I add a .dockerignore to skip node_modules and .git. Finally I run the process as a non-root user and pass secrets and configuration through environment variables or a secret manager at runtime, never baking them into the image.

Status codes are grouped by their first digit. 2xx means success: 200 OK for a normal response, 201 Created after creating a resource, and 204 No Content when there is nothing to return, such as after a delete. 3xx is about redirects and caching, like 301 for a permanent move and 304 Not Modified for a valid cached copy. 4xx means the client did something wrong: 400 for bad input, 401 when not authenticated, 403 when authenticated but not allowed, 404 when the resource does not exist, 409 for a conflict like a duplicate, 422 for valid JSON that fails business rules, and 429 for rate limiting. 5xx means the server failed: 500 for an unexpected error, 502 and 504 from gateways, and 503 when temporarily unavailable. Using them correctly matters because clients and proxies decide on retries from them: retrying a 503 makes sense, retrying a 400 does not.

First I would measure, using EXPLAIN and traces, to see if the query can simply be fixed with an index. If it is still expensive and read often, I would use cache-aside with Redis: on a read, check the key; on a miss, run the query, store the result with a TTL, and return it. The key must include everything that changes the result, such as user id, tenant id and query parameters, otherwise one user may see another user data. On writes, I update the database and then delete the related keys, so the next read rebuilds fresh data; the TTL is a safety net. For hot keys I protect against stampedes with a short lock or serving stale while refreshing. For public data I would also use HTTP caching headers or a CDN. I would monitor hit rate and latency.

A direct rename breaks old app instances still running during a rolling deploy, so I use the expand and contract pattern. Step one: add the new column as nullable, which is a fast metadata change in PostgreSQL. Step two: deploy code that writes to both the old and new columns but still reads the old one. Step three: backfill existing rows in small batches so I do not hold long locks or create huge transactions. Step four: deploy code that reads from the new column, and verify the data matches. Step five: stop writing the old column. Finally, in a later release, drop the old column. Every step is backward compatible, so I can roll back the app at any point. I also check lock timeouts and run the migration first on a staging copy of production data.

Old mobile apps can stay installed for years, so I treat the API as a contract. Most changes should be additive: adding optional fields or new endpoints does not break clients that ignore unknown fields. Breaking changes, like renaming or removing a field or changing its type, go into a new version, for example /v2/orders or a version header, while v1 keeps working. I keep both versions on the same business logic with a thin mapping layer. Then I announce a deprecation timeline, add Deprecation and Sunset headers, and track how many requests still hit v1, per client version. Only when traffic is near zero, or the app forces an update, do I remove it. I use OpenAPI docs and contract tests in CI to catch accidental breaking changes before release.

First I confirm the problem with metrics: look at p50, p95 and p99 latency for that endpoint, the error rate, and exactly when it started. Then I check what changed around that time: a deploy, a traffic spike, a big data import or a dependency slowdown. Next I use distributed tracing, such as OpenTelemetry with Jaeger or Datadog, to see which part of the request takes the time: database, an external API call or our own code. If it is the database, I check the slow query log and run EXPLAIN ANALYZE to find full scans, missing indexes, N+1 patterns or lock waits. If it is CPU, I profile. After fixing, for example adding an index or batching queries, I verify the latency graph has recovered and add an alert on p95 so we catch it earlier next time.

The checkout request should only do what must be done before replying: validate, save the order and charge payment. Then it pushes a job, such as SendInvoice with the order id, to a queue like SQS, RabbitMQ or BullMQ on Redis, and returns. To avoid losing the job if the app crashes after commit, I would use an outbox table. Separate worker processes consume jobs, generate the PDF, store it in object storage and send the email. Workers scale independently from the API. Failed jobs retry with exponential backoff, and after several failures go to a dead-letter queue for investigation. Because queues usually deliver at least once, jobs must be idempotent, for example by marking the invoice as sent. I monitor queue depth, job age and failure rate, and alert when they grow.

First I would decide the key: usually the API key or user id, with IP limits for anonymous traffic, and stricter limits on expensive endpoints like search or login. For the algorithm I prefer a token bucket, which allows short bursts but enforces an average rate, or a sliding window counter, which avoids the double burst at fixed window edges. Because there are many servers, the counters must be shared, so I would keep them in Redis and update them atomically with a Lua script or INCR plus EXPIRE. When a client is over the limit I return 429 with a Retry-After header, and on every response headers showing the limit and remaining quota. I would also decide what happens if Redis is down; for most APIs I fail open with a local in-memory limit. Coarse limits can also live at the API gateway or CDN to stop floods early.

I would go through the OWASP API Security Top 10. The first thing is authorization on every object: can user A fetch user B's order by changing an id? Then authentication: strong password hashing, short-lived tokens, and protection against brute force on login. Next, input: every request validated with a schema, only allowlisted fields saved to prevent mass assignment, and all SQL parameterized. I would check transport and browser settings: HTTPS only, HSTS, a strict CORS allowlist, and cookies with HttpOnly, Secure and SameSite. Then secrets: none in the code or images, stored in a secret manager, with database users on least privilege. I would also confirm rate limits, safe error messages without stack traces, audit logs for sensitive actions, and dependency and container scanning in CI. Finally, any feature that fetches URLs is checked for SSRF.

First, security: I verify the HMAC signature over the raw request body using a constant-time comparison, and reject events with old timestamps to stop replays. Then I store the event and return 200 quickly, because providers time out and retry if the handler is slow. The real processing happens in a background worker that reads from a queue or the stored events table. Providers deliver at least once, so I deduplicate using the event id with a unique constraint, which makes processing idempotent. Events can also arrive out of order, for example "refunded" before "paid", so I either compare timestamps or versions, or fetch the latest object state from the provider API before updating. Finally, I alert when processing fails, keep failed events for replay, and run a periodic reconciliation job that compares our records with the provider's in case a webhook was missed entirely.

They model messaging differently. Kafka is a distributed append-only log split into partitions. Messages stay for a retention period, and each consumer group tracks its own offset, so many independent services can read the same events and replay history. Ordering is kept per partition, and throughput is very high. I pick Kafka for event streaming, like order events consumed by billing, analytics and search, or for change data capture. RabbitMQ is a traditional broker: producers publish to exchanges, which route messages into queues, and a message is removed once a consumer acks it. It offers flexible routing, per-message acknowledgement, delayed retries and priorities, which makes it great for work queues like sending emails or resizing images. Both are usually at-least-once, so consumers must be idempotent. For simple needs, a managed queue like SQS can be enough.

I would not stream gigabytes through the API servers. Instead, the client asks the API to start an upload; the API checks permissions and limits, creates a record with status "pending" in the database, and returns presigned URLs for object storage such as S3. For big files I use multipart upload, so the client sends parts in parallel and can resume after a network failure by retrying only the missing parts. When all parts are done, the client calls a complete endpoint, or a storage event notifies us, and the API verifies size and content type. Then a job goes onto a queue for malware scanning and processing like transcoding or thumbnails, and the status changes to "ready". Files are served through a CDN with signed URLs if they are private. This keeps API servers light and lets storage handle the heavy traffic.

At 100 million links a month, writes are around 40 per second on average, but redirects may be 100 times more, so the system is read-heavy. Over five years that is about 6 billion links; with around 500 bytes each, a few terabytes. For IDs, 7 base62 characters give about 3.5 trillion combinations. I would use a distributed ID generator, for example ranges of counter values handed to each server, then base62 encode, which avoids collisions. Random IDs also work with a unique constraint and retry. Storage is a simple key-value lookup by short code, so DynamoDB, Cassandra or sharded PostgreSQL fit. Redirects go through Redis and a CDN since popular links are hot. I would use 302 if we need click analytics, because 301 is cached by browsers. Click events go to Kafka and are aggregated asynchronously. I would add rate limiting and malware URL checks.

Over an unreliable network you cannot guarantee a message is delivered exactly once: if an acknowledgement is lost, the sender must choose between retrying, which risks duplicates, or not, which risks loss. So we aim for effectively-once: at-least-once delivery combined with idempotent processing. Each event carries a unique id. The consumer, in the same database transaction as its business change, inserts that id into a processed_events table with a unique constraint; a duplicate fails the insert and is skipped. On the producer side, the transactional outbox ensures the event is published if and only if the business data was committed. Kafka offers idempotent producers and transactions for read-process-write inside Kafka, but side effects in external systems still need idempotency keys, for example when calling the payment provider. I also plan for ordering per key, retries and a dead-letter queue.

Before adding complexity, I would fix slow queries and indexes, add PgBouncer for connection pooling, and scale the machine up, because that solves many problems cheaply. For reads, I would add caching for hot data and read replicas. Replicas are asynchronous, so there is replication lag: a user may update their profile and then read old data from a replica. I handle that by routing reads after a write, or critical reads, to the primary. For writes, a single primary is the limit. I could partition large tables by time, and archive old data. If that is not enough, I would shard by a key such as tenant_id or user_id that keeps most queries on one shard and spreads load evenly. Sharding makes cross-shard joins, transactions, unique constraints and rebalancing hard, and a bad key creates hot shards, so I would consider managed distributed databases too.

There is no single ACID transaction across three databases, and two-phase commit is slow, couples services and blocks when the coordinator fails, so I would use a saga. A saga is a series of local transactions, each with a compensating action. For example: Order service creates the order as PENDING, Inventory reserves stock, Payment charges the card, then the order becomes CONFIRMED. If payment fails, Inventory releases the reservation and the order becomes CANCELLED. With choreography, services react to each other events, which is simple for few steps but hard to follow. With orchestration, a central orchestrator, for example using Temporal or a state machine, tells each service what to do, which is easier to monitor. Each step publishes events via an outbox and must be idempotent. The system is eventually consistent, so the UI shows states like pending, and timeouts trigger compensation.

There are three main models. Shared tables with a tenant_id column is cheapest and simplest to migrate, but a missing WHERE clause can leak data, and big tenants can be noisy neighbours. Schema per tenant gives more isolation but migrations across thousands of schemas are slow. Database per tenant gives the strongest isolation and easy per-tenant backups, which enterprise or compliance customers may require, but costs more to run. Many products use shared tables by default and dedicated databases for large customers. For safety, I would never rely on each developer remembering the filter. The tenant id comes from the verified auth token, not the request body, and is enforced centrally, for example with PostgreSQL row-level security using a session variable, or a repository layer that always adds it. Cache keys, file storage paths and search indexes must include the tenant, and I would add automated tests that try cross-tenant access.

Products call one API with a template id, recipient and data, plus an idempotency key. The API validates the request, stores it, and publishes it to a durable queue like Kafka or SQS, so producers are never blocked by slow providers. A routing step loads user preferences and opt-outs, applies quiet hours and deduplication, renders the template, and puts the message on a per-channel queue. I keep separate high and low priority queues so a marketing blast of five million emails cannot delay one-time passwords. Channel workers call providers such as an email service, SMS gateway, APNs and FCM, respecting each provider's rate limits, retrying with backoff, failing over to a backup provider, and sending permanent failures to a dead-letter queue. Provider callbacks update delivery status in a store built for heavy writes. Metrics on queue lag, send rate and failure rate per provider drive alerts.

First I would ask what problem we are solving: many teams blocking each other on releases, one part needing very different scaling, or just a messy codebase. Messy code is not fixed by adding a network; a modular monolith with clear internal boundaries may be enough, especially for a small team. If we go ahead, I would map business domains and data ownership to find boundaries, then use the strangler fig pattern: put a gateway in front, extract one well-bounded area like notifications or billing, route its traffic to the new service, and repeat. Each service must own its database; shared tables bring back the coupling. Cross-service consistency then needs events, an outbox, and sagas instead of transactions. Before the first extraction I would invest in CI/CD, tracing, centralised logs and API contracts, because debugging distributed failures without them is very painful.

Clients keep a WebSocket open to a fleet of stateless gateway servers behind a load balancer. A presence store in Redis maps each online user to their gateway and expires entries via heartbeats. When a user sends a message, it carries a client-generated id for deduplication. A chat service validates membership, assigns an ordered per-conversation id, and writes it to a store partitioned by conversation id, such as Cassandra, ScyllaDB or sharded PostgreSQL, then acks the sender. It publishes the message through pub/sub, for example Redis or NATS, to the gateways of online members. Offline members get a push notification. On reconnect, clients ask for everything after the last id they saw, so missed messages are never lost. For very large groups I would fan out on read instead of pushing to every member, and I would rate limit senders to prevent spam.

During the incident I focus on stopping the damage, not on the root cause: turn off the feature that calls the dependency with a flag, shed non-critical traffic, or roll back if a deploy triggered it, while keeping a timeline in the incident channel. The usual mechanism is that callers wait on the slow service with long timeouts, so their threads and connection pools fill up, and then their callers do the same. Retries at every layer multiply the load. Afterwards I would add short timeouts with propagated deadlines, circuit breakers that fail fast, and bulkheads, meaning separate pools per dependency so one cannot starve the others. Retries would be limited to one layer, with backoff, jitter and a retry budget. I would add load shedding and degraded responses, such as cached data. Finally, a blameless postmortem with owned action items and alerts on dependency latency.

I would use double-entry bookkeeping. Every movement of money is a journal transaction with two or more entries, debits and credits, that must sum to zero, so money is never created or lost by a bug. Entries are append-only and never updated; a mistake is fixed with a reversing entry, which gives a full audit trail. Amounts are stored as integers in minor units, like cents, together with a currency code. Each request carries an idempotency key with a unique constraint so retries do not double charge. To stop overspending, I write the entries and update a cached balance in one database transaction, locking the account row or using a version check, and enforcing that the balance cannot go below zero. The cached balance can always be rebuilt from entries. Daily reconciliation compares the ledger with bank and provider reports.