Comprehensive Backend Interview Guide: MySQL Indexes, Redis Architecture, Java SpringBoot Auto‑Configuration, and JVM Memory Management

The article begins by noting that small‑company backend interviews often focus on a concise set of core topics, yet some interviews can be as extensive as those at large tech firms, covering around 30 questions.

MySQL

From a data‑structure perspective, MySQL commonly uses B+Tree, HASH, and Full‑Text indexes. Different storage engines support different index types; InnoDB (the default since MySQL 5.5) uses B+Tree indexes, while MyISAM uses non‑clustered indexes.

The B+Tree index stores data only in leaf nodes, forming a doubly linked list for efficient range queries. Compared with binary trees, B+Tree reduces tree height, minimizing disk I/O operations.

Key differences between InnoDB and MyISAM include transaction support (InnoDB supports, MyISAM does not), index structure (clustered vs. non‑clustered), lock granularity (row‑level vs. table‑level), and count(*) performance.

IN and EXISTS Keywords

Both IN and EXISTS handle subqueries, but they differ in semantics and performance. IN checks if a value is within a list or subquery result, returning TRUE or FALSE, while EXISTS simply tests for the existence of any row in the subquery.

SELECT column_name(s)
FROM table_name
WHERE column_name IN (value1, value2, ...);

SELECT column_name(s)
FROM table_name
WHERE EXISTS (SELECT column_name FROM another_table WHERE condition);

Generally, EXISTS performs better on large subqueries because it stops scanning after finding the first match.

Transaction ACID Properties

Atomicity – all operations succeed or all are rolled back.

Consistency – data remains in a valid state before and after the transaction.

Isolation – concurrent transactions do not interfere with each other.

Durability – once committed, changes survive system failures.

InnoDB ensures these via redo logs (durability), undo logs (atomicity), MVCC or locks (isolation), and the combination of all three for consistency.

Redis

Redis processes commands in a single thread (client request → parse → data read/write → response), which simplifies concurrency control. Since Redis 6.0, multiple I/O threads can handle network I/O to improve throughput, while command execution remains single‑threaded.

Persistence is achieved through AOF (Append‑Only File) and RDB snapshots. AOF logs every write command; three sync strategies are always , everysec , and no . RDB creates binary snapshots at intervals, offering faster recovery but possible data loss between snapshots.

// Enable I/O threads for read requests
io-threads-do-reads yes

// Set number of I/O threads (N‑1 additional threads)
io-threads 4

Redis can also serve as a message queue (Pub/Sub, List with LPUSH/BLPOP ) and implement distributed locks using SET key value NX PX ttl with Lua scripts for atomic unlock.

SET lock_key unique_value NX PX 10000

if redis.call("get", KEYS[1]) == ARGV[1] then
  return redis.call("del", KEYS[1])
else
  return 0
end

Java & SpringBoot

SpringBoot auto‑configuration relies on @EnableAutoConfiguration , which scans META-INF/spring.factories for classes implementing AutoConfiguration . The AutoConfigurationImportSelector loads candidate configurations, filters them based on @Conditional annotations, sorts them, and imports the resulting classes.

public class AutoConfigurationImportSelector implements DeferredImportSelector {
    @Override
    public String[] selectImports(AnnotationMetadata metadata) {
        List
configurations = getCandidateConfigurations(metadata, attributes);
        configurations = filter(configurations, metadata, attributes);
        sort(configurations, metadata, attributes);
        return StringUtils.toStringArray(configurations);
    }
}

Common SpringBoot starters include spring-boot-starter-web , spring-boot-starter-security , mybatis-spring-boot-starter , spring-boot-starter-data-redis , and spring-boot-starter-test .

JVM Memory and Class Loading

The JVM memory areas consist of the program counter, Java stacks, native stacks, heap, metaspace, and direct memory. The heap is divided into Young Generation (Eden + Survivor spaces) and Old Generation, with optional large‑object spaces in G1.

Class loading follows the parent‑delegation model: Bootstrap → Extension → System → Custom loaders. The process includes loading, linking (verification, preparation, resolution), and initialization (executing <clinit> ).

Garbage Collection

GC determines object reachability from GC Roots (stack references, static fields, JNI references). Algorithms include Mark‑Sweep, Copying, Mark‑Compact, and generational collection (young vs. old). Mark‑Sweep suffers from fragmentation; Copying avoids fragmentation but halves usable memory; Mark‑Compact moves live objects to eliminate gaps.

Reference counting is rarely used due to inability to handle cyclic references.