Backend Development 19 min read

Comprehensive Guide to Common Backend Interview Questions: Locks, I/O Models, Redis, MySQL, and Data Structures

This article compiles typical backend interview questions covering spin locks versus regular locks, various I/O models, cache‑related pitfalls, Redis eviction strategies, MySQL locking and logging mechanisms, and the principles of skip lists and other fundamental data structures.

Java Captain
Java Captain
Java Captain
Comprehensive Guide to Common Backend Interview Questions: Locks, I/O Models, Redis, MySQL, and Data Structures

The author recounts a challenging backend interview experience and presents a collection of frequently asked questions that help candidates identify knowledge gaps and study relevant materials.

1. Operating‑system related

Spin locks differ from ordinary locks in that a thread repeatedly checks the lock (busy‑waiting) instead of sleeping, which avoids context switches but can waste CPU cycles if the lock is held for long.

Common issues with spin locks include high CPU usage when a thread holds the lock indefinitely.

Unlike mutexes that put a thread to sleep, spin locks keep the thread active, making them more efficient when the wait time is expected to be short.

Implementation of a spin lock in Java:
public class SpinLock {
    private AtomicReference
cas = new AtomicReference
();
    public void lock() {
        Thread current = Thread.currentThread();
        // use CAS
        while (!cas.compareAndSet(null, current)) {
            // DO
        }
    }
    public void unlock() {
        Thread current = Thread.currentThread();
        cas.compareAndSet(current, null);
    }
}

The lock method uses a CAS loop; if thread A holds the lock, thread B will keep looping until A releases it.

Advantages of spin locks:

They run in user space, avoiding thread‑state switches and thus have lower latency.

They do not cause the thread to enter kernel mode, eliminating costly context switches.

2. I/O models

Blocking I/O : The calling thread is suspended until the kernel finishes the operation, which can make the application appear frozen.

Non‑blocking I/O : The kernel returns immediately, allowing the thread to continue processing other tasks.

I/O multiplexing (e.g., select, epoll) lets a program monitor multiple descriptors and handle events concurrently.

Signal‑driven I/O : The process receives a SIGIO signal when data is ready, enabling asynchronous handling without blocking.

Asynchronous I/O : The application requests an operation and the kernel notifies it upon completion.

Differences between select and epoll :

Select returns an array of all file descriptors; the application must scan the whole array, uses level‑triggered notifications, copies data between user and kernel space each call, and is limited to ~1024 descriptors.

Epoll maintains a red‑black tree and a ready‑list, avoiding full scans and copying, and scales to large numbers of connections.

3. Cache problems

Cache penetration : Malicious requests query non‑existent keys, causing repeated backend lookups and overload.

Mitigation: cache empty results briefly, filter impossible keys, or use a bitmap to pre‑filter.

Cache avalanche : Simultaneous expiration of many keys overwhelms the backend.

Mitigation: stagger expiration times, use locking or queues to limit concurrent DB reads, employ a two‑level cache (A1 short‑term, A2 long‑term).

4. Redis related

Redis eviction policies (controlled by maxmemory ) include:

volatile‑lru – evict least‑recently‑used keys with an expiration.

allkeys‑lru – evict least‑recently‑used keys regardless of expiration.

volatile‑random – randomly evict an expired key.

allkeys‑random – randomly evict any key.

noeviction – reject writes when memory limit is reached.

Deletion strategies:

Timed deletion – a scheduled task removes expired keys.

Lazy deletion – keys are removed when accessed and found expired.

Periodic deletion – a background process scans and deletes expired keys.

5. MySQL

Lock types: InnoDB uses row‑level locks based on index entries; without an index it falls back to table locks. Non‑primary index locks are also taken.

Gap locks define a range between index entries and are used to prevent phantom reads.

B+‑tree node splitting occurs when a node exceeds capacity, propagating splits up to the root, increasing tree height.

Transaction logs:

Redo log – records physical changes for crash recovery, ensuring durability.

Undo log – stores previous versions for rollback and MVCC reads.

Binlog modes:

ROW – logs each row change.

STATEMENT – logs the SQL statement.

MIXED – chooses ROW or STATEMENT per statement.

Replication flow: master writes to binlog, slave reads it into a relay log, then an SQL thread parses and applies the changes.

6. Basic data structures

LRU caches can suffer when many one‑time items evict frequently used data; solutions include using a two‑level cache or adjusting eviction policies.

Circular linked list: the last node points back to the head, forming a loop; termination is detected when a node’s next pointer equals the head.

Skip list: layered linked lists provide O(log n) search by promoting a subset of nodes to higher levels using a random function.

Compared with binary search trees, skip lists avoid worst‑case O(n) degeneration and are simpler to implement than red‑black trees, which require rotations to maintain balance.

7. Summary

Key takeaways: interview expectations are high, code written in an IDE differs from handwritten code, review each interview, master fundamental computer‑science concepts, and persist regardless of background.
backendRedisMySQLinterviewLocksIODataStructures
Java Captain
Written by

Java Captain

Focused on Java technologies: SSM, the Spring ecosystem, microservices, MySQL, MyCat, clustering, distributed systems, middleware, Linux, networking, multithreading; occasionally covers DevOps tools like Jenkins, Nexus, Docker, ELK; shares practical tech insights and is dedicated to full‑stack Java development.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.