Backend Engineer Interview Questions India 2026: APIs, Databases, and System Design

Backend engineer interview topics:

1. REST API design: HTTP methods, status codes, API versioning, pagination (cursor vs offset), rate limiting, request validation, error response format

1. Database design: schema design for common entities (users, orders, products, sessions), normalisation vs denormalisation, indexing strategy, transactions, connection pooling

1. Authentication and security: JWT (stateless token: header.payload.signature), OAuth 2.0 (authorization code flow), API key authentication, SQL injection prevention (parameterised queries), CORS

1. Performance: caching (Redis), async processing (Kafka, RabbitMQ, SQS), CDN for static assets, horizontal scaling

1. System design: basic distributed systems (load balancer, horizontal scaling, database replication, eventual vs strong consistency)

Interview structure by tier:

• IT services (TCS, Infosys, Wipro): mostly OOP, DBMS, OS theory, 1-2 SQL queries
• Mid-tier product (Freshworks, Zoho, Mphasis): API design, database, 1-2 system design questions
• Top product (Flipkart, Swiggy, CRED): deep API design, database design, 1 full system design
• FAANG India: 2 coding rounds + 1-2 system design rounds + behavioural

API design interview questions:

1. 'Design the API for a URL shortener': POST /api/shorten {longurl} returns {shorturl, shortcode} GET /{shortcode} returns 302 redirect to long_url Discussion: URL expiry (TTL), analytics (click count via async increment), custom codes (user-supplied alias), rate limiting.

2. 'What HTTP status code should you use when a user tries to access a resource they do not own?' 403 Forbidden: the user is authenticated but does not have permission to access this specific resource. Contrast with 401 Unauthorized (not authenticated) and 404 Not Found (which can be used to hide that a resource exists when the user is not authorised to know it does).

3. 'How do you implement rate limiting in a backend API?' Token bucket algorithm: each user has a bucket that refills at a fixed rate; each request consumes one token; if the bucket is empty, return 429. Implemented with Redis: INCR key with TTL for sliding window, or a Lua script for atomic token bucket operations.

4. 'What is idempotency and why does it matter for payment APIs?' Idempotency: the same request produces the same result no matter how many times it is sent. Critical for payments because network failures can cause a client to retry. Implementation: unique idempotency-key per request (UUID from client); server checks if key was seen before; if yes, return the cached response without charging again.

5. 'How would you design the error response format for an API?' Consistent structure: {error: {code: 'VALIDATION_ERROR', message: 'Email is required', field: 'email', requestId: 'abc123'}}. Always include: machine-readable error code, human-readable message, requestId for debugging, field name for validation errors.

Database design questions:

1. 'Design the database schema for a ride-sharing app (like Ola/Uber)': Key tables: - users (id, name, phone, email, usertype: driver or rider) - drivers (id, userid FK, vehicleid FK, currentlocation lat/long, status: available/ontrip/offline) - vehicles (id, driverid FK, make, model, licenseplate, type: auto/mini/sedan/xl) - rides (id, riderid FK, driverid FK, pickuplocation, dropofflocation, status: requested/accepted/ongoing/completed/cancelled, fare, starttime, endtime) - payments (id, rideid FK, amount, method, status, transaction_id)

2. 'When would you use a NoSQL database instead of SQL?' NoSQL when: flexible or rapidly evolving schema, horizontal write scaling (MongoDB sharding, DynamoDB partitioning), time-series or event data (Cassandra, InfluxDB), or when data is hierarchical and joins are never needed (document model). SQL when: data has clear relationships (foreign keys matter), ACID transactions are required, complex querying patterns (multiple joins, GROUP BY), or strong consistency is non-negotiable.

3. 'What is connection pooling and why do you need it?' Creating a new database connection per request is expensive: TCP handshake + authentication takes 5-20ms per connection. A connection pool maintains a set of reused connections (typically pool size = cores * 2 + spindle count for traditional RDBMS). Libraries: HikariCP (Java), pgBouncer (PostgreSQL), SQLAlchemy (Python).

Backend engineer system design questions by experience:

0-2 years:

• 'Design the backend API for a todo app' (REST CRUD, JWT auth, SQLite or PostgreSQL, basic schema)
• 'What happens when you type a URL in the browser?' (DNS lookup, TCP handshake, HTTP request, server processing, HTTP response, browser rendering)

2-4 years:

• 'Design a URL shortener' (API + base62 encoding + Redis cache for hot URLs + read replica)
• 'Design a rate limiter' (token bucket + Redis for distributed rate limiting across multiple servers)

4-7 years:

• 'Design a notification service that sends 10M push notifications per day' (fanout: read user preferences; Kafka or SQS for async delivery; exponential backoff for delivery failures; separate worker pools for different notification types)
• 'Design a ride-sharing matching system' (geospatial indexing, driver location update rate, matching algorithm)

7+ years:

• Full distributed system design (consistent hashing, distributed consensus, data sharding, multi-region replication, CAP theorem trade-offs)

Authentication questions:

1. 'How does JWT authentication work?' JWT (JSON Web Token): three parts separated by dots: header.payload.signature. Header: algorithm (HS256 or RS256) and token type. Payload: claims (user ID, role, expiry time). Signature: HMAC of header + payload using the server's secret key. Server creates the token at login; client stores it (localStorage or httpOnly cookie); client sends it in Authorization: Bearer <token> header on every request; server verifies signature and extracts user from payload without a database query (stateless). Risk: JWTs cannot be invalidated before expiry (you cannot 'log out' a JWT). Solution: short-lived access tokens (15 min) + long-lived refresh tokens (7 days) stored in httpOnly cookies.

2. 'What is OAuth 2.0 and how does it work?' OAuth 2.0: an authorization framework that allows a user to grant a third-party application limited access to their account on another service without sharing their password. Authorization code flow (most secure, used for server-side apps): user clicks 'Login with Google' -> redirected to Google consent screen -> user grants permission -> Google returns an authorization code to your callback URL -> your server exchanges the code for an access token (server-to-server, never exposed to the browser) -> use the access token to call Google APIs or retrieve the user's profile.

3. 'What is CORS and how do you configure it?' CORS (Cross-Origin Resource Sharing): a browser security mechanism that restricts web pages from making requests to a different domain than the one that served the web page. The server must respond with Access-Control-Allow-Origin header specifying which origins are permitted. Never use '*' in production for APIs with authentication.