Beyond Caching: How Redis Can Serve as a Full‑Featured Database

Most databases become slow under high concurrency because they frequently interact with disk; to bridge this speed gap, many systems add a cache layer, and Redis, with its excellent performance and rich data structures, has become the de facto distributed cache standard.

However, Redis is far more than just a cache.

Its rich data structures and persistence features (RDB and AOF) allow it to be used as a durable database, powering many internet companies, especially in social, gaming, and live‑streaming domains.

1. Redis Can Handle Storage Work

Redis provides several clustering modes: master‑slave, sentinel, and cluster, satisfying high‑availability needs. It also offers two persistence methods: AOF and RDB, with RDB being the most common.

Using the bgsave command, the master forks a new process to write a snapshot to disk. Because it lacks WAL and checkpoint mechanisms, bgsave cannot provide real‑time backup; a sudden power loss may cause data loss.

Fortunately, Redis is an in‑memory database, so master‑slave synchronization is very fast. With proper cluster maintenance and memory allocation, Redis can maintain a high SLA unless the data center loses power.

Before fully embracing Redis, ensure your business meets the following characteristics:

Targeting C‑end users with data that can be quickly located by user ID, small data sets, and little need for range queries.

Acceptable memory cost for an in‑memory store.

Minimal need for transactional operations.

These conditions are common in social, gaming, live‑streaming, and operational services, making Redis a viable primary store.

2. Redis Application Scenarios

2.1 Basic User Data Storage

Using Redis hash structures enables a flexible schema. Attributes can be stored as JSON within the hash value, and commands like HGET and HMGET retrieve only needed fields.

> HSET user:199929 sex m
> HSET user:199929 age 22
> HGETALL user:199929
1) "sex"
2) "m"
3) "age"
4) "22"

For read‑heavy, write‑light scenarios, HINCRBY can increment numeric fields efficiently.

2.2 Implementing Counters

Redis provides INCRBY for atomic increments, useful for likes, follows, tag fans, comment counts, hotness scores, etc.

> INCRBY feed:e3kk38j4kl:like 1
> INCRBY feed:e3kk38j4kl:like 1
> GET feed:e3kk38j4kl:like
"2"

These operations execute in milliseconds, far faster than traditional DB COUNT queries.

2.3 Leaderboards

Redis zset (sorted set) uses a skip‑list to maintain ordered scores, handling millions of entries with sub‑5 ms response times.

> ZADD sorted:xjjdog:2021-07 55 dog0
> ZADD sorted:xjjdog:2021-07 89 dog1
> ZADD sorted:xjjdog:2021-07 32 dog2
> ZCARD sorted:xjjdog:2021-07
3
> ZREVRANGE sorted:xjjdog:2021-07 0 -10 WITHSCORES
1) "dog1"
2) "89"
3) "dog0"
4) "55"
5) "dog2"
6) "32"

2.4 Friend Relationships

Sets store unique collections such as follow lists, fans, blacklists, etc. ZADD and ZRANK can store timestamps as scores, while SINTER finds mutual friends.

2.5 Active User Counting

Bitmaps efficiently record boolean states for massive user bases.

> SETBIT online:2021-07-23 3876520333 1
> SETBIT online:2021-07-24 3876520333 1
> GETBIT online:2021-07-23 3876520333
1
> BITOP AND active online:2021-07-23 online:2021-07-24
> GETBIT active 3876520333
1

Large IDs should be pre‑processed to avoid excessive memory usage.

2.6 Distributed Locks

A simple lock can be implemented with SET using NX and PX options. Example Java code:

public String lock(String key, int timeOutSecond) {
    for (;;) {
        String stamp = String.valueOf(System.nanoTime());
        boolean exist = redisTemplate.opsForValue().setIfAbsent(key, stamp, timeOutSecond, TimeUnit.SECONDS);
        if (exist) {
            return stamp;
        }
    }
}
public void unlock(String key, String stamp) {
    redisTemplate.execute(script, Arrays.asList(key), stamp);
}

The Lua script for safe unlock:

local stamp = ARGV[1]
local key = KEYS[1]
local current = redis.call("GET",key)
if stamp == current then
    redis.call("DEL",key)
    return "OK"
end

2.7 Distributed Rate Limiting

Simple counters with INCR and EXPIRE provide basic throttling, while Redisson's RRateLimiter offers a smoother sliding‑window algorithm.

incr key
expire key 1

RRateLimiter limiter = redisson.getRateLimiter("xjjdogLimiter");
// initialize once
limiter.trySetRate(RateType.OVERALL, 5, 2, RateIntervalUnit.SECONDS);
// acquire permits (blocks if unavailable)
limiter.acquire(3);

2.8 Message Queues

Lists implement simple queues with LPUSH and RPOP (or blocking BRPOP). Pub/Sub supports broadcast, and Redis 5.0+ adds STREAM for Kafka‑like semantics.

2.9 LBS (Location‑Based Services)

Since Redis 3.2, the GEO family (e.g., GEOADD) enables latitude/longitude storage, distance calculations, and nearby‑user queries.

2.10 Extended Applications

Redisson provides Java client abstractions for many Redis data structures (Set, Map, List, Queue, etc.), turning Redis into a versatile distributed data platform. It can also serve as a configuration center or JWT token store.

3. Challenges of an All‑In‑One Redis Architecture

3.1 High‑Availability Challenges

Redis offers master‑slave, sentinel, and cluster modes. Cluster, while popular, has drawbacks: virtual slots (0‑16383) increase maintenance complexity, slaves cannot serve reads, and batch operations (MGET, HMSET, SUNION) suffer performance penalties. Master‑slave lacks automatic failover; sentinel adds monitoring but is hard to maintain at scale.

3.2 Hot‑Cold Data Separation

Because Redis stores everything in memory, hot‑cold data separation is essential for cost control. Middleware can route cold data to slower, larger stores while keeping hot data in Redis, preserving a uniform API for the application layer.

3.3 Functional Requirements

Modules like RediSearch add full‑text search. Exporting Redis RDB files to big‑data platforms (e.g., Hadoop) enables analytics beyond Redis' native capabilities. RDB becomes a central data‑exchange format for downstream processing.

4. Summary

Redis powers a large portion of modern internet services, especially those with fast, user‑centric data access patterns. Selecting the right tool for the right scenario—Redis for hot, low‑latency data and traditional RDBMS for complex queries or massive historical datasets—maximizes both performance and reliability.