Backend Interview — The Complete Guide

Node.js runs JavaScript on the server using V8 and libuv. The single-threaded event loop is the core concept — understand it deeply and you'll answer 80% of Node interview questions.

🔥 Event Loop — Node vs Browser

Both use an event loop, but Node's has phases: timers → pending callbacks → idle/prepare → poll → check → close. The browser's loop is simpler: task → microtasks → render. The key difference: Node has setImmediate (check phase) and process.nextTick (runs before any phase, even before microtasks).

// Node.js execution order
console.log("1 — sync");

setTimeout(() => console.log("2 — timer phase"), 0);
setImmediate(() => console.log("3 — check phase"));

process.nextTick(() => console.log("4 — nextTick"));
Promise.resolve().then(() => console.log("5 — microtask"));

console.log("6 — sync");

// Output: 1, 6, 4, 5, 2, 3
// nextTick > microtask > timer > immediate (from main module)
// Note: timer vs immediate order can vary inside I/O callbacks

Non-blocking I/O

Node delegates I/O operations (file reads, network calls, DB queries) to libuv's thread pool or OS-level async APIs. The main thread never blocks — it registers a callback and moves on. When the I/O completes, the callback is queued for the event loop. This is why Node handles thousands of concurrent connections with a single thread.

Streams & Buffers

Streams process data in chunks instead of loading everything into memory. A 2GB file? Stream it — don't readFileSync it. Four types: Readable, Writable, Duplex, Transform. Buffers are fixed-size chunks of raw binary data — the building blocks streams operate on.

import { createReadStream, createWriteStream } from "fs";
import { pipeline } from "stream/promises";
import { createGzip } from "zlib";

// Stream a file through gzip compression to output
await pipeline(
  createReadStream("input.log"),    // Readable
  createGzip(),                      // Transform
  createWriteStream("output.log.gz") // Writable
);
// Memory usage stays constant regardless of file size

Clustering & Scaling

Node.js is single-threaded, so it can only utilize one CPU core per process. The cluster module allows us to fork multiple worker processes, each running its own event loop and sharing the same server port. This helps utilize all CPU cores. However, in production, tools like PM2 or Kubernetes are preferred for better process management and scalability.

In Node.js clustering, the master (primary) process is responsible for creating and managing worker processes, while the workers handle actual incoming requests.

📝 Quick Revision

Common Interview Questions

API design questions test whether you can build interfaces that are predictable, scalable, and pleasant to consume. Think like the developer who has to use your API.

REST Principles

• Resources as nouns: /users, /orders/123 — not /getUser
• HTTP verbs for actions: GET (read), POST (create), PUT (replace), PATCH (update), DELETE (remove)
• Stateless: each request contains all info needed — no server-side session dependency
• Consistent responses: always return the same shape — { data, error, meta }

🔥 Idempotency — Must Know

An idempotent operation produces the same result no matter how many times you call it. GET, PUT, DELETE are idempotent. POST is not. This matters for retries — if a network timeout occurs, can you safely retry? With idempotent endpoints, yes.
GET, PUT, and DELETE are idempotent because repeating them does not change the final state of the server, whereas POST is not idempotent since each request creates a new resource.

Pagination Strategies

Versioning

API versioning is the practice of managing changes to an API by introducing versions so that existing clients continue to work without breaking.

URL path versioning (/api/v1/users) is the most common and explicit. Header versioning (Accept: application/vnd.api.v2+json) is cleaner but harder to test in a browser. Pick one and be consistent. In interviews, mention that you version to avoid breaking existing clients when the API evolves.

Error Handling Standards

// Consistent error response shape
{
  "error": {
    "code": "VALIDATION_ERROR",
    "message": "Email is required",
    "details": [
      { "field": "email", "message": "must not be empty" }
    ]
  },
  "meta": { "requestId": "req_abc123", "timestamp": "2026-04-01T10:00:00Z" }
}

// Use proper HTTP status codes:
// 400 — bad input (client's fault)
// 401 — not authenticated
// 403 — not authorized
// 404 — resource not found
// 409 — conflict (duplicate)
// 422 — unprocessable entity (valid JSON but invalid data)
// 429 — rate limited
// 500 — server error (our fault)

📝 Quick Revision

Auth is asked in almost every backend interview. Know the difference between authentication (who are you?) and authorization (what can you do?), and the trade-offs between JWT and sessions.

🔥 JWT vs Sessions — Must Know

OAuth 2.0 Basics

OAuth lets users grant third-party apps limited access without sharing passwords. The Authorization Code flow (with PKCE) is the standard for web apps: redirect to provider → user consents → provider redirects back with a code → your server exchanges the code for tokens. Know the roles: Resource Owner (user), Client (your app), Authorization Server (Google/GitHub), Resource Server (API).

RBAC (Role-Based Access Control)

Assign roles (admin, editor, viewer) to users. Each role has a set of permissions. Check permissions at the API layer, not just the UI. Common pattern: middleware that checks req.user.role against the required permission for the endpoint.

📝 Quick Revision

Why Rate Limiting?

• Prevent abuse (brute-force login, scraping, DDoS)
• Protect downstream services from overload
• Ensure fair usage across clients
• Control costs (API calls to third-party services)

🔥 Algorithms

Where to Implement

// Sliding window counter with Redis
async function isRateLimited(userId: string, limit: number, windowSec: number): Promise<boolean> {
  const key = `rate:${userId}`;
  const now = Date.now();
  const windowStart = now - windowSec * 1000;

  // Remove old entries, add current, count
  const multi = redis.multi();
  multi.zremrangebyscore(key, 0, windowStart);  // remove expired
  multi.zadd(key, now, `${now}`);               // add current request
  multi.zcard(key);                              // count in window
  multi.expire(key, windowSec);                  // auto-cleanup

  const results = await multi.exec();
  const count = results[2][1] as number;
  return count > limit;
}

📝 Quick Revision

Database questions separate backend devs who write queries from those who understand why queries are fast or slow. PostgreSQL knowledge is highly valued at product companies.

🔥 Indexing — When and When Not

An index is a separate data structure (B-tree by default in Postgres) that speeds up lookups. Without an index, Postgres does a sequential scan — reads every row. With an index on the WHERE column, it does an index scan — jumps directly to matching rows.

-- Check if your query uses an index
EXPLAIN ANALYZE SELECT * FROM orders WHERE user_id = 42;

-- Create an index
CREATE INDEX idx_orders_user_id ON orders(user_id);

-- Composite index (order matters!)
CREATE INDEX idx_orders_user_date ON orders(user_id, created_at);
-- Works for: WHERE user_id = 42
-- Works for: WHERE user_id = 42 AND created_at > '2026-01-01'
-- Does NOT work for: WHERE created_at > '2026-01-01' (leftmost prefix rule)

Joins vs Denormalization

🔥 Transactions & Isolation Levels

A transaction groups multiple operations into an atomic unit — all succeed or all fail. Isolation levels control what concurrent transactions can see.

Connection Pooling

Each Postgres connection uses ~10MB of memory. Opening a new connection per request is expensive (~50ms). A connection pool (PgBouncer, built-in pool in your ORM) maintains a set of reusable connections. Set pool size to ~(CPU cores × 2) + disk spindles. Too many connections = context switching overhead.

📝 Quick Revision

Caching is the single biggest performance lever in backend systems. The hard part isn't adding a cache — it's invalidating it correctly.

Redis Basics

Redis is an in-memory key-value store. Sub-millisecond reads. Supports strings, hashes, lists, sets, sorted sets, and streams. Common uses: caching, session storage, rate limiting, pub/sub, leaderboards. Data is in memory — use persistence (RDB/AOF) or accept data loss on restart.

🔥 Cache Invalidation — VERY IMPORTANT

// Cache-aside pattern (most common)
async function getUser(id: string) {
  // 1. Check cache
  const cached = await redis.get(`user:${id}`);
  if (cached) return JSON.parse(cached);

  // 2. Cache miss — read from DB
  const user = await db.query("SELECT * FROM users WHERE id = $1", [id]);

  // 3. Populate cache with TTL
  await redis.set(`user:${id}`, JSON.stringify(user), "EX", 300); // 5 min TTL

  return user;
}

// On update — invalidate (don't update) the cache
async function updateUser(id: string, data: Partial<User>) {
  await db.query("UPDATE users SET ... WHERE id = $1", [id]);
  await redis.del(`user:${id}`); // next read will repopulate
}

📝 Quick Revision

Backend system design tests whether you can think beyond a single server. These concepts come up in every senior-level interview.

Horizontal vs Vertical Scaling

Load Balancing

A load balancer distributes incoming requests across multiple servers. Algorithms: Round Robin (simple rotation), Least Connections (send to least busy), IP Hash (sticky sessions), Weighted (more traffic to stronger servers). In production: Nginx, HAProxy, AWS ALB, or cloud load balancers.

Designing Scalable APIs

• Stateless servers — no in-memory sessions. Store state in Redis/DB.
• Database read replicas — write to primary, read from replicas.
• Caching layer — Redis between app and DB for hot data.
• Async processing — offload heavy work to queues (email, reports, image processing).
• CDN for static assets — serve images, JS, CSS from edge servers.

📝 Quick Revision

Not everything needs to happen in the request-response cycle. Async processing is how production systems handle email, notifications, reports, and any work that can be deferred.

When to Use Async Jobs

• Sending emails/SMS/push notifications
• Generating reports or PDFs
• Image/video processing
• Syncing data to third-party services
• Any work that takes > 500ms and the user doesn't need the result immediately

Kafka vs RabbitMQ

Retry Mechanisms & Dead Letter Queues

Jobs fail. Network timeouts, service outages, bugs. A retry strategy handles transient failures: retry 3 times with exponential backoff (1s, 4s, 16s). After max retries, move the message to a Dead Letter Queue (DLQ) for manual inspection. Never retry indefinitely — you'll amplify the problem.

📝 Quick Revision

A. Core Architecture

How Spring Boot Works Internally

Spring Boot is an opinionated layer on top of Spring Framework. When you run @SpringBootApplication, three things happen: (1) @Configuration — marks the class as a bean definition source, (2) @EnableAutoConfiguration — triggers auto-config based on classpath, (3) @ComponentScan — scans the package for beans. Spring Boot reads META-INF/spring.factories (or spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports) to find auto-configuration classes.

🔥 Auto-Configuration — How It Decides

Auto-configuration uses @Conditional annotations to decide what to configure. For example, @ConditionalOnClass(DataSource.class) means "only configure this if DataSource is on the classpath." @ConditionalOnMissingBean means "only create this bean if the developer hasn't defined their own." This is why adding spring-boot-starter-data-jpa to your dependencies automatically configures a DataSource, EntityManager, and transaction manager — without any XML.

🔥 Dependency Injection — Deep Understanding

DI is not "Spring creates objects for you." It's inversion of control: instead of a class creating its dependencies, the container injects them. This enables testability (inject mocks), loose coupling (depend on interfaces, not implementations), and lifecycle management (singleton by default).

// Constructor injection (preferred — immutable, testable)
@Service
public class OrderService {
    private final OrderRepository repo;
    private final PaymentGateway gateway;

    // Spring auto-injects because there's only one constructor
    public OrderService(OrderRepository repo, PaymentGateway gateway) {
        this.repo = repo;
        this.gateway = gateway;
    }
}

// Why constructor injection > field injection (@Autowired on field):
// 1. Fields can be final (immutable)
// 2. Dependencies are explicit in the constructor signature
// 3. Easy to test — just pass mocks in the constructor
// 4. Fails fast if a dependency is missing (compile-time vs runtime)

Bean Lifecycle

Instantiate → Populate properties (DI) → @PostConstruct → Ready to use → @PreDestroy → Garbage collected. Scopes: singleton (default — one instance per container), prototype (new instance per injection), request/session (web scopes).

B. Application Design

Layered Architecture

Controller (HTTP layer — receives requests, returns responses) → Service (business logic — orchestrates operations) → Repository (data access — talks to DB). Each layer depends only on the layer below. Controllers never call repositories directly. Services never return HTTP responses.

DTO vs Entity Separation

Entities are JPA-managed objects mapped to DB tables. DTOs are plain objects for API input/output. Never expose entities directly in API responses — you'll leak internal fields, create tight coupling to the DB schema, and risk lazy-loading exceptions. Map between them in the service layer.

C. REST API Implementation

🔥 Request Handling Flow (DispatcherServlet)

Every request flows through: Filter chain → DispatcherServlet → HandlerMapping (finds the right controller method) → HandlerAdapter (invokes it) → Controller → ViewResolver (for MVC) or direct response (for REST). Interceptors run before/after the handler. Filters run before/after the entire servlet.

Interceptors vs Filters

Exception Handling (@ControllerAdvice)

@RestControllerAdvice
public class GlobalExceptionHandler {

    @ExceptionHandler(ResourceNotFoundException.class)
    @ResponseStatus(HttpStatus.NOT_FOUND)
    public ErrorResponse handleNotFound(ResourceNotFoundException ex) {
        return new ErrorResponse("NOT_FOUND", ex.getMessage());
    }

    @ExceptionHandler(MethodArgumentNotValidException.class)
    @ResponseStatus(HttpStatus.BAD_REQUEST)
    public ErrorResponse handleValidation(MethodArgumentNotValidException ex) {
        List<FieldError> errors = ex.getBindingResult().getFieldErrors()
            .stream()
            .map(f -> new FieldError(f.getField(), f.getDefaultMessage()))
            .toList();
        return new ErrorResponse("VALIDATION_ERROR", "Invalid input", errors);
    }

    @ExceptionHandler(Exception.class)
    @ResponseStatus(HttpStatus.INTERNAL_SERVER_ERROR)
    public ErrorResponse handleGeneric(Exception ex) {
        log.error("Unhandled exception", ex);
        return new ErrorResponse("INTERNAL_ERROR", "Something went wrong");
    }
}

D. Data Layer (JPA / Hibernate)

🔥 Lazy vs Eager Loading — VERY IMPORTANT

🔥 N+1 Query Problem — MUST KNOW

You fetch 100 orders. Each order has a lazy-loaded user. When you access order.getUser() for each order, Hibernate fires 100 separate SELECT queries (1 for orders + 100 for users = N+1). This destroys performance.

// ❌ N+1 problem — 101 queries for 100 orders
List<Order> orders = orderRepo.findAll();
orders.forEach(o -> System.out.println(o.getUser().getName())); // 100 extra queries!

// ✅ Fix 1: JOIN FETCH in JPQL
@Query("SELECT o FROM Order o JOIN FETCH o.user")
List<Order> findAllWithUsers();

// ✅ Fix 2: @EntityGraph
@EntityGraph(attributePaths = {"user"})
List<Order> findAll();

// ✅ Fix 3: @BatchSize on the entity (Hibernate-specific)
@BatchSize(size = 50) // loads users in batches of 50 instead of 1-by-1
@OneToMany(mappedBy = "order")
private List<OrderItem> items;

🔥 @Transactional Deep Dive

@Transactional creates a proxy that wraps the method in a DB transaction. Key gotchas: (1) only works on public methods, (2) self-invocation bypasses the proxy (calling another @Transactional method from the same class doesn't create a new transaction), (3) checked exceptions don't trigger rollback by default — use @Transactional(rollbackFor = Exception.class).

E. Performance & Optimization

• Connection pooling (HikariCP) — Spring Boot's default. Set maximum-pool-size to ~(CPU cores × 2). Monitor with /actuator/metrics.
• Caching with Redis — @Cacheable("users") on service methods. Use @CacheEvict on writes. Configure RedisCacheManager with TTL.
• Reducing DB calls — batch inserts (saveAll), projection queries (select only needed columns), avoid N+1 with fetch joins.
• Pagination — use Pageable parameter in repository methods. Return Page<DTO>, not List<Entity>.

F. Security

🔥 Spring Security — Filter Chain

Spring Security is a chain of servlet filters. Each filter handles one concern: CORS → CSRF → Authentication → Authorization → Exception handling. The SecurityFilterChain bean configures which endpoints require auth, which are public, and how authentication works (JWT, session, OAuth).

@Configuration
@EnableWebSecurity
public class SecurityConfig {

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        return http
            .csrf(csrf -> csrf.disable()) // disable for stateless APIs
            .sessionManagement(s -> s.sessionCreationPolicy(STATELESS))
            .authorizeHttpRequests(auth -> auth
                .requestMatchers("/api/auth/**").permitAll()
                .requestMatchers("/api/admin/**").hasRole("ADMIN")
                .anyRequest().authenticated()
            )
            .addFilterBefore(jwtFilter, UsernamePasswordAuthenticationFilter.class)
            .build();
    }
}

// JWT Filter — runs before Spring's auth filter
// 1. Extract token from Authorization header
// 2. Validate token (signature, expiry)
// 3. Set SecurityContext with user details
// 4. Chain continues — Spring Security checks roles/permissions

G. Advanced Topics

• AOP (Aspect-Oriented Programming) — cross-cutting concerns (logging, timing, security) without modifying business code. @Aspect + @Around/@Before/@After. Spring Security and @Transactional are built on AOP.
• Custom annotations — combine @Target, @Retention with an AOP aspect to create reusable behaviors like @RateLimit or @Audit.
• Profiles — @Profile("dev") / @Profile("prod") to swap beans per environment. Use application-dev.yml for env-specific config.
• Microservices role — Spring Boot is the standard for building individual microservices. Each service is a standalone Boot app with its own DB, deployed independently. Spring Cloud adds service discovery, config server, circuit breakers.

📝 Spring Boot Quick Revision

Node.js (1-5)

API & Auth (6-10)

Database (11-16)

Caching & System Design (17-22)

Spring Boot (23-30)

Backend interviews reward structured thinking. Here's the framework that works for both coding and system design questions.

The STAR-T Framework for Backend

Node.js

API & Auth

Database

Caching

Spring Boot

System Design