Backend Engineering Interview Questions for 2026

REST uses multiple endpoints with fixed data shapes (GET /users, GET /users/1/posts). GraphQL uses a single endpoint where clients specify exactly what data they need in a query. REST can over-fetch or under-fetch data; GraphQL solves this but adds complexity with query parsing, schema management, and N+1 query problems. REST is simpler for CRUD; GraphQL excels with complex, nested data and multiple client types.

Common strategies: URL path versioning (/v1/users, /v2/users) is explicit and easy to understand. Header versioning (Accept: application/vnd.api.v2+json) keeps URLs clean. Query parameter versioning (?version=2) is simple but less RESTful. The best approach depends on your consumers: public APIs benefit from URL versioning for clarity; internal APIs may use header versioning for flexibility.

The N+1 problem occurs when a query fetches a list of items (1 query) and then makes individual queries for each item's related data (N queries). In GraphQL, this happens because resolvers execute independently. Solutions include DataLoader (batches and caches database calls within a single request), query lookahead to optimize SQL joins, and using persistent query patterns.

Start with a monolith and extract microservices when you have clear domain boundaries, teams that need to deploy independently, services with different scaling requirements, or components needing different technology stacks. Microservices add significant operational complexity (networking, monitoring, distributed tracing, data consistency). Most startups should start monolithic and decompose after reaching product-market fit.

Synchronous: REST or gRPC for request-response patterns. gRPC is faster (Protocol Buffers, HTTP/2, streaming) and better for internal communication. Asynchronous: message queues (Kafka, RabbitMQ) for event-driven communication, decoupling services and handling traffic spikes. Choose synchronous when you need an immediate response; asynchronous when the caller does not need to wait or when building event-driven architectures.

The saga pattern manages distributed transactions across microservices where traditional ACID transactions are impossible. Each service executes its local transaction and publishes an event. If any step fails, compensating transactions undo previous steps. Two types: choreography (services react to events, simpler but harder to track) and orchestration (a central coordinator manages the flow, easier to understand and debug).

An API gateway is a single entry point for client requests that routes to appropriate microservices. It handles cross-cutting concerns: authentication, rate limiting, request/response transformation, SSL termination, load balancing, circuit breaking, and API composition. Examples include Kong, AWS API Gateway, and NGINX. Without a gateway, clients must know about every service and handle these concerns individually.

Authentication verifies who you are (identity). Authorization determines what you can do (permissions). Authentication happens first: login with credentials, receive a token. Authorization happens on each request: check if the authenticated user has permission for the requested action. Common models: RBAC (role-based), ABAC (attribute-based), and ACL (access control lists).

OAuth 2.0 delegates authorization without sharing credentials. The Authorization Code grant (with PKCE) is the standard for web and mobile apps: the client redirects to the auth server, the user authenticates, receives an authorization code, and exchanges it for tokens. Client Credentials grant is for machine-to-machine. Implicit grant is deprecated. Always use PKCE with public clients to prevent code interception attacks.

A JWT (JSON Web Token) has three Base64-encoded parts: header (algorithm, token type), payload (claims like user ID, expiration, roles), and signature (verifies integrity). JWTs are stateless (no server-side storage) but cannot be revoked until they expire. Security considerations: use short expiration times, store in httpOnly cookies (not localStorage), validate all claims, use RS256 over HS256 for distributed systems, and implement refresh token rotation.

Session-based: server stores session data, sends a session ID cookie. Easy to revoke (delete from store) but requires sticky sessions or shared storage (Redis) across servers. Token-based (JWT): stateless, no server storage, works across domains and services. Cannot be easily revoked and increases payload size. Use sessions for traditional web apps; tokens for SPAs, mobile apps, and microservices. Many systems use both: JWT for service-to-service and sessions for user-facing apps.

Cache-aside (lazy loading): application checks cache first, loads from DB on miss, writes to cache. Write-through: writes to cache and DB simultaneously (strong consistency, slower writes). Write-behind (write-back): writes to cache immediately, asynchronously syncs to DB (fast writes, risk of data loss). Read-through: cache loads from DB on miss (simpler application code). Choose based on your consistency requirements and read/write ratio.

Cache invalidation removes or updates stale cached data when the source data changes. It is hard because: you must track all cached copies across multiple layers (application, CDN, browser), race conditions can cause stale data, and invalidation at scale introduces latency. Strategies include TTL-based expiration, event-driven invalidation (publish an event when data changes), and versioned keys. The two hardest problems in CS: cache invalidation, naming things, and off-by-one errors.

A CDN (Content Delivery Network) caches content at edge servers geographically close to users, reducing latency and origin server load. CDNs handle static assets (images, CSS, JS), but modern CDNs also cache API responses and run edge compute (Cloudflare Workers, Lambda@Edge). Use a CDN when: you serve users globally, have high traffic, or need DDoS protection. Configure cache headers (Cache-Control, ETag) carefully to balance freshness and performance.

A message queue decouples producers (senders) from consumers (receivers), enabling asynchronous processing. Use message queues for: background job processing (email sending, image resizing), smoothing traffic spikes (buffer requests during peak load), event-driven architectures, and cross-service communication in microservices. Message queues improve resilience (if a consumer is down, messages wait) and scalability (add more consumers to increase throughput).

Kafka is a distributed log: messages are persisted, ordered within partitions, and can be replayed. It excels at high throughput, event streaming, and event sourcing. RabbitMQ is a traditional message broker: supports complex routing (exchanges, bindings), message acknowledgment, and priority queues. Choose Kafka for event streaming, log aggregation, and high-throughput scenarios. Choose RabbitMQ for task queues, complex routing, and when message ordering across queues is not critical.

True exactly-once is extremely difficult in distributed systems. Practical approaches: at-least-once delivery with idempotent consumers (use idempotency keys to detect and skip duplicate processing), Kafka transactions for exactly-once within Kafka, and the outbox pattern (write events to an outbox table in the same DB transaction, then publish asynchronously). Design consumers to be idempotent: processing the same message twice should produce the same result.

Use nouns for resources (/users, /orders), HTTP methods for actions (GET, POST, PUT, PATCH, DELETE). Return appropriate status codes (201 Created, 404 Not Found, 422 Unprocessable Entity). Support pagination (cursor-based for large datasets), filtering, and sorting. Use consistent error response format. Version your API. Implement rate limiting and return rate limit headers. Document with OpenAPI/Swagger. Design for idempotency (PUT is idempotent, POST is not).

Offset-based (?page=3&limit=20): simple but slow for deep pages (database must skip rows) and inconsistent with concurrent inserts/deletes. Cursor-based (?cursor=abc123&limit=20): uses an opaque cursor (encoded ID or timestamp) for the next page. Consistent and performant regardless of page depth. Keyset pagination is similar but uses a visible column value. Use cursor-based for feeds and large datasets; offset-based only for small, static datasets.

Rate limiting restricts the number of requests a client can make in a time window, protecting against abuse and ensuring fair resource usage. Algorithms: fixed window (simple, burst-prone), sliding window (smooth, more accurate), token bucket (allows controlled bursts), leaky bucket (constant rate). Implement with Redis (INCR with TTL for fixed window, sorted sets for sliding window). Return 429 Too Many Requests with Retry-After and rate limit headers (X-RateLimit-Remaining).