Databases 30 min read

Redis Interview Guide: Core Concepts, Caching with Spring Boot, Persistence, Replication, Sentinel and Performance

This comprehensive guide explains what Redis is, its data structures and features, demonstrates how to use Redis as a cache in Spring Boot applications, discusses cache eviction policies, persistence mechanisms, replication, Sentinel high‑availability, and performance characteristics while also covering common interview questions such as cache snowball, penetration and breakdown.

Top Architect
Top Architect
Top Architect
Redis Interview Guide: Core Concepts, Caching with Spring Boot, Persistence, Replication, Sentinel and Performance

Redis is an open‑source, high‑performance, in‑memory key‑value store written in C and licensed under BSD. It can be used as a database, cache, or message broker and supports multiple data types such as strings, hashes, lists, sets, sorted sets, and more.

Key characteristics of Redis include excellent read/write speed due to in‑memory storage, single‑threaded event‑driven architecture with I/O multiplexing, rich data structures, persistence options, master‑slave replication, and support for distributed locks and pub/sub messaging.

Five core data types are:

String – simple key‑value pairs, binary safe, up to 512 MB.

Hash – a map of fields and values, ideal for representing objects.

List – ordered collection implemented as a doubly linked list, useful for queues.

Set – unordered collection of unique strings.

Sorted Set – like a set but each member has a score that determines ordering.

Using Redis as a cache in Spring Boot

Two common approaches are:

Directly using RedisTemplate to read and write objects.

Integrating Spring Cache with Redis, which allows cache annotations such as @Cacheable, @CachePut, and @CacheEvict to manage cache entries automatically.

Example Maven dependencies:

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-data-redis</artifactId>
    </dependency>
    <dependency>
        <groupId>org.apache.commons</groupId>
        <artifactId>commons-pool2</artifactId>
    </dependency>
    <dependency>
        <groupId>org.springframework.session</groupId>
        <artifactId>spring-session-data-redis</artifactId>
    </dependency>
    <!-- other dependencies such as lombok and test starter -->
</dependencies>

Typical application.yml configuration:

server:
  port: 8082
spring:
  cache:
    type: redis
  redis:
    host: 127.0.0.1
    port: 6379
    database: 0
    lettuce:
      pool:
        max-active: 100

Custom RedisCacheConfig to use JSON serialization:

@Configuration
@AutoConfigureAfter(RedisAutoConfiguration.class)
public class RedisCacheConfig {
    @Bean
    public RedisTemplate<String, Serializable> redisCacheTemplate(LettuceConnectionFactory connectionFactory) {
        RedisTemplate<String, Serializable> template = new RedisTemplate<>();
        template.setKeySerializer(new StringRedisSerializer());
        template.setValueSerializer(new GenericJackson2JsonRedisSerializer());
        template.setConnectionFactory(connectionFactory);
        return template;
    }
}

Cache annotations explained: @Cacheable – caches method result based on parameters. @CachePut – always executes method and updates the cache. @CacheEvict – removes cache entries, optionally all entries.

Cache problems

Cache snowball occurs when many keys expire simultaneously, causing a sudden surge of database traffic. Mitigation includes adding random jitter to expiration times or using hot‑data without expiration.

Cache penetration happens when requests query keys that never exist, repeatedly hitting the database. Solutions are request validation, returning null quickly, or using a Bloom filter to pre‑check existence.

Cache breakdown is similar to snowball but focuses on a single hot key that expires, causing a burst of DB queries. Strategies include keeping hot keys permanent, using mutex locks, or employing a “lazy” rebuild with a short lock.

Why Redis is fast

All data resides in memory, giving O(1) access similar to a HashMap.

Simple data structures reduce processing overhead.

Single‑threaded design eliminates context switches and lock contention.

Uses non‑blocking I/O with multiplexing (epoll/kqueue).

Redis vs. Memcached

Redis provides persistence (RDB/AOF) while Memcached is purely in‑memory.

Redis supports multiple data types; Memcached only stores simple strings.

Redis runs its own VM and protocol, offering richer features.

Redis values can be up to 1 GB, whereas Memcached limits values to 1 MB.

Eviction policies (six built‑in strategies): volatile‑lru, allkeys‑lru, volatile‑lfu, allkeys‑lfu, volatile‑random, allkeys‑random, and noeviction. Since Redis 4.0, LFU (least‑frequency‑used) policies are also available.

Persistence mechanisms

Redis offers two main persistence options:

RDB (snapshot) – periodically forks a child process to write the entire dataset to a binary dump.rdb file. It is fast for backups and restores but may lose up to the interval’s worth of data.

AOF (append‑only file) – logs every write command to appendonly.aof. Configurable appendfsync policies ( always, everysec, no) balance durability and performance. AOF files are larger but provide near‑real‑time durability.

Both can be enabled simultaneously; on restart Redis prefers AOF for recovery.

Master‑slave replication

Replication is asynchronous: the master streams write commands to slaves. The process uses PSYNC (partial sync) which supports full sync (initial copy) and incremental sync (replaying commands from a replication backlog). Key concepts include runId, offset, and repl_backlog_size. If a slave falls behind the backlog, a full sync is triggered.

Sentinel for high availability

Sentinel monitors masters and slaves, performs automatic failover, and provides clients with the current master address. Its duties are:

Monitoring – periodic PING and INFO to all known instances.

Notification – alerts administrators via scripts or APIs.

Automatic failover – when a master is marked objectively down (after enough Sentinels agree), a slave is promoted to master and other slaves are re‑configured.

Configuration provider – clients query Sentinels to discover the current master.

The failover algorithm involves subjectively down (SDOWN) detection, quorum agreement, and election of a new master based on replication offset.

Conclusion

The article walks through Redis fundamentals, caching techniques with Spring Boot, performance reasons, eviction policies, persistence options, replication details, and Sentinel high‑availability mechanisms, providing a solid knowledge base for interview preparation.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

performanceSpring BootPersistenceReplicationsentinel
Top Architect
Written by

Top Architect

Top Architect focuses on sharing practical architecture knowledge, covering enterprise, system, website, large‑scale distributed, and high‑availability architectures, plus architecture adjustments using internet technologies. We welcome idea‑driven, sharing‑oriented architects to exchange and learn together.

0 followers
Reader feedback

How this landed with the community

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.